エンジニア組織を強くするための本を出版しました。
Qiitaでエンジニアリングに関する様々なコミュニケーションの問題やその解決策について書いてきました。そのエッセンスをこの度書籍として出版しました。

エンジニアリング組織論への招待
～不確実性に向き合う思考と組織のリファクタリング

この書籍では、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングやその間のコミュニケーションに関連する現象を説明しています。

デメテルの法則
別名「最小知識の法則」。デメテルは豊穣の女神で、アスペクト指向などの研究であった「デメテルプロジェクト」に由来。
基本的な考え方は、オブジェクトが自分以外（サブコンポーネントを含む）の構造やプロパティに対して持つ仮定を最小限にするべきだという点です。

簡単に言うと、オブジェクトの「メンバーのプロパティやメソッド」を直接操作しないようにするということです。

js
Sao chép mã
// デメテルの法則に違反している
console.log(aStudent.class.grade)

// デメテルの法則に違反していない
console.log(aStudent.getGrade())
この法則は、サブコンポーネントに関する知識を持たずに実装することを推奨します。

ヴィルトの法則
「ソフトウェアは、ハードウェアが高速化するより急速に低速化する」という経験則。
計算資源が豊富になると、フレームワークなどが進化し、ハードウェアが進歩してもソフトウェアの速度はあまり変わらないという現象が見られます。

ブルックスの法則
「遅れているソフトウェアプロジェクトに要員を追加すると、プロジェクトがさらに遅れる」という経験則。
この背景としては、「プロジェクトへの習熟に時間がかかる」や「コミュニケーションコストの増大」などが挙げられます。

参加する https://cto.skysolution.com/our-team/

コンウェイの法則
「システムを設計する組織は、その組織のコミュニケーション構造を反映した設計を生み出す」という原則。
組織構造がバグの再現率に寄与するという研究結果もあります。

ホフスタッターの法則
「いつでも予測以上の時間がかかるものである — ホフスタッターの法則を計算に入れても。」
予測において、自己言及的な見積もりに関する法則です。

驚き最小の原則
インタフェースにおいて、矛盾や不明瞭な点があるとき、最も自然に思える動作（驚きが少ないもの）を選ぶべきだという考え方。

ボーイスカウトの規則
ボーイスカウトが来る前よりも帰った後の方が山をきれいにするという規則に由来し、ソフトウェア開発においては「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」といった意味です。

YAGNI
"You ain't gonna need it"（必要にならないよ）という意味。XPにおける格言で、必要になるまで実装しないという考え方です。

DRY
"Don't Repeat Yourself"（繰り返しを避けよ）という意味。
システム内の変更が、論理的に関連のない他の部分に影響しないようにすることを目指します。

KISS
"Keep it simple, stupid"（シンプルにしろ）という意味。
シンプルさが重要で、余計な複雑さを避けるべきという原則です。

SOLID
オブジェクト指向設計の原則をまとめた言葉です。

頭文字略語コンセプト
S SRP Single Responsibility Principle（単一責務の原則）
「クラスを変更する理由は一つでなければならない」
O OCP Open/Closed Principle（開放閉鎖の原則）
「クラスは拡張に対して開き、修正に対して閉じていなければならない」
L LSP Liskov Substitution Principle（リスコフの置換原則）
「派生型はその基本型と置換可能でなければならない」
I ISP Interface Segregation Principle（インターフェース分離の原則）
「クライアントが利用しないメソッドへの依存を強制してはならない」
D DIP Dependency Inversion Principle（依存性逆転の原則）
「上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。」