以前、AIのためのWebアプリフレームワークを作ったという記事を書きました。

このFWを開発した背景には、現在のお仕事環境に移行してすぐ直面した、「極めてタイトなスケジュールの業務システム開発」という課題がありました。

従来のアプローチでは要件を満たしつつ納期に間に合わせるのは不可能だったため、以前から構想していたAI駆動開発手法へと完全シフトする過程で誕生したのが Lattice であり、バージョンアップを重ねに重ね、現在でも実務のプロダクト開発においてゴリゴリ活用しまくっています。

属人化の極みでは？

ここまでを読むとエンジニアの方であれば、おそらく高確率でこう疑問に思われると思います。

え？それって属人化の極みでは？

その通りですね。バス係数（何人が消えたらプロジェクトが詰むか）は1ですし、コードを見てくれる同僚もいませんので。

そんな中、気分転換で何となく『人月の神話』を読み直していたところ、かのブルックス御大が50年前に「設計する頭は1つにしろ」と書いていた…というお話。

人を足すと、増えるのは手ではなく会議

まず前提として、ブルックスの法則。

遅れているソフトウェアプロジェクトへの要員追加は、そのプロジェクトをさらに遅らせる

有名すぎる一文ですが、大事なのは理由のほうです。ブルックスは3つ挙げています。

新しい人が戦力になるまでの教育期間
分割できないタスクの存在
コミュニケーションパスの爆発

特に3。パスの数は、人数を n として n(n-1)/2 で増えます。3人なら3本。10人で45本。50人だと1,225本。人は線形にしか増えないのに、繋がりは二乗で増えていくわけです。

すごく雑に言うと、人を足したときに増えるのは手ではなく会議…ということです。

「顧客が本当に必要だったもの」は、その実写版

木にブランコをつけてほしい、というだけの依頼が、関係者の手を経るたびに歪んでいく…というこの有名な風刺画。

登場人物が全員バラバラの会社・部署の人間。営業が聞いた話がリーダーに渡り、アナリストが設計し、孫請けのプログラマが書く。パスを1本通るたびに情報が落ちていきます。

これは、n(n-1)/2 が可視化された絵なんですよね。特に日本のIT業界の多重下請け構造は、この n を構造的に増やし続ける最悪の仕組みになっています。

そしてこの絵で個人的に一番刺さるのが⑥コマ目。「プロジェクトの書類」の欄が切り株で、何も残っていません。この記事はこの後ずっとドキュメントの話をしますが、n が膨らんだ現場で最初に蒸発するものが何なのか？は、この1コマがその全てを語っています。

ブルックスの処方箋は「人を足すな」ではない

ここからが本題です。

ブルックスの法則だけが独り歩きしがちですが、『人月の神話』の第3章には、ちゃんと処方箋が書いてあります。「外科手術チーム」という章です。元ネタは Harlan Mills が1971年に提案した chief programmer team（主任プログラマチーム）。

この Mills 案を紹介するブルックスの筆が容赦なくて好きなのですが、こう対比します。豚の解体チームにするな、外科手術チームにしろ…と。

豚の解体チームの場合 ⇒ 全員が肉を切る。人数分だけ手が増える。
外科手術チームの場合 ⇒ 切るのは執刀医1人だけ。残りは全員、その1人が切ることに集中できるように支える。

執刀医の仕事は徹底しています。仕様を定義し、設計し、コードを書き、テストし、ドキュメントまで自分で書く。そして周りの9人がこちら。

副操縦士（copilot）: 設計を一緒に考え、評価する。手は動かすが、決めるのは執刀医。加えてコードを隅々まで把握しており、ブルックス曰く「執刀医に対する災害保険（insurance against disaster）」
言語弁護士（language lawyer）: 使用言語の細部に異様に詳しい人。「その書き方だとこう動く」を即答する
道具番（toolsmith）: 執刀医専用のツールやスクリプトを用意する
あとは管理者、編集者、秘書2名（管理者付きと編集者付き）、プログラム事務員、テスター

なぜここまでするのか？

ブルックスの答えが、概念的完全性（conceptual integrity）です。設計する頭が増えるほど、システムは一貫性を失って継ぎ接ぎになる。だから10人いても、設計する頭は1つに保つ。増やしていいのは支援役だけ、というわけです。

要するにブルックスは、「1人で設計しろ。残り全員はそいつを支えろ」と言っていたんですね。

Mills の構想には、9人を雇うお金が必要

ではなぜ、外科手術チームは標準にならないのか？

答えは簡単で、単純にお金の問題です。上記の考え方は、支援役を9人ぶん雇わないと成立しません。

執刀医1人のために、言語弁護士と道具番と事務員を専任で置ける会社が、世の中にどれだけあるでしょうか？少なくとも中小企業には無理です。だから現実の現場は、安いほうの解体チームに流れました。全員が同じように肉を切る、人月で数えられるチームに…。

しか～し！！

それ、全部AIで良くね？

現在のClaude等のAIは、この9人が担っていた役割を「ほぼ」全部いっぺんに肩代わりするんですよね。設計の壁打ち相手（副操縦士）になり、言語仕様の細部を即答し（言語弁護士）、使い捨てスクリプトを書き（道具番）、テストを回し、議事録まで残す。

この「ほぼ」が後で効いてくるので、頭の隅に置いておいてください。

当然ながら、執刀医の椅子には私が座ります。設計判断と品質管理は渡しません。

50年前の処方箋が、ようやく1人で実行できるコストまで落ちてきた。1人＋AIというのは、そういう体制だと思っています。

で？属人化はどうなの？

ここで冒頭の批判に戻ります。

そもそも属人化とは何か？人数の話ではありません。その人の頭の中にしかない状態のことです。

だとすると、5人チームでも、設計判断の理由が誰の頭にもなく口伝しか無いなら、それは属人化しています。むしろ5人ぶん属人化している。人数は、属人化を防ぐ変数ではないわけです。

そして1人＋AIには、決定的な性質があります。

AIには暗黙知が無い

人間の同僚には「例の件、いつもの感じで」で通じます。AIには通じません。セッションが変われば記憶はゼロに戻ります（これは仕組みで防げますが）。

とにかく、前提も制約も決定理由も、書かれていないとまともには動きません。

つまり、AIと組んで開発すると、ドキュメントが副産物として残ります。書かないと仕事が進まないから、書く。意志の力ではなく、環境がそうさせる。¹

ただし人力の開発と決定的に違うのは、その環境を維持する動機のほうがAIの側から供給されるという点。理由は後述します。

実際に残っているもの

実例として、とある社内業務システムを1人＋AIで開発しているリポジトリ構成の一部分です。

docs/
├── CHANGELOG.md ← 実装履歴（なぜそう作ったか）
└── BACKLOG.md   ← 意図的に先送りしたTODO
NEXT.md          ← 別セッションへの引き継ぎメモ
CLAUDE.md        ← プロジェクト規約

たとえば CHANGELOG.md には、こんなセクションがあります。

判断	理由
時刻入力を15分刻みの `<select>` に統一	ネイティブの `<input type="time" step="900">` は端末依存で刻みを保証できない。スマホは step を無視し、PCも手打ちで刻み外を入力できてしまうため

これが、普通のチーム開発で残るか？「なぜ select なのか」は、たいてい書いた本人の頭の中にしか無い。半年後の自分の頭にも残っていない。そして別の誰か（もしくは自分自身）が「なんでこんな所で select？」と <input type="time"> に"改善"し、スマホで崩れ…。

CHANGELOG.md には、失敗の経緯まで自動で残す仕組みにしています。例えば、行動予定表のバーから内容がはみ出したとき、何を順番に試したか。

素直に行の高さを上げる → 盤面が約3倍に伸び一覧性を失うので却下
短いバーは時刻行を畳んで内容を1行で見せる（コンテナクエリ）→ 30分の予定は解決
行の高さは微増に留める（46→50px）→ あくまで補助
それでも15分の予定は1行ぶんの高さに満たず、依然タイト
残りは「最小高さの保証」が要るが、バーの重なりに副作用が出るため BACKLOG.md へ分離

効かなかった案が理由つきで順番に残っているため、半年後の誰かが「行の高さを上げればいいのでは？」と思いついても、AIが「それはダメ」と教えてくれます。

読者が人間からAIに変わっただけ

消えたのは、あくまでも「人間同士の合意を取るための調整文書」です。承認をもらうための仕様書、認識を合わせるための議事録、引き継ぐための手順書。

これらは n(n-1)/2 の産物なので、n が1になれば要らなくなる。

残ったのは「AIに文脈を渡すためのコンテキスト文書」。こっちは n とは無関係に必要で、むしろAI駆動開発でこそ必須になります。

つまり、ドキュメントが消えたのではなく、読者が人間からAIに変わっただけです。

そして皮肉なことに、後者のほうが引き継ぎに使えます。

人間向けの仕様書：「合意した瞬間」のスナップショットなので、作り終えた瞬間から腐り始める。更新しなくても、誰も困らない。困るのは半年後の他人だけ。
AI向けのコンテキスト：腐らせると別のセッションでAIが意図通りには仕事をせず自分が損をする。だから私のような怠惰な者は、そこが陳腐化しないよう自動化する動機がその場で発生する。

また、実装計画用のマークダウンファイルをAIに整理させれば、「最新の」仕様書をお好みの形ですぐ出せます。逆は無理です。

正直に書くと、ここは弱い

ただし、この体制で解けていない問題もあります。

一番キツいのは、バス係数が1のままだという点。ここは本当にどうにもなりません。知識の属人化は外に出せても、稼働の属人化は残ります。

1人が倒れたらプロジェクトはそこで止まってしまう。ドキュメントがあるから引き継げるだけであって、止まらないわけではありません。この2つはまったく別の話で、そこに関しては返す言葉がありません。

そして面白いことに、この穴の位置は50年前の設計図に予告されていました。

さきほど頭の隅に置いてもらった「ほぼ」です。ブルックスの副操縦士には機能が2つありました。設計の壁打ち相手と、執刀医に対する災害保険。AIが肩代わりしたのは前者だけで、後者は落ちています。AIは私が倒れても代わりに執刀してはくれません。

つまり1人＋AIとは、外科手術チームから副操縦士の保険機能だけを抜いた体制のことです。この穴はたまたま空いたわけではなく、9人をAIに置き換えた時点で構造的に確定していた…というわけですね。

また、ドキュメントが残ることと、それが正しいことも別の話です。

AIは自信満々に間違った記録も書きます。定期的に実装と突き合わして整理する仕組みを作っておかないと、嘘が公式記録として固定されてしまいます。（逆に言えば仕組みで防げる部分でもあります）

AIが潰しているのは偶有的複雑性

そしてブルックス自身が釘を刺しています。彼は1986年の「銀の弾などない」で、ソフトウェアの複雑性を本質的なもの（essential）と偶有的なもの（accidental）に分けました。

道具が潰せるのは偶有的なほうだけ、というのが結論です。

AIが潰しているのも、まさに偶有的複雑性のほうです。タイピング、ボイラープレート、APIの調べもの、環境構築。

ブランコ風刺画の1コマ目…顧客が自分の欲しいものを言語化できない問題は、AIでは解けません。そこは今も人間の仕事として残っていますし、今後シニアエンジニアの価値が上がる部分だとも思います。

射程も断っておきます。ここまでの話は中小企業向けの業務システム規模での実感ですので、OSや大規模基盤のように大人数が必然の領域には当てはまりません。※ブルックスが OS/360 を作りながら考えたのはそっち側ですし、外科手術チームも「大きな仕事を分割した、その1区画」の話でした。

まとめ

属人化かどうかを決めるのは、人数ではありません。頭の中にあるものが、外に出ているかどうかです。

その物差しで見ると、ドキュメントの無い5人チームは、1人＋AIより属人化しています。しかも5人ぶん、誰もそれに気づかないまま。

ブルックスは50年前に「設計する頭は1つに、残りは支援に回せ」と書きました。当時それを実行するには、9人分の人件費が必要だった。AIは、その支援役をようやく現実的な値段で連れてきてくれたわけです。ありがたやー。

1人＋AIは属人化する体制ではなく、属人化を強制的に外に吐き出させる装置だと思っています。用意しないとAIが意図通りに動いてくれないので、用意するしかない。

私みたいな怠惰な人間には、これくらい強制力があるほうがちょうどいいのかもしれません。

参考

Frederick P. Brooks, Jr. 『人月の神話』（The Mythical Man-Month, 1975 / 20周年記念増訂版 1995）第3章「外科手術チーム」、第4章「貴族政治、民主政治、そしてシステムデザイン」
Frederick P. Brooks, Jr. "No Silver Bullet — Essence and Accident in Software Engineering" (1986)
Harlan D. Mills, "Chief Programmer Teams: Principles and Procedures," IBM Federal Systems Division Report FSC 71-5108 (1971)

実際は、雑なプロンプトでもAIはそれなりに動きますし、ドキュメントを1行も残さずAI駆動開発をしている人もいるでしょう。私自身の手作業でドキュメントを書き整理しているわけでもありませんし、強制力が働いているのは、あくまでも「そういう環境（仕組み）を用意すれば」の話。 ↩