ハクソク

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

AIはエンジニアの生産性を10倍にしていない

293日前原文(colton.dev)

概要

  • AI時代の10xエンジニア神話 による不安の実態解説
  • AIコーディング体験の現実 と期待値のギャップ
  • 10x生産性の数学的な非現実性 の指摘
  • 本当に価値あるエンジニアの特徴 についての考察
  • AI活用の現実的なメリットと限界 の整理

AI時代の10xエンジニア症候群の克服

  • SNSや業界の噂 による「AIで10〜100倍生産的なエンジニア」神話の蔓延
  • 自分のスキルへの不安 と「置いていかれるのでは」という焦燥感
  • 最新AI（Claude, Cursor, Roo Code, Zed等）を実際に試用 した体験
    • AIは定型的なコード生成やスクリプト作成に強み
    • プロジェクト固有の文脈や特殊な言語（Terraformなど）には弱い
    • ライブラリの誤利用やセキュリティリスク、文脈把握の限界
  • AI活用のコツ
    • タスク分割などの基本的な使い方はすぐ習得可能
    • AIの出力が的外れな時は自分で手綱を握る判断力が重要
  • AIを使いこなすこと自体は難しくない
    • 1週間もあれば中級エンジニアなら十分適応可能
    • 「AIを使わないと時代遅れ」は誇張

10x生産性神話の現実

  • 「10x生産性」とは1クォーター分の成果を1.5週間で出すレベル
    • 実際の開発プロセス（レビュー、QA、デプロイ等）のボトルネックは解消されていない
    • 人間が関与する工程はAIで10倍速くならない現実
  • コード執筆自体が作業全体のごく一部
    • AIが生成するコードはしばしば誤りや基準未達、再修正が必要
    • 大規模コードベースではエラー頻度が増大
  • 「10x」の規模感の誤解
    • 10倍は「ミニバンと音速ジェット」の違いレベル
    • 現実には信号待ち（人間的な工程）が大半の時間を占める

本当に価値あるエンジニアとは

  • 10xエンジニアの本質
    • 不要な作業を未然に防ぐ力（PMとの対話、設計判断、ドキュメント整備等）
    • チーム全体の生産性を底上げする仕組み作り
    • 特定状況で10倍の価値を発揮するが常時ではない
  • AIアシスタントの限界
    • 不要な作業防止よりも「量産・過剰実装」を助長しがち
    • 設計判断や本質的な価値創出は依然として人間の役割

AIポスターは嘘をついているのか？

  • AI万能論を煽る人々の内訳
    • 善意の自己過大評価者
    • AIビジネスに利害のある関係者（起業家・投資家等）
    • 従業員を不安にさせたい経営層
    • 単なる計算ミスのエンジニア
  • AIによる「一時的な10倍生産性」は確かに存在
    • 例：ESLintルール自動生成など、年1回レベルの単発タスク
    • ただし、恒常的な業務ではすぐに限界にぶつかる
    • 本質的なスキルや知識習得が不可欠な場面は必ず訪れる

まとめ：AI時代のエンジニアの価値

  • AI活用で局所的な効率化は可能だが、万能ではない
  • 本質的な価値は「不要な作業の削減」「チーム全体の底上げ」にあり
  • AIへの過度な期待や不安は不要、冷静な自己評価と継続的な学習が重要
  • AIを使い倒しても「恐竜」にはならない、むしろ本質を見極める力が問われる時代

Hackerたちの意見

期待は現実より高いけど、LLMは色んな場面でかなり役立つよね。「ズームレベル」で使い方を考えると、高い方は「雰囲気コーディング」で、低い方は「引数と返り値を考慮してこの関数を書いて」って感じ。俺の経験では、ズームインすればするほど、うまく機能すると思う。あと、LLMにはコードを書く能力を補強する以上の使い道もあるし、新しい技術を学ぶのにも役立つよ。成果は役割に応じたタスクの分布に依存する。例えば、会議が多かったり、コードをプッシュするのに管理業務が多いと、LLMの助けは少なくなるかな。（ただ、プルリクエストのワークフローやコミットの整理・再配置にLLMを適用するのは、すぐにでも来ると思うけど。）

これって、平均的なソフトウェアエンジニアが自分たちを暴露してる感じがするよね。自分が作ってる技術を知っていて、作業をうまく分けられるなら、複雑さがどこにあるか事前にわかるし、AIにどのレベルで作るか指示できるんだ。AIは魔法じゃないから、例えばSonnet 4が一度に書けるプログラムの複雑さには上限がある。もしその限界を理解できて、自分のプロジェクトの技術も把握していれば、AIにその閾値を下回る個々のコンポーネントを作るように指示できる。これがうまくいくんだよね。

└

でも、難しいのはもっと複雑な部分を見極めることだよね。それを正しく理解するのに時間がかかるんだ。

└

ここでの含みは、自分を平均以上のエンジニアだと思ってるってこと？

この記事には結構同意する部分が多かったな。俺はAI支援の開発にはかなり賛成だけど、10倍の生産性向上の主張には納得できたことがない。LLMが俺の仕事の中でコードを打つ部分で2〜5倍の生産性を上げてくれると見積もってるけど、それ自体がソフトウェアエンジニアとしての仕事の小さな部分に過ぎない。この記事の前提ともあまり離れてないと思う。この記事からの引用: > 「AIが多くのエンジニアに特定のタスクを20〜50%早くこなさせるのは驚きではないが、ソフトウェアのボトルネックの性質から、これは20%の生産性向上にはつながらず、もちろん10倍の向上にはならない。」これは過小評価だと思う。実際にこの技術をうまく使えるエンジニアは0.2倍以上の向上を得るはずだけど、ソフトウェアを作る上での他の要素が多いから、10倍の話はほとんどの場合非現実的だと思う。

└

これは（たぶん）10倍エンジニアへの言及だね。これはずっと疑わしい神話だと思ってる（https://www.simplethread.com/the-10x-programmer-myth/）。

└

コメントありがとう、サイモン！正直、この記事をちゃんと読んだ人のコメントはこれが初めてだわ。特にLLMが得意な言語やツールに関わってる人たちが、仕事の特定の部分で2倍の改善を得てるっていう考えには全然賛成だよ。

└

そうだね。ちょっと手をかけすぎる必要があるんだ。Copilotはいい提案をくれるし、時々は自分が打つのと全く同じコードを出してきて驚くこともある。でも、実際にコードを書かせると（少なくともgpt4.1やgpt4oでは）俺にはあんまりうまくいかない。半分の確率でコンパイルすら通らないし、直した後も正しく動かないことが多い。もっとジュニアなプログラマーのように動いてほしいんだけど、実際には全然話を聞かない酔っ払ったシニアプログラマーみたいな感じだよ。

└

AIを使っての一番の気づきは、(1) 日常の仕事では、創造性を高めるわけじゃないけど、発見や学び、行き詰まりから抜け出すのに役立つし、面倒なコードを書くのも助けてくれるってこと。(2) でも、一番のメリットは副業がめちゃくちゃ楽になること。AIがなかった頃は、副業に時間をかける余裕がなかったけど、今はアイデアが形になるのが見えるし（コードはちょっとひどいけど）、精神的な負担も少なくて済む。締切やデータプライバシー、ツールの制約なしにAIエンジニアリングスキルも磨けるしね。

└

GenAIを使った経験では、Stack Overflowよりもかなり改善されてるし、一般的には新卒の人を雇ったのと同じくらいの能力があると思う。以前知ってたことの文法やライブラリを思い出すために使うと、すごく便利。まだやったことのないことを探るときには速くなるけど、時々嘘をつくこともある。それはStack Overflowでも同じだった。でも、かなり複雑なことを自分でやらせると、たいてい失敗する。いろんなモデルでいろんなテストを試したけど、いつも完璧にはいかない。小さなミスなら修正できるけど、ひどい結果になることもあって、結局捨てる羽目になることも。例えば、Webベースの計算機やWebGLを使った太陽系の3Dモデルを作ってもらおうとしたけど、試したモデルはどれもできなかった。

└

2〜5倍の主張もかなり疑わしいと思う。もしチームがAIを使っているなら、他の条件が同じなら、四半期で2〜5倍の成果を上げるってことになる。でも、自分はそんなの見たことないし、チームのほとんどがAIを使ってるよ。[そして、使い方が間違ってるって言ってる人には…反論できないものに対しては何も言えないよね]

└

でも、その10倍の主張には納得できたことがない 誰がそんな主張をしてるの？

この記事で一番の洞察だったのはこれだね：10倍エンジニアって実際に存在するの？「この議論にはあまり関わりたくないけど、関わらざるを得ないかも。俺の答えは、時々、ちょっとだけ。10倍の価値があるエンジニアがいたとしたら、それは主に不必要な作業を防ぐ能力によるものだった。実現不可能なタスクからPMを引き下ろすことや、別のエンジニアに不必要なマイクロサービスを作らせないこと。すべてのタスクで少しずつ時間を節約できるような開発者体験への投資。将来のエンジニアがすぐに作業に入れるように自分の作業を文書化すること。これらのことが時間をかけて積み重なって、1人のエンジニアが会社全体で10倍の時間を節約することにつながる。」本当にそうだよね、テックリードが効果的に交渉して、機能のあらゆる側面に対してコストの少ない解決策を創造的に提供できると、たくさんの価値と利益が得られるんだ。

└

実現不可能なタスクからPMを説得する うちのEMの一人が今週やったことだ。彼はかなりの下調べをして、いくつかの専門家に話を聞いて、結局そのタスクは彼のチームには難しすぎるって気づいた。PMやVP、Cレベルに働きかけて、無駄な作業をたくさん防ぐことができた。開発者にとって一番大事な言語は英語だと思うけど、* s/英語/あなたの好きな言語/g

└

10倍エンジニアの存在は、実際に会うまでは誰も信じないもので、彼らはめちゃくちゃ珍しいから、会ったことがない人が多いのも納得できる。俺が働いてた会社の共同創業者は、しばらくの間そうだった（今はもう10倍エンジニアじゃないけど、人生の制約があるから、あの生産性をずっと維持するのは無理だと思う）。彼は文字通り、数百万行のシステムの大部分を作ったんだけど、そのコードのほとんどは今でもほとんど変わらずに動いていて、ユニコーンレベルのビジネスを支えてる。正直、信じられなかったけど、その瞬間に立ち会ったんだ。もう一人、もしかしたらそうかもって思った人に会ったけど、彼は会社を早く辞めちゃったから、はっきりとは分からなかった。AIが10倍エンジニアを生み出すとは思えない。なぜなら、その共同創業者が素晴らしかったのは、アーキテクチャに対する第六感みたいなものを持ってたからで、普通の人はもっと時間をかけたり、試行錯誤で学んだりしないといけない。彼はただコードを書いて、書いて、初めての試みでうまくいったって感じ。ほんとにユニークな存在だよ。AIはしっかりしたコードを生成できるけど、今のところその仕様をうまく決めることはできないし、大規模なアーキテクチャについて推論することもできないし、何百もの機能の実装を通じてその推論を維持することもできない。

自分は10倍エンジニアだとは思ってないけど、会社の他のエンジニアより生産性が高い理由は、システム設計やビジネスニーズを考えるときに、適当に書かれたプロダクトチケットをそのまま受け取らないパターンを使ってるからだって気づいた。AIを使っても、同僚たちがシンプルなことを複雑にしすぎる痛みからは救われてないみたい。AIはこれを解決してくれないね。

└

自分は2倍エンジニアだとは思ってない。会社が自分に同僚の2倍の給料を払わないってことは、実際に2倍以上の成果を出してるって知ってるし、他の人もそう思ってるけどね。AIを使ったところで、この状況は何も変わらないよ。

自分は古い人間だけど、このPSAを投稿する気持ちは強い。「No Silver Bullet」をもう一度読んでみてほしい。多分、2〜5年ごとに再読をスケジュールするべきだよ、こんなクレイジーで疲れる時代には特に。彼の元々の主張は今でも真実だと思う。「技術や管理手法の中で、単独で生産性や信頼性、シンプルさを10年以内に1桁向上させることを約束するものはない。」この数年、誤解されたり曲解されたりしてるけど、「エージェンティックコーディング」は大きな改善を約束する単一の開発だって感じる。結局、役立つかもしれないけど、決して銀の弾丸じゃないよね。

└

同意。これが「ノー・シルバー・バレット」に関するHNの投稿の一つだよ： https://news.ycombinator.com/item?id=32423356

AIのおかげで、サイドクエスト的な生産性がすごく上がってる。やるべきことはたくさんあるけど、面倒くさいんだよね。でも、やりたいことでもある。そういうのはAIが得意だよね。モックを作ったり、テストを作ったり、いくつかのことをライブラリに抽象化したり、ドキュメントを整えたり。だから、1日で2週間かかる機能を出してるわけじゃないけど、2週間で余計な便利さがついた機能を出してる。現実はそういうもので、完璧になる前にリリースすることが多いけど、リリース時には少し完璧に近づいてる。これで、余計にやった作業が将来のバグ発見セッションを減らしてくれるといいな。

AIのおかげで、あるタスクでは100倍生産的になって、他のタスクでは2〜4倍、全く効果がないタスクもある。AIが得意なタスクを見極めて任せるのが、戦いの95%だね。

先日、chatgpt（o3）にいくつかのタスクオーケストレーションシステムを比較して、俺が気にしてる変数（人気、機能の豊富さ、耐久性、セルフホスティングできるかどうかなど）に基づいて整理してもらったんだ。結局、俺が使ったのは https://www.inngest.com/ で、これは俺にとって新しいツールだったんだけど、そのおかげで特定のタスクが少なくとも10倍速くなった。これは一度きりのプロジェクトだから、一般化は難しいけど、LLMの特定の強みが時間を大幅に節約してくれるケースを見つけ続けてる。（別の例としては、技術面接の質問に対する回答を作成・評価すること）。これが簡単に定量化できるとは思わないけど、重要なことだよ。これはOPに反論するためじゃなくて、エンジニアにとっても、スピードアップが期待したところに現れないかもしれないってことを指摘したいだけ。 [EDIT 同じポイントを指摘してるコメントが他に4つくらいあるのを見た :)]

中心テーマには異論が出しにくいね。生産性向上の主張が自己報告であることはしばしば誤解を招く。今後の道は数学と意味のある測定だよ、これは繰り返し言うべきこと。最近のソフトウェアでは、ゼロから80〜90%の機能を実現するのが非常に簡単だと感じる。だから、AIがその波に乗ってるのかもしれない。ソフトウェア開発は成熟してきていて、AIを使っても使わなくても、ソフトウェアを作るのが10〜100倍速く感じる。これは、共同作業ツールやコンパイラ、言語、オープンソースの手法などで大きな飛躍があったからだと思う。