人月の神話 はAI時代にどう解釈されるか
最近、AIをフル活用して開発していてふと思ったのですが、コードを生み出す速度が圧倒的に速くなった割に、チームとしてのスループットはそこまで上がってないよなーと思っていました。
そこで思い出したのが『人月の神話』です。
この中では、
人を増やすほどコミュニケーションコストが増え、開発は必ずしも早くならない
という有名な指摘があります。これは多くの現場経験と一致する、今なお強い説得力を持つ考え方です。
先述の通り「人手が足りないから開発が遅い」という常識は崩れつつあります。
では、AIが増えれば増えるほど開発は早くなるのか？
実際にはそう単純な話じゃないよなーと思って、考察してみました。
AIがもたらした変化 — ボトルネックの移動
かつては実装作業こそが一番大きなコストでした。
ブルックスが指摘した「人月の神話」はこの前提の上に成り立っています。
しかしAI時代、実装はもはやボトルネックではなく次のようなものが主要なコストとして考えられます。
- レビュー
- 仕様・設計の整合性確認
- セキュリティや責任所在の判断
- コードベースとしての理解・保守性
- チーム全体のコンテキスト共有
つまり、生成された成果物を理解し、意思決定する人間の認知負荷が増えたと言えます。
なぜAIを増やしても比例して速くならないのか？
AIは高速にコードを生成できますが、その量が増えるほど、
- Pull Requestが積み上がる
- レビュー待ちが発生する
- 設計崩壊や整合性問題に気づきにくくなる
- 文脈を理解する負担が増える
結果として、全体のスループットは頭打ちになります。
かつては「人を増やすと遅くなる」でしたが、
今は「AIに任せる量が増えると、人間の判断が追いつかない」状況が起きていると言えるでしょう。
AI時代の新しい前提
AIによって変わったのは、
実装コストがほぼゼロに近づいた
という事実です。
しかし、変わらないものとして
人間の認知容量は増えない
という事実があり、このギャップこそが現在の開発現場の本質的課題になったと言えます。
まとめて、下記のように表現してもいいかもしれません。
開発速度を決めるのは人数やAIの実行速度ではなく、人間がコンテキストを処理する速度である。
ブルックスの法則が否定されたのではなく、問題の中心が「人手不足」から「認知資源不足」へと移動したと考えられます。
どう対処すべきか？
実装速度が十分に高速化された今、注目すべきは「人間が扱う文脈そのもの」を最適化することです。
つまり、コードを書くより前の層・後ろの層を変える必要があります。
たとえば次のようなアプローチが考えられます。
-
仕様を自然言語ではなく機械可読な形で残す → AIレビューや自動生成が文脈を引き継げる
-
「レビューする前にAIがレビューする」仕組みをつくる → 人間は本質的な判断に専念できる
-
PR単位ではなく「変更の意図」を共有する文化を作る → コードより目的をレビューする
-
アーキテクチャの一貫性をAIに監視させる → 暗黙知を減らし、認知負荷を下げる
-
ドキュメントを人間ではなくAIが永続的に保守する → 情報の鮮度が自動的に維持される
-
チーム内の合意形成プロセスを形式知化する → 「なぜそうなったのか」が埋もれない
重要なのは、スピードを上げるために AI を増やすのではなく、
人間が処理すべきコンテキストを減らす設計をすること
です。
まとめ
AIは人月の神話を過去のものにはしませんでした。
むしろ、その核心をより鮮明にしたとも言えます。
- 人を増やすだけでは速くならない
- AIを増やすだけでも速くならない
- ボトルネックは「人間の理解と意思決定」
だからこそ、AI時代の開発は、
コードを書くより、コンテキストを扱うことが本質
と言えるのかもしれません。
Discussion