「AIが開発を3倍速くしてくれる」— みんなそう信じて導入しました。
でも、なぜ納期は変わらないんでしょう?
みんなこう信じてますよね
信念自体は間違ってないんです。GitHubのCopilot研究では、HTTPサーバー作成のような孤立したコーディングタスクを平均55%速く完了できたと報告されています。Copilotなしで2時間41分かかった作業が1時間11分になったんです。
これを見れば自然な結論が出てきますよね。「70日かかるプロジェクトをAIで35日に」と。タイムラインで一番長いフェーズをAIが圧縮してくれるわけですから。
でもデータは逆を示してたんです
GoogleのDORAチームが2024年に公開したデータが興味深いんです。AI導入で個人の生産性と満足度は上がったのに、ソフトウェアの提供安定性とスループットは逆に下がるケースが観察されたんです。個人は速くなったのに、チーム全体の信頼性が落ちるというパラドックスです。
これを説明するのが「制約理論(Theory of Constraints)」です。核心原則はシンプル:どんなシステムも全体パフォーマンスは最も遅いステップ一つで決まる。 ボトルネック以外のステップをいくら速くしても、全体のスピードは変わりません。
だから問うべき質問はこれです:「あなたのプロジェクトで実際に一番時間がかかっているのは本当に"コーディング"ですか?」
ボトルネックを間違えると
AIでコーディングをゼロに近づけても、要件の明確化に6週間かかるなら、プロジェクトは6週間未満には縮まりません。これが制約理論の核心です。
トヨタが知っていた原則
この問題を正確に突いた原則があります:「ボトルネックには予測可能で高品質なインプットが提供されなければならない。」 エリヤフ・ゴールドラットの「ザ・ゴール」でも、トヨタ生産システムでも繰り返し強調される原則です。
例えば「販売完了したらユーザーにメールを送って」という要件が来たとします。これを実装するには、まず何を決める必要があるでしょうか:
- メールの内容は?注文番号?配送予定日?
- 「完了」って何ですか?決済承認?在庫引き当て?発送開始?
- 失敗したらどうする?リトライ?誰かに通知?
- メールが届かなくても注文は有効ですか?
これが明確でなければ、開発者も、AIも、推測で実装するか質問するために止まるしかないんです。コーディング速度が55%上がっても、ここで詰まれば意味がありません。
Martin Fowlerの「Specification by Example」も同じ文脈です:要件は抽象的な説明ではなく、具体的な例示(入力 → 期待される出力)の形で表現されたときに初めて完全になるんです。AIにも同じことが言えます。
| AI単独導入 | 要件明確化 + AI | |
|---|---|---|
| インプット品質 | 依然として曖昧 | 具体的な例示ベース |
| コーディング速度 | 速くなる | 速くなる + 手戻り最小化 |
| 提供安定性 | 低下リスク | 維持または向上 |
| 実際の納期 | 変わらないか遅延 | 短縮可能 |
では、どこから始めればいいんですか?
- 本当のボトルネックを見つける
最近のプロジェクトの各フェーズにかかった時間を正直に書き出してください。「なぜ時間がかかったか」の原因も。要件変更?手戻り?承認待ち?そこが本当のボトルネックです。 - コーディング前に「完了の定義」を作る
機能ごとに具体的な例示を書いてください。「ユーザーAが決済完了したら → 注文確認メールがB形式で送信される。」この具体性がAIにも開発者にも高品質なインプットになります。 - 不確実性をコーディング前に解消する
「これどう実装しよう?」がコーディング中に出てきたら、すでに遅いんです。PM/POと1時間話すことが2日の手戻りを防ぎます。 - そのあとにAIを付ける
要件が具体的な例示レベルで定義された後にAIに実装を任せてください。明確なインプットがあって初めてAIのスピードアップが意味を持ちます。 - 正しい指標で測定する
「速くなったか?」ではなく「手戻りが減ったか?」「要件変更が減ったか?」で測定してください。DORAのデプロイ頻度、リードタイム、変更失敗率が良い基準です。
もっと深く知りたい方へ
I don't think AI will make your processes go faster この記事のもとになったFrederick Vanbrabantの原文。ガントチャートの例と制約理論の実際の適用が具体的です。 frederickvanbrabant.com
2024 DORA Accelerate State of DevOps Report AIが開発チームに与える影響をデータで分析したGoogleの年次報告書。 dora.dev
Theory of Constraints — Wikipedia エリヤフ・ゴールドラットの制約理論の概要。ボトルネック管理と5段階の集中手順の基礎。 wikipedia.org
SpecificationByExample — Martin Fowler 具体的な例示で要件を定義する方法論。抽象的な要件の問題と例示ベースのアプローチがなぜ効果的かを説明。 martinfowler.com
Research: Quantifying GitHub Copilot's Impact on Developer Productivity GitHubの公式研究。55%スピードアップの実際の実験条件と限界。 github.blog




