Skip to content

アペタイトの再定義 ​

原作においてアペタイト(appetite)とは、この問題に使う意思がある時間の上限を指します(第3章: 境界を定める)。2週間なのか6週間なのかを先に決め、その中に収まる解決策を探します。

これが見積もり(estimate)と分かれるのは、問いの向きです。見積もりは「これを作ったらどれくらいかかるか」を問います。デザインから出発して数字で終わるので、解決策をすでに決めたあとでなければ答えられません。アペタイトは「この問題にどれだけ使う価値があるか」を問います。数字から出発してデザインで終わるので、解決策を決める前に答えなければなりません。だからアペタイトは予測ではなく決定であり、その場でただちにシェイピング(shaping)を推し進める創造的な制約になります。

時間予算の限界 ​

この仕掛けが規律として働いていたのは、時間が高かったからです。「これは6週間ものではない」という判定には、力が込もっていました。6週間を使うという言葉は、チーム一つが他のすべてをやらないという意味であり、聞く人全員がその重みを知っていました。

今、同じ文を口にしてみると力が抜けています。作るのに本当に一日あれば足りる機能に向かって「我々のアペタイトは2週間だ」と言っても、何も止められません。上限のはるか下に来ているので、通過です。そしてこの地点で、最も厄介な反問が入ってきます。「一日で作れるのに、なぜ作らないのか?」時間予算には、これに答える言語がありません。反問の前提が真だからです。本当に一日で作れます。問題は、一日がその機能の請求するコストのすべてではないという点にあるのですが、時間という単位では残りの請求書が見えないのです。

三つの予算へ ​

だとすれば変えるべきは仕掛けではなく単位です。前章で名前を付けた三つのボトルネックが、そのまま三つの予算になります。

検証予算は「我々が責任を持って確かめられる範囲はどこまでか」を問います。一日で付けた決済の例外処理が分岐を二十個も生み出したのに、それを最後まで追って読む人が誰もいないなら、実装にかかった時間がいくらであれ、この予算はすでに超過しています。確かめないまま世に出したものは、作ったのではなく先送りしたのです。

注意力予算は「この問題は我々の集中をどれだけ占める価値があるか」を問います。作るのは半日なのに、その後何週間もチームの議論の半分を持っていく設定画面があります。実装の請求書は半日で、注意力の請求書は数週間です。後者のほうがはるかに高いのに、どこにも記載されません。

複雑度予算は「この機能が増やす表面積を、我々は負い続ける意思があるか」を問います。外部サービス連携を一つ二日で付けたなら、その二日のあとには、APIバージョンが変わるたび、あちら側で障害が起きるたび、この近くを直そうとする人が現れるたびに、少しずつ分割して払うコストが付いてきます。

三つのうち一つでも超過すれば、「作らない」が正当な答えになります。先の反問にも、これで答えられます。作るのに一日かかるのはその通りです。しかし我々には、それを確かめる時間も、それが広げてしまう表面を負い続ける余力もありません。

VDLCの二重通貨アペタイト ​

この再定義を、実務で使う予算フォーマットとして実装したのがVDLCの二重通貨アペタイトです。ピッチ(pitch)ごとに二つの通貨を数字で書きます。人間の注意力予算はシェイピングN時間と検証N時間に分けて書き、コンピュート予算はトークンまたはセッションの上限として書きます(VDLC 週次サイクル)。

三つの予算が二つの通貨へ畳まれる仕方はこうです。検証予算は、人間の注意力予算の中の「検証N時間」の項目に入ります。何を作るか選ぶ集中と、作られたものを確かめる集中は、結局は同じ人の同じ一日から出てくるので、別々に数えるより一つの通貨にまとめるほうが、実際に消耗される仕方に合っています。複雑度予算は、コンテキスト負債(context debt)、すなわちコードにはあるが意図を書いた文書にはない決定を管理する仕事へ吸収されます。負うべき表面積が広がったということは、すなわち他人が読んで復元できない決定が増えたという意味だからです。残るコンピュート予算は人の側の資源ではなく、お金で増える資源ですが、それでも上限を書いておきます。予想より速く燃えていくコンピュートは、それ自体が、この仕事はシェイピングされたよりも難しいというシグナルだからです。

変わらない原理 ​

単位は変わりましたが、原理はそのままです。どれだけかかるかで範囲が決まるのではなく、どれだけ望むかで範囲が決まります。

見積もりとの対比もそのまま有効です。むしろ今は見積もりを得るのが容易になりすぎたぶん、この区別がいっそう重要になりました。エージェントに尋ねれば数秒で計画と所要時間が返ってきます。もっともらしく、自信に満ちていて、ときには正しい。しかしそれは依然として見積もりです。デザインから出発して数字で終わる答えであり、すでに決まった解決策を前提とした答えです。AIがこの仕事を二時間と言おうと二日と言おうと、我々がここに使う意思がある量の上限は、その数字ではなく我々のアペタイトです。

だから原作の「固定された時間、可変のスコープ(fixed time, variable scope)」は破棄されるのではなく、一段だけ一般化されます。「固定された予算、可変のスコープ」です。固定されるものが時間ひとつから三つの資源へ増えただけで、予算を先に打ち込み、その中に収まるように範囲を削るという動作は変わりません。では、その削る仕事、予算の中に収まる解決策の輪郭をあらかじめ描く仕事は、これから誰がやるのでしょうか。次章の主題です。

BasecampのShape Up(Ryan Singer)をバイブコーディング時代に合わせて再構成したガイドです。