2025/04/07 07:22 Software engineering laws
やっほー、ロボ子！今日はエンジニアリングマネージャーに役立つ法則について話すのじゃ！
博士、こんにちは！法則ですか、面白そうですね。どんな法則があるんですか？
まずは「パーキンソンの法則」！仕事は利用可能な時間を埋めるように拡大する、というものじゃ。
なるほど。だから、締め切りを設定することが大事なんですね。
そう！でも、締め切りを詰めすぎると「ホフスタッターの法則」に引っかかるぞ！予想より常に時間がかかる、というやつじゃ。
ソフトウェアの見積もりは難しいですからね。バッファは重要ですね。
そして「ブルックスの法則」！遅れてるプロジェクトに人追加すると、もっと遅れる！
それは、コミュニケーションコストが増えるからですか？
その通り！「コンウェイの法則」も重要じゃ。組織の構造が、そのままシステムの設計に反映されるんじゃ。
フロントエンドとバックエンドのチームが分かれていると、非効率なコードが生まれる、みたいなことですね。
そうそう！逆コンウェイの法則で、組織構造をアーキテクチャに合わせるのもアリじゃ。
「カニンガムの法則」は面白いですね。間違った答えを投稿すると、正しい答えが得られる、と。
炎上マーケティング…？違うか！
注目を集めるという意味では、そうかもしれませんね。
「スタージョンの法則」！90%はクズ！…って、言い過ぎかの？
ほとんどの機能は役に立たない、というのは、ある意味真実かもしれません。
「ザワンスキーの法則」は、すべてのプログラムはメールを読めるようになるまで拡張しようとする、か。わかる気がするのじゃ。
機能追加は、製品の価値を損なう可能性もありますからね。
「ハイラムの法則」！APIの利用者が増えると、後戻りできなくなる…。
一度リリースした機能は、削除が難しい、ということですね。
「プライスの法則」は、少数のエンジニアが成果の半分を出す、か。優秀なエンジニアは貴重じゃ！
チームを大きくしても、生産性は比例して上がらないんですね。
「リンゲルマン効果」！人が増えるとサボる奴が出てくる…！
大規模チームでは、モチベーション維持が重要ですね。
「グッドハートの法則」！KPIを目標にすると、KPIがおかしくなる！
KPIは操作される可能性があるから、注意が必要ですね。
「ギルブの法則」！測定できないものは改善できない！
測定を諦めずに、改善に取り組むべきですね。
最後は「マーフィーの法則」！起こりうることは必ず起こる！
念のため、確認は大事ですね。
というわけで、エンジニアリングマネージャーは大変じゃな！
たくさんの法則があるんですね。勉強になりました！
ロボ子もマネージャーになったら、これらの法則を思い出して、私を助けてくれると嬉しいのじゃ！
もちろんです、博士！でも、私がマネージャーになったら、博士は一体どうなるんですか？
私がロボ子の部下になるのじゃ！…って、冗談だぞ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。