AIがあなたのプロセスを速くするとは思えません

8日前原文(frederickvanbrabant.com)

概要

多くの組織 がプロセス最適化に注力する傾向
AI導入 と過剰な期待が現場で増加
The Toyota Way および The Goal の再読で気づいた本質的課題
ボトルネック への誤った対処が多い現状
プロセス改善 の正しいアプローチの重要性

市場低迷時のプロセス最適化とAI幻想

市場が低迷すると、多くの組織が プロセス最適化 に注力
最近では AI導入 がプロセス最適化の文脈で語られる機会が増加
AIに対する 非現実的な期待 が現場で蔓延
プロセス最適化の本質を理解せず、表面的な施策に終始するケースが多発

名著再読から得た気づき

大学時代に The Toyota Way と The Goal を読了
再読を通じて、現場のプロセス最適化が 単純化 されすぎていることを実感
多くの最適化活動が 本当に注目すべきポイント を見誤っている現状

ガントチャートで見るボトルネックの可視化

プロジェクト全体の流れを ガントチャート で可視化
最も時間がかかる工程（例： ソフトウェア開発）が一目瞭然
多くの人は「一番時間がかかる工程＝改善対象」と判断
しかし、 時間が長い＝原因がそこにある とは限らない

ボトルネックへの誤ったアプローチ

ボトルネックに対し 人員を投入 したり、AIで一気に解決しようとする傾向
なぜその工程が長いのか、 根本原因 を探らないまま対処
単に工程を短縮するのではなく、 上流工程 の問題把握が不可欠

上流課題の重要性

ソフトウェア開発に限らず、 全ての長期プロセス に共通する課題
開発の本質は「 問題の正確な理解と定義」にある
不明瞭な要件や曖昧な仕様が 開発の遅延 を招く主因
「販売完了時にユーザーへメール送信」など、 曖昧な指示 が現場を混乱させる

AIによる自動化への過度な期待

「AIがコード生成すれば 開発が不要 になる」といった過信
実際にはAIも 詳細な指示や要件定義 が不可欠
AI導入後も ドメインエキスパートやプロダクト担当者 の深い関与が必要
人間開発者に 詳細な仕様書 を与えれば生産性が劇的に向上するのも同じ

プロセス高速化の本質

プロセスを本当に早くしたいなら、 実務者が必要な情報やリソース を事前に揃えることが重要
例：法務承認が遅い場合、 必要書類の不足や手配の煩雑さ が根本原因
人員増強ではなく、 高品質なインプットの提供 がボトルネック解消の鍵

名著から学ぶボトルネック管理

The Goal の教訓：「 ボトルネックには予測可能で高品質なインプットを与えること」
これこそが プロセス自動化・最適化 の第一歩
The Toyota Way はプロセス改善の優れた指南書
The Goal は漫画版もおすすめ
The Mythical Man-Month も合わせて読む価値あり

まとめ

表面的な最適化 やAIへの過信ではなく、 本質的な課題の特定と高品質なインプット が重要
プロセス改善の本質を理解し、 現場の実態に即した施策 を講じることが成功の鍵

Hackerたちの意見

一方で、これは多くの人が大企業でのテクノロジー関連の仕事で考えていることや見ていることを、まさにその通りに説明しているクリーンな投稿だね。著者さん、あなたの意見に110%同意するし、他の人にもあなたが書いたことを理解してほしいと思ってる。でも、最近特にHNや実際の職場で、これを何度も繰り返している気がする。別のブログ記事が、リーダーたちに「AIが本当に物事を早くする」って思わせるのは無理だよ。彼らは社会的にも経済的にもそう振る舞うインセンティブがあるからね。だから、彼らのAIプロジェクトが失敗するか、前のプロジェクトと同じくらい遅くなるのを待つしかないし、何かを学んでくれることを願ってる。

└

そうだね。僕は住宅ローンが終わって、少し仕事を選べる余裕があるから、日々ガーデニングしたり、エージェントツールを使って個人的なコーディングプロジェクトに没頭してる。例えば、高性能のOLTPデータベースをゼロから作ったり、全く新しい論理的な永続プログラミング環境を構築したり、ちょっと変わった数学に基づいたシンセサイザーやFPGAソフトプロセッサを作ったり。普通の人がやることだよね。だから、これらのツールが一人の手の中でどれだけのことができるかは知ってる。すごいよ。でも、最低トークンのノルマを設定したり、「スターAIコーダー」と呼ばれる人たちが「コードレビューはしないで」とか「手でコーディングするのをやめて」と言っている話を友達から聞くと、首を振りたくなる。冬に契約の仕事を少しやってみたけど、まあまあだったけど、結局はコードレビューで対立するLLM同士の戦いになって、創業者が毎週末に新しいプロジェクトをコーディングしてた。これらのツールはチームワークや本当のチームソフトウェアエンジニアリングには向いてない。業界が理解するまで、ただ様子を見るつもりだよ。まともに働ける場所は、ゆっくりと言える年配の賢い人たちがいるところだけだと思う。今のところ、オンタリオ州ハミルトンエリアでカットしたルバーブが1束5ドルで売ってるよ。アスパラガスもたくさんある。

└

いや、ビジュアルやガントチャートは、まさに理解できる「PM用語」だと思う。確かに、C-suiteや投資家がイノベーションのシグナルを出している限り、何も解決しないけど、それも長くは続かないだろうね。

└

残念だけど、君の言う通りだと思う。こういう投稿を職場でシェアするのも躊躇しちゃうよ。現状に合わないことはあまり受け入れられない感じがするから。

そう、AIはコードを素早く生成できる（それが良いことかどうかは議論の余地があるけど）、でもそれが正しいコードを生成しているわけではない。いや、実際にはコードはほぼ常に正しいよ。追加される方法は、君が自分のコードベースを十分に理解しているなら、あまり好ましくないかもしれない。どこに何を追加するか、どう名前を付けるか、どれだけコメントを追加したいか、どこに追加するかといった儀式があるからね。そういうのが、エージェントによってうまく行われないと、僕みたいな人をイライラさせるみたいだし、AGENTS.mdにあっても失敗することが多い。> もし人間の開発者に同じ量の機能や範囲のドキュメントを与えたら、彼らの生産性が急上昇するのが見えるだろう。IT業界でほぼ20年やってきたけど、これは絶対に起こらないと思う。もし起こったとしても、それは非常に稀で、話す価値もないよ。

└

いいえ、コードは実際にはほぼ常に正しいそれは私の経験とは違う、特に入力がバグやパフォーマンスの問題のときは。ガイドがないと、頻繁に幻覚を見たり誤診したりする。でも、何をしているかに目を光らせて、正しい方向に押し進めれば、RCAや分析はうまくできて効率を改善することができる。 > 人間の開発者に同じ量の機能/スコープのドキュメントを与えたら、あなたの生産性は急上昇するだろう。人が情報を消化して分析する速さには、機械と比べて限界があると思う。

LLMが最初に出たとき、人々は「Facebookのクローンを作って」みたいに言えばいいと思ってたけど、今はもっと具体的に要求を伝えたり、定義を明確にする必要があるって気づいてきたよね。それがソフトウェアのボトルネックだった。僕が働いていたときも、「データを取得してユーザーに渡す」みたいな要求が来て、何のデータか、どこに保存されているのか、どんな形式で返すのかの定義が全くなかった。だから、プロダクト担当者と一緒に彼らが本当に何を望んでいるのかを理解するのにかなりの時間を費やしてた。LLMで良い結果を得るためには、似たようなことをしないといけない。曖昧な要求は曖昧な結果を生むからね。

└

LLMが最初に出たとき、人々は「Facebookのクローンを作って」みたいに言えばいいと思ってたけど、今はもっと具体的に要求を伝えたり、定義を明確にする必要があるって気づいてきた。それがソフトウェアのボトルネックだった。これは1986年にフレッド・ブルックスが「No Silver Bullets」というクラシックなエッセイの中で「エキスパートシステム」や「自動プログラミング」のセクションで予測していたことだ。彼は、Vibe Codingの核心的な特徴と、今私たちが経験していることを正確に示している。慎重に選ばれたいくつかの領域での初期の成功と、その領域を超えて広がるにつれての合理的だが画期的ではない生産性の向上がある。

└

今、プロダクトオーナーたちが自分の仕事をLLMに振り分けようとしている。以前は、要求を出す人が曖昧な要求や悪い要求を出していたから、プロセスはうまくいかなかった。彼らはビジネスの意図を理解していなかったり（または不注意だったり）したからね。LLMは、同じ曖昧で悪い要求を受け取って、それを信じられるように見せるだけなんだ。

└

もっとひどいよ。曖昧な要件は、問題の曖昧な解釈しか生まない。たとえ良い要件を提供しても、結局は曖昧な解釈しか手元にない。将来的にはこういうことが問題にならないって約束されてるけど、実際には全然実現してない。「Facebookのクローンを作れ」っていうのが、エンドユーザーへの曖昧な約束なんだ。現実は、曖昧な解釈から生まれる多くの仮定に繋がって、最終的には成功を主張するために要件を変更しなきゃいけなくなる。だから、すべてが妥協の産物になっちゃう。市場に出せる製品を作るための特別な結果はない。どこにでも死体が転がってる。要件を定義して実装するためには、この技術よりももっと良いものが必要だよ。

└

さらに悪いのは、人間のソフトウェアチームと関わると、曖昧な要件は（少なくともうまく運営されている組織では）さらなる具体化を求められることだ。「『データを取得する』ってどういう意味？」みたいにね。でもLLMは「もちろん！データを取得してユーザーに渡す完全に実装されたコードをどうぞ。」って言って終わりなんだ。

└

プロダクトの人たちはLLMが大好きだよ。なぜなら「Xはどういう意味？どうやって機能するの？」って質問しないから。プログラマーは、すべてのケースについて聞くけどね。

└

見たところ、チケットは今や詳細が豊富になってるね。PMたちがAI（Claude CodeやCodexのように、コードベースに接続されているもの）を使って、問題が何で、なぜそうなっているのか（つまり、バックエンドにXフィールドが存在してフロントエンドにはない）、どのようにデータを取得するか（バックエンドをクエリする）、そして必要な受け入れ基準は何か（フロントエンドにはそのフィールドが表示されて、「送信」ボタンを押すと、そのフィールドのデータがバックエンドに送られ、データベースに表示されるべき）をテンプレートに記入しているからだ。これは、以前は怠惰で開発者が解決できると思っていたからやらなかったことだと思う。それから、開発者はこのJiraチケットの内容を選んだLLMエージェントにコピペすることができる（あるいは、AtlassianのMCPを使ってLLMに自動で読ませることもできる）。これによって、開発者は大いに助けられて、要件が非常に明確になった。正直なところ、最初のステップでPMたちはすでに機能の実装に半分到達しているように見えるから、将来的には彼らがすべて自分でやって、数人の開発者がフルスケールの実装者ではなくSDETとして残るのかもしれないね。

└

あなたの言う通りで、これが明らかだと思ってたんだけど。私は「Facebookのクローンを作れ」なんて言ったわけじゃないんだ。どう動くべきかの説明をしただけ。例えば、こんな感じ：1) /etc/hostsを読み込むPythonスクリプトが必要なんだ。2) 特定のホストの値を見つける（.confから読み取る）例えばserver1、localhostとか。3) それらの設定に名前を付ける。例えば、.confに[Env1] 192.168.0.1 production-read 192.168.0.2 production-write 192.168.0.27 amqp [Env2] 192.168.0.101 production-read 192.168.0.201 production-write 192.168.1.127 amqpってあったら、基本的にフォーマットは[CONFIG_NAME]、普通のhostsファイルみたいな感じ。4) それぞれをメモリに保存する。5) /etc/hostsにマッチするのがあったら、その「現在の環境」をconfignameに設定する。6) Ubuntu 22のデフォルトのGNOMEの右上にアイコンを作る。7) そのアイコンは現在の設定名のテキストか、何もマッチしなければ「カスタム」って表示される。8) ユーザーが「トレイ」やアプリインジケーター（GNOMEが呼んでるやつ）をクリックすると、設定名がシンプルなGTK/GNOMEでリスト表示される。9) ユーザーが一つの設定をクリックすると、~/.config/backups/に/etc/hostsのバックアップを作成する。名前はhosts-%UNIX_TIMESTAMP%。10) それをhostsファイルに適用する（ホスト名を変更する行だけを見つけて、その行だけを修正する）。これでシンプルなGNOMEアプリインジケーターの環境スイッチャーが完成した。いくつかの行を修正する必要があったけど、ほとんどはそのまま動いたよ。適切な仕様をLLMに与えれば、ちゃんとやってくれる。DSLを使ってやりたいことを説明することもできるし、向こうが理解してくれる。

└

これはすでに数年前から現実だったよ。いくつかの会社で、プロダクトマネージャーがチームに参加しても、PMの「オンボーディング」の間に小さな要件すら準備できないことが何ヶ月も続いてるのを見てきた。そして、コードは準備できてるのに、DevOpsが忙しかったりQAが時間を見つけられなかったりで、リリースに何ヶ月もかかる。ソフトウェアのリリースペースは、コーディング部分からずっと切り離されていて、私たちはそれについて静かだった。

└

でも今、私たちは要求をもっと正確にし、物事をより良く定義する必要があることに気づいている。だからこそ、プログラミング言語でプログラムを書くんだ、英語じゃなくて。プログラミング言語は自然言語よりも正確な指示を与えるのがずっと効率的だから。

└

今は最悪だよ。長いChatGPTのチャット履歴をPDFでエクスポートすると、「これの見積もりを出してもらえますか？」って一文だけがある。

これは全体的に正しいし、AIがプロセスを早くするためにどこに焦点を当てるべきかのヒントを与えてくれる。例えば、あるプロダクトマネージャーが、ステークホルダーとの会議で、会議の終わりまでにインタラクティブなプロトタイプができなかったら、その会議は失敗だと考えていると言ってた。これは方向性として正しいと感じる。他に期待しているのは、Vibecodingが「Excel 2.0」になることで、インタラクティブなアプリを自己サービスで構築できるようになり、ITと戦いながら、より良いセキュリティ保証や適切なアクセス制御、ロギング、スケーラビリティ、変更管理などを実現すること。だけど、ここでの大きな歴史的なポイントは、すべての革命的な移行は、初期段階で「蒸気馬」を生み出すということ。蒸気機関の発明によって、人々は未来の交通手段が蒸気で動く馬の形をした物体が従来のカートを引っ張ることになると想像していた。後の発展があって、交通手段の機能が形から切り離されることを理解するまで時間がかかった。最初にMOOCsの文脈で蒸気馬について話し始めたのは、まさにそのクラシックな蒸気馬のアイデアだった。

面白い二項対立があると思う。自分が得意なことに関しては、LLMはあまり影響がないと感じる。でも、苦手なことに関しては、すごいゲームチェンジャーだね。大企業なら、プロジェクトに必要な役割をほとんど外注できるから、全体的な影響はそれほど大きくないと思う。せいぜい、1人が5人分の仕事を mediocre にこなして、結果的に質の悪い製品にすることで労働コストを削減できるくらい。短期的な利益が長期的なコストに繋がるってやつだね。だけど、小さなスタジオや独立した開発者にとっては、LLMは大きなゲームチェンジャーだよ。5人分の仕事を mediocre にこなせるっていうのは、そういう仕事なしでやりくりするよりも大きな飛躍だし、サードパーティのアセットや他のコンテンツに頼ったり、もっとひどいのは、その仕事を即興でやろうとして本当にひどい結果になることだよ。プログラマーが作ったUIが明らかにデザイナーの手によるものでないことがわかる、ほとんどのプログラムのUIを見てみればわかるよね。あるいは、dribbbleからパクろうとしてスキルが足りないっていうのもある。でもAIを使えば、突然、すべてを上手にパクれるようになるんだ。基本的にそれが彼らのやり方だよ。

└

自分が得意なことに関しては、LLMはあまり影響がないと感じる。でも、苦手なことに関しては、すごいゲームチェンジャーだ。これがGell-Mannの忘却効果ってやつの可能性はどれくらいあるんだろう？教科書的な定義に聞こえるね。個人的には、逆のことが真実だと思う。LLMは、自分が何をしているかを正確に知っているときだけ助けてくれる。

この記事は、大規模な世界的サービスのデプロイ時間を過小評価してるね。通常、デプロイの戦略は小さな「爆風半径」を持って段階的に進めるもので、時間制限もある（「焼き上げる」ってやつ）。それに、デプロイでしか見つからない障害や修正も考慮されてない。Pythonのようなプログラミング言語は、Javaでのインジェクション（例えばGuiceを使う）を利用する場合、完璧なテストが必要だし、全てのテストチームは20年前に開発に回されたか、コンパイラや静的解析が提供できるサポートを壊す魔法の方法が必要なんだ。だから、6ヶ月のデプロイの中で4週間の開発を取って、AIを使って6週間のデバッグとリトライを追加することになる。どういたしまして、これで300万トークンになるけど、そのうち1kはあなたが書いたもので、残りはシステムのプロンプトや「推論」で、あなたがコントロールできるものじゃない。このAIの領域は修正可能だけど、誰も投資したがらない、特に過去のミスからの分野ではね。

この記事は、AIが開発フェーズにしか影響を与えないと仮定しているけど、それは全くの誤解だよ。アイデア出し、法務、ドキュメント作成、開発、デプロイのすべてのステップを加速できる。アイデア出し：アイデアを出し合って、知識ベースと照らし合わせて、設計文書を生成する。ドキュメント：ドキュメントの大部分を生成する。開発：明確に。デプロイ：デプロイマニフェストを生成し、テスト周りのツール、クラウドプラットフォームに関する知識を得る。どのステップもAIを使えばもっと良く、早くできる。全部ではないけど、多くの部分で。開発もそう。確かに、あなたの仕事の一部は、誰よりも問題を理解して解決策を作ることだけど、単純な作業もある。もしXをするボタンが必要だと分かっているなら、そのボタンをデザインして配置し、ホバーやプレス状態のエッジケースを考え、バックエンドに接続するなどは、スキップできる作業だよ。ほとんどのステップにこの原則が当てはまる。

└

AIを効果的に使う人々に、その効果を他の人に証明する責任はないよ。実際、こうした意見の不一致は市場に機会を生み出している。

└

その通り。人々は全てが数字だということに気づいていない。プロジェクトに関わる人々の平均IQが140だとすると、IQ150のAIはそのパイプラインにいるすべての人を再現できる。AIがこれをできない、あれをできないと言っている人たちは、このIQの差が一貫して広がっている事実を受け入れるべきだ。

└

上記のポイントは、私たちの組織の経験と一致しています。でも、もう一つ大事なことがあるんです。今は、物理的なプロセスで無理やり解決していた問題に対して、ソフトウェアソリューションを作れる人が増えてきたんですよ。（私たちは小さな製造業です。）これらは大規模な企業プロジェクトではなく、深いソフトウェアエンジニアリングの経験を必要としないシンプルなツールですが、プロセスや生産性を向上させているのはすごいことです。出荷担当が、以前は多くの労働時間をかけていた問題を解決するための特注ツールを作れるようになると、本当に驚くべきことが起こりますね。

└

記事に同意するな。新しい重要な機能を追加しようとすると、ビジネスとの間で多くの会議（数日、数週間、数ヶ月など）が必要になるのが典型的な例だよ。システムX、Y、Z間の作業の流れや、重要な例外（例えば、Aのサブセットはこう扱い、Bのサブセットはああ扱うけど、最終ステップではそれらを混ぜる。ただし、Cのサブセットは特別なプロセス97が必要）を理解するためにね。そうやって理解が得られたら、複数のシステムにまたがるシステムソリューションを考えることになるんだけど、内部システムやベンダーのシステムが混ざっていて、それぞれカスタマイズのレベルが違うから、最終的なソリューションの形がいろんな方向に変わってしまうんだ。コーディングを早めることには確かに価値があるけど、それはパズルの一部分に過ぎないし、今のところLLMはドメイン情報を集めたり、ソリューションを定義したりするのには役立たないよ。

この投稿は、エンジニアの役割が機能のギャップを埋めることだけのように聞こえるけど、エンジニアは機能の実現可能性にも責任があることを完全に無視している。もし機能のリクエストが来ても、現在のシステムの制限を理解しているなら、ビジネスの枠組みに合った解決策を考えるのがあなたの仕事だよ。でも最近は、エンジニアが管理に抵抗を示すことがスキル不足として描かれ、管理がスタッフを信頼していないことが問題だとは見なされなくなっている。管理が実際に何もクリアしないことが明らかになると、自己宣言されたミッションの背後にある本当の動機が見えてくる。もし管理の受け入れ基準があなたの原則に合わないなら、あなたは合わないかもしれないし、私の意見では、管理の受け入れ基準はほとんどが投資家への次の約束や見込み客への営業によるものだから、彼らの目標はお金を稼ぐことであって、質の高い製品を開発することではない。

そう思うよ。主な問題は、開発者がこの技術の影響を最も直接的に受けていることだね。採用できること、採用したいと思うこと、そして技術が開発者に関連する問題に対して非常に優れていることが組み合わさっているのはユニークだよ。ビジネスの他の部分も最終的には追いつくと思う。リアルタイムでその様子を見ているけど、ほとんどの場所では非常に遅いね。でも、確実に進んでいる。開発者が1年分の作業キューを午後のうちに片付けても、ビジネスの他の部分がその影響を同じタイムフレームで吸収できなければ意味がない。とはいえ、ビジネスはあなたのアイドル作業キューを長く放置することはないよ。どんどん吸引していけば、最終的にはそのスペースが埋まるから。

いい説明だね。AIが毎回正しいプログラムを生成するわけじゃないのは確かだけど、残念ながらソフトウェアエンジニアリングのあらゆる側面にAIを取り入れるのが一般的になってしまった。おかげで、ソフトウェアエンジニアはプロダクトマネージャーになり、彼らの仕事はコード全体のデバッグやテストに変わってしまって、余計にフラストレーションが溜まるんだ。全体的には大丈夫だけど、ガントチャートのサイズはもっと広げるべきだね。

ハクソク