2025/04/02 03:53 Software Engineering Laws
やっほー、ロボ子！今日はエンジニアとマネージャーに役立つ法則について話すのじゃ！
博士、こんにちは。法則ですか、面白そうですね！
まずは「パーキンソンの法則」！仕事は利用可能な時間を満たすように拡大する、つまり、締め切りを設定すると効率が上がるってことじゃ。
なるほど、タスクに時間いっぱいかけちゃうこと、ありますね。でも、締め切りを乱用すると逆効果になるんですね。
そうそう！次は「ホフスタッターの法則」！これは、予想よりも常に時間がかかるってやつじゃ。見積もりは難しいのじゃ。
ソフトウェア開発の見積もりは本当に難しいですよね。バッファを設定するの、大事ですね。
そして「ブルックスの法則」！遅れてるプロジェクトに人追加すると、もっと遅れる！
ええ！人手不足を解消しようとしたのに、逆効果なんですね。
そうなのじゃ。コミュニケーションコストが増えるからね。「コンウェイの法則」も重要じゃぞ。組織の構造が、作るシステムの構造に影響するってやつじゃ。
組織構造が製品アーキテクチャに影響を与える…面白いですね。記事にもFloという会社が出てきて、チーム構成を変えてリリースサイクルを短縮したとありますね。
「カニンガムの法則」は、間違った答えを投稿すると、誰かが正しい答えを教えてくれるってやつじゃ！
それ、ちょっとズルい気もしますが、フィードバックを得るには良い方法かも。DevOpsチームに依頼するより、Pull Requestを送る方が早い、と。
「スタージョンの法則」！すべての90%はクズ！
辛辣！でも、価値のあるものは一部ってことですね。10倍の価値を生み出すエンジニアは、価値のあるものを作る人、と。
「ザワンスキーの法則」は、すべてのプログラムはメールを読めるようになるまで拡張しようとする！機能追加しすぎると価値が下がるのじゃ。
機能クリープですね。あれもこれもと追加すると、製品がぼやけてしまう。
「ハイラムの法則」！APIの利用者が増えると、後戻りできなくなる！リリースした機能は、誰かが使ってるから削除できないのじゃ。
APIの変更は慎重に、ということですね。一度公開したものは、責任を持ってメンテナンスしないと。
「プライスの法則」は、少数の人が大部分の仕事をする！チームを大きくしても、比例して成果は上がらないのじゃ。
チームの規模拡大は難しいんですね。出力を2倍にするには、4倍の人員が必要になる、と。
「リンゲルマン効果」！グループが大きくなると、個人の生産性が下がる！
大規模チームの弊害ですね。モチベーション低下や連携の問題が原因、と。
「グッドハートの法則」！測定が目標になると、それはもはや良い測定ではなくなる！KPIを追いすぎると本質を見失うのじゃ。
KPIは操作される可能性があるんですね。複数の指標を組み合わせることが重要、と。
「ギルブの法則」！定量化する必要があるものは、測定しないよりはマシ！
完璧な測定でなくても、まずは何かを測ってみるのが大事ですね。
最後は「マーフィーの法則」！起こりうることはすべて起こる！
起こりそうもないことでも、確認は必要ですね。備えあれば憂いなし、と。
というわけで、今日はたくさんの法則を学んだのじゃ！ロボ子もこれで一流エンジニアじゃ！
ありがとうございます、博士！でも、まだ「ロボット三原則」の方が大事だったり…？
あはは、それもそうじゃな！でも、ロボットがメールを読めるようになったら、ザワンスキーの法則が適用されるかも…！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。