新たな3つのボトルネック

工場で一つの生産ラインの速度を二倍にすると何が起きるでしょうか。全体の産出量が二倍になることは、まずありません。代わりに、そのラインの後ろに在庫が積み上がり始めます。ボトルネックは消えたのではなく次の工程へ移ったのであり、これ以後の工場の速度はその次の工程が決めます。

前章で残した問いがこれでした。実装コストが下がったのなら、そのコストはどこへ行ったのか。本章では、その在庫が積み上がった場所を三か所、一つずつ指し示します。以降の章では、この三つの名前を定義なしにそのまま呼ぶことになります。

第一のボトルネック: 検証とレビュー

前章で引用したFaros AIのデータをもう少し広げてみると、移動の痕跡がそのまま現れます。AI導入度の高いチームでは、マージされたPRが98%増え、完了したタスクは21%増えました。ところが同じチームで、PRレビューにかかった時間は91%増え、平均PRサイズは154%大きくなり、バグは9%増えています(Faros AI)。

数字を並べてみると話は明白です。生成側で二倍に稼いだものが、レビューのキューでかなりの部分また支出されています。しかも入ってくるPRは二倍多いうえに一件あたりのサイズが二倍半なので、一人が読まなければならないコードの総量はもっと急に増えます。組織レベルの利得が、レビューという一点に吸収される構造です。

さらに厄介なのは、読むこと自体が難しくなったという点です。人が書いたコードは、拙ければ拙いと見て取れます。一方、AIが書いたコードは、ざっと読めば通ってしまうほどもっともらしく、かえってレビューを難しくします。間違っている箇所が不自然に見えないため、誤った前提や抜けた例外処理を捕まえるには、文章をなぞるのではなく意図を追いながら読まなければなりません。ある調査では、シニア開発者はAIが生成したコード一件のレビューに平均4.3分を費やした一方、人が書いたコードには1.2分でした(LogRocket)。同じ量を読むのに三倍を超える注意力がかかります。

つまり、生成が安くなった分だけ検証が自動的に安くなったわけではありません。むしろ単位あたりのコストが上がった状態で、物量が二倍になったのです。

第二のボトルネック: 注意力と集中

二つ目の資源は、何を作るかを選ぶ人の注意力です。

作るのに二日かかっていた時代には、アイデアのリストが自然と絞り込まれました。ほとんどのアイデアは着手する前にコストに耐えられず脱落し、その脱落が事実上、優先順位の決定を代わりに担ってくれていたのです。今やそのフィルターは消えました。たいていのアイデアは午後半日もあれば形になるので、「作れるのか」という問いはもはや何も濾し取ってくれません。何でも作れるようになると、何を作らないのかが決定のほぼすべてになります。

ここに、より危険な事情が一つ加わります。作ることが面白くなった、ということです。序文で短く触れたDavid Heinemeier Hanssonの警告が、この場で本題になります。彼が名指ししたのはツールの品質ではなく、ツールが生み出すリズムでした。出力が数秒で返ってくる環境では、次のプロンプトを入れる行為そのものが報酬になり、そうして形成されたドーパミンループは中毒的に働いて、かえってバーンアウトのリスクを高める、というのです(Pragmatic Engineerインタビュー)。止まれない状態で真っ先に押しのけられるのが、「これをなぜ作っているのか」を問う時間です。

反対側に錘を吊るすのは、彼の共同経営者です。Jason Friedは、速度も、コミット数も、投入した人数も、その人数にエージェントを含めたとしても、プロダクトを本質的により良くするわけではないと言います(37signals)。より多く作られたプロダクトがより良いプロダクトだという保証は、どこにもありません。ところが今のツールは、より多く作る側の抵抗だけを取り除いてくれます。選り分ける側の抵抗はそのままで、選り分ける仕事をする資源は、一日に数時間しかない人の集中力です。

第三のボトルネック: 複雑度負債

三つ目は、時間が経ってから請求書が届く項目です。

「コードは資産ではなく負債だ」という古い命題があります。コードは持っているだけで値が張ります。読まれ、理解され、依存関係を辿られ、脆弱性が見つかれば更新されなければなりません。生成が高かった時代には、この命題はいくぶん修辞に近いものでした。作ることが難しかったので、作られる量そのものが自然に制限され、負債は耐えられる速度でしか積み上がらなかったのです。

生成が安くなれば、蓄積も安くなります。そして蓄積されたものを維持するコストは、一緒には安くなりません。20分で付けた機能一つが残すのは、その20分ではなく、これから先そのコードが生きているあいだずっと払い続ける保守とセキュリティ更新、そしてこのシステムを理解しようとするすべての人が追加で背負う認知負荷です。次にこの近くを直そうとする側は、その分だけ広がった表面の上で判断しなければなりません。数か月後の自分かもしれませんし、エージェントかもしれません。

ここには、先の二つのボトルネックへ戻っていく環もあります。システムが複雑なほど、変更一つをレビューするのに必要な文脈が増え、何を作るか判断するときに考慮すべき相互作用も増えます。簡単に作ったものが、あとで検証をより高くつかせ、注意力をより多く食います。この項目については、先の二つのボトルネックのように引用できる堅い数値がまだありません。ただ、蓄積の速度だけが数倍に上がり、返済の速度はそのままだという構造は、数値がなくても明白です。

三つのボトルネックの共通点

三つの資源を並べてみると、共通点が一つ見えてきます。三つとも人の側にあり、三つとも有限です。コンピュート(トークン消費やエージェントセッションの実行を含む計算資源)はお金を積めば増えますが、レビューに使える注意力、判断に使える集中、システムを頭の中に収めておける容量は、予算を増やしても増えません。ボトルネックが移った先は、結局スケールしない資源の上でした。

そして、まさにここでShape Upが再び登場します。原作は初めから、有限な資源を予算として扱う方法についての本でした。その予算を立てる仕掛けがアペタイト(appetite)であり、そのとき予算の単位は時間でした(第3章: 境界を定める)。有限な資源が時間ひとつではなくなったのなら、破棄すべきはその仕掛けではなく、その仕掛けが数える単位です。次章で、アペタイトを三つの資源の予算として書き直します。