失われた確信（Lost confidence）

• RICE などの確信ベースの優先順位付けフレームワークは大半がノイズであり、わからない未来を知っているふりをせずに意思決定する方法が必要である
• 確信スコアはこうした小さな（small）プロジェクトには高く、大きな（large）プロジェクトには低く付けられるため、価値の大きいプロジェクトを体系的に押しのけ、優先順位を歪める
• 確信スコアは定義が曖昧で検証データも不足しており、プロジェクトは常に遅れ、期待よりインパクトも小さいため、信頼できない
• 解決策は確率（probability）ではなく不確実性（uncertainty）の領域で、「どんな確率分布であっても賢明な行動は何か」を問うこと
• 確信の代わりに、常に真であること・顧客インパクト・オプション確保・非対称ベットのような手法で優先順位を決めることが重要である

---

確信ゲーム（Confidence games）

• 多くの優先順位付けフレームワークは、予測した工数で予測したインパクトを出せるという確信をスコアに含めている
  • 同じ価値・同じ工数の 2 つのプロジェクトのうち、実行の確信が高い方を選ぶこと自体は合理的である
  • しかし実際の使われ方は、「1）スコア付け → 2）明確な勝者を実行 → 3）同点なら確信の高い方を選ぶ」ではない
• RICE は第 1 段階のスコア計算式に確信を直接掛け込んでいる
  • RICE の公式: Score = (Reach × Impact × Confidence) / Effort
  • RPS の公式: Score = Reach × Potential × Solution Confidence
• この方式は異なる 2 つのシナリオを同格に扱い、偽りの等価性を生む
  • 小さいが確実に実行できる漸進的な機能
  • インパクトは大きいがリスクを抱える大規模な機能
• 通常、小さなプロジェクトには確信が高く、大きなプロジェクトには低いため、確信を掛けると価値を最大限届ける方向から体系的に遠ざかる
  • Agile ムーブメントの核心的な動機そのものが、「大規模プロジェクトの成功は常に確信が低いはずだ」という洞察だった
• 確信スコアを信じない理由
  • 定義が曖昧: 「30%」が何を意味するのか不明確。本来はすべてのプロジェクトの確信スコアを記録し、実際の結果と照合して精度を数値で算出すべきだが、実際にはそうしていない
  • 毎年リリースする主要機能が少数しかないなら、事後に検証するためのデータ自体が不足している
  • プロジェクトはほぼ常に遅れ、期待よりインパクトが小さく遅い。9 か月・6 チームのプロジェクトであっても、「ある程度の確信」があったから始まったのである
• Hofstadter's Law の引用: 「Hofstadter's Law を考慮しても、常に予想より長くかかる」
• 経験豊富な PM に「間違いなく歓迎されると確信していたのに、そうではなかった機能」を尋ねれば、誰もが複数の例を持っている
  • 顧客との会話、明示的な要望、購入の約束といった根拠があっても、実際に作ると、約束した本人ですらほとんど使わない
  • 予測を改善する手法: 顧客に実際のワークフローの中で段階ごとにどう使うかを説明してもらう。手順をたどるうちに、「これはコードを書き直さないといけないからやらない」といった具合に、自分で気づくようになる
• コンテンツ制作者も同様で、ほとんど期待せず急いで出した記事がその年で最も高い閲覧数・反応を得る一方、何十時間もかけた力作が見向きもされないこともある
  • 「確信の有無 × 結果（愛される／無関心）」の 2×2 表の4 つの枠すべてに事例があふれている

確信とリスクの代わりに何を使うべきか（What to use in place of confidence and risk）

• 答えは確率ではなく不確実性（uncertainty）の領域にある
  • 確率は分布を知っていることが前提である。公正なコインを 100 回投げれば、表が 40〜60 回の範囲に収まる可能性が非常に高いと予測できる
  • スタートアップのほぼすべてはこれとは異なる。成功・戦略・機能は前例がないか、複雑すぎるか、入力変数の精度がないため、意味のある確率を与えられない
  • 経済学者 Frank Knight の 1921 年の著作に由来する**「Knightian Uncertainty（ナイト的不確実性）」**という概念
  • Bayesian な方法も数値的な事前確率と条件付き確率を必要とするが、そのどちらもわからず、定義できない
• 不確実性の領域で問うべきことは、**「確率分布に関係なく、どんな行動が賢明か」**である

• 常に真であること（True always）

  • どんな状況でも常に真であることに集中する — Bezos の**長期定数（long-term constants）**の原則
    • ユーザーは普遍的に、速くて応答性の高いソフトウェアを好む。バックグラウンド同期・即時のインタラクション・あらゆるデバイスで動くことに価値を感じる
    • 最悪の場合（速度に無関心）でも、速度をマイナスには捉えない。最良の場合、Notion、Figma、Miro、Gmail、Google Docs のように、パフォーマンスが中核的な差別化要因になる
  • すべての機能が普遍的な魅力を持つわけではない。精密な数値分解の代わりに、事実上すべての顧客が価値を感じる、あるいは少なくとも好意的に受け取る機能を見極める
    • ときには義務だからこそ確実である。SOC 2 コンプライアンスのようなエンタープライズ要件は面白くなくても、エンタープライズ販売では確実に価値がある
    • こうした確実性が差別化の欠如を補う
  • ただし、最も革新的で差別化されたアイデアは、「絶対に確実」なカテゴリにはほとんど入らない
    • 確実なものは価値があるが、戦略的な差別化要因にはなりにくい
    • 優れた製品には、信頼できる改善と革新的な飛躍の両方が必要である

• 早い発見、早い回復（Quick discovery, quick recovery）

  • ビルド前に潜在顧客へ体系的にインタビューし、アイデアを検証することを長く支持してきたが、これもまた「確信の罠」に陥る
    • 作ってみるまでは決して確実にはわからない
    • ただし、ビルド前に**検証失敗（invalidate）**は可能であり、数か月〜数年の無駄を防げるので、依然として出発点として正しい
  • 典型的な解決策はSLC（MVP をアップグレードした概念）を作ること — シンプルだが完成した製品として、本物のフィードバックを得る（予測ではなく体験）
    • 既存製品は、確実な勝利と革新的なベットのあいだでバランスの取れたポートフォリオを保ち、それぞれに異なる検証方法を適用する
  • **「ダミー機能（dummy features）」**の例: クリックすると「この機能はまだありません。どのように使いたいか教えてください」と表示されるボタン
    • 関心のあるユーザー数と、潜在的なインタビュー対象を行動によって確保できる、実際のシグナルを提供する
    • アンケートより100 倍良いシグナルである。アンケートには簡単に「はい」と答えられるが、ボタンをクリックするような行動には本当の関心が必要である。観察された行動は表明された意図に勝る

• 確信の代わりに顧客インパクトに集中する（Focus instead on customer impact）

  • 確信をインパクトに置き換える。インパクトは 2 つの形で定義される
    • 多数決（Majority rule）: 多数のユーザーが定期的に使う機能は明らかに重要であり、採用や継続利用の中核的な理由である可能性が高い
    • 熱烈な支持者（Passionate advocates）: 少数に熱狂的なファンを生む機能。「これがあるから買った」と言う人たち。普遍的ではなくても、特定のセグメントに深い忠誠心を生む（「magnificent delighters」）
  • ユーザーがある部分を心から愛していれば、他の欠点は受け入れる
    • iPod の魅力のおかげで、何十億人もの人が最悪のソフトウェアである iTunes に耐えた
    • 美しく設計されたソフトウェアは、機能の欠落やプラットフォーム制約があっても、デザイン体験だけで受け入れられる
  • 高インパクト機能の定量的定義
    • （1）顧客の少なくとも 51% が定期的に使う、または
    • （2）顧客の少なくとも 15% が選定・継続利用の理由として上位 3 つに挙げる
    • 高い基準ではあるが、革新的でリスクのある機能には高い基準がふさわしく、報酬の大きさがリスクを正当化すべきである

• レバレッジに投資する（Invest in leverage）

  • 小さな漸進的変化が大きな結果を生む領域が存在する
  • 数学的・構造的にほぼ常に成り立つレバレッジ領域がある
    • （関連書籍の宣伝部分は広告のため除外）

• オプションを最大化する（Maximize optionality）

  • 未来を知ることができないなら、そこに到達したときに持てる選択肢の数を最大化する選択をする
    • 単なる柔軟性やロックイン回避を超えて、何が起きても対処できるように設計する
  • 例
    • 低コストを維持する → 収益性を守りながら、多様な価格設定・パッケージング実験と将来の回復力を確保
    • 十分に検証され活発に開発されているクロスプラットフォーム UI ライブラリ・フレームワークを選ぶ → プラットフォームやデバイスの進化に対応
    • プラグインアーキテクチャ → 自分たちやコミュニティが今は想像できないものを構築できる
    • API-first アーキテクチャ → チーム分離、フロントエンド・バックエンド・顧客統合を接続
    • ベンダーサービスのラッパー → 不安定・高コスト・遅れたベンダーを置き換え可能にする
  • 将来のオプション確保は、今日の追加作業を必要とする
    • ベンダーをラップする API は、今日この瞬間には価値を追加しない
    • 安定性・予測可能性が重要な成熟企業には賢明だが、速度で既存の強者に勝たねばならない初期段階では誤った選択になりうる
  • 会社全体のオプションを最大化する道は、優れた会社を作ることである
    • 健全で持続的な成長、大きく拡大する粗利率、継続利用・アップグレード・口コミで証明される顧客の愛、長期勤続とキャリア成長で証明される従業員の愛
    • 優れた会社は、買収・独立維持・資金調達・IPO・承継など多くのオプションを持つ

• ベットのポートフォリオ（Portfolio of bets）

  • ポートフォリオは変動性を下げる代わりに、最大の上振れも小さくする
    • 勝ちがまったく出ない可能性は低く、下振れは悪くないが、勝ちが損失を埋める必要があるため、ときどきの大当たりですら単独ベットほど大きくはならない
    • たとえ話: IPO 時に Amazon を買って永遠に保有していれば最高だっただろうが、同じ年の別の IPO に当てはめていたら $0 になっていたかもしれない。ポートフォリオなら 0 にはならないが、最大成長は最高の銘柄よりずっと小さい
  • 数学的サイドバー: ポートフォリオが分布に関係なく機能する理由は、**中心極限定理（Central Limit Theorem）**にある
    • 安定しているが未知の分布の母集団から N 個の標本を繰り返し抽出し、標本平均のヒストグラムを描くと、その分布はガウシアン（正規分布）に収束する（平均は母平均、分散は母分散の 1/n）
    • Lindeberg–Lévy CLT は、各標本が異なる分布から来ていても成り立つことを示している（独立性・有限分散・単一変数が支配しないという条件のもとで）
    • ただし、スタートアップ環境でよくある分布ではこの条件が破れることがある（いくつかの Power Law では分散が無限大になる）
  • ポートフォリオは、予測可能だが平凡な結果を望むときには機能するが、**外れ値（outlier）**を狙うときには機能しない
    • ベンチャー・エンジェル投資のポートフォリオの例: 65% が損失を出し、リスクと非流動性を正当化できるリターンを生むのは約 10% にすぎない
    • 外れ値を狙うなら、ポートフォリオではなく一点集中の投資が必要である（スタートアップの収益分布が Lindeberg の基準を破る Power Law だからである）
  • 結論: 市場での差別化や成長ドライバーを探す優先順位付けにとって、ポートフォリオは誤った道具である。小さく信頼できる漸進的な結果には適しており、この場合は確信について争う必要はない

• 非対称ベット（Asymmetric bets）

  • ポートフォリオの自然な対極である。ポートフォリオが信頼性のためのものなら、非対称ベットは外れ値のためのものである
    • ベットの成否を予測するのではなく、下振れは限定され定量化でき、上振れは大きいベットを取る
  • 最悪が「2 か月の損失」で、最良が「完全な差別化」なら、確率はほとんど無意味である
    • 下振れが生存可能であり、上振れが 1 回の勝ちで 10 回の負けを埋められるほど大きければよい
    • 正確な確率はわからなくても、各ベットの**形（shape）**はわかる
  • 戦略レベルの非対称ベットは、たいてい形があらかじめ決まっている（複利的に推薦が積み上がる新市場、売るほど深くなる moat）
    • 機能レベルでは非対称性を自分で構成しなければならない。ソフトウェアプロジェクトの基本形は「2 週間 → 2 か月 → ここまで使った以上、終わらせるしかない」と漂流しがちだからである
    • メカニズムは開始前に書き留める予算: 「エンジニア 2 人、3 週間、その後で止めて見直す」。タイムボックスこそが限定された下振れである
  • 確信を**「どれほど非対称か」**に置き換えるのも一つの方法である
    • RICE は、わからないと認めている確率を見積もれと求める
    • 非対称性は、実際に見積もれる 2 つのことを問う: 時間・コスト基準での最悪と顧客価値基準での最良。どちらも具体的であり、すべての数字を 10 のべき乗に制限すれば、会議でも合意可能な数字に収束しうる

結論

• 確信を定量化または定義できるふりをやめること
• 代わりに、未来が予測不可能なときにいつでも機能する手法を使うこと — 未来は常に予測不可能なのだから

[hmmhmmhm]

「その代わり、未来が予測不可能なときにいつでも機能する手法を使うこと。未来は常に予測不可能なのだから」素晴らしいですね

[spilist2]

とても素晴らしい記事ですね。