evaluating-trade-offs

トレードオフを評価する

競合する選択肢を比較検討する技術を身につけ、長期的なインパクトとチームの開発速度を最大化しましょう。

Lenny's Podcast と Newsletter に登場する14人のゲストや投稿から得た知見を活用し、トレードオフの評価をサポートします。

サポート内容

1. フレームワークの選択 - 直面している具体的なトレードオフの状況に合った意思決定テンプレートを選びます。
2. ROI の算出 - 提案された方針について、長期的なビジネスへの影響と運用コストをモデル化するのを支援します。
3. ステークホルダーとのコミュニケーション - 「はい」と答えることで生じる隠れたコストをリーダーが理解できるよう、トレードオフの伝え方を改善します。
4. バイアスの検出 - サンクコストの誤謬や「エンジニアをあと1人追加すれば解決する」という神話など、現在の考え方に潜むよくある落とし穴を特定します。

基本原則

企画段階で技術的な難所を洗い出す

Ryan Singer：「家のリフォームにたとえてよく説明します。新しい寝室の素晴らしい完成予想図を描き、ベッドの脇には壁から出ているランプを設置するとしましょう。でも、その壁に電気が通っているかどうかを確認していなければ、費用も時間も、その他すべてが大きく変わってしまいます。」

精度の高いデザインにチームが着手する前に、シニアエンジニアを早い段階から巻き込み、技術的な複雑さやインフラの制約を特定しましょう。

何もしないリスクを定量化する

「This Week #13: Balancing outcome-thinking with design and technical requirements ⚖️」より：「成果を重視する考え方と、エンジニアリングやデザインのニーズ（これらは成果に直接結びつかないことがよくあります）をどう両立させたか、という質問への答えは簡単です。成果を重視する考え方を、さらに先の未来まで広げるのです。この作業は、1年以上先の成果（成長、品質、定着率など）にどれほど貢献するでしょうか。実施しない場合、どうなるでしょうか。成功する可能性はどれくらいでしょうか。」

大規模な技術投資やデザイン投資を評価する際は、今実施した場合のインパクトと、何もしない場合のコストやリスクを比較しましょう。

基盤となるニーズには SaaS を活用する

Austin Hay：「実際に開発速度を高める方法は、単に『自社開発か購入か』で考えるのではなく、『今すぐ自社開発と購入の両方をする』と考えることです。つまり、まずツールを購入して90％まで対応し、その上に残りの10％となる優れた機能を自社開発します。その設計上の判断は、通常この担当者に委ねられます。」

車輪の再発明は避け、コア機能にはサードパーティ製ソリューションを購入し、社内のエンジニアリングは独自のレイヤーに注力しましょう。

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

• トレードオフを伝える5つの手法（リーダーに耳を傾けてもらえるトレードオフの伝え方） - Tara Seshanによる5段階の実践ガイドです。トレードオフを明確にして、シニアリーダーが「両方やる」という選択を安易にするのを防ぎます。
• マジックレンズ（4つの定番レンズ＋カスタム）（Foundation Sprintのご紹介：Design Sprintの生みの親による取り組み） - それぞれ異なる意思決定の視点を表す複数の2×2チャートに、複数のプロダクトアプローチをプロットして評価する手法です。
• 技術／デザイン投資評価フレームワーク（今週のトピック #13：成果思考とデザイン・技術要件のバランス ⚖️） - Airbnbで、短期的な成果に直結しない大規模な技術・デザイン作業に投資するかどうかを判断するために使われている、シナリオベースの評価フレームワークです。
• 構築と購入の両立（Austin Hay） - ソフトウェア調達における二者択一の「構築か購入か」という議論を、ハイブリッドなアプローチに置き換える意思決定フレームワークです。
• 信号機式意思決定マトリックス（Naomi Gleit） - 会議で、単純なメリット・デメリットの一覧ではなく色分けを使い、特定の基準に照らして3つの選択肢を評価する視覚的な表です。
• 重み付け意思決定スプレッドシート（Nicole Forsgren） - 重み付けした基準に基づいて選択肢を評価するスプレッドシートです。
• 「何を最適化するか」フレームワーク（Nikita Miller） - 優先順位付けとトレードオフのためのメンタルモデルです。
• SCQAトレードオフ意思決定文書（リーダーに耳を傾けてもらえるトレードオフの伝え方） - Situation-Complication-Question-Answerフレームワークと要点を用いて、優先順位付けのトレードオフを経営陣に提示する構造化された文書です。
• 「自分たちでやるべきか？」文書（Jeff Weinstein） - 社内の能力を構築するか、サードパーティーベンダーを利用するかを評価する、年次の戦略文書です。
• 大企業向けの構築／購入／提携の意思決定フレームワーク（Tanguy Crusson） - Atlassianが新市場への参入時に、社内で構築するか、買収するか、提携するかを評価する方法です。

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

ユーザーを支援するための質問

• 「チームが優先事項を絞り込み、この具体的なトレードオフを解決するのに役立つ、最も明確な問いは何ですか？」
• 「これを社内で構築する場合、長期的な保守費用と運用コストはどのくらいになると予測されますか？」
• 「このプロジェクトは、チーム固有の目標と比べて、会社全体のロードマップにどのような影響を与えますか？」
• 「開発を始めた後、どのようなインフラ上の制約や技術的な難題に直面する可能性がありますか？」
• 「短期的な指標を最適化しているのでしょうか。それとも、長期にわたって大きな顧客価値を生み出す基盤を構築しているのでしょうか？」
• 「検討中の案よりも別の判断のほうが優れているのは、どのような具体的な条件のときですか？」

注意すべきよくある間違い

• 構築か購入かの二者択一の罠 - ハイブリッドなアプローチのほうが効率的な場合が多いにもかかわらず、チームは完全なカスタムソリューションを構築するか、融通の利かないツールを購入するかのどちらかしかないと思い込みがちです。
• 無理を重ねる代償の無視 - 両方の選択肢を実行するための短期的な無理が、時間とともにチームの士気や運用の安定性を損なうことを、リーダーは見落としがちです。
• 抜本的な再設計の成功を過大評価すること - 抜本的な変更は、段階的な改善よりも統計的に失敗する可能性が高いにもかかわらず、実行が簡単そうに見えることから選ばれがちです。
• 「エンジニアをもう1人増やせば何とかなる」という誤謬 - 根本的に欠陥のあるプロジェクト構造や競争上の不利を、リソースを1つ追加するだけで解決できると考えることです。

詳細

14人のゲストから得た、出典付きの13件すべてのインサイトについては、references/guest-insights.mdを参照してください。

関連スキル

• ロードマップの優先順位付け
• 目標設定（OKR）
• 計画の実施サイクル
• 重要な意思決定