アウトプットを最小に、アウトカムを最大に

前編は、ひとつの隙間で終わりました。スクラムは予測可能に作るためのリズムをくれますが、スプリントに入っているものがそもそも存在すべきかを問う儀式はありません。Marty Cagan の言う50〜80%は、その隙間に住んでいます。

この記事はその後半です。題材は同じ Marvel Unlimited アプリ、同じブレイクアウトグループ。終盤の2日間が、私たちのチームが不満を並べるのをやめ、何かに賭けなければならなくなったところでした。

スクラムが残した隙間を埋めるループです。事業課題から実際にリリースできるものまで、作ってから捨てるのではなく、作る前に捨てていきます。

正確には、誰なのか

Jeff はディスカバリー編を、Clayton Christensen のミルクシェイクの研究から始めました。私が知るかぎり、プロダクト理論で最も役に立つ10分間です。

マクドナルドはミルクシェイクをもっと売りたいと考えました。そこで当然の調査をします。買っている人に、どうすればもっと良くなるかを聞いたのです。もっと濃く、もっと安く、味の種類を増やして。そのとおりに変えました。売上は動きませんでした。

そこで誰かが現場を見に行きました。ミルクシェイクのかなりの割合が朝8時前に、一人客に、持ち帰りで売れていたのです。彼らはデザートを買っていたのではありません。退屈な長い通勤があり、空いている手は片方だけで、運転のあいだ持ちこたえ、10時に空腹にならないものが欲しかった。彼らはその仕事のためにミルクシェイクを雇っていたのです。

つまりミルクシェイクの本当の競合は、バナナ（2分でなくなる）、ベーグル（両手が要る）、ドーナツ（粉が落ちるし9時には空腹）でした。ミルクシェイクを買った人にミルクシェイクのことだけ聞いていては、何ひとつ見えてきません。

教訓は「違いを生む違い」を探すことです。属性ではありません。作るものが実際に変わるような、目的と文脈の違いです。34歳のマーケティング担当者と34歳のマーケティング担当者を比べても何も分かりません。通勤20分と通勤90分を比べれば、すべてが分かります。

続いてペルソナですが、Jeff のやり方は意図的に安上がりです。プロトペルソナを、今ある仮説から10分ほどで作り、名前と顔を与えます。目的は正確さではなく、チームが個人の好みで議論するのを止めることです。判断基準はひとつ。作るものが変わる特徴だけを書くこと。

持ち帰るとしたら
企画の議論で「ユーザー」と言うとき、私たちはたいてい別々の人物を思い浮かべています。名前をつけないので、そのズレに気づかないままです。

今すでにやっていることを描く

何かを設計する前に、今日ある姿のままのジャーニーを、1ステップ1枚の付箋で描きます。全体を支配するルールはひとつ、名詞ではなく動詞句です。「カレンダー」ではなく「カレンダーを確認する」。名詞は機能であり、動詞は人が実際にやっていることです。名詞で作られたマップは、いつのまにか機能一覧に変わってしまいます。

そのうえで4つを書き添えます。どこが痛むのか、その人が求めている報酬は何か、どれくらいの時間と頻度か、そして自社のソフトウェアの外で使っている回避策です。最後のひとつが宝です。困っていない問題のために回避策を作る人はいません。

そもそも「良くなる」とは何か

すべてを良くすることはできないので、アウトカムをひとつ選ぶ必要があります。事業指標は遅行指標です。売上、NPS、解約率。これらが動くころには、原因は数か月前のものになっています。プロダクト指標は先行指標で、選び方について Jeff は二つの基準を示しました。顧客が価値を得ている度合いを測ること（Zoom なら、ログイン数ではなく1ユーザーあたり週何回の会議を主催・参加したか）。そして、今回変更したものの利用状況を測ること。

Dave McClure の海賊指標 AARRR も紹介しつつ、彼自身の追加がひとつありました。ロールバック、つまり試したうえで自ら元に戻した人たちです。売上が最後にあるのは、それが結果であって、ユーザーの行動ではないからです。

そして、研修全体が腑に落ちた瞬間がラダーダウンです。

演習での事業課題は、長く使っている顧客が離れていくことでした。そしてここが肝心です。継続率は直接には解決できません。「継続率」という機能は存在しないからです。離脱を生んでいる具体的な顧客課題を見つけ、そちらを解くしかありません。

プロダクトの目標は、機能を指定せずに行動の変化を描くべきです。解決策の名前が出た時点で、ディスカバリーを飛ばしたことになります。

演習にて

自分が離脱者だったと気づく

4日目、山積みの不満をひとつの目標に変える作業でした。議論は検索の改善と読書の継続性の改善で割れました。検索案は具体的で技術的です。ユニバーサルリンクで外部検索のインデックスに対応させ、スマートフォンで Spider-Man と検索したときに Marvel Unlimited が現れ、そのまま作品へ直接遷移できるようにする。提案した本人は測り方まで用意していました。あるキーワードで検索し、改善前と改善後で返ってくる作品数を数える、と。
そのとき、誰かが話の途中で止まってこう言いました。

「私はサインアウトしました。自分にとってつらかったからです。だから私には継続性がなかった。ユーザーとして。物語を続けて読み終えられるように、簡単にしてあげる必要があります」
自分こそが離脱者だったと、その場で声に出して気づいた瞬間でした。ペルソナでもアンケートの回答でもなく、本人です。部屋が一瞬静かになり、目標はほとんど自動的に書き上がりました。次に読みたい作品を最も見つけやすい場所にし、読者が戻ってきて、もっと探索するようにする。
書かれていないことに注目してください。「レコメンドエンジンを作る」とは、どこにも書いていません。

選択肢を出す。ばかげたものも含めて

ここでようやく解決策を許します。Jeff はまず沈黙のブレインストーミングを行いますが、その理由は創造性ではなく人間関係にあります。議論から始めると、声の大きい人や役職の高い人が場を固定してしまい、静かな人のアイデアは最後まで出てきません。まず全員が一人で書き、それから話します。

1. まず当たり前のアイデアを出し、頭から追い出します。

2. 誰かの付箋に乗っかって発展させます。

3. まったく関係ないプロダクトから盗みます。

4. 実現不可能なアイデアを書きます。

4つ目こそ皆が飛ばすもので、そして本質です。Jeff は古い盗難防止装置の広告を見せました。トランクに住んでいる猿が飛び出して泥棒を撃退する、というものです。当然作れません。ですが少し戻して考えると、種がそこにあります。自分がいなくても、その場で、自分の代わりに反応してくれる何かです。

演習にて

ARグラスと、Stan Lee からの電話

6分間で、できるだけ多くのアイデアを出しました。マルチバース全体の読む順序が分かる Marvel のタイムラインマップ、Marvel 世界のインフルエンサーによるおすすめ、キャラクター別の Netflix 風のおすすめ列、好きなキャラクターと今の気分を聞くオンボーディングのアンケート、「心を読んでほしい」から発展した視線追跡ARグラス、そして Stan Lee から電話がかかってくる演出。
取っておく価値があるのは Stan Lee の電話です。次に起きたことが理由でした。誰かが「わくわくするより、威圧的かもしれない」と指摘したのです。ばかげたアイデアを通じて到達した、本物のプロダクトの洞察でした。愛されている人物からの個別の働きかけは、喜びではなくプレッシャーとして受け取られ得る。まともなアイデア一覧からは、この気づきは出てきません。

選び方：価値と工数ではなく、価値とリスク

たいていの優先順位づけの図は、縦に価値、横に工数を取ります。Jeff が横軸に取るのはリスクと確信度で、その理由を強く主張しました。問題そのものを取り違えている可能性に比べれば、コストは二次的な心配ごとにすぎません。高くついても機能するものは問題ありません。間違った前提の上に作られた安いものは、まるごと無駄です。しかも安いのは、確かめなかったからです。

価値が高く確信度も高いなら作ります。価値が高くリスクも高いなら、捨てるのではなく検証します。その象限がディスカバリーのバックログです。この図の要点は、ひとつの順位表を作ることではなく、仕事を二つの異なる行き先へ振り分けることにあります。

演習にて

良いアイデアが、別の象限に着地する

今回の研修でいちばん良かった30秒は、チームがタイムラインマップを配置する場面でした。誰かが見た瞬間に気に入り、そう口に出しました。ところが位置が定まる前に、その同じ人が自分で左へ寄せていったのです。価値が高いのは明らかだが、読者が実際に使うかどうかは分からない、と。結局それは左上、つまり「まず検証する」列に落ち着き、誰も異論を唱えませんでした。
熱意と確信度が、その場で切り離されたのです。それこそがこの図の唯一の仕事であり、全員が気に入ったアイデアでさえ、そのまま開発のバックログには入りませんでした。

時間の予算化

そのまま真似したい関連アイデアです。種類の違う仕事どうしを優先順位で比べてはいけません。紙の上では戦略的な仕事が必ず勝ち、技術的な仕事は決して勝たないからです。代わりに時間を予算化します。たとえば戦略60%、戦術20%、技術20%、規制対応が必要な業界ならもう1枠。技術の時間を確保しないと、技術的な仕事が遅れるのではなく、やがてプロダクトの仕事そのものが止まる、と Jeff は率直に言いました。

賭けを言語化する

アイデアを選んだら、チケットになる前に枠に落とします。Jeff の道具はオポチュニティ・キャンバスで、その中身はほとんどが、自分が何を前提にしているかをあぶり出す問いの集まりです。

Jeff は、ステークホルダーに書いてもらうのではなく、こちらが代わりに埋めてしまうことを勧めました。人はゼロから書くよりも、下書きを直すほうがはるかに気軽だからです。組織運営としての小さな工夫ですが、まったくそのとおりです。

そして作る前に、良い・より良い・最高の3段階を描きます。3つの水準の解決策をスケッチし、スコープの3分の2ほどが落ちる前提で臨みます。机の上に案がひとつしかないと、チームはうまく削れません。削ることが損傷に感じられるからです。3つあれば、削ることは単なる選択になります。

まずトーストを描く

Jeff はストーリーマップを1枚も見せる前に、手を止めてトーストの話をする講演を再生しました。

https://www.youtube.com/watch?v=yAo8KLKZMW4

Tom Wujec『Got a Wicked Problem? First, Tell Me How You Make Toast』（厄介な問題があるなら、まずトーストの作り方を教えてください）。

前提はとても単純です。部屋にいる人たちに、トーストの作り方を絵で描いてもらう。文字は禁止、絵だけ。返ってくるものは二つとして同じになりません。食パンを描く人、トースターの内部を描く人、キッチンに立つ自分を描く人。そしてどんなに雑な絵でも、その下にあるものは同じ種類の対象です。ノードとリンクからなるシステムです。

そこで彼はひとつだけ条件を変えます。もう一度、ただし1ステップにつき付箋1枚で。モデルはたちまち良くなります。絵であることをやめ、手に取って動かせるものになるからです。さらにもうひとつ変えて、一人ではなくグループでやらせると、また良くなります。

これで講演のすべてです。長さは9分。

Jeff がそこから取り出したもの。彼はトーストのために見せたのではありません。研修中のあらゆる演習の下で静かに動いていた方法そのものを見せていたのです。そこから4つのルールを引き出しました。

• 1ステップにつき付箋1枚。並べ替えられるモデルは、並べ替えられない絵に勝ちます。ストーリーマップが文書ではなく付箋である理由は、まさにこれです。

• 3人から5人。人数を増やすとモデルは良くなるどころか悪くなります。

• 発散は沈黙で、収束は声に出して。いきなり議論すると、最初に話した人に引っぱられます。沈黙のブレインストーミングと同じ理由です。

• 時間を区切り、分析より直感を信じる。彼はこれをサティスファイシングと呼びました。今のところ十分なら、そこで止めます。

これらはすべて、初日と最終日の朝に繰り返された合言葉に凝縮されます。考える、書く、言う、貼る。口に出す前に書き留め、それを全員が見える場所に置く。分散したチームであれば、会議のたびに新しい白紙のボードを作って二度と戻らないのではなく、大きなボードをひとつ持ち続け、情報の放射器として機能させることを意味します。

そして、私たちにやらせました。課題は自分の朝の習慣を描くこと。起きてから仕事の席につくまでを、1ステップ1枚の付箋で。先に相談はなし。全員が自分の分を作りました。

教訓は、出てきたものの中にありました。6枚で終わる人もいれば、25枚になる人もいる。25枚の人には子どもかペットか長い通勤があり、6枚の人にはそのどれもありませんでした。

これはこの記事の前半で出てきた「違いを生む違い」が、全員が同じありふれた朝を描いているつもりでいた部屋に現れたということです。誰ひとり同じではありませんでした。そして10分後に本物のユーザーのジャーニーを描くとき、探しているのはまさにこれです。実際、私たちが次にやったのがそれでした。

ストーリーマップ

ここは Jeff の本領であり、彼が見せたなかで最も役に立つ図でした。実物の写真もありました。壁一面に横長に並んだ付箋の帯を、青いテープが何本も水平に横切っています。

上端を走るのが背骨です。大きな活動が、人が実際に行う順番で並びます。その下に具体的なタスクが、おおむね重要度順にぶら下がります。そしてテープ。水平の帯ひとつひとつがリリースの単位です。最初の線より上にあるものが、端から端まで物語として成立する最小のかたまりです。

スライドにあった二つの問いはまさに的確でした。これらは成立するリリースか。どの顧客に絞り、成功をどう測るのか。彼にはもうひとつ強い意見がありました。見積もりと計画のために開発者が必要とするのは、文章のユーザーストーリーではなく絵だということです。Jira に何かが入る前に、UI をカードにスケッチすること。

演習にて

閉じ込めてしまうかもしれない質問

私たちが選んだ機能は、好きなキャラクターと今の気分を尋ねる短い質問で、その結果をおすすめに反映するというものでした。すぐに二つの設計上の問いにぶつかりましたが、実際にはどちらもリスクの問いでした。
ひとつ目。この質問はジャーニーの最初に置くべきか、最後に置くべきか。履歴のない新規の読者には最初が有効ですが、戻ってきた読者にとっては後のほうがよく、そもそも不要かもしれません。
ふたつ目、これが私は気に入りました。誰かが自分たちのアイデアの中にリスクを見つけたのです。答えた好みに沿ったおすすめを出し続けると、本当は好きになったはずのキャラクターに、その人が一生出会わなくなるかもしれない。最終的に私たちは、Spotify のスマートシャッフルのような形が理想だと話していました。信頼できる程度に馴染みがあり、驚ける程度にゆるい。
ストーリーマップを作り始めてまだ8分ほどで、本物のプロダクトリスクが1つ出てきていました。それがマップの仕事です。

作る前に検証する

ここが、ふつうのアジャイルと分かれる部分です。作る前に検証による学習のループを回します。Steve Blank に由来し、Eric Ries が「構築・計測・学習」として広めた考え方です。

Jeff は「構築・計測・学習」の「構築」という語について釘を刺しました。本番コードのことではありません。可能なかぎり安い検証のことです。フェイクドア（機能が存在する前にボタンだけ置き、押した人を数える。TripAdvisor も Atlassian もやっています）、紙のプロトタイプ（ヒューレット・パッカードのチームは複雑なデータマッピングの使用性を午後だけで検証しました）、あるいはスパイクです。

それから、初めて見てすぐ気に入った捉え方があります。「忠実度が低い・高い」と言うのをやめること。忠実度には見た目・データ・機能という独立した3つの軸があり、それぞれ別々に動きます。紙のプロトタイプは見た目の忠実度がほぼゼロでも、機能の忠実度は非常に高くできます。使用性の検証にはそれがまさに適切です。問うべきは高いか低いかではなく、いま立てている問いに答えるのに適切な忠実度は何か、です。

MVPという言葉が指す、三つの別物

この節は、私がこれまで見てきた6年分の議論を説明してくれました。

ひとつ目はどの本にも出てきません。多くの組織が実際にやっていることであり、Jeff はホワイトボードに正直版としてこう書いていました。「期間内に取れる最大量。ただし何かは諦めることになる」。二つ目と三つ目はほぼ正反対でありながら、どちらも流通しています。だからこそ、相手は出荷できる製品を思い浮かべ、チームはフェイクドアの検証を指すという食い違いが起きるのです。

稼ぐためのリリースの前に、学ぶためのリリースを

Jeff が挙げた良い MVP の例は初代 iPhone でした。カメラは貧弱、App Store もなく、コピー＆ペーストすらない。それでもウェブ閲覧とメッセージのやりとりが他のどれよりも圧倒的に良かったので、対象としていた人々にとって、それ以外はどうでもよかったのです。

Spotify 版は、Henrik Kniberg のエンジニアリング文化の記事にある「考え、作り、出し、調整する」です。完璧に満たない解決策を一部の利用者に出し、素晴らしくなるまで反復し、うまくいかないものを捨てることを恐れない。Jeff の警告はこうです。チームは「調整する」に永遠にとどまってしまう。どこかで、広げるか捨てるかを決めなければなりません。

二つのトラック、ひとつのチーム

最後の大きな考え方であり、Jeff が最終日の朝に「Two Tracks, One Team」と上部に書いて描いたものです。

スコープが膨らむのではありません。理解が育つのです。
Jeff Patton

これは前編で触れた1986年の論文の「組み込まれた不安定さ」と同じものです。混乱こそが手法なのです。私が最も役に立つと感じたのは、そこから導かれる実務的な帰結でした。月曜日から変えられるものばかりだからです。

• デイリースクラムは、一人ずつの進捗報告をやめ、作業項目そのものをたどる場にします。人ではなく項目の話をすると、人は礼儀正しく聞く代わりに、詰まっているものへ群がります。「今（デリバリー）」と「次（ディスカバリー）」に分け、後半は任意参加にします。

• バックログリファインメントは、スプリントに一度の長い憂鬱な会議をやめ、週2回の短いセッションにします。参加は任意で。

• スプリントレビューでは、作ったものだけでなく学んだことも扱います。そうしないとディスカバリーの仕事は見えなくなり、静かに後回しにされます。

• エンジニアと QA もディスカバリーに参加します。対話、観察、クレイジーエイト、デザインスタジオ。前編にあった Sherif Mansour の「開発者がいない顧客インタビューはやらない」という言葉に、ここでつながります。

私が実際にした質問

小さなチームだったら？

ちょうど彼がこれを描いているとき、チャットで誰かが「プロジェクトのデイリーと通常業務のデイリーはまったく別物だ」と書きました。そこで私は、研修中ずっと考えていたことを打ち込みました。

「小さなチームだったら、どうなりますか？」
ここで描かれているものの多くは、専任のPMと専任のデザイナーがいて、2人をディスカバリーに1週間割いてもデリバリーが止まらない、8〜9人のチームを前提にしています。私たちの大半は、そうではありません。
考えたうえで私がたどり着いた答えはこうです。二つのトラックとは二種類の仕事であって、二つの人の集まりではありません。小さなチームは、人を半分に割ってトラックを回すのではなく、先ほどの戦略と技術の配分と同じように、時間を予算化して回します。週のいくらかは学習の仕事にあて、それをボードに載せ、スプリントレビューで扱います。
そしてチームが小さいほど、安い検証の価値は上がります。間違ったものを二度作る余裕がないからです。フェイクドアの検証と3人へのインタビューはほぼコストゼロで、大きなチームより小さなチームにとって価値があります。規模を決めるのは人数ではなく、規律です。

AIはどこに入るのか

Jeff と Sherif Mansour の両方がこの話をしましたが、2026年のAIの議論としては、予想よりずっと抑制的な見方でした。

AIを使って働くことについて。Atlassian は10か月で16,000を超えるプロトタイプを作りました。プロトタイプのコストがほぼゼロになると、ボトルネックは移動します。希少になるのは判断力です。何を検証するかを決めること、Noと言うこと、プロダクト・デザイン・エンジニアリングのあいだで共通理解を保つこと。Sherif の具体的な警告は、プロダクトマネージャーが舵取りを犠牲にしてAIとコードを書くことに没入してはいけない、というものでした。

プロダクトにAIを入れることについて。初期のチャットは有用な汎用インターフェースです。自由入力欄に人が何を打ち込むかを見れば、本当に欲しいワークフローが分かるからです。そのあとで、それらを本物のワークフローとして作ります。彼はこれを「けもの道を舗装する」と呼びました。ただしチャットは、何を尋ねればよいか分からない新規ユーザーを混乱させます。目的地というより、ディスカバリーの道具です。

使わないほうがよい場面について。決定的なコードのほうが安く優れている場合です。基本的なスパム検出にモデルは要りません。そしてモデルのコストは、賭け金の大きさに合わせます。

オプトアウトについて。最も示唆に富む部分でした。顧客が細かいAIのオン・オフを求めてきたとき、スイッチをそのまま作ってはいけません。その先にあるのは、機能ごとに依存関係の表がついたプロダクトです。「なぜ」を5回繰り返して本当の懸念、たいていはデータの扱いか教育不足を突き止め、より上の階層で解決します。

結局、私が持ち帰るもの

• 作る前に、意図するアウトカムとそれを示す指標を書き出すこと。書けないなら、まだ依頼を理解できていません。

• どちらの意味のMVPかを言うこと。毎回です。

• 工数ではなくリスクと突き合わせ、左上の象限はバックログではなく検証へ送ること。

• 最も安い検証を本気で扱うこと。フェイクドアや紙は劣ったエンジニアリングではなく、前提に1か月を溶かさないための手段です。

• 顧客との会話には、必ずエンジニアを入れること。

• 学習の時間を隙間に期待せず、予算として確保すること。小さなチームでは、隙間に収まることは決してないからです。

前編：スクラムがくれたのはリズムであって、羅針盤ではない
前編で述べたのは、スクラムがくれたのはリズムであって羅針盤ではない、ということでした。この後編が羅針盤です。新しいフレームワークを導入する話ではありません。私たちが普段より早い段階で問いを立てること、そして捨てるコストがまだ安いうちに仕事を捨てる覚悟を持つこと。ほとんどそれだけです。