コードを書くことは決してボトルネックではなかった
(ordep.dev)- ソフトウェア開発におけるボトルネックはコードを書くことではなく、コードレビュー、知識移転、テスト、デバッグ、協業/コミュニケーションなど、さまざまな人間中心のプロセスで発生する
- LLMのおかげでコード生成そのものは非常に容易になったが、むしろ理解、検証、信頼にかかるコストと負担はさらに大きくなっている
- 速いコード生成は、レビュー担当者・統合担当者・保守担当者により大きな負担を与え、チーム全体の速度が実際に速くなるわけではない
- コード理解こそが最も難しい部分であり、LLMがコードを生成しても、チームの信頼とコンテキスト共有なしに品質は保証されない
- LLMはプロトタイピング・自動化には強力だが、慎重な設計・レビュー・コンテキスト共有など、ソフトウェア開発の基本を置き換えることはできない
コード記述の本当のボトルネック
- 長年にわたり、コードを書く作業そのものはソフトウェアエンジニアリングのボトルネックではなかった
- 実際のボトルネックは、コードレビュー、メンタリングとペアプログラミングによる知識共有、テスト、デバッグ、協業・コミュニケーションのコストで発生する
- チケット管理、プランニング会議、アジャイルミーティングなどの複雑な手続きが速度をさらに遅くする
- 品質保証のためのこれらのプロセスは、実際にはコードを書くこと自体よりもはるかに多くの時間と思考を要求する
- しかしLLMのおかげで、動作するコードを生成するコストは0に近づいている
- その一方で、コードの理解、テスト、信頼確保のコストはむしろ高くなっている
- 初期実装の速度は上がったが、より多くのコードがレビュー/統合/保守の対象となり、負担は増している
LLMは仕事の本質を変える ― なくしはしない
- ClaudeのようなLLMツールは初期実装の速度を高めてくれるが、結局はより多くのコードがより短時間でシステムに流入することで、レビューや保守の担当者により大きな負担を与える
- 特に次のような状況でこの負担は深刻化する
- 作成者本人が、自分で登録したコードを十分に理解しているか不確かである
- 生成されたコードが見慣れないパターンだったり、既存の規約に違反していたりする
- 境界条件や意図しない副作用が明確に表れていない
- その結果、コード生産は容易になっても、検証の難易度はさらに上がり、結果としてチーム全体の速度を引き上げることはできない
- もともと開発者の間には**「コピー＆ペースト・エンジニアリング」**という冗談があったが、LLMによってこの現象ははるかに増幅されている
コード理解こそが本当の難しさ
> 「コードの最大のコストは、書くことではなく理解することだ」
- LLMのおかげでコード生産そのものは速くなるが、動作を推論したり、微妙なバグを見つけたり、長期的な保守性を担保したりする作業が容易になるわけでは決してない
- 特にレビュー担当者が生成コードと手書きのコードを区別できなかったり、選ばれた解法の理由を把握しにくかったりする場合は、さらに難しくなる
チームは依然として信頼と共有コンテキストに依存している
- ソフトウェア開発は基本的に協業を前提としており、共有された理解とアラインメント（Alignment）、メンタリングに全面的に依存している
- コードが議論やレビューの速度よりも速く生成されると、チームは実際には品質を確認していないにもかかわらず、品質がすでに検証済みであるかのように錯覚してしまう
- これにより、レビュー担当者やメンターの心理的負担が大きくなり、チーム全体の速度が新しい形で遅くなる可能性がある
LLMは強力だが本質は解決できない
- 高速なプロトタイピング、scaffold、自動化においてLLMの価値は大きいが、明確な思考、慎重なレビュー、深い設計の必要性をなくしてはくれない
- コードを書くコスト自体は下がったが、チームがコードを共に理解し、意味を与えるためのコストは変わっていない
- 本当のボトルネックは、依然として「理解と協業」にある
7件のコメント
まさにこの記事で紹介されているようなスキルが不足していて、LLMに強く依存している開発者です。
技術知識が足りず、AIなしではWBSに合わせて業務を進めるのが難しい状況なのですが……
せめて先輩開発者のレビュー時間を減らすために、私に何ができるでしょうか……？
ついでに自分の知識も蓄えられるといいのですが……
レビュー時間を短縮したいなら、自分が書いたコードがどんな背景から生まれ、さまざまな実装方法の中からなぜそれを選んだのかを自分で判断し、説明できる必要があります。そうするには、3.を週末や空き時間に継続して取り組む必要があり、有名なライブラリや他の人がGitHubに上げたコードをランダムに眺めながら、コード構造や実装スタイルのようなものを分析してみるとよいです。
温かいお言葉、ありがとうございます！！
それでも人員を減らしているのを見ると暗たんたる気持ちになります.. プロジェクト12件を4人でどうやれというのか.. そのうち1人は管理もしながら..
しくしく ご苦労が多いのでしょうね
Hacker Newsの意見
経験豊富なメンターとして、野心は大きいがまだ未熟なインターンたちを指導する中で、1日で1週間分、あるいは2週間分のコードを吐き出す様子を目にしてきた。だが、私の仕事は以前よりむしろ難しくなった。コードレビューの際、インターンたちは自分が書いたコードについて深く考えていないため、私のフィードバックがうまく伝わらない。単純なバグや些細な問題はほとんどなくなったが、残る問題はより微妙で複雑で、説明するのもずっと難しい。しかも、これまで見たことのない新しい種類のバグまで現れる。見た目はまともなコードが実際にはまったく動かなかったり、完成度が高そうに見えても基本的な部分から壊れていることが多い。LLMと協業するジュニアは、単純で議論の価値があるコードを出すのではなく、さまざまな面で協業と保守に問題を起こす複雑なコードを、一見完成したもののようにまとめて作ってしまう傾向がある。その結果、1つのPRを最終品質まで磨き上げる従来の「漸進的改善」というやり方がうまく機能していないように感じる。フィードバックを与えると、元のPRを直すよりもまったく新しいアプローチを提示してくることがあり—しかもそれが別の新たな問題を生むことも多い。結果として、この1つのPRにジュニアよりもシニアのほうがはるかに長い時間を費やすことになる。ジュニア側は自分が非常に生産的だと感じるかもしれないが、シニアレビューアのフィードバックが以前ほど温かく励ます雰囲気ではなくなっていく現象もある。結局、多くのテストケースを必須にしたことが多少は効果的だったが、このテストさえも似たような問題で限界に突き当たる
この「完成度が高そうに見えるのにまったく動かない」コードを見て、以前私が関わった25万ドル規模の海外ソフトウェア開発プロジェクトを思い出した。仕様書だけ見ればすべて正しいように見えたが、実際にはまったく一貫性のないシステムだった。仕様書の解釈にばかり執着して常識的な部分を見落とし、結局プロジェクト全体を即座に破棄したことを覚えている。今ではこうしたことがLLMのおかげで自動化され、無料化されているのが印象的だ
この問題には完全に共感する。私自身の経験でも、LLMを使えば数千行のコードを非常に速く作れるが、本当に難しいのはコードレビュー、バグ修正、セキュリティ脆弱性の点検、リファクタリング、不要コードの削除などだ。結局は自分で直接コーディングしたほうが生産的な場面が多かった。LLMは自動補完や簡単な断片の生成にだけ使うのが最も現実的な使い方だ。ジュニアがLLMを間に挟み、そのうえ私がさらに伝達役をしなければならないなら、効率はむしろ落ちる気がする。現在LLMでより生産的だと感じている人たちは、実際にはこうした重要な作業をそもそも飛ばしているか、気にしていないからそう感じているのかもしれない。実際に製品品質を気にする少数の人たちだけが、膨大なコード量を受け止める負担を背負わされる。彼らは不必要に厳しい人だと誤解されることもあるが、実際にはユーザーに最良の製品を届けようとする本当の主役だ。改善策は特になく、むしろ状況はさらに悪化しそうだ。LLMだけを使って訓練された開発者が業界に流入し続け、ツールを作る会社は誇張されたマーケティングを続ける。結局、品質維持の負担だけが増えていく構図だ
シニアが1つのPRにジュニアより多くの労力を注ぐようになる「effort inversion」という現象を、私も経験している。私の場合、PR担当者たちがブログ記事やプレスリリースの作成にAIを使っていて、テーマの専門家である私が成果物を受け取ると、あらゆるAIハルシネーションや誤りを修正するために作業時間が3倍、4倍に増える。彼らの仕事は本来私を支援することなのに、今では私が彼らを助ける立場になっている。しかもAIハルシネーションは毎回違うので、そのたびに新しく苦労する。この現象はすでに役員にも伝えたが、この調子ならPR人員の半分は来年いなくなる気がする。メールをコピーしてChatGPTに貼り付け、また私に送り返す役割が不要なら、自分でやれる
「レビュー中に私のフィードバックがうまく伝わらなかった」という部分について、もう少し詳しく説明してもらえないだろうか。似た問題を経験していて、解決策や洞察があれば共有してほしい
私の考えを付け加えると、前の世代はリファクタリングやユニットテストを通じて、ソフトウェアの構造や設計に対する深い理解を自然に積み上げていたのだと思う。だが今後、LLMがユニットテストまで生成するようになれば、開発者は「自分には何が必要なのか？」「これをもっと単純にするにはどうすればいいのか？」といった自己省察や学習をする機会を失うかもしれない。私が考える「開発者」「エンジニア」「アーキテクト」の違いはまさにそこにある。LLMや「vibe coding」は、その種のマインドセットを決して育ててくれない。Goのように文法の負担が少ない言語では、こうした設計ミスがレビューでより見えやすい。Goのユニットテスト構造は、コード複雑性の診断に有用だ。結局、私たちにはより良いテスト／レビュー手法が必要だ。ファジング、単体テスト、統合テストだけでは不十分だ。コードの分岐が正しく呼び出されているか、満足条件が成立しているかを論理的に確認してくれる自動テストフレームワークが必要だと思う
LLMのおかげでソフトウェアの新規導入コストはほぼ0に近づいているが、そのコードを深く理解し、テストし、信頼するコストはかつてないほど高くなったように感じる。ただ、私の経験ではLLMが作ったコードが、すでに去った人が残していって質問すらできない大量のレガシーコードや、ネット上に転がっているコードと比べて、そこまで著しく悪いとは思わない。むしろLLMはテストコードを書くのを人間のように面倒がらないし、疲れて適当に済ませることもない。私の哲学は「すべてのコードは潜在的な負債である」という前提から出発する。だからコードの信頼性をそれほど心配してはいない。実際、AIで巨大なコードベースを作りながら十分に動かしたこともある—ただし、ドメインが検証可能で、テストと反復が多い場合に限る。結論として、LLMの成果物によってコード生産は速くなったが、コーディングそのものの知的刺激は減った感じがして、私の脳も一緒に怠けていくように感じる。むしろ要件定義や設計といった前段の頭脳労働が、はるかに重要な時代に移っている
LLMがなくても、業界はすでに「コード不足」ではなく、市場需要と資本の制約によって開発速度に限界がある状態だった。ツールが良くなりすぎて、コーディング自体は核心ではなくなったのだ。初期とはまったく違う環境だ。Bill Gatesが10代だった頃、単に「コードを書ける能力」それ自体が希少資源だった時代の逸話を思い出す。会社が切羽詰まって16歳のGatesとPaul Allenを雇い、彼らが単に速くコードを書くというだけで驚いていたという話だ。今では「何を開発するのか、そしてそこにビジネスが成り立つのか」がより重要な問題だ
関連動画
コーディングがボトルネックではなかったのは市場需要のせいだという主張に同意する。AIブーム以前にMarc Andreessenも「資本は余っているが、投資すべき良いアイデアが不足している」と言っていた。私はその言葉が現実を正確に反映しているとは思わないが、少なくともデータ上は彼の発言にもっともらしさがある
Bill Gatesの昔の逸話のように、今でも高品質なコードを書き、それを深く理解する能力は希少資源だ。ただ以前と違うのは、業界がその能力をそれほど重視していない空気があることだ
AIのインパクト分析の観点から見ると、私たちは効率性を過度に過信しがちだ。だが現実の経済はそれよりはるかに複雑な構造でボトルネックが発生する。コード生産量が100倍になったとしても、それが実際に有用かどうかは不明だ
最近こうした体験談を見ると、とても憂鬱になる。ジュニアが動かず、実際にテストも検証もせず、簡潔に磨き込むこともしていない巨大なコードの塊を、文書やコメントや説明もなく渡してくるなら、それ自体がすでに「LLMが人間に載った版」と表現できる。結局重要なのは批判的思考と結果に対する責任感だ。むしろLLMのほうが、従来のジュニアソフトウェアエンジニアよりフィードバックに忠実に反応する可能性すらあると思う
私もかつてはコードを書くことがボトルネックだと思っていたが、10年やってみて本当に難しいのは技術をビジネスに整合させることだと気づいた。B2BやSaaSのように顧客ごとに異なる複雑なコードの山を扱う環境でも、技術がビジネスにきちんと合っていればすべては順調に進む。今や技術は十分に進歩したので、真の鍵は開発者の「エゴ」と、顧客価値に集中する姿勢だ。顧客が本当に欲しいものは何か、そこにお金を払うのか、そもそもWebインターフェースが必要なのかまで考えるべきだ。開発者が自己満足のために作る「猫じゃらし機能」こそが、クラウドコストを増やす本当の原因だ。さらに悲しいのは、強いインセンティブやストックオプションや高給を与えても、この本質的な問題は解決しないことだ。ソフトウェアを良く作りたいという「使命感」を持つ誰か、少なくとも1人は顧客と直接対話し、きちんとやり切ろうとする意思が必要だ
組織でLLMが本当に役立った瞬間は、私の個人プロジェクトやサイドプロジェクトだった。小さな問題を解決するアプリを開発するとき、時間が足りず、コードを書くことが実際に大きなボトルネックになる。こうしたプロジェクトではLLM活用度は100%だ
私も完全に同感だ。1日1〜2時間Claude codeに投資すると、週末が終わる頃には実際に使える成果物が1つできている。短い時間投資でアイデア検証や実験がしやすくなる。こうしたLLMツールは、実際にプロの組織でも非常に大きな価値を生むと思う。普段は時間不足で作れなかった各種の管理ツールや自動化システムも、素早くプロトタイピングできる。チームメイトがDBクエリや簡単な自動化を必要としているなら、Claudeに聞いてレビューし、そのまま貼り付ければいい。こうしてエンジニアでなくても自分の領域の反復作業を自分で処理できるよう支援するのが、私のプロジェクトmcp-front[0]の目的でもある
mcp-front GitHub
正直、今の自分のキャリアの状況では何週間も注ぎ込むのは難しく、長年のノウハウから非機能要件や長期的な観点まで常に考えている。テストのようなものを省いたとしても、結局ずっと考え続けることは多い
Robert C. Martinの「コードを読む時間は、書く時間の10倍以上多い」という名言を思い出す
関連引用
残念ながら、彼のクリーンコード流儀は、実際には文脈を断片化してしまい、意図をかえって把握しにくくすることも多い
さらに悪いのは、書く時間だけ減って読む時間ばかり増え、全体の作業量が減らないかもしれないことだ
誰も触れていないJoel Spolskyの2000年10月2日の文章を紹介したい
Joel on Software: Painless Functional Specifications (2000)
本当のボトルネックはコードではなく、機能仕様（spec）だ。ソフトウェアがどう動くべきかを、英語、図、ユーザーストーリーなどで明確な仕様として作ることのほうが重要だ。仕様がしっかり固まっていれば、LLMでも十分に優れたソリューション、テスト、統合テストを一度に作り出せる。大きすぎるなら、仕様はMarkdownファイル1つで管理するのではなく、Wikiのように機能ごとに分割し、リンクや参照で管理すべきだ。実装の難しさではなく、仕様にどれだけ力を注いだかこそが本当の競争力だ
筆者は著者の見解に同意しない。大企業の観点ではコードはボトルネックではないかもしれないが、スタートアップの立場では資源が限られており、効率的なプランニングがより重要だった。つまり、実際に正しく動くコードを作る作業そのものが最大のボトルネックだったケースも多い。結局、この種の議論で「AI/LLMがどれほど有用か」を一般化することはできない。あるチームにとってはコードがボトルネックであり、別のチームにとってはそうではなかった
みんなが知っているように、LLMが生み出すコードはひどいことが多く、レビューすら不可能な場合がある。ジュニアが提出したLLMコードがおかしいので理由を尋ねても、本人もわからず、LLMが作ったと答えるだけだ。結局こうした流れは、コード保守に「ノイズ」と「オーバーヘッド」を増やすだけだ。もしLLM導入を避けられないなら、レビューや保守もLLMに任せるしかない。もちろん結果はさらに複雑なスパゲッティになるだろう。しかし現実には、大半のビジネスでは品質がそれほど重要でないことが多く、LLMコードがそこそこ動けばそれで十分と見なされる。あるいは必要なだけLLMを継ぎ足していき、最終的に解決できる程度で十分だと考えられている