ボトルネックの正体は、実は「コード」ではなかった件

パフォーマンス改善に四苦八苦してコードばかり追いかけていたけれど、真のボトルネックはそこじゃなかった。エンジニアなら一度は陥るこの罠、一度立ち止まって全体を見渡してみるのが解決の近道かもしれない。

何のためのボトルネック？機能追加？会社の成否がソフトウェアの量で決まるとは思わない。コンテキストの量を確保することもそれほど重要じゃない。大事なのはコンテキストの質。人間がどれだけ適切に推論できるか。次に態度、悪い状況にどう対処するか。それからリソース管理、人や金をどう扱うか。最後は運、コントロール不能な要素がどれだけ味方してくれるか。これらこそが企業にとっての真のボトルネック。エージェントがこれらを解決できるとは思えない。少なくともすぐにはね。

笑えるよ。キャリアを通じてずっと、チームの会議やアジャイルの儀式、イシュートラッカー、バックログ、Slack、メール、デザインレビューといった、「フロー状態」を妨げるあらゆるものを罵倒し、コーディングという聖域を守るためにそれらが必要不可欠だと主張していたエンジニアたちが、機械の方が速くコードを書けるようになった途端、恥じることもなく「コラボレーションの重要性」や「コーディングなんて二の次」みたいなことを説き始めている。彼らが間違っているとまでは言わないけれど、つい1年前までチームで最も非協力的だった人間が、これほど堂々と手のひらを返しているのを見ると、本当に異常だと感じるよ。

ベテランエンジニアなら、ベロシティの真の問題が技術面ではなく組織面にあることはずっと前から分かっていたはず。ビジネス側が的を絞った生産性の高いロードマップを定義できないことが、ソフトウェアエンジニアリングの長年の課題だ。ほとんどROI（投資利益率）のない流行り物にすぐ飛びつき、組織的な技術的負債を解消させないせいで、僕が働いてきた多くの会社は長期的にボロボロになってきた。

一体どんなプロジェクトに関わっていれば、マネジメント層が望む機能を理解することだけが難関で、あとは「打ち込む」だけ（今ならLLMに丸投げ）なんて状況になるんだ？もしそれが君の仕事なら、HNの多くの人が「LLMに取って代わられる」と考えるのも不思議じゃないね。

記事の引用についてだけど、「ジェヴォンズのパラドックス：何かが安くなると、それを使う量は減るのではなく増える傾向がある」。これ、ジェヴォンズのパラドックスの解釈が間違ってるよ。書かれているのはパラドックスじゃなくて、ごく自然な現象だ。何かが安くなれば利用が増えるのは当たり前。ジェヴォンズのパラドックスが実際に説明しているのは、リソースの利用効率が向上した（つまり、あるタスクに対して必要なリソースが減った）にもかかわらず、そのリソースの総消費量はむしろ増大してしまうという状況のことだ。

「ソフトウェアとは、人間同士がシステムに何をさせるか交渉した後に残る残骸である」という言葉、最高だね。特にコンテキストに関する部分は同意。経験豊富なチームが長く維持されていると、そこで真価が発揮される。僕も何十年かそういうチームを管理していたけど、部門が解体される時の末端エンジニアでさえ勤続10年だった。チームがそれだけ長く一緒にいれば、コミュニケーションコストはほぼゼロになる。今の使い捨てのような雇用文化には、本当にがっかりさせられる。最近はほとんど一人で仕事をしている。生産性は高いけど、スコープが極端に狭い。優れたチームにいた頃が懐かしいよ。

コードは負債だ。資産だと捉えがちだけど、本質的には負債なんだよ。新しいコードに対する「ボトルネック」のいくつかは、その負債を上回るリターンがあるかを確実にするために存在している。より多くのコードを速く生成するエージェントは、負債をより速く作り出していることになる。コーディングエージェントへの興奮や懐疑論の多くは、短期的な生産性向上（新機能）や利益が、長期的な負債の増大を上回れるかどうかという点にある。答えが出るのは1〜3年後だろうし、ドメインによっても結果は違うはずだ。この視点に立てば、エージェントのワークフローにボトルネックを組み込もうとする試みには理がある。プロジェクトの一貫したビジョンを重視し、安易な機能追加や制限のないプロセスにブレーキをかけるような文脈をエージェントに与えることは有益だろう。記事の意図はそこにあるのかな？エージェントにプロダクトマネジメントの責任を一部担わせ、一貫したビジョンを常にリマインドさせるようなことだろうか。あるいは、新しいプルリクエストが「全体像に適合しているか」をエージェントにレビューさせるべきなのかな。彼らは文脈を統合して、チームの価値観に沿ったもっともらしいロードマップを提示するのは上手いだろうが、優れたマネージャーやチームが持つ「審美眼」まで持てるとは思えない。特定のロードマップを迅速かつ納得感を持って承認させることが、かえって害になる可能性だってある。

その通りだけど、コードを書くことは常に何かを教えてくれる。スタートアップから数千億規模の公開企業まで働いてきたけど、仕様書やピッチデック、PRDに書かれた通りの解決策で問題が解決したことなんて一度もない。実際に作ることで、どう振る舞うべきかが分かるんだ。ソフトウェアは複雑な対話型メディアだからね。問題を理解し、解決を望む人たちとコードを反復改良していくことこそ、価値あるプロダクトを生む唯一の方法だよ。会議や図面も役に立つけど、実際に動作するソフトウェアを書くまでは、何が手元にあるのかすら分からないものさ。

「コードやコーディング能力なんて重要じゃない」なんて言われているけど、以前はデベロッパーの採用に膨大なエネルギーを費やして、彼らがどうコードを書くか、どう扱うかを厳しくチェックしていたよね。FizzBuzzは平均的なデベロッパーがいかに絶望的かを示す踏み絵だったし、コーディング面接こそがプログラミング能力を測る真の試験だった。それが今になって、あれらは全部意味がなかったって言えるの？時代が変わったことは認めよう（確信は持てないけど）。これまでは間違いなくコードとコーディング能力がボトルネックだった。でも、これからはそうじゃなくなるのかもしれないね。

本当にその通りで、最近毎日言ってるよ。Claude Codeを使えばデモアプリが速攻で作れるからって、本番システムも1週間で構築できると思い込んでいる人が多すぎる。コード生成自体は最初からボトルネックじゃなかったんだ。何を作るかを決めることこそが問題だったのさ。Claude Codeでアプリを作る時、君はコーダーであり、デザイナーであり、プロダクトオーナーであり、クライアントであり、宇宙のCEOでもある。光速で意思決定し、反復し、気に入らなければ即座に壊せる。2週間ごとのボード会議なんて必要なく、いつでも好きな時に戦略的かつ戦術的な決定を下せるからね。結局ボトルネックは、複数の人間が関わる時の意思決定とレビューなんだよ。特に、LLMベースのエージェントシステムを作ろうとしている時、結果が非常にバラつきやすく、品質を自動テストで検証したり進捗をベンチマークしたりするのが不可能な現状では、その傾向が顕著になる。