AIがあなたのプロセスをより速くすることはなさそうです
(frederickvanbrabant.com)- プロセス最適化の流れの中でAIに対する非現実的な期待が広がっているが、単にAIを導入するだけでは処理速度は改善しない
- ソフトウェア開発に時間がかかる本当の理由はコーディング速度ではなく、曖昧な要求事項を明確な問題定義へ変換するプロセスにある
- AIコード生成も同じ上流の問題に直面しており、正確な結果のためにはドメイン・プロダクト専門家の深い関与が不可欠である
- AI活用の比較事例でしばしば抜け落ちるハンドホールディング（handholding）の過程が実際の生産性格差を生み、人間の開発者も同じ詳細な文書を受け取れば生産性は急上昇する
- 真のプロセス高速化のためには、The Goalの教訓どおり**「ボトルネックに予測可能で高品質な入力を供給する」**ことが優先課題である
市場低迷下のプロセス最適化とAIへの期待
- 市場が低迷すると、多くの組織は少なくとも部分的にプロセス最適化へ注力する傾向があり、最近はそこにAIという要素と非現実的な期待が加わっている
- The Toyota Way と The Goal は、多くのプロセス最適化が何に注目すべきかを誤解しやすいことを思い出させる
- 時間のかかる区間は改善を始める合図にはなり得るが、問題が実際に発生している地点だと断定はできない
- 単に人を増やしたり、AIが大幅に速度を上げてくれると期待したりすると、なぜ作業が遅れているのかを見落としてしまう
- プロセスを速くしたいなら、作業者が実際に仕事を始めて終えられる入力と条件を備えているかをまず確認すべきである
視覚的なボトルネック（The visual bottleneck）
- Ganttチャートの例を通じて、最も時間がかかる段階がソフトウェア開発であることを視覚的に確認できる
- 本来はBPMNを使うのが一般的だが、説明を簡単にするためにGanttチャートで示している
- プロジェクトのスループット改善が目標であれば、最も時間のかかる段階を優先して見るというアプローチ自体は正しい
- 問題は人々がそれを解決する方法にある
- 人員を追加投入する（throw people at the problem）
- AIがはるかに速くしてくれると仮定する
- 肝心の**「なぜこの段階に時間がかかるのか」**を見ておらず、さらに重要なのは、所要時間が長いからといって原因がその段階にあるとは限らないという点である
上流で問題を解決する
- ソフトウェア開発を例にしているが、想定より時間がかかるあらゆるプロセスに同様に当てはまる
- ソフトウェア開発は単にタイピング速度を上げても速くならない。もしそうなら、誰もがタイピング講座を受けていたはずだ
- ソフトウェア開発の本質は、問題をコンピュータが自動で解決できるソリューションへ翻訳することであり、できるだけ安全かつ拡張可能な形で行うことにある
- そのためには問題に対する全体的な理解が必要である
- ウォーターフォール方式に近いなら、機能文書やスコープ文書が必要になる
- アジャイル方式なら、ドメイン専門家との継続的な反復（iteration）が必要になる
- 実際に開発を遅くしているのは、タイトルしかない曖昧な feature 要求が何を意味するのかを把握する過程である
- **「販売が完了したらユーザーにメールを送る（send mail to user once sale is completed）」**という要求も、すぐに実装できる要件ではない
- メールを送ることはできても、そのメールに何を含めるべきか
- 販売プロセスに問題があった場合、エラーメールも送るべきか
- 販売が「完了」する時点とはいつか
AIにすべて任せればよいという主張
- よく聞く主張は、AIコード生成によって開発段階を迂回し、ソフトウェア開発者はプロジェクトマネージャーの役割だけ果たせばよいというものだ
- 多くの人は、従来の長いソフトウェア開発工程が3日ほどのAI開発工程に置き換わると期待している
- 人々が期待するAI開発の完成形はあるが、実際にはそのようには機能せず、同じ上流の課題にそのまま直面する
- AIがコードを素早く生成できるのは事実だが（それが良いことかどうかは別の議論として）、速い生成がそのまま正しいコード生成を意味するわけではない
- 人間 vs AI の開発比較でいつも無視されるのは、AIがきちんと動くようにするための**ハンドホールディング（handholding）**の過程である
- この方法は従来方式より速い可能性はあるが、公正な比較ではない
- AI開発が機能するには、ドメイン専門家とプロダクト専門家のはるかに深い関与が必要になる
- すべての機能を非常に細かな詳細まで書き出さなければならない
- すべてのバグ修正でも、望む結果が何かを詳しく整理しなければならない
- これはまさに、ソフトウェア開発者たちが職業の始まり以来ずっと求めてきたこと、つまり問題と最終成果物に関する詳細な概要の提供である
- 人間の開発者に同じ分量の feature / scope 文書を与えれば、生産性も急激に向上するだろう
実際にプロセス速度を上げる方法
- プロセス速度を高めるには、仕事を行う人たちが実際にその仕事を遂行できる手段をすべて備えていることを保証しなければならない
- 法務承認プロセスが遅いなら、まず法務承認プロセスを開始するために何が必要かを見るべきである
- 不完全な文書のせいで5人を追い回さなければならない状況なら、その部門に弁護士を増員しても速くはならない
- The Goal の大きな教訓の一つは、ボトルネックは予測可能で高品質な入力を受け取るべきだということだ
- "bottlenecks should receive predictable, high-quality inputs"
- プロセス自動化の最初の出発点はボトルネック区間そのものではなく、ボトルネックが受け取る入力品質と予測可能性を高めることに置くべきである
1件のコメント
Hacker Newsの意見
ソフトウェア開発が最初から望んでいたのは「問題と望ましい結果を詳しく説明してもらうこと」だという話はあるが、実際にはそれ自体がソフトウェアエンジニアリングである
2026年になっても、十分に詳細な要件と仕様さえあれば完璧な解決策を一発で作れるという考えは捨てるべきだ
私の経験では、AIのおかげで機能やアイデアをずっと速く反復できるようになり、今では摩擦の大半は他チームとの足並み合わせと調整から生じている
プロセスを速くしたいなら、調整コストを減らし、個人やチームが判断して実行する権限をもっと持つべきだと思う
Anthropicでさえ、完璧な仕様、参照実装、何年にもわたって人間が書いた数千のテストがあったのに、動くCコンパイラのような単純なものすら作れなかった
現在のモデルは、完璧な仕様と完璧なテストがあっても、注意深い人間の監督なしに、取るに足らないとは言えない運用ソフトウェアを作れるほど十分ではない
完璧な仕様と人間が直接書いた完璧なテスト群がなければさらに難しくなり、おそらく2027年ごろには可能かもしれない
午後になるとプロダクト担当者が思いついた作業をよく受け取るが、彼らは正常系しか気にせず、ときにはその一部しか見ていない
グローバル企業なので各国の規制や法律を守らなければならないのに、機能を実装したあとで「実は我々が事業展開している市場の90%では法的にこれはできない」と言われ、無効化機能を付け直すことになる
すると今度は「そのうち一部の市場では規制手続きを踏めば可能だから、そう実装してほしい」と戻ってくる
締め切りが目前なので、結局は解決策をハック気味に修正するしかない
これはソフトウェアエンジニアリングではなく、ソフトウェアそのものとも関係がない
ソフトウェアエンジニアの仕事は要件一覧を受け取り、その要件をどう達成するかを見つけることであり、要件収集はソフトウェアエンジニアリングの問題ではない
ソフトウェアは実装であり、プロダクトは振る舞いであり、作る対象の振る舞いは本気で作り始める前に分かっているべきだ
誰かが1週間延期して実地調査をしていれば、スケール可能で、拡張しやすく、保守しやすく、将来をもっと楽にする構造を設計できたはずだ
最初のプログラムを書いてから40年以上になるが、先に仕様を完成させ、その後でソフトウェアを書いてすべてがうまくいった例を見たことがない
取るに足らないものではないエンジニアリングで最も難しいのは問題を理解することであり、ソフトウェアの初期バージョンはその理解に到達する手段だ
だからAIベースの「ソフトウェア工場」は決してうまく機能しないと思う
結局はウォーターフォールに戻るだけで、アーキテクトがUMLダイアグラムを書き、プログラマチームに本質的には単純な実装作業を渡すが、実際に実装されるのは間違ったものだ
AIは、間違った最初のバージョンから、少しだけ間違いが少ない二つ目のバージョンへ素早く進むのには非常に向いている
ただし、中心的な任務が解決しようとしている問題を理解することだという点は忘れてはならない
詳細な仕様だけ渡されるなら、ただのコーディングロボットでしかなく、そんな仕事はジュニアに回す
以前と同じく、私の仕事はその要件を読み、理解し、自分の知っている現実に照らして検証することだ
コードも同じだ
少なくともここ20年、ソフトウェアエンジニアリングの核心は誰も信用するなであり、これは変わっておらず、今でも多くの時間と労力がかかる
LLMが最初に出てきたとき、人々は「Facebookクローンを作って」といった感じで言えばいいと思っていたようだ
今では、要件をもっと正確に書き、よりよく定義しなければならないと気づき始めている
これこそが常にソフトウェアのボトルネックだった
昔働いていたときには「データを取ってきてユーザーに渡して」のような要件を実際に受けていた
どのデータなのか、どこに保存されているのか、どんな形式で返すべきかの定義がなく、プロダクト担当者と長い時間をかけて本当に欲しいものを探らなければならなかった
LLMでよい結果を得るにも似たようなことが必要で、曖昧な要件は曖昧な結果を生む
なぜその問題が存在するのか、たとえばバックエンドにはXフィールドがあるのにフロントエンドにはない、といった形でテンプレートを埋め、データをどこからどう取得するか、受け入れ基準は何かまで書く
以前なら怠慢や「開発者が何とかするだろう」という考えでやらなかったことだ
その後、開発者はこのJiraチケットの内容を好きなLLMエージェントにコピペするか、Atlassian MCPでLLMに自動で読ませることができる
これによって開発者には大きな助けになり、要件も非常に明確になった
正直、最初の段階だけ見れば、PMたちはすでに機能実装の半分まで来ているように思えるので、将来的にはPMが全部自分でやって、少数の開発者だけが完全な実装者というよりSDETのような形で残るのかもしれない
そこではバイブコーディングの中核的特徴と、今私たちがしている体験が正確に説明されている
慎重に選ばれた一部の領域で初期成功を収めたあと、その領域の外へ広がるにつれて、妥当ではあるが革命的ではない生産性向上が現れるという話だ
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
「Facebookクローンを作って」に近いプロンプトを使ったことはなく、代わりにどう動作すべきかを説明する
たとえば
/etc/hostsを読み、.confで設定された特定のホスト値を見つけ、各設定に名前を付け、現在の環境を判断し、Ubuntu 22標準のGNOME右上にアイコンを作り、クリックすると設定名を一覧表示し、選択時には/etc/hostsをバックアップしたうえで特定のホスト名の行だけを書き換えるPythonスクリプトを依頼したこれで単純なGNOMEアプリインジケーター環境切り替えツールがほぼ一発でできて、数行直せば大半は動いた
LLMにちゃんとした仕様を与えればうまく作るし、欲しいものを説明するために偽のDSLを作っても理解してくれる
以前のプロセスがうまくいかなかった理由は、要件作成者がビジネス意図を理解していなかったか、不注意で曖昧または質の悪い要件を出していたからだ
LLMは同じ曖昧で質の悪い要件をもっともらしく見せるだけで、深掘りすると問題が露呈する
「『データを取ってくる』とはどういう意味ですか？」のような質問が出る
LLMはただ「もちろんです！ データを取得してユーザーに渡す完成コードはこちらです」と言って終わる
この記事はAIが開発段階にしか影響しないと仮定しているが、それは明らかに事実ではない
アイデア出し、法務、ドキュメント化、開発、デプロイを含むすべての段階を高速化できる
アイデア出しではアイデアを出し合い、知識ベースと照合し、設計文書を作れるし、ドキュメント化では文書の大部分を生成できる
開発は言うまでもなく、デプロイではデプロイマニフェストやテストツール、クラウドプラットフォーム関連の知識を作れる
すべての段階がAIでもっと良く、もっと速くなり得るし、全部ではなくても多くは可能だ
開発も同じで、問題を誰よりも理解して解決策を作る部分もあるが、純粋に雑務な部分もある
ボタンがXをすべきだと分かっているなら、そのボタンをデザインし、配置し、hoverやpress状態の例外を考え、バックエンドにつなぐ作業は飛ばせる雑務であり、ほぼすべての段階に同じ原理が当てはまる
新しく重要な機能を追加しようとすると、通常は業務担当者と何日、何週間、何か月も会議して、システムX、Y、Zの間で仕事がどう流れ、重要な例外が何かを理解しなければならない
たとえばサブセットAはこう処理し、Bはああ処理するが、最後の段階では両グループを統合し、ただしCには特別プロセス97が必要、といった具合だ
その理解をもとに、複数システムにまたがるシステム解決策の設計が続き、内部システムとベンダーシステムが混在し、各システムのカスタマイズ可能性の度合いが異なるため、最終的な解決策の形はさまざまな方向に引っ張られる
コーディング速度を上げることに価値があるのは確かだが、それはパズルの一片にすぎず、現在のLLMはドメイン情報を収集して解決策を定義する助けにはなっていない
もう一つあるのは、今では以前なら物理的な手順で力業で押し切っていた問題を、より多くの役割の人たちがソフトウェアツールで解決できるようになったことだ
私たちは小さな製造業者なので、深いソフトウェアエンジニアリング経験が必要な巨大な企業プロジェクトというわけではないが、単純なソフトウェアツールがあちこちでプロセスと生産性を改善している
出荷責任者が、以前は多くの労働時間を溶かして解決していた問題を、カスタムツールで解けるようになると、本当に驚くようなことが起きる
ソフトウェア開発にAIをかなり使っているが、より速くリリースできているわけではなく、似たような理由や別の理由でむしろ遅くなっている気さえする
ユートピアが来るのを待っている妙な感覚だが、それは来ず、どこが問題なのかも正確には指摘しづらい
むしろ、こうした意見の不一致や不信感こそが市場での機会と突出点を生む
プロジェクト参加者の平均IQが140なら、IQ 150のAIはパイプライン内のあらゆる個人を複製できる
AIにはこれができない、あれができないと言う人たちは、このIQギャップが単調に広がっているという事実を受け入れるべきだ
一方では、この記事は大規模組織で技術職をしている多くの人が考えていて現場でも見ていることを、正確に説明した簡潔な文章だ
著者に110%同意するし、他の人たちにもこの記事の内容を理解してほしい
他方では、HNでも実際の職場でも、最近こういう話を何十回もしてきた気がする
リーダーたちには、AIが本当にスピードを上げると装う社会的・金銭的インセンティブがあるので、ブログ記事ひとつでは説得されないだろう
だから今は、彼らのAIプロジェクトが失敗するか、既存プロジェクトと同じように遅く進むのを待ち、そこから何か学んでくれることを願うだけだ
会社でこういう記事を共有することさえためらうようになっていて、現状維持に合わない内容は受け入れられにくい感じがある
ビジュアル資料やGanttチャートは、まさにPMが理解できるPMの言語だと思う
Cレベルと投資家がイノベーションのシグナル送りを続ける限り、すぐには解決しないだろうが、そういうものも永遠には続かない
それで最近は庭仕事をしつつ、エージェント型ツールで個人のコーディングプロジェクトにのめり込んで時間を過ごしている
最初から高性能なOLTPデータベースを作ったり、新しい論理関係型の永続プログラミング環境を作ったり、風変わりな数学ベースのシンセサイザーやFPGAソフトプロセッサを作ったりしている
ありふれた人たちがやる、ありふれたことだ
だから、一人の手に渡ったときにこれらのツールが何をできるかは分かっていて、本当に驚異的だ
しかし会社勤めの友人たちから、最低トークン割り当てを決めたり、「スターAIコーダー」リーダーボードを作ったり、「コードレビューするな」「手でコーディングするな」と言ったりしている話を聞くと、首をかしげてしまう
冬に少し契約仕事をしたが悪くはなかったものの、創業者が毎週末ごとに新しいプロジェクト全体をバイブコーディングする間に、コードレビューはLLM同士の決闘のようなものへと劣化していた
これらのツールはチームワークや、本当の意味でのチームソフトウェアエンジニアリングにはあまり向いていない
業界が整理されるまでは、ひとまず距離を置いて眺めているつもりだ
働くのに良い場所は、「ゆっくりやれ！」と言える、そしてそう言っても持ちこたえられる年長で賢い人たちがいる場所だけだろう
その間、オンタリオ州ハミルトン地域で切ったルバーブを1束5ドルで販売中だ
アスパラガスもあるし、たくさんある
興味深い二面性がある
すでに得意なことではLLMは相対的にあまり影響がないが、自分が苦手なことではとてつもないゲームチェンジャーだ
大企業はプロジェクトに必要なほとんどの役割を採用できるので、全体としての効果は相対的に小さいだろう
せいぜい、一人で五人分の仕事を中途半端にこなして人件費を下げる代わりに、より悪い製品を得る程度かもしれない
短期的利益と長期的コストの組み合わせがどうなるかは目に見えている
しかし、小さなスタジオや個人開発者にとって、LLMは大きな変化だ
五人分を中途半端にでもこなせることは、その役割なしで耐えることや、サードパーティ資産や他人のコンテンツに頼ること、もっと悪ければ即興でひどいものを作ることに比べて、はるかに大きな飛躍だ
プログラマがデザイナーなしで配置したのが明らかな、ほとんどすべてのプログラムUIを見れば分かる
あるいはDribbbleで何かを真似しようとしても、腕が足りない場合もそうだ
AIを使えば、突然あらゆるものやあらゆる人をもっともらしく真似できるようになり、実際それこそがAIのほぼ全体的な動作原理でもある
教科書的な定義そのもののように聞こえる
個人的にはまったく逆だ
LLMは、自分が何をしているかを正確にすでに分かっているときにしか役に立たない
取るに足らないものではないソフトウェア開発がコーディング50%にも満たない、ということを人々はあまり理解していない
コーディング段階はたいてい最も簡単な部類で、ジュニア開発者に任される
大きな組織では、ほとんどの製品変更が複数のシステムと人の運用をまたぐ
シニアやミドルレベルは、おおむねローカルな優先順位を既存のサイバネティックな存在の中で新しい並びに合わせ、各自の優先順位を持つ他チームからその新しいビジョンへの合意を得ることに時間を使う
そこには当然、多くのトレードオフと政治が入り込む
シニアエンジニアたちは、自分が責任を負うシステムに「重み」を足すことを避け、スコープ追加や意図した進行方向からの逸脱を防ぐために強く戦う
だから妥協が必要になったり、優先順位の選択のために経営陣へエスカレーションしなければならなかったりする
AIがこれも解決できるのかは分からないが、それははるかに難しい仕事だ
今ではツール呼び出し者なので、コーディングエージェントはlint、型チェック、テストを実行してそのエラーを直し、Sentryのような可観測性プラットフォームを掘って根本原因を見つけ、ベンチマークを回して遅いコードやホットパスを見つけ、使っているライブラリの新しいメジャーバージョン向けマイグレーション文書を読んで適用し、システムを最新の状態に保てる
こうしたものがエージェントに逆圧をかけ、システムをよりよく理解させるように構成されていなければ、ただの愚かなLLMコード書きのままだろう
しかしモデルとハーネスが急速に改善している状況では、明らかにそこからずっと先まで進める
この記事はおおむね正しく、AIがプロセスをもっと速くするためにどこへ集中すべきかのヒントを与えている
たとえば、あるプロダクトマネージャーが、ステークホルダーとの会議が終わるときにインタラクティブプロトタイプが出てこなければ失敗と見なされる未来を想像していると言っていたが、方向性としては正しいと感じる
もう一つ予想しているのは、バイブコーディングが「Excel 2.0」になることだ
対話型アプリをかなりセルフサービスで作れるようになり、ITはそれをより良いセキュリティ保証、適切なアクセス制御とロギング、スケーラビリティ、変更管理などを備えたものに変えようとする終わりのない戦いに入る
もっと大きな歴史的視点で見れば、あらゆる革命的転換は初期に「蒸気の馬」を生み出す
蒸気機関が発明された当時、人々は交通の未来を、蒸気で動く馬の形をした物体が既存の荷車を引くものだと想像していた
後になって初めて、私たちは交通の機能をその形から切り離して理解するようになった
もともとMOOCについて話すときに蒸気の馬と言い始めたのだが、MOOCは典型的な蒸気の馬の発想だった
プロトタイプを作るのにコードは要らない
シーンを収めるのに俳優やカメラが必須ではなく、何枚かのスケッチで足りるのと同じだ
提示されたGanttはウォーターフォールモデルか、ソフトウェアに最終目的地があるとみなす別の方法論の例だ
今日のソフトウェアの99.999%はそんなふうには作られていない
現代のソフトウェア開発に目的地はない
2週間単位でビジネスがソフトウェアに求めることを変える
新機能、新しい統合、変わった機能、アップグレードまたは置き換えられた構成要素、より大きな規模、別のホスティングが次々に生まれる
数年たつとソフトウェアは根本的に変質し、品質とテストは窓の外へ投げ捨てられる
その場しのぎで変更に対応するだけでなく、エントロピーと戦う絶え間ない苦行が続く
ソフトウェアは傷つき、生活様式が変わり、老いていく生き物になる
会社は憂鬱な動物を生かし続けようとする動物園の飼育員のように、その怪物を管理する保護者になる
人間は習慣の生き物なので、AIを使っても同じ問題はすべて起きるだろう
ただし、すべてが少し速くなり、コードレビューでコードが少しだけ良くなるかもしれない
同時に、良いテストの欠如と、より速いデプロイへの欲求が、すべてを少しだけ悪くするだろう
この綱引きの結果、ソフトウェア品質はほぼ同じままだが、少しだけ速く動くようになる
結局のところ、より速いプロセスは生まれるだろうが、残りは依然として苦行なので、誰も大して実感しないだろう
おそらく全員がもっと速く燃え尽きる可能性が高い
複雑なのには理由があり、その理由を取り除かない限り複雑性は取り除けない
ツールでビジネス上の問題は解決できない
「AIはコードを速く生成できても、それが正しいコードを生成することを意味しない」という話について、実際にはコードはほぼ常に正しい
気に入らないのは、たいていコードの追加のされ方だ
コードベースを十分よく知っていれば、どこに追加すべきか、どう命名すべきか、コメントをどれだけどこに付けるべきかといった儀式がある
エージェントがそれをうまくできないと、私のような人間はいら立つし、AGENTS.mdに書いてあっても失敗するようだ
「人間の開発者に同じ量の機能・スコープ文書を渡しても生産性は急上昇するはずだ」という話は、ITで20年近く働いてきたが、絶対に起こり得るとは信じられない
仮に起きるとしても、あまりにまれで議論する価値がない
すでに書かれたシステムを複製するのにかかる労力と、そのシステムをゼロから作るのにかかる労力を比べればよい
特に入力がバグや性能問題のとき、しばしば幻覚を起こし、手取り足取り導かなければ誤診する
それでも何をしているかを見守り、正しい方向へ押してやれば、根本原因分析や分析自体はうまく、効率も高められる
人間は機械に比べて情報を消化・分析する速度に限界があるので、生産性向上にも天井があると思う
AIがプロセスを迂回しなければならないわけではないが、それでも速度を上げることはできる
リファクタリング、定型コード作成、これまで見たことのないエラー発見、リンターが拾えないものの補助ができる
多くのコメントは、標準的に知られたプロセスを使っていないか、AIを使えばその標準に従う必要がないと仮定しているように見える
より多くのコードや機能を出荷できるかといえば、良い要件と十分なテストがあるなら、当然できる
AIが書いたすべてのコードはレビューとテストを通すべきで、分離されたコミットとプルリクエストに分けるべきだ
数千行のPRを上げる人は危険信号だ
AIなしでもそんなことはしないのに、なぜAIを使ったからといってそうするのか
大規模な書き換えやリファクタリングだけが知られた例外だが、その場合でも、変更過程を見られるように切り替え可能な個別コミットがあったほうが、よりよい判断ができると思う
巨大な一発コミットやPRを見せられたら却下する
普通の開発者が監査できる断片に分割すべきだ