世の中にはxxの法則や、xxの原則といったものが沢山ありすぎて、Podcastや会話の中で突然現れると 何それとなること多いですよね。と言うことで自分の知っているものをまとめてみます。
ブルックスの法則
遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである Adding manpower to a late software project makes it later.
「銀の弾丸などない」と共に「人月の神話」の中で語られた有名な法則。
デスマになってから人を大量投入しても、その人たちがパフォーマンスを出せるまでに時間と教育コストがかかるし、人が増えた分コミュニケーションコストも上がって余計に遅くなるという話。
途中から採算度外視で何でもいいから終わらせろモードになるの良くありました。
プロマネならみんな知っているはずなのに、でもやっちゃうお約束芸。
マーフィーの法則
昔、嘉門達夫が歌にするほど流行った奴。懐かしい。
マーフィーの法則と行っても沢山あるみたいだけど、1番有名なのはこれ。
失敗する可能性のあるものは、失敗する。
If anything can go wrong, it will.
失敗する余地を残しているものは必ず失敗するので、失敗しようしても出来ないような「仕掛け」を作ることが必要なんだろうな。
コンウェイの法則
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
ソフトウェアの構造は、それを開発する組織の構造がそのまま反映されると言う、ネガティブな文脈で語られることが多い法則。
それを逆手にとって、DevOpsするため運用・開発を同じ組織にしたり、小さなチームを作ってマイクロサービスにすると言うのが「逆コンウェイ戦略」
パーキンソンの法則
仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。 Work expands so as to fill the time available for its completion.
余裕があるスケジュールを引いても前倒しで終わることは少なく、時間一杯まで使ってしまうことが多いので各タスクのバッファは控えめに、それとは別にプロジェクトバッファを設けるとかはやっている。
ハリンリッヒの法則
1つの重大事故の背後には29の軽微な事故がある。その背景には300の異常が存在する
「ヒヤリハット」を管理をして事前に防げば重大な事故を防げると言うもの。
ランスの法則
うまくいっている事は手を入れるな
If it ain’t broke don’t fix it.
その労力をうまく言っていないことに注ぎましょう。
90対90の法則
コードの最初の90%が開発時間の90%を占める。残りの10%がさらに90%を占める
ninety-ninety rule
進捗が90％から永遠に上がらない問題。
KISSの法則
「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）
これは現場でよく使う。シンプルは正義。
割れ窓の法則
建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になって、やがて他の窓もまもなく全て壊される
確か、自分は「達人プログラマー」で知った気がします。
ソフトウェア開発に当てはめると、IDEの警告やTypoを無視すると誰もその状態がおかしいことだと感じなくなりより重大な問題が起きやすくなるのは実感としてあります。
自転車置場の議論 (bikeshed discussion)
「瑣末なことほど議論が紛糾する現象」
確か、rebuild.fmで「bikeshed」と言うのを聞いて（最初は聞き取れなかった）調べた記憶があります。
簡単な機能のコードのレビューだったり些細なコーディングスタイルに関することは白熱するのに、難しい機能のコードレビューがあっさり終わったりするのはよくある話ですね。
ハンロンの剃刀
無能で十分説明されることに悪意を見出すな
Never attribute to malice that which is adequately explained by stupidity.
これも最近良く聞く。大抵のことに悪意はないので考えすぎは良くないということ。
おわりに
有名なものはとりあえず知っておくと、自分の引き出しが増えて他の人との意識を合わせるのに便利だし発表スライドを作る際などにも役にたちそうです。 他にも沢山あるので、気が向いたら追記します。