「遅い工程に人やAIを足すだけでは、プロセスは速くならない。まず上流の詰まりを直そう」 という話です。
これ、かなり大事です。しかも地味に耳が痛い。というのも、組織って何かが遅いと、つい「もっと人を」「もっとAIを」と言いがちなんですよね。でも著者はそこに待ったをかけています。
著者は、最近の多くの組織がprocess optimization（業務プロセス改善）に注目していると書いています。景気が悪いと、会社は新規拡大よりも「今ある仕事をもっと効率よく回す」方向に向かいがちです。これはよくある流れです。
そこに今はAIブームが乗っています。
こうした期待が一気に膨らんでいる、というのが著者の見立てです。
個人的にも、これはかなり“わかる話”だと思います。効率化の話は、華やかなツールほど魅力的に見えるんですよね。でも、現実はそんなに単純ではないです。
著者はこの話を考えるために、『The Toyota Way』 と 『The Goal』 を読み直したそうです。
どちらも、ざっくり言えば「現場の流れをどう改善するか」「どこがボトルネックか」を考えるための名著です。
著者は、こうした古典を読み直して、最近の「AIでなんでも速くなる」的な議論は、かなり単純化されすぎていると感じたようです。ここはかなり同意です。
改善って、派手な魔法ではなく、だいたい地味な泥くさい話なんですよね。
記事では、プロジェクトの流れを Gantt chart で示しています。
Gantt chart は、工程と期間を横棒で並べたスケジュール表のことです。何にどれだけ時間がかかるかが一目でわかります。
そこで見ると、いちばん長いのは software development です。
なので普通は「じゃあ開発を速くすればいい」と考えます。これは正しいように見えます。
でも著者が言いたいのは、長い工程がある＝そこが本当の原因とは限らない ということです。
たとえば、開発が遅い理由が
といった上流の問題だったら、開発チームだけ頑張っても速くなりません。
これは本当にその通りで、「遅い場所」を見ているつもりで、実は「遅くさせている原因」を見逃していることが多いんです。
著者は、プロセス改善の現場でよくある対応として、
この2つを挙げています。どちらも、やりがちな発想です。
でも彼の主張はシンプルで、
「なぜその工程が遅いのか」を見ずに、力技を入れてもだいたいうまくいかない というものです。
ここで面白いのが、著者はAIを完全否定しているわけではない点です。
「AIがコードを速く生成すること」自体は認めています。けれど、速く書けることと、正しく書けることは別 だと言っています。
これ、めちゃくちゃ重要です。
速さだけを見ると、AIはすごく見える。でも、現実の仕事は「何を作るべきか」を決めるほうがむしろ大変だったりします。
著者はかなりわかりやすい比喩を使っています。
typing faster では project は速くならない
つまり、開発は「文字を打つ速度」では決まらない、ということです。
ソフトウェア開発の本質は、
人間の曖昧な問題を、コンピュータが理解できる形に翻訳すること です。
しかも、それを
作らなければいけない。
この時点で、単純な作業速度の話ではなくなります。
正直、ここを「AIが書くから早いでしょ？」で済ませるのは、かなり雑です。著者の苛立ちもわかります。
記事の面白いところはここです。
AI開発を「すごく速い」とする比較では、
AIが答えるまでに必要な人間側の手間 が抜け落ちていることが多い、と著者は指摘します。
たとえばAIにやらせるなら、本来は人間がかなり細かく指示しないといけません。
つまり、「雑な依頼」ではAIは意外と使えない。
逆に言えば、AIをうまく使うには、仕様や期待値をかなり丁寧に詰める必要があるわけです。
著者は、AI開発を速いものとして見る比較が、
その“丁寧な詰め作業”を見落としている と言っています。
これにはかなり納得感があります。
AIは魔法の省エネ装置というより、むしろ「雑さを許さない鏡」みたいなところがあると思います。
著者の議論を読むと、AIの価値がないと言っているわけではないのがわかります。
むしろ、入力が整っているなら、AIは速さに貢献できる 可能性がある、という立場です。
ただし、その条件はかなりはっきりしています。
つまり、AIが強いのは、上流が整ったあと です。
ここを逆にして、「AIを入れれば上流の混乱まで片付く」と期待すると失敗しやすい。これはかなり本質的な指摘だと思います。
著者の答えはかなり実務的です。
仕事をする人が、ちゃんと仕事できるようにすること
これです。
たとえば法務承認が遅いなら、単に法務担当を増やすのではなく、
を確認するべきだ、という話です。
そして『The Goal』の有名な考え方として、著者は
「ボトルネックには、予測可能で高品質な入力を与えるべき」
と紹介しています。
これ、地味だけど本当に効く発想です。
ボトルネックって、だいたい「頑張りが足りない場所」ではなく、「必要なものが安定して来ない場所」なんですよね。
著者のメッセージをかなり短くまとめると、こうです。
個人的には、この記事は「AIに冷や水を浴びせる記事」というより、
“AIをちゃんと使いたいなら、地味な設計をサボるな” という記事 だと思います。
派手さはないけれど、こういう話のほうが実は現実を変えるんですよね。
「AIで全部速くなる！」より、「何が本当の詰まりかを見よう」のほうが、ずっと仕事に効きます。
正直、この記事はかなり好きです。
理由は、AIへの期待をむやみに煽らず、でも頭ごなしに否定もしないからです。
結局のところ、プロセス改善で大切なのはツールじゃなくて構造です。
AIはその構造の上で働く道具にすぎない。ここを見失うと、「すごいツールを入れたのに、なぜか遅い」という、よくある残念な結果になります。
たぶん今後も、AI導入の議論では「何が自動化できるか」より先に、
「そもそも何が詰まっているのか」 を問うほうが大事になっていくのではないでしょうか。
