high-stakes-decisions

ハイステークスな意思決定

不可逆的な選択と極度の不確実性を、スピードと構造的な明確さで乗り切りましょう。

Lenny's Podcast と Newsletter にわたる30名のゲストと投稿からのインサイトを活用し、ハイステークスな意思決定をユーザーが行えるよう支援します。

支援の方法

1. ステークスを分類する - その意思決定が一方通行のドアか両方向のドアかを見極め、適切なレベルの厳密さを適用できるよう支援します。
2. 核心となる問題を明確にする - 「Eigenquestion（固有の問い）」、つまりその選択を左右する唯一の決定的な理由を特定できるよう促進します。
3. 感情的なバイアスを軽減する - プリモータムや中立な第三者からの視点といった手法を用いて、恐怖やサンクコストが現実を歪めている箇所を特定します。
4. 結論へと導く - 合意形成から明確なオーナーシップへと移行し、70パーセントの情報で最終判断を下す前に、全員の意見が聞かれるようにします。

中核となる原則

先行指標を特定する

Annie Duke：「長いフィードバックループというものは存在しません。そして、フィードバックループを短縮する方法とは、最終的に自分が望む結果と相関するものは何かと問うことです。」

長期的な目標を測定可能な中間シグナルに分解し、より短いフィードバックループを生み出すことで、より良い意思決定を行います。

必要な痛みに向かって走る

Ben Horowitz：「あなたが犯す最大の過ち、リーダーとして行う最悪のことは——自分の制御下にあるものも、制御外にあるものもある中で——ためらいです。それは一般に最も破壊的です。私はそれがどれほど破壊的であるかのあらゆる側面を見てきましたが、極めて悪いものです。そして、あなたがためらう原因となるのは、どちらの選択肢も恐ろしいということです。」

等しく苦痛な二つの選択肢に直面したときは、選択を避けるのではなく、自分の知覚を信じて断固として行動します。

技術の軌道に合わせて構築する

Kevin Weil：「私たちの基本的な考え方は、2か月後にはより優れたモデルが登場し、現在の一連の制約など吹き飛ばしてしまうだろうというものです。これは開発者にも言っています。もしあなたが構築しているプロダクトが、モデルの能力のまさに限界線上にあるなら、そのまま続けてください。それは正しいことをしている証拠です。もう数か月待てばモデルは素晴らしくなり、ぎりぎり動いていただけのあなたのプロダクトが、突然本当に輝き始めます。」

現在の技術的制約に最適化するのではなく、数か月後にモデルの能力がどこに到達するかに基づいてプロダクトとロードマップを設計します。

既存の誠実さを優先する

Laura Modi：「今日 Bobbie を利用している赤ちゃんたちに提供するプロダクトがなくなってしまいます。すでに Bobbie にコミットしてくれた人たちに提供できなくなるまで、あと6日ほどです。彼女はこう言いました。『だから、サイトを閉じて、ビジネスの成長を止める必要がある』と。」

真の顧客中心主義とは、供給やリソースが深刻に不足している時期に、新規獲得よりも既存ユーザーへの提供を優先することを求めます。

恐怖に基づく予測を無効化する

Matt Mochary：「私が魔法使いや天才だからではありません。恐怖の中にいる人は、とらわれてしまい、現実を見ることができず、脳が非常に誇張された予測を生み出します。一方、恐怖の中にいない人——私の場合、自分の状況ではないので恐怖の中にいません——はとらわれておらず、したがって脳が誇張された予測を生み出しません。そして、私が一度勝つというこの賭けをすると、CEO は突然こう気づくのです。なんてことだ、これは確かに何かがある、恐怖は悪い助言を与えるのだと。」

困難な選択について、恐怖が誇張された否定的な予測を生み出しているのはいつかを見極めるために、中立な第三者を活用します。

前進し続ける

Claire Hughes Johnson：「意思決定者が誰かわからない場合、まず、おそらくそれはあなたです。そうではないと考えるより、そのように行動するほうがいいと思います。そうしないと、会社全体の動きが遅くなってしまいます。プロセスに従ってやり遂げ、実際に決定を下すことを忘れないでください。」

権限が曖昧なときは、自ら率先して決定を主導し、組織の機能停止を防いで、キャリアの歩みを前進させましょう。

70％の情報で決める

「厄介なプロダクトマネージャーの5つの習慣」より：「次に決断に迷ったら、チームにこう聞いてみてください。議論を続けるのと、あなたに決めてもらうのと、どちらがいいか。きっと、みんな先に進みたいと思うはずです。」

完璧な合意を求めるのではなく、チームの勢いを保つため、判断を下すのに必要な情報のおよそ70％がそろった段階で決定することを目指しましょう。

テンプレートとフレームワーク

• Eigenquestions：問題を捉える技術（お気に入りのプロダクトマネジメント用テンプレート）- ひとつ答えが出れば、その後のすべての問いに答えられる、最も重要な問いを特定するためのフレームワークです
• S.P.A.D.E. 意思決定フレームワーク（お気に入りの意思決定フレームワーク）- 合意形成の代わりに、単独の意思決定責任者を定めて説明責任を明確にする、体系的な意思決定フレームワークです。SPADE は Setting、P
• RAPID 意思決定フレームワーク（Hari Srinivasan）- 複雑な意思決定における役割を明確にし、迅速さと説明責任を確保するモデルです。
• Kombucha Scale（お気に入りの意思決定フレームワーク）- 重要度と緊急度という2つの変数に基づいて、意思決定に正式なフレームワークが必要かどうかを判断する、Square の簡易な思考モデルです。
• Type-1 および Type-2 の意思決定（プロダクトマネジメントへの入り方）- Jeff Bezos による意思決定の分類フレームワークです。取り消せない決定（Type-1）と取り消せる決定（Type-2）に分類し、どれほど熟慮すべきかを判断します
• Tigers、Paper Tigers、Elephants を用いたプレモーテム（Shreyas Doshi）- プロジェクトが失敗したと仮定してから、リスクを3種類に分類する、体系的なプレモーテム会議のフレームワークです。Tigers は実際にプロジェクトを潰す脅威を指し、
• Single Decisive Reason（SDR）（Rahul Vohra）- Reid Hoffman から学んだ意思決定ツールです。弱い理由をいくつも並べるのではなく、それだけで決定を正当化できる理由をひとつ特定します
• 危機におけるシナリオ計画（3つのシナリオ）（パンデミックを乗り越えて会社を導く - 第20号）- 経済危機において、深刻度が異なる3つのレベルで事業の成果をモデル化するフレームワークです
• フレームワーク選択ガイド（体系的なものから最も体系化されていないものまで）（お気に入りの意思決定フレームワーク）- 意思決定フレームワークを最も体系的なものから最も体系化されていないものまで並べた Lenny によるランキングで、それぞれをいつ使うべきかの指針も示しています。

詳細を含む全リストは references/artifacts.md を参照してください。

ユーザーに役立つ質問

• 「取り消すコストを考えた場合、これは一方通行の決定ですか、それとも双方向の決定ですか？」
• 「この提案について、理由をたくさん並べなくても単独で決定を正当化できる、決定的な理由は何ですか？」
• 「最終的な結果が出る前に、この方針が正しいかを検証するため、どの先行指標をモニタリングしますか？」
• 「主な反対者は誰ですか。また、懸念を理解するために、それぞれと個別に話しましたか？」
• 「このプロジェクトを客観的に中止するきっかけとなる、事前に定めた中止基準は何ですか？」
• 「必要なデータが70％しかない状態で決めなければならないとしたら、今どの方向に進みますか？」

よくある指摘すべき間違い

• 意見の一致を重視し、足並みをそろえることを軽視する - 全員の合意を目指すと、決定が骨抜きになったり、組織が意思決定できなくなったりすることがよくあります。
• 二方向ドアの考え方を誤って適用する - 多くのリソースを費やす戦略的な機能について、深く考えることを避ける口実として、元に戻せることを利用します。
• 苦渋の選択を避ける - 選択肢がどれも望ましくないため、リーダーが決定を先延ばしにすることがありますが、それによって最終的なコストが増すだけです。
• サンクコストバイアスを無視する - 将来的な有用性ではなく、プロジェクトに結びついた感情的なアイデンティティのために、失敗しているプロジェクトに固執します。

詳細

30人のゲストから得られた24件の知見すべてについては、references/guest-insights.md をご覧ください。

関連するスキル

• ロードマップの優先順位付け
• 目標設定とOKR
• 計画の実施サイクル
• トレードオフの評価