開発では、なぜか「あるあるの状況」とそれにより「あるあるの結果」にでくわす。 備忘録として、それらの法則をまとめます。
「これは〇〇の法則だね」・「〇〇の法則になりそうだから、こうしておこう」といった会話に使えたらいいな。
ブルックスの法則
ブルックスの法則（ブルックスのほうそく）はフレデリック・ブルックスによって提唱された、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。 これは1975年に出版された著書 "The Mythical Man-Month"（邦題：『人月の神話』[1]）に登場した。
ブルックスの法則はなぜ起こる？
- 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる。
- 人員の投下は、チーム内のコミュニケーションコストを増大させる。
- タスクの分解可能性には限界がある。
ブルックスの法則に陥らないために
- プロジェクト全体を小規模のグループが担当できるサイズに分ける。
- そもそもの遅れの原因を追求する。
コンウェイの法則
組織がシステムを設計すると、その設計には、自らのコミュニケーション構造が反映されてしまうという設計に関する格言です。 小規模な組織は、モノシリックなシステムを作り、組織がチームで分割されている場合は、小さなシステム(マイクロサービス)を多数作りがちになります。 この、「組織体制」が「アーキテクチャ」に影響を与えるというのが、この法則の肝になります。 逆に、「アーキテクチャ」を先に決めて「組織体制」を決める逆コンウェイの法則という考え方になります。
コンウェイの法則はなぜ起こる？
組織内のコミュニケーションの結果が設計に直結しているため、コミュニケーションが効率的に行われる構造がそのまま設計に反映されてしまう。
コンウェイの法則に陥らないために
コンウェイの法則は、適切に発現すると開発効率が向上するので、コンウェイの法則に従った「組織作り」や「サービスの分割」を行うべきだと考えています。
パーキンソンの法則
パーキンソンの法則は、2つの法則から構成されています。 第1法則は仕事の量について、第2法則はインプットとアウトプットに関するものである。
- 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
- 支出の額は、収入の額に達するまで膨張する
パーキンソンの法則第1の法則
仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
例えば、開発現場で下記のようなことは起きていないだろうか？ あるタスクを「1時間の作業」と「1時間のバッファ」という時間構成で見積したとする。 するとなぜか、当初の見積もりにない完成度を高める仕事を無意識にして、バッファを食い潰し、2時間でタスクが終わらせていた。
ちなみに私はある！
パーキンソンの法則第2の法則
支出の額は、収入の額に達するまで膨張する
もらったらもらった分だけ使ってしまう、人間だもの…ちなみに私は使ってしまう！
パソコンで考えると、メモリが8Gから16Gに増えたとしたら動作は早くなるはずだ。 しかし、そうはならず、内部で動くアプリケーションのメモリ使用量が増え、動作は早くならない…
パーキンソンの法則はなぜ起こる？
人間は、一度与えられた資源(時間・お金等)は、「全て使ってもいい」or「ある程度までは使ってもいいか」or「使い切ることに意味がある」と認識してしまうからか…？
パーキンソンの法則に陥らないために
- バッファは積まない
- 「作成する作業」と「完成度を上げる作業」は分ける
マーフィーの法則
マーフィーの法則は、任意の特徴をもつ、いくつかの経験則を総称した法則である。 主な特徴は下記の通りである。
- ユーモラスである
- 哀愁がある
- 必ずしも事実とは異なる また、特徴を満たす法則はいくらでも見つけることができるので、今もどこかで日々増えていると言われる。
例えば、下記のような法則が有名である。
- 「失敗する余地があるなら、失敗する」
- 「落としたトーストがバターを塗った面を下にして着地する確率は、カーペットの値段に比例する」
特に開発現場では下記のような例があげられる。
- バックアップする直前にクラッシュ
- 保存ボタンを押すとクラッシュ
- 新しい手法は別の新しい問題を生む
ハインリッヒの法則
ハインリッヒの法則とは、事故発生についての経験則である。 事故が発生したときに下記の法則が成り立つと言われている。
- 重大事故: 人が死傷する重大事故が1件発生した。
- 軽微事故: 重大事故には至らなかったが、軽微な事故が29件発生している。
- 回避された事故: 事故には至らなかった異常が300件発生している。 ハインリッヒの法則