私は、AI が業務プロセスを速くするとは考えません。

Japanese Translation:

ソフトウェア開発の加速を図るために単に人員を増員する，あるいは人工知能（AI）に依存するだけでは失敗してしまうことが多く，これらの戦略は実質的な遅延がどこに生じているかを無視しているためです。ガントチャートの分析によると，「ソフトウェア開発」がプロジェクトのスパンを支配し 70 日かかるにもかかわらず，成功の成否はコード作成前に提示された課題定義の品質に完全に依存しており，入力が不十分であればそのフェーズ自体にボトルネックが発生したわけではなく，単に期間が長いだけでは理由にはなりません。データは，開発者がタイピング速度を上げてもプロジェクトを加速できないことを示しています（開発者は問題をコンピュータが理解可能な解に変換しなければならないため），実質的な遅延はあいまいな要件定義，不明確なロジック（例：販売完了トリガー），および機能スコープといった上流のボトルネックから来ていることを確認しました。AI ツールもスコーピングやドキュメンテーションには多大な専門家の入力が必要で，現実的なスケジュールを数日から約 40 日程度に拡大させ，即座のスパン短縮について論じることは，ドメインエキスパートに対する必要な「手引き」を無視していることになります。弁護士を増やしたり，即時の高速化を期待したりすることで全ての遅延が解決するという従来の仮説は不実であることを示しており，人員増員は書類の不備や承認チェーンの遅れといった上流の問題を解決しないからです。今後のプロジェクト成功には，生な速度から転換し，深い専門家の関与を通じて入力を予測可能かつ高品質なものにすることを目指すべきです。詳細な課題定義を提供することは AI を用いなくても生産性を劇的に向上させます。組織はコードを記述する前に機能を明確化し複雑なロジックを整理するために徹底的に投資を行うべきで，そうしないと上流の非効率を継続させ，プロジェクトの遅延を引き続き招き，ユーザー満足度と業界全体の流通性を害することになります。

このように感じています。現状にあるどの組織も、少なくとも部分的にプロセスの最適化に注力しており、これは市場が低迷期によく見られる傾向です。最近ではさらに AI という要素が全体を彩っており、それに伴う過度な期待も生じています。これらに十分に備えるため、この分野における 2 つの絶対的な古典、「トヨタの道」と「ゴール」を再度読もうと決心しました。大学時代以来両書は読み込んでいましたが、改めて読むことにより、多くのプロセス最適化の実践が本質的にあまりにも単純化されており、かつどこに焦点を当てるべきかを誤解していることに気づかされました。

視覚的なボトルネック

私が何を意味しているのかを示しましょう。

[以下は説明のための甘特図です。通常であれば BPMN を使用しますが、この場合甘ト図の方が要点が伝わりやすいと考えました]

この甘ツ図をご覧くださいとすぐに、最も時間を要するのは「ソフトウェア開発」であることがわかります。もしプロジェクトの Throughput（生産性）を向上させることが課題であれば、まずはここから着手するのが正解です。

しかし問題は、一般的に人々がこれに取り組む方法にあります。単に人員を追加するだけでよいか、あるいは AI によって劇的に高速化されると想定し込んでしまうことです。人々があまり行わないことは、なぜそれがこれほど長くかかるのかを調査すること、そしてより重要なのは、「長期間要するという事実は必ずしも問題の根源がその工程にあるわけではない」という点です。

サプライ側（Upstream）での解決

私たちは今ソフトウェア開発について話していますが、これは実際には望まない以上に長時間かかるあらゆるプロセスに適用可能です。全てのソフトウェア開発者は分かっているはずです：単にタイピングを速くするだけではプロジェクトは速くなりません。そうだとすれば、私たちは皆タイピングのレッスンを受けるべきです。

ソフトウェア開発とは、問題をコンピュータが理解し自動的に解決できる解に変換することです。できれば安全でスケーラブルな方法で。そのようなことを成し遂げるためには、問題全体に関する俯瞰的な視覚が必要です。ウォーターフォール手法を採用するなら機能仕様のドキュメントや範囲定義書を用意するか、アジャイル的手法なら領域専門家との継続的な反復を通じて進めることになります。これがしばしばソフトウェア開発を遅らせる要因となります。曖昧な題名だけの機能依頼が実際何を意味するのかを解明しようとする過程です。

「売上完了後にユーザーに 1 通メールを送信する」とはどういうことでしょう？さて、メールを送ることは可能ですが、そのメールの内容は何が適切か？売上プロセスに問題が発生した場合でも、エラーメールを送るべきか？そして「売上が完了した」のはいつを意味するのか？

ただ AI を投げつけるだけなのか？

ソフトウェア開発の自動化（AI 生成コード）に関する議論でよく耳にするのは、「開発工程そのものをスキップできてしまうため、ソフトウェア開発者はプロジェクトマネージャーに変身できる」という主張です。ソフトウェア開発をめぐる AI 討論はまさにこの問題を完璧に浮き彫りにしています。

多くの人が AI による開発の結果をこのようなものだと期待しています：

範囲定義
- 機能探索：2024 年 1 月 1 日（10 日間）
- 予算の枠組み決定：s1 終了後（3 日間）
- 法務対応：s1 終了後（10 日間）
- 文書化：s3 終了後（5 日間）
開発
- AI による開発：s4 終了後（3 日間）→ [注：これは範囲定義がほぼ完了していることを示唆]
配備・運用
- 配備：d1 終了後（5 日間）
- ハイパークヤ：dp1 終了後（10 日間）

しかし、実際にはそうは働きません。ここでは以前と同じアップストリームの問題に直面します。はい、AI はコードを素早く生成できます（それが善いことかどうかは議論の余地がありますが）、しかしそれが必ずしも「正しいコード」を生成しているとは限りません。人間と AI の開発力を比較する際、常に AI が機能するために必要な手取り足足の支援を見落としています。

実際にはもっと以下のような形になります：

範囲定義
- 機能探索：2024 年 1 月 1 日（10 日間）
- 予算の枠組み決定：s1 終了後（3 日間）
- 法務対応：s1 終了後（10 日間）
- 文書化：s3 終了後（40 日間）→ [注：問題の定義には遥かに長い時間が必要]
開発
- AI による開発：s3 終了後（40 日間）→ [注：生成自体は速いが、定義に時間がかかる]
配備・運用
- 配備：d1 終了後（5 日間）
- ハイパークヤ：dp1 終了後（10 日間）

この構成の方が従来の働き方と比較して速いかもしれませんが、それは不公平な比較であると考えます。このような働き方には、領域専門家やプロダクト専門家へのはるかに深い関与が必要です。これはつまり、すべての機能とバグ修正まで最小単位まで詳しく書き出すことを意味します。

まさにこれがソフトウェア開発者の職業開始からずっと懇願してきたことです：問題を詳細にoutlined し、最終結果がどのようなものになるかを示すものです。もし人間開発者にも同程度の機能・範囲のドキュメンテーションを提供するならば、生産性が劇的に向上することも明らかになります。

プロセスを本当に加速させるには

プロセスを速くしたいのであれば、実際に作業を行う人々がその作業を実行するための全手段を持っていることを保証する必要があります。つまり、法務承認プロセスが遅延していれば、法務承認プロセスを開始するために何が必要なのかを検討すべきです。もし incomplete な文書を追跡するために 5 人の異なる担当者を手配しなければならないなら、単に部門に追加の弁護士を採用するだけではそのプロセスを速くすることはできません。