ハクソク

世界を動かす技術を、日本語で。

コードを書く速さが問題だと思っているなら、もっと大きな問題があります。

45日前原文(andrewmurphy.io)

概要

  • AIコーディングアシスタント導入による生産性向上への誤解
  • ボトルネック理論（Theory of Constraints）の重要性
  • コード出力増加が必ずしも価値提供速度を上げない現実
  • 真のボトルネックがどこにあるかの見極めの必要性
  • 価値提供プロセス全体の最適化の重要性

AIコーディングアシスタント導入の幻想

  • VP of EngineeringがAIコーディングアシスタントの導入を熱弁
  • 「コード出力が40%増加」という指標に現場が困惑
  • 本来の目的（velocity toward what?）が議論されず
  • 既に速い工程を更に高速化し、システム全体の最適化を見失う状況
  • ボトルネックでない部分の最適化が全体を悪化させる危険性

Theory of Constraints（制約理論）の教訓

  • **Eli Goldratt著『The Goal』**に基づく制約理論の基本
  • システムには**必ず一つの制約（ボトルネック）**が存在
  • ボトルネック以外の最適化は全体の生産性向上に寄与しない
  • 非ボトルネックの高速化は在庫（WIP）増加・混乱・品質低下を招く
  • 生産性向上の錯覚による実害

コード出力増加がもたらす現場の混乱

  • PR（プルリクエスト）レビューが追いつかず滞留
  • レビュー担当者の増員・プロセス改善なし
  • 文脈喪失・レビューの形骸化による品質低下
  • CI/CDパイプラインの遅延、デプロイ承認の停滞
  • WIP（作業中在庫）増加、本質的な価値提供速度（サイクルタイム）の悪化
  • 「コードは増えたが、出荷は減った」という逆転現象

さらに悪化する理解不足とリスク拡大

  • AI生成コードの理解不足、責任の所在不明確化
  • インシデント発生時の対応困難化
  • 表面的な生産性ダッシュボードと実態の乖離
  • 知識伝達・保守性低下による将来リスク

真のボトルネックはどこか？

  • コードを書くこと自体がボトルネックであることは稀

  • 価値提供プロセス全体を俯瞰する必要性

    • 1. 何を作るべきか分からない問題

      • ユーザー理解・要件定義の曖昧さ
      • 間違ったものを高速で作るリスク
      • 仮説検証・フィードバックループの欠如

    • 2. コード完成後の停滞

      • PRレビューやQA、承認プロセスでの長期停滞
      • 実作業時間より待機時間が圧倒的に長い現実

    • 3. デプロイへの恐怖とバッチ化

      • リリース失敗体験によるリリース頻度低下
      • バッチサイズ増大→リスク増大→更なる遅延の悪循環

    • 4. 出荷後のフィードバック不足

      • 実際に価値が届いたかの検証不在
      • 次の開発も仮説ベースの繰り返し

    • 5. カレンダー依存の調整コスト

      • 意思決定待ち・承認待ちがボトルネック化
      • 組織構造・調整コストが開発速度を決定

取るべきアクション（地味だが本質的な改善策）

  • バリューストリームマッピングの実施

    • アイデアからプロダクションまでの全工程を可視化
    • 各工程の実作業時間と待機時間を記録
    • サイクルタイムの計測・改善

  • 出力ではなくサイクルタイムの計測

    • コード量・PR数・ストーリーポイントではなく
    • **「ユーザーに価値が届くまでの時間」**を指標化

  • ボトルネックの特定と重点改善

    • 非効率な会議・承認フローの見直し
    • デプロイプロセスの自動化・信頼性向上
    • ユーザー理解・要件定義プロセスの強化

  • 組織・文化的な課題へのアプローチ

    • 責任の明確化・ナレッジ共有
    • フィードバックループの構築

  • AIツール導入はボトルネック解消後に検討

    • 局所最適化ではなく全体最適化を意識

このように、AIコーディングアシスタントの導入やコード出力増加に一喜一憂する前に、本質的なボトルネックの特定と改善が不可欠です。全体最適化こそが、真の価値提供速度向上への道となります。

Hackerたちの意見

> 問題を理解することがボトルネックなんだよね。どんなに速くタイプしても、それは解決しない。なんでだろう？速くタイプすることで、どうして問題を早く理解できないの？ > この環境でコードの出力を速くすると、間違ったものを作る速度が上がるだけなんだ。間違ったものを速く作ることで、どうして正しいものを早く見つけられないの？この例では、どちらにしても間違ったものを作るつもりだったよね？私はよく、自分が何を求めているのかを理解するために何かを作るけど、プロトタイプを作るのが安くなればなるほど、その傾向が強くなってる。 > 間違った機能を速く作って、出荷して、失敗するのを見て、誰かが「ユーザーともっと話す必要がある」と言って、みんなが真剣にうなずくけど、結局何も変わらないんだよね。たぶん、みんなシニカルだからかな。
└
> どうして速くタイプすることで、問題を早く理解できないの？逆立ちしたらどうなの？
└
> どうして間違ったものを速く作ることで、正しいものを早く見つけられないの？顧客は通常、単位時間あたりに許容できる失敗の回数が限られてるから。フィットネス関数を実行するのは、他の人の時間を考えるとかなり高コストなんだ。これはB2B/SaaSの銀行業界での最大のボトルネックだよ。もし本当に良いクライアントがいれば、週に一回くらいはイテレーションできるかもね。
└
問題を理解する前に実装に取り組んでるからじゃない？
└
>なんで？ 速くタイピングすることで、問題をもっと早く理解できるってことはないの？ 速くタイピングすることで、問題を早く理解できる例（おもちゃみたいなやつでもいいけど）ある？
└
>なんで？ 速くタイピングすることで、問題をもっと早く理解できるってことはないの？ 速く話すことで問題を早く理解できるってことはないの？
└
>なんで？ 速くタイピングすることで、問題をもっと早く理解できるってことはないの？ ある場合にはできると思うよ。例えば、最近ある機能のプロトタイプを作って、その統合をテストしたんだ。数時間かかったけど、オープンコードがなければ、これを試すことすらなかったし、成功することもなかったと思う。機能をテストしてたから、パフォーマンスやメンテナンス性、シンプルさにはこだわらなかった。問題の説明をより良く書けたし、それに取り組んでる人にも統合がうまくいくって保証できた。これは価値があったよ。でも、そのプロトタイプコードはすぐに捨てちゃったけどね。考える必要がなかったから。
└
AIが本当に得意なのは： 1. 何かを、過去に何度もやったことがある場合で、それを圧縮データセットの中から見つけられる時 2. 何かを求めていて、ざっくりそれが欲しいものであれば大丈夫 でも、実際にはこれがエンジニアにお金を払って書いてもらうソフトウェアの大部分ではないんだ。そして、実際にコードを書くことは、あなたが払っているものの一部に過ぎない - 大多数の人が思っているよりずっと小さい。外科医にお金を払っているのは、ただ切るためだけじゃないし、エンジニアにお金を払っているのも、ただコードを書くためだけじゃないんだ。
└
早いプロトタイピングは、プロトタイプが問題に接触させるときに役立つ。たとえば、ユーザーが「違う」と言ったり、デモの下で仕様が崩れたりする場合ね。もしループが自分がタイピングしてデバッグして磨きをかけるだけなら、リポジトリの中で大きな混乱を生んで、自分自身にその混乱が何かを教えてくれたと思い込んでいるだけだよ。コードは質問をする一つの方法であって、良い質問をした証明ではないんだ。時には、PMや顧客、チケットを書いた人との面倒な1時間が最善の手段だったりする。
└
> なんでダメなの？早くタイピングすることで問題を早く理解できないの？時には、ゆっくり考えないと理解できないこともあるよ。思考を数字のブラックボックスに委ねて、出てきたものをそのまま受け入れるのは、ゆっくり考えているとは言えない（つまり、じっくり考えること）し、目の前の問題を処理することでもない。逆に、トンネルビジョンに入って力技で進めているだけだよ。つまり、ショットガンコーディングってやつ。
└
元のアジャイルジョークを思い出すな、「30日以内に欲しくないソフトウェア」。今は「5日以内に欲しくないソフトウェア」だね。
企業は本当に良いコードを求めてないんだよね。個々のチームは、どれだけ多くのものを押し出したかで評価されるだけ。何かがうまくいかないかもしれないと警告する社員は、「細かいことにこだわりすぎ」とか「現実逃避してる」とか叱られるんだ。しばらくはこれが理解できなかったけど、企業内の内部関係者は本当に成功を主張したいだけなんだよ。
└
> 企業は本当に良いコードを求めていない。 もっと寛容に考えられるかもしれないけど、こう言いたいな。「企業は本当に良いコードを求めているけど、良いコードのメリット（将来の柔軟性、低いメンテナンスコスト）をコスト（デプロイの遅れ、機能の減少）と天秤にかけている。」各企業は自分たちが適切だと思うトレードオフを選ぶ権利がある。技術者は、リスクや理由を説明する責任があるんだ。弁護士が自分の専門分野でやるようにね。
└
彼らは良いコードには興味がないけど、良いコードに気を使う人にはたくさんお金を払ってる。雇った人たちが気にしなかったら、私たちのソフトウェアの品質は今より悪くなってるよ。そして、AIの影響で人々が気にしなくなってきているから、どんどん悪化している。
両方の意見には部分的に正しいところがあると思うけど、失敗のモードが違うんだよね。スピードは誤解を解決しないけど、理解に向かうイテレーションの速さは変わる。実際には、何かを作る（たとえそれが間違っていても）ことで、考えるだけでは得られないフィードバックループが生まれる。特にMLやLLMのようなシステムでは、行動がアイデアからではなくパイプラインから生まれるからね。本当のボトルネックはタイピングスピードじゃなくて、仮定をどれだけ早く検証できるかなんだ。反省なしの速いイテレーションは混乱を招くし、構築なしの純粋な思考は停滞を引き起こす。大事なのは、意図的な評価を伴うタイトなフィードバックループなんだ。
└
物を作るスピードが速くても、実際にはあまり役に立たないんだよね。必要なのはモデルとシミュレーションフレームワークだよ。従来のやり方では、通常はシンプルなモデルとフレームワークから始める。新しいパラメータを追加するときは、フレームワークを適応させて、バランスの取れた入力セットを見つけたら、どの新しいパラメータを追加したいかを考える。この反復がモデルやシステムの挙動を深く理解することにつながるんだ。LLMの使用は通常、全パラメータセットのシステムを構築することだから、スピードの向上はシステムの理解がないことや、シミュレーション空間が広すぎてユーザーが探索しようとしないことによって相殺される。シミュレーションのための完全なテストスイートについての話はたくさんあるけど、それは離散的で、入力空間の特定のポイントを証明するだけなんだ（有限のポイントを通過する曲線はたくさんあるから）。
人間の開発者として、私たちは「コードを手放す」ことに苦労してると思う。私たちが書くコード（またはエージェントが書くコード）は、解決策の中間表現に過ぎないんだ。たとえば、GCCは関数をインライン化したり、ループを展開したり、他にもたくさんの最適化をするけど、私たちはそれにこだわらない。GCCが生成するASMをレビューすることはないけど（しない）、私たちは「スパゲッティ」や「高い結合度」、「低い凝集度」については気にしない。大事なのは、それが機能していて、期待されることに対して正しいことなんだ。そして、それが私たちが達成しようとしている解決策の忠実な表現であること。高水準言語のソースコードは、もはやそれほど違いがない。エージェントがコードを書くけど、私たちはパターンを指導したり、明らかに間違っているときに修正したりするだけで、コードは徹底的な仕様、議論、提案レビュー、さらにそのレビューのレビューから生まれる作業アイテムの成果物に過ぎない。よく指導された反復プロセスと問題/解決策の説明があれば、人間がコードを書くかエージェントが書くかに関わらず、同等の実装を生成できるはずなんだ。
└
もし本当にそう思うなら、コードを直接アセンブリに変換すればいいじゃん。仲介者を省いて、パフォーマンスを一気に上げよう！
└
>高水準言語のソースコードは、もうあまり違いがないよね。ソースコードは、自然言語とは違って、ある意味で形式的な言語なんだ。
└
どの比較も意味がないよ。要するに、これらの概念を理解するのが重要だよ： - 決定論 vs 非決定論 - 概念的整合性 vs 「なんとなく動くから、触らないで」
└
これ、コピペの返答？ このサイトの他のAIスレッドでも全く同じことを見たことあるよ。
└
LLMが高水準の指示を低水準の指示に変換できるからって、コンパイラになるわけじゃないよ。
└
LLMでのコーディングを、ただスタックを上に移動するだけでコンパイラと変わらないように見せるのが本当に嫌だ。コンパイラは決定論的で、理解できるルールがある。出力を見ればパターンがわかるし、コンパイラが何をしているのか、なぜそうするのか、どこでそうするのかがわかる。そして、それをするのは決定論的なんだ。
└
高レベル言語で記述されたセマンティクスは、絶対に決定論的に維持される。エージェンティックコーディングでは、セマンティクスは決定論的に維持されない。拡張されたり、圧縮されたり、変更されたり、さらには失われたりすることもある；非決定論的にね。
└
> GCCが生成するASMをレビューする（私たちはしない） もちろん、しないよ。必要ないからね。高次言語をアセンブリにコンパイルするプロセスは決定論的で、よくテストされている。常に同じ結果を出すものをレビューし続ける必要はない。 > 私たちは、それが機能し、期待されることに対して正しいことを気にしている。そうだね。これがLLMの出力にはないものなんだ。なぜなら、誤解したり、幻覚を見たりすることがあるから。だから、常にレビューする必要がある。それがコンパイラの出力とLLMの出力の違いだよ。
└
私の経験では、そんなにうまくはいかないよ。複数回リモデルされた家に似てる。最終的には、その家の構造的なキャパシティが限界に達して、内装を全部剥がして再構築しないといけなくなる。今のところ、コーディングエージェントは間違ったパターンを選んだり、必要な抽象化や追加システムが必要なところで力技で解決しようとしたりする。いくつかのPRがあったからって問題になるわけじゃないけど、開発チームが常に貢献しているリポジトリでは、すぐに厄介なことになって、エージェントが技術的負債に苦しんでいるように見えることもあるかも。いつかプログラミング言語を書くのをやめられる日が来るかもしれない。考えさせられるアイデアだけど、実際にはまだそこまで行ってないと思う。
└
僕はちょっと違った見方をしてる。コードは解決策を伝えるための手段なんだ。 > 「プログラムは人が読むために書かれ、機械が実行するのは偶然のことだ。」 -- ハル・アベルソン これがないと、コンピュータやプログラムをもっと魔法のように扱うことになっちゃう。もし「エージェント」が何かを誤解して、その「誤解」をコードにしてしまうと、結果的に間違ったものになる。だから、詳細を見に行けるようにしないといけないし、ただ機械の神に犠牲を捧げるだけじゃダメなんだ。
そうだね、また問題を探している解決策（LLMs）があるって感じだね。物事を早く進めるための正しいアプローチは、「X、Y、Zを妨げている制約は何か？」って聞くことだと思う。管理側がAIのおかげで物事が早くなることを期待するのは「バイブマネジメント」だよね。魔法のツールのワクワクするプレゼンを見たら、考えたり理解したり、スタッフと話したりする必要なんてないって思っちゃうのかな？
└
これは明らかに違うよ。私の30年間のほとんどはこうだった。1. ビジネスと話をして、XY問題を解決し、組織の複雑さに対処し、ビジネスやそのニーズを学ぶ。2. 「コード」だけじゃなくてアーキテクチャを設計する、コードは何かで動かさなきゃいけないから。3. デザインを承認して、ホーリー・トリニティ（時間・コスト・予算）に合意する。4. 実装を行う。5. 既知の要件に対してテストする。6. ステークホルダーの承認を得るか、たぶん#4に戻る。7. 本番環境に移行する。8. メンテナンス。これらの中で、#4は常に必要な地味な作業だと思っていて、特にAI以前のエンタープライズ開発では、ほとんどの開発者の仕事が10年以上も商品化されてきたから。ビッグテックや関連するコードでも、他のステップを処理できず、大きな/影響力のある/あいまいなプロジェクトをリードできないと、中堅開発者のままだよ。#5に関しては、多くはAIによって書かれ、レビューされるべき自動テストで行うことができるし、そうすべきだよ。もちろん、UIやUXのテストには人間が必要だよね。LLMは今、たくさんの地味な作業をこなせるようになってる。
私はソロ開発者なんだけど、実際には開発者ってほどでもないかな。ただの役に立つスキルって感じ。コードを書くスピードは問題で、他の作業に貴重な時間を奪われちゃう。皿洗いみたいなもんだね。今夜、Claude Codeをセットアップしたばかりなんだけど、まだ全ての行を読んで理解できる。でも、Googleで調べたり、移動させたり、自分でテストを書く必要はないんだ。自分の意図を低レベルで伝えると、あとはやってくれる。生産性が10倍になるわけじゃないけど、少し時間が空くのは助かるよ。単なる労働節約技術で、万能薬じゃない。食洗機みたいなもんだね。
└
これ、かなり的を射てると思う。理想的には、コードを行ごとにレビューしなきゃいけない。テンプレートやジェネレーターみたいなもので、助けにはなるけど、10倍にはならないよ。要件の収集も10倍にならない限り、今のところAIはその影響を与えてないから。
└
タイトルの意図は、あなたの主な問題を指摘することなんだ。あなたを$PROFIT$から隔てている問題は、 1. アイデア 2. ??? 3. 利益 コーディングがうまくいかないのは確かに一つの問題で、AIがその問題を助けるのは正しい。でも、スタートアップや副業、VCへのピッチ、企業の内部事情（HNの人たち）にとって、コーディングは決して問題じゃなかったんだよ。
└
でも大きな違いがあるよね。食器洗い機は水とエネルギーを節約する技術なんだ。LLMが全部悪いとは言わないけど、食器洗い機と比較するのはあんまり良いアイデアじゃないと思う。
私は同意しないな。私は一人でReplitのクローンを数ヶ月で作ったよ。彼らは数億ドルの資金を持ってるし…ちなみに： https://playcode.io
私たち（私が働いているエンジニアリングチーム）がエージェントをもっと真剣に使い始めたとき、これについて心配してたんだ。コーディング時間は短縮できるけど、レビュー時間が遅くなって、結局サイクルタイムが増えるんじゃないかって。今のところ、明らかな変化はないけど、まだあまり時間が経ってないし、みんな新しいワークフローを模索中だから、平均化するためのデータはまだ足りてないと思う。でも、速いコーディングが本当に役立つケースも見つかってるよ：* アイデアやリファクタリングを試してみると、どうなるか教えてくれることが多い（エージェントが） * 複雑で面倒な置き換え（文脈によって見つけられないもの） * 進むべき道がシンプルだけど、たくさんの作業が必要なとき（面倒な作業） * ハッピーパスを構築した後のエッジケースの処理 * 追記：もう一つ大きなポイントを追加すると、追加するものが別のブランチ/PRの完全なアナロジーである場合、エージェントはうまくやるみたい（これは「シンプルだけど面倒」なケース）。ただ、最大の生産性向上の可能性は、エージェントがコーディングしている間に他のことができることだと思う。PRをレビューして戻ったときに、エージェントが作ったものをチェックできるからね。私たちは、非常に懐疑的だったところから慎重に期待するようになった。オーダーオブマグニチュードの違いが見られるとは思えないけど、2倍（これは大きい！）を期待してるよ。
こういう記事を読んでると、今は「否認」の段階にいる気がする。僕たちは、この変化が自分たちの技術にとって確実なパラダイムシフトだってことを受け入れるんじゃなくて、ネガティブな面ばかり探してる。
> 誰かが本当に読まずにPRを承認する。みんなやったことあるよね（そんな目で見ないで）。それがマージされる。CIは45分かかって、フレークなテストで失敗する。再実行されて、2回目の試みで合格する（フレークなテストは大丈夫、いつも大丈夫、でもそうじゃなくなる時が来て、土曜日の午前2時に下着姿で本番環境をデバッグしてる自分がいる。どうして知ってるか聞いてみて…実際、聞かないで）。デプロイパイプラインは、会議についての会議に出てる誰かの手動承認が必要なんだ。その機能は3日間ステージングに留まってるけど、「本番環境に持っていく」ステップを急いでやる人がいない。この会社で（もうすぐ働かなくなる）ことになったんだ。問題は、AIの使用すら許可されてないことなんだ。ほとんどのコードは人間が書いたって言われてるけど、ちょっと疑ってる。タイムラインは合ってるけどね。