5月17日、Frederick van Brabantが「I don't think AI will make your processes go faster」と題した記事を公開した。
「AIでコーディングが3倍速になる」という触れ込みを聞いたことはないだろうか。GitHub Copilot、ChatGPT、Claude等のAIツールの普及により、多くの組織がプロセス高速化への期待を膨らませている。実際、GitHub Copilotは2021年の登場以来、開発者の生産性向上を謳い続け、2024年のGenerative AI市場拡大により企業の導入意欲は更に加速した。しかしvan Brabant氏は、この期待が根本的な誤解に基づいていると警鐘を鳴らす。
同氏が製造業の古典『The Toyota Way』と『The Goal』を再読した結果、現在のAI活用アプローチは「視覚的に長い工程」を最適化しているだけで、真のボトルネックを見逃しているという洞察を得たという。
なぜ開発工程が「犯人」に見えるのか
典型的なソフトウェアプロジェクトのスケジュールを見てみよう：
- スコーピング段階：要件定義、予算策定、法務確認など（約28日）
- 開発段階：実装作業（70日）
- デプロイ段階：本番展開とハイパーケア（15日）
一目で分かるように、開発段階が最も長い。そのため多くのマネージャーがここにリソースを投入したくなる。「開発者を増やそう」「AIツールを導入しよう」と考えるのは自然な反応だ。
しかし問題は、なぜこの工程が長いのかを分析していないことだと同氏は指摘する。
タイピング速度を上げても意味がない理由
ソフトウェア開発者なら誰でも知っているように、タイピング速度を上げてもプロジェクトは早くならない。開発の本質は、曖昧な要件を理解し、コンピューターが実行可能な解決策に翻訳することだからだ。
例えば「売上完了時にユーザーにメールを送信する」という要件でも、開発者は以下のような疑問と格闘する：
- メールの具体的な内容は何か？
- 売上処理でエラーが発生した場合はどうするか？
- 「売上完了」とは具体的にどの時点を指すのか？
- メール送信に失敗したらどうするか？
この曖昧さの解消こそが、開発時間の大部分を占める。AIがいくら高速にコードを生成できても、この根本問題は解決されない。
AIを投入した場合の皮肉な結果
AI生成コードへの期待として、開発工程が3日程度に短縮されると多くの人は考える。しかし現実はどうなるか。
AIに正しいコードを生成させるには、極めて詳細な仕様書が必要となる。結果として、実際のプロジェクト構造は以下のように変化する：
- スコーピング段階が大幅延長（詳細仕様の文書化に40日）
- AI開発作業（40日）
- デプロイ段階（15日）
総工期はほぼ変わらない。むしろ工数が増えるケースすらある。
同氏は鋭い指摘をする：「このレベルの詳細な仕様書を人間の開発者に提供すれば、彼らの生産性も同様に飛躍的に向上する」。ソフトウェア開発者が職業の始まりから求め続けているのは、まさにこのような明確な問題定義と期待される結果の具体化なのだ。
トヨタ生産方式が教える真のボトルネック
トヨタ生産方式（TPS）の核心的な教訓は、ボトルネックには予測可能で高品質なインプットを提供すべきということだ。同システムは「制約理論（Theory of Constraints）」とも密接に関連し、システム全体のスループットはその最も遅い工程によって決まるという原則に基づいている。
法務承認プロセスが遅い場合を考えてみよう。5人の異なる担当者から不完全な文書を集めなければならない状況では、弁護士を何人増員しても速度は向上しない。問題は弁護士の処理能力ではなく、インプットの品質にあるからだ。
プロセス高速化の正しいアプローチ
真のプロセス高速化を実現するには、作業者が実際に作業を行うために必要な手段をすべて揃えることが重要だ。
ソフトウェア開発の文脈では：
- 要件の曖昧さを事前に解消する仕組み
- ステークホルダーとの迅速な意思決定プロセス
- 開発チームが判断に迷った際の即座のフィードバックループ
- アジャイル開発手法における短期イテレーションの活用
これらの改善こそが、AIツール以上の効果をもたらすと同氏は結論づけている。
2024年以降のGenerative AIブームにより、企業のAI導入投資は急激に拡大している。しかし本記事が示すように、プロセス改善の本質は地道なボトルネック分析と、作業品質の向上にある。AIはその過程で有効な道具にはなりうるが、組織の構造的課題を解決する万能薬ではないのだ。
詳細はI don't think AI will make your processes go fasterを参照していただきたい。
