コードは大量に出力された、だが見合った“成果”は出ているのか：及川卓也からエージェント時代の開発者たちへ（10）（2/2 ページ）

米トップテック各社が、社員のAI利用に次々ブレーキを踏み始めました。これだけ使って、成果は出ているのか。AIはコードという出力を爆発的に増やしましたが、それが価値に変わっているかどうかは別の話です。今回は「出力と成果のズレ」を掘り下げます。

[及川卓也，Tably株式会社]

　自分自身を称賛したいように思われるかもしれませんが、実は私は2年前、既にそれを指摘していました。2024年に開かれた「開発生産性Conference 2024」での話です。開発生産性とは、ざっくり言えば「開発チームがどれだけ速く、安定してソフトウェアを届けられるか」を測り、高めようという考え方です。エンジニア不足が深刻になる中、少ない人数で成果を出すための経営テーマとして、当時にわかに注目されていました。

　そうした中、冷水を浴びせるような形だったかもしれませんが、開発生産性とは投資に対するリターンだ、と前置きして、私はこう言いました。「アウトプットではなく、アウトカム。何を作ったかではなく、どのような価値を生み出したか」「ゴミをいくら作っても意味はない」「コードの向こうに、ユーザーを見よう」。

　当時、どのくらいこの言葉が響いたか分かりません。あまり話題になりませんでしたし、開発生産性に関する議論で、アウトカム向上を目指そうという話もさほど聞こえてきませんでした。

　ところが、AIがこの構図を一変させました。出力だけが爆発的に増えた結果、「これだけ作っているのに、成果に結び付いていない」という事実が、もう誤差では片づけられない大きさで表に出てきたのです。AIは、問題を作ったわけではありません。実は前からあった問題を、隠せない大きさまで膨らませて、私たちの目の前に突きつけたのです。

私たちは、ずっと「出力」を成果と呼んできた

　ここで私は、少し意地になって反証を探しました。ところが、探しても探しても出てきません。私の探し方が悪いかもしれませんが、出てくるのは、生産性が何割上がった、コードの何割をAIが書いた、レビューが何割速くなった、どれも出力の話ばかり。収益が伸びた、顧客の課題が解けた、というところまで線を引いたものが見つかりません。

　なぜ、出力の話ばかりになるのか。私たちが頼ってきた物差しが、そもそも出力しか測っていないからです。Four KeysやDORA、SPACEといった、開発の現場でおなじみの指標はどれも優秀ですが、見ているのは「どれだけ速く、多く出せるか」、つまり出力です。それをいつのまにか「成果」と呼んできた。けれど、いくらデプロイが速くても、その機能を誰も使わなければ、事業価値はゼロです。2年前の講演のスライドには次の言葉が残っています。「使用頻度の少ない機能のFour Keysが、いくら高くても意味はない」。

　これは、数字にも表れています。Deloitteの2026年の調査では、AIで生産性が上がったと答えた組織が66%、なのに収益が伸びたと答えた組織は20%。46ポイントの開きです。Uberの「線が引けない」は、1社の話ではなかったのです。手応えを感じている現場はあるでしょう。でも、その手応えが出力のものか成果のものかを分けないと、量を成果と取り違えているだけかもしれません。この「見当たらなさ」こそが、問題の正体だと私は思います。

回路をつなぐのは「組織の知」

　手がかりはDORAにあります。AIは「増幅器（アンプやブースター）」だ、というのです。組織の強みも弱みも、そのまま増幅する。ナレッジの薄い組織では、薄っぺらい出力が増えます。顧客理解の浅い組織では、その浅さが増えます。裏を返せば、ナレッジと顧客理解という土台のある組織でこそ、出力から成果への線は引けます。回路をつなぐのは、トークンの量ではなく、組織の知です。

　もう一つ、回路の流れを妨げるものがあります。「何を作るか」の入口です。作るコストが下がった分、丁寧に考えずにとにかく出して反応を見ればいい、そんな声をよく聞きます。一理はあります。でも、顧客の本当のニーズから逆算せず、ただ乱発するだけなら、出力がいくら増えても、成果は一向に積み上がりません。

　個人的には、（Xでも書きましたが）「とにかく出して反応を見ればいい」ということをされたユーザーは、たまったものではありません。ゴミをそのまま世の中に放流しないでほしいものです。

計器を、張り替える

　では、どう直すか。やるべきことは計器の張り替えです。速く作ることと、正しいものを作ることは別です。前者はAIにより大きく改善しました。開発生産性という形で測る計器もあります。でも後者を測る計器を持っていないことが多いのではないでしょうか。計器がなければ、組織は測れるもの、つまり出力だけを最大化します。だから、立場ごとに1つずつ、計器を足したいのです。

　手を動かす開発者なら、見るのは生成量ではなく「廃棄率」です。AIが書いたコードのうち、すぐ取り消したり大きく書き直したものがどれだけあるか。その比率を数えるだけで、出力と成果の距離が見えてきます。

　開発者を束ねる立場の管理職なら、出力の数字（スループットやトークン消費）と成果の数字（収益や顧客の課題解決）を、同じダッシュボードに並べないこと。混ぜれば、測りやすい「出力」が測りにくい「成果」を必ず押しのけます。成果の指標がまだなくても、「AIが関わったリリースのうち、使われ続けている機能の割合」のような暫定値で十分です。支出の上限にも目安があります。開発者のサイモン・ウィルソン（Simon Willison）は、Uberの月1500ドルという上限を、エンジニアの報酬のおよそ1割に当たると試算しました。その1割が成果に見合っているかを、時々問い直せばいいのです。

　経営の立場なら、AIへのお金を「出力を買う」から「変換に投資する」へ組み替えること。トークンをいくら買っても、価値に変える仕組みがなければ、回路は詰まったままです。張り替えは、事業の根っこにまで及びます。例えば、SIerならば、売り物の単位を、出力（工数）から成果へ移します。計器の張り替えの、いちばん深いところです。

　ここまでの処方（「廃棄率を見る」「ダッシュボードを分ける」「上限を引く」）は、回路の詰まりを取る手当てです。大事な手当てですが、それだけでは足りません。支出管理もナレッジの整備も、煎じ詰めればコストを正す話で、価値そのものを生むわけではないからです。価値が生まれるかどうかは、もう一段手前の問いにかかっています。

　極端を承知で言います。本当は、自分が書くコードの一行一行が、いくらの価値を生むのかを考えられないといけない。さらに言えば、書く前に、それが生む価値を見積もって、その価値が、大量のトークン、つまり高価な半導体と、それを動かす電力と二酸化炭素を焚くに値するのかを、考えないといけない。そこを問わずに作り続ければ、私も、他の多くの人も言うとおり、私たちはAIでゴミを量産することになります。

　私たちは、AIがどれだけ「使われたか」を語る数字なら、幾らでも持っています。次に問うべきは、それが何を「前に進めたか」です。コードは幾らでも作れるようになりました。忘れてはいけないのは、その向こうにいるユーザーと、届けるべき価値の方です。

　その「前に進めたか」を問い続ける仕事だけは、多分私たち全員に残ります。不思議なのは、コードを書く側ではAIを全力で走らせているのに、「何を作る価値があるのか」を見極める側では、AIも、自分の頭も、まだ同じようには使っていないことです。出力をAIに任せられるようになった今こそ、その手前、つまり何を作るかを決め、価値を確かめる仕事に、同じ熱量を向けたいのです。コードを速く書くことは、もうAIができます。何を書くべきかは、まだ私たちが握っています。