feature-investment-advisor

目的

財務インパクト分析に基づいて機能を開発すべきかどうかを評価できるよう、プロダクトマネージャーを支援します。収益とのつながり（直接的または間接的）、コスト構造（開発費＋売上原価＋営業費用）、ROI の計算、戦略的価値を評価し、根拠となる計算を添えて、実行可能な「開発する／しない」の推奨を提示することで、データに基づいた優先順位付けの判断に役立てます。

これは汎用的な優先順位付けフレームワークではありません。機能の意思決定を財務的な視点から捉え、ほかの優先順位付け手法（RICE、価値対労力、ユーザー調査）を補完するものです。財務インパクトが重要な判断要因となる場合に使用してください。

入力

最適な入力： 開発するかどうかを判断している機能の説明（1、2 文）。 あると便利な情報： 収益とのつながり（直接的または間接的）、概算コスト（開発時間、売上原価、継続的な営業費用）、その機能を推す戦略的な根拠。

呼び出し時に渡された情報（スキル名の後に続くテキスト、貼り付けられたコンテキスト、または追記された ARGUMENTS: 行）は、すでに回答済みの情報として扱います。その情報を使い、該当する内容は聞き直さないでください。

何も情報がなくても大丈夫です。 アドバイザーがまず、どのような機能なのか、どのように収益を生み出す、またはコストを削減する想定なのかを尋ねます。

呼び出し例： Should we build SSO/SAML? Enterprise deals keep stalling on it; est. 2 engineer-months plus ongoing support burden.

主要な概念

機能投資フレームワーク

機能を財務面から体系的に評価するアプローチです。

1. 収益とのつながり — この機能は収益にどのような影響を与えますか？

   • 直接的な収益化（新しいプラン、アドオン、使用量に応じた課金）
   • 間接的な収益化（顧客維持率、コンバージョン、アップセル・クロスセルの促進）

2. コスト構造 — 開発と運用にはいくらかかりますか？

   • 開発コスト（一度限りの投資）
   • 売上原価への影響（継続的なインフラ、処理）
   • 営業費用への影響（継続的なサポート、保守）

3. ROI の計算 — 投資に見合うリターンはありますか？

   • 直接的な収益化：収益インパクト ÷ 開発コスト
   • 顧客維持機能：顧客基盤全体における LTV への影響 ÷ 開発コスト
   • 収益だけでなく、粗利益率も考慮する

4. 戦略的価値 — ROI だけでは評価しきれない価値

   • 競争上の堀（競合への顧客流出を防ぐ）
   • プラットフォームの基盤（将来の機能を実現可能にする）
   • 市場での位置付け（エンタープライズ案件の獲得に必要）
   • リスクの低減（コンプライアンス、セキュリティ）

アンチパターン（このフレームワークではないこと）

• 機能のスコア付けだけではありません： 財務分析と戦略的判断を組み合わせます
• 収益だけを考えるものではありません： 表面的な収益だけでなく、利益率、コスト、ROI も考慮します
• 顧客維持を無視しません： 間接的な収益インパクト（解約の削減）も同等に有効です
• 検証なしで開発するものではありません： 課題の探索を終えていることを前提とした、財務的な視点です

このフレームワークを使うタイミング

次のような場合に使います：

• 定量化可能な収益または顧客維持への影響がある機能の優先順位を決める場合
• 高コストの機能（エンジニア 1 人月超の作業）を評価する場合
• 内製・購入・提携の判断を行う場合
• 関係者や経営陣に機能の優先順位付けを説明する場合
• 直接的な収益化（アドオン）と間接的な収益化（顧客維持）のどちらを選ぶか判断する場合

次のような場合には使わないでください：

• 機能が競争上の必須条件である場合（競争力を同等に保つために必須）
• 影響が定性的なものだけである場合（測定可能な顧客維持効果を伴わないブランド価値や UX の満足度）
• 課題を検証していない場合（まず課題の探索を行ってください）
• 機能の開発に 1 週間未満しかかからない場合（そのまま開発してください）

---

ファシリテーションの信頼できる情報源

このスキルのデフォルトの対話プロトコルとして、workshop-facilitation を使用してください。

以下を定義しています。

• セッション開始時の案内と開始モード（ガイド付き、コンテキストの一括提供、最善の推測）
• 平易な言葉での質問を用いた、1ターンにつき1つの質問
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 中断への対応と一時停止・再開の動作
• 意思決定のタイミングでの番号付き推奨事項
• 通常の質問での番号付きクイック選択式回答（有用な場合は Other (specify) を含める）

このファイルでは、ドメイン固有の評価内容を定義しています。競合がある場合は、このファイルのドメインロジックに従ってください。

適用

この対話型スキルでは、最大4つの適応型質問を行い、意思決定のタイミングで3～5個の番号付き選択肢を提示します。

---

ステップ 0：コンテキストの収集

エージェントが質問します：

「この機能への投資が財務に与える影響を評価しましょう。以下を教えてください。

機能の説明：

• どのような機能ですか？（1～2文）
• 対象顧客セグメント（SMB、ミッドマーケット、エンタープライズ、すべて）

現在の事業状況：

• 現在のMRR/ARR（または収益化前の場合は顧客数）
• 現在のARPU/ARPA
• 現在の月次解約率
• 粗利益率（%）

制約：

• 開発コストの見積もり（チームの人数 × 期間）
• 継続的なCOGSまたはOpExへの影響はありますか？

正確な数値がわからない場合は、見積もりを入力してください。」

---

ステップ 1：収益との関連性を特定する

エージェントが質問します：

「この機能は収益にどのような影響を与えますか？収益との関連性を最もよく表す選択肢を選んでください。

1. 直接的な収益化（新たな収益源） — この機能に料金を設定します（新しい料金プラン、有料アドオン、従量課金）
2. 顧客維持率の向上（解約の削減） — 主要な解約理由に対処し、顧客の離脱を防ぎます
3. コンバージョン率の向上（トライアルから有料への移行） — 無料ユーザーやトライアルユーザーの有料顧客への転換を促します
4. 拡大の促進（アップセル／クロスセル） — アップセルの経路を作る、または利用量に応じた拡大を促します
5. 直接的な収益への影響なし — 必須機能、プラットフォームの改善、または戦略的価値のみ

番号を選ぶか、独自の収益との関連性を説明してください。」

選択に応じて、エージェントが質問を調整します：

1（直接的な収益化）の場合：

• 「どのような料金設定を検討していますか？」
• 「顧客の何％がこの機能を利用すると見込んでいますか？」（保守的、基本、楽観的）
• 計算：想定月間収益 = 顧客基盤 × 採用率 × 価格

2（顧客維持率の向上）の場合：

• 「この機能によって、解約の何％に対処できますか？」（例：「解約した顧客の30%がこの機能の不足を理由に挙げた」）
• 「解約率はどの程度改善すると見込んでいますか？」（例：「月次解約率が5%から4%へ」）
• 計算：LTVへの影響 = 顧客の平均利用期間の増加 × 顧客基盤 × ARPU × 利益率

3（コンバージョン率の向上）の場合：

• 「現在のトライアルから有料へのコンバージョン率は？」
• 「どの程度のコンバージョン率の上昇を見込んでいますか？」（例：「コンバージョン率が20%から25%へ」）
• 計算：追加MRR = トライアルユーザー数 × コンバージョン率の上昇幅 × ARPU

4（拡大の促進）の場合：

• 「この機能によって、どのような拡大の機会が生まれますか？」（上位プランへのアップセル、利用量の増加、アドオン）
• 「顧客の何％が利用を拡大すると見込んでいますか？」
• 計算：拡大によるMRR = 顧客基盤 × 拡大率 × ARPUの増加額

5（直接的な収益への影響なし）の場合：

• 戦略的価値の評価に進みます

---

ステップ 2：コスト構造の評価

エージェントが質問します：

「この機能のコスト構造はどのようになっていますか？

開発コスト（一時的）：

• チームの人数：___ 人のエンジニア
• 期間の見積もり：___ 週間／か月
• 開発コストの見積もり：$___

継続的なコスト（該当する場合）：

• COGSへの影響：$___ /月（ホスティング、インフラストラクチャ、処理）
• OpExへの影響：$___ /月（サポート、保守）

継続的なコストがない場合は、$0と入力してください。」

エージェントが計算します：

• 一時的な投資：開発コスト
• 継続的な月間コスト：COGS + OpEx
• 貢献利益率への影響：(収益 - COGS) / 収益

エージェントが次の点を警告します：

• COGSが予測収益の20%を超える場合：「⚠️ この機能により利益率が大幅に低下します」
• 継続的なコストが収益に対して高い場合：「⚠️ 持続可能かどうか検討してください」

---

ステップ 3：制約とタイミングを評価する

エージェントが尋ねます：

「どのような制約やタイミングに関する考慮事項がありますか？

1. 競争上の脅威が差し迫っている — 競合他社がこれをリリースし、商談を失っています
2. 予算／チームの対応力に限りがある — 今四半期に開発できる主要機能は 1 つだけです
3. 他の作業への依存関係がある — 先にプラットフォームの改善や他の機能が必要です
4. 大きな制約はない — 対応力と柔軟性があります

番号を選ぶか、制約について説明してください。」

選択に基づいて：

1（競争上の脅威）の場合：

• 戦略的価値が高まります（顧客離れの防止）
• 推奨内容に緊急性を反映します

2（対応力に限りがある）の場合：

• ROI をバックログにある他の機能と比較します
• 優先順位付けを推奨します

3（依存関係がある）の場合：

• 依存関係のリスクを明示します
• 実施順序を提案します

4（制約がない）の場合：

• 推奨内容に進みます

---

ステップ 4：推奨内容を提示する

エージェントが統合します：

• 収益への影響（ステップ 1 の内容）
• コスト構造（ステップ 2 の内容）
• 制約（ステップ 3 の内容）
• ROI の計算
• 戦略的価値の評価

エージェントが 3～4 件の推奨内容を提示します：

---

推奨パターン 1：強い財務的根拠がある

条件：

• ROI が 3:1 超（直接収益化）、または LTV への影響が 10:1 超（顧客維持／拡大）
• 貢献利益がプラス
• 重大な懸念事項がない

推奨内容：

「今すぐ開発する — 強い財務的根拠があります

収益への影響：

• [直接／間接の収益への影響の計算]
• 保守的な見積もり：$___／月
• 楽観的な見積もり：$___／月

コスト：

• 開発：$___
• 継続的な COGS／OpEx：$___／月
• 純利益率への影響：___%

ROI：

• 初年度の ROI：___:1
• 投資回収期間：___ か月

妥当と考えられる理由： [数値に基づく具体的な理由]

次のステップ：

1. 顧客調査で価格設定／導入の前提を検証する
2. 中核となる価値提案をテストするため、MVP を開発する
3. [具体的な指標] を監視して影響を測定する」

---

推奨パターン 2：財務的根拠は弱いが、戦略上の理由で開発する

条件：

• ROI が 2:1 未満、または財務的影響がわずか
• ただし、戦略的価値が高い（競争、プラットフォーム、コンプライアンス）

推奨内容：

「戦略上の理由で開発する（財務的根拠はわずかです）

財務上の実態：

• 収益への影響：$___／月（わずか）
• 開発コスト：$___
• ROI：___:1（3:1 の基準未満）

戦略的価値：

• [競争優位性／プラットフォームの実現要因／市場要件]
• 競合他社 X への顧客離れを防ぎます
• エンタープライズセグメントで必須です（パイプラインの 30%）

推奨内容： 開発しますが、注意深く監視してください：

1. 導入状況を予測値と比較して追跡する
2. 顧客離れへの影響を測定する（目標：顧客離れを ___% 削減）
3. 導入が低調な場合は、6 か月後に再評価する

リスク： 機会費用 — 他の機能のほうが ROI が高い可能性があります」

---

推奨パターン 3：開発しない（ROI が低い）

条件：

• ROI が 1:1 未満（直接収益化）、または LTV への影響がマイナス
• 利益率を低下させる
• 説得力のある戦略的価値がない

推奨内容：

「開発しない — 財務的根拠が投資を裏付けていません

理由：

• 収益への影響：$___／月
• 開発コスト：$___
• ROI：___:1（損益分岐点未満）
• 利益率への影響：粗利益率が ___% から ___% に低下します

代替案：

1. 範囲を縮小する — コストを 50% に抑えた、より簡易なバージョンを開発できますか？
2. 収益化の方法を変える — 価格を引き上げたり、別の方法で課金したりできますか？
3. 優先度を下げる — [代替案] のような、ROI の高い機能に注力する

どのような変化があればよいか：

• 導入率が ___% から ___% に上昇すれば、ROI が実現可能になります
• 開発コストを $___ まで削減できれば、投資回収期間が許容範囲になります」

---

推奨パターン 4：後で構築する／データをさらに集める

次の場合：

• 前提の不確実性が非常に高い
• 収益への影響が未検証の仮説に左右される
• 戦略的価値が中程度

推奨事項：

「後で構築する — まず前提を検証します

現在の不確実性：

• 想定導入率：___％（検証が必要）
• 解約への影響：___％の減少（仮説であり、実証されていません）
• 価格は不明

検証する項目：

1. 50社以上の顧客を対象に機能需要のアンケートを実施する
2. プロトタイプを作成し、支払い意思をテストする
3. 解約した顧客にインタビューし、解約理由への対処になるか確認する

判断基準：

• 顧客の___％が$___を支払うと回答した場合は、構築する
• 解約者へのインタビューで上位3つの理由の1つだと確認できた場合は、構築する
• それ以外の場合は、優先度を下げる

スケジュール：

• 検証に2〜4週間を費やす
• 実データをもとに再評価する」

---

ステップ 5：追加の質問に対応する

エージェントからの提案：

「次のどれを行いますか？

1. 詳細な計算内訳を見る
2. 別の機能と比較する
3. 前提（価格、導入率、コスト）を調整する
4. 推奨事項の概要をエクスポートする

または、追加の質問をどうぞ。」

エージェントができること：

• 詳細な計算を表示する
• 感度分析を行う（導入率が2倍なら？0.5倍なら？）
• 複数の機能を並べて比較する
• 関係者向けに概要をエクスポートする

---

例

会話フローのサンプルは examples/ フォルダーをご覧ください。以下に簡単な例を示します。

例 1：直接的な収益化（タイムトラッキングのアドオン）

ユーザー：「有料アドオンとしてタイムトラッキングを構築することを検討しています。」

エージェント：［コンテキストを収集］

ユーザーからの情報：

• 現状：顧客1,000社、ARPU $500、粗利益率80％
• 機能：タイムトラッキングのアドオン、ユーザーあたり月額$10
• 開発コスト：$100K（エンジニア2名 × 3か月）
• 想定導入率：顧客の20％

エージェントの計算結果：

• 1アカウントあたりの平均ユーザー数は10人 = 1,000アカウント × 10人 = 10,000人
• 導入率：ユーザーの20％ = 2,000人
• 収益：2,000 × $10 = 月額$20K = 年額$240K
• 粗利益：$240K × 80％ = 年額$192K
• ROI：$192K / $100K = 1年目で1.92:1
• 投資回収期間：$100K / $20K = 5か月

エージェントの推奨事項：

「今すぐ構築する — 投資回収が早く、ROIがプラスです

収益への影響： 年額$240K（導入率を控えめに20％と想定） ROI： 1年目で1.92:1、2年目で3.8:1 投資回収期間： 5か月

有効な理由：

• 投資回収が早い（5か月）ため、リスクが低い
• アドオン収益の粗利益率は80％
• 導入率20％は控えめな想定です（支払い意思をテストします）

次のステップ：

1. 顧客にアンケートを実施する：タイムトラッキングにユーザーあたり$10を支払うのは誰か？
2. 中核的なタイムトラッキング機能に絞ってMVPを構築する
3. 幅広くリリースする前に、50社の顧客を対象にベータテストを行う
4. 導入率を目標の20％と比較して追跡する」

例 2：解約防止機能（データエクスポート）

ユーザー：「データを簡単にエクスポートできないため、顧客を失っています。包括的なエクスポート機能を構築すべきでしょうか？」

エージェント：［コンテキストを収集］

ユーザーが提供した情報：

• 現状：MRR 200 万ドル、顧客 500 社、ARPA 4,000 ドル、月次解約率 5%
• 機能：完全なデータエクスポート（CSV、API、スケジュールエクスポート）
• 開発コスト：15 万ドル（エンジニア 3 人 × 2 か月）
• 解約の背景：解約した顧客の 30% がデータエクスポートを理由に挙げた

エージェントが計算：

• 現在の年間解約率：約 46%（月次 5% を複利計算）
• 年間の解約顧客数：500 × 46% = 230 社
• エクスポートの問題が原因で解約した顧客数：230 × 30% = 69 社
• 失われる MRR：69 × 4,000 ドル = 年間 27 万 6,000 ドルの MRR 損失 = ARR 330 万ドル

この機能で解約を 50% 削減できる場合：

• 防止できる解約：年間 35 社
• 節約できる MRR：年間 14 万ドル
• LTV への影響（顧客の契約期間を 24 か月と仮定）：14 万ドル × 24 = 336 万ドル

エージェントが ROI を計算：

• 投資額：15 万ドル
• 節約できる LTV：336 万ドル（保守的に 50% 削減と想定）
• ROI：336 万ドル / 15 万ドル = 22.4:1 🚀

エージェントの推奨：

「すぐに構築しましょう — 解約防止において非常に高い ROI が見込めます

効果：

• 年間約 35 社の解約を防止
• 年間 14 万ドルの MRR を節約
• LTV への影響：顧客の契約期間全体で 336 万ドル
• ROI：22:1（非常に優れています）

迷わず実行できる理由：

• 解約の 30% がこの問題を理由に挙げている（問題が検証済み）
• 解約防止率が 25% にとどまっても（50% ではなく）、ROI は 11:1
• 解約防止の改善は複利効果を生みます（将来の解約も減らせます）

次のステップ：

1. 解約した顧客にインタビューし、エクスポートが主な理由だったかを検証する
2. まず基本的なエクスポート機能（CSV、API）を構築する
3. リリース後の解約率の変化を測定する（目標：5% → 4.5%）
4. 利用率が高ければ、スケジュールエクスポートを追加する」

---

例 3：ROI の低い機能（ダークモード）

ユーザー：「ユーザーからダークモードの要望が寄せられています。優先すべきでしょうか？」

エージェント：［コンテキストを収集］

ユーザーが提供した情報：

• 現状：MRR 50 万ドル、顧客 2,000 社、ARPA 250 ドル、月次解約率 3%、粗利益率 75%
• 機能：製品全体での完全なダークモード
• 開発コスト：8 万ドル（デザイナー 2 人 + エンジニア 2 人 × 1 か月）
• 収益との関連：間接的 — 解約防止に多少役立つ可能性があります

エージェントの質問：「ダークモードで解約率が下がるという、どのような根拠がありますか？」

ユーザー：「50 人のユーザーから機能リクエストがありました。解約への影響を示すデータはありません。」

エージェントが計算：

• 顧客 2,000 社のうち機能をリクエストしたのは 50 人 = 顧客全体の 2.5%
• 解約への影響は検証されていません
• 開発コスト：8 万ドル
• 楽観的なシナリオ：年間 5 社の解約を防止（顧客全体の 2.5%）
• 節約できる MRR：5 × 250 ドル = 月 1,250 ドル = 年間 1 万 5,000 ドル
• LTV への影響（顧客の契約期間を 24 か月と仮定）：1 万 5,000 ドル × 24 = 36 万ドル

ROI：36 万ドル / 8 万ドル = 4.5:1（一見よさそうですが、根拠の弱い前提に基づいています）

エージェントの推奨：

「後回しにしましょう — ROI を裏付ける根拠が弱いです

現時点での評価：

• 収益への影響：年間 1 万 5,000 ドル（楽観的な想定）
• 開発コスト：8 万ドル
• ROI：4.5:1（ダークモードで解約を防げると仮定）

問題点：

• 要望したユーザーはわずか 50 人（顧客全体の 2.5%）
• ダークモードで解約率が下がるという根拠がありません
• 解約者へのインタビューでも、主な理由として挙がっていません

代替案：

1. 解約した顧客にアンケートを実施する — ダークモードは解約理由の上位 5 位に入りますか？
2. 需要をテストする — トライアルユーザーに「ダークモードは、利用を継続する判断に影響しますか？」と尋ねます
3. 範囲を縮小する — 実験として、基本的なダークモードを構築します（コストは 20%）

検討すべき、より効果的な機能：

• 解約防止が優先事項の場合：解約した顧客にインタビューし、解約の主な要因を 3 つ特定する
• 収益が優先事項の場合：拡張機能（アップセル、追加機能）に注力する

構築を決める基準：

• 解約者へのインタビューで、ダークモードが上位 3 位の理由に入る → 構築する
• コンバージョン調査で 10% 以上の効果が示される → 構築する
• それ以外の場合 → 優先度を下げる」

---

よくある落とし穴

落とし穴 1：収益と利益を混同する

症状：「この機能で 100 万ドルの収益が見込めます！」（売上原価 80 万ドルを無視）

**結果：**利益率 20% の場合、収益 100 万ドルの価値は利益 100 万ドルではなく、20 万ドルです。コストを考慮するまでは、機能の価値が非常に高く見えてしまいます。

**対処法：**必ず限界利益を計算します。収益だけではなく、Revenue × Margin % を使用します。

---

落とし穴 2：投資回収期間を無視する

症状：「ROI は 5:1 だ。開発しよう！」（ただし投資回収期間は 36 か月で、顧客は 24 か月で解約します）

**結果：**投資回収前に顧客が離れてしまうため、投資を回収できません。

**対策：**投資回収期間を確認します。平均顧客継続期間より短くなければなりません。

---

落とし穴 3：導入率を過大評価する

症状：「顧客の 100% がこの有料アドオンを使うはずです！」

**結果：**実際の導入率は 10〜20% です。収益予測が 5〜10 倍も高くなります。

**対策：**控えめな導入率の見積もり（アドオンの場合は 10〜20%）を使います。支払い意思の調査で検証します。

---

落とし穴 4：検証せずに開発する

症状：「これで解約率が下がると思います」（顧客インタビューなし）

**結果：**実際の解約理由に対処しない機能を開発してしまいます。解約率は変わりません。

**対策：**まず解約した顧客にインタビューします。この機能が上位 3 つの解約理由に対処することを検証します。

---

落とし穴 5：機会費用を無視する

症状：「この機能の ROI は 2:1 だ。開発しよう！」（他の機能の ROI は 10:1）

**結果：**より優れた選択肢がバックログに残ったまま、平凡な機能を開発してしまいます。

**対策：**機能間で ROI を比較します。最高の ROI を持つ機能から開発します（戦略的価値を優先する場合を除きます）。

---

落とし穴 6：戦略的価値を言い訳にする

症状：「ROI はひどいが、戦略的です！」（明確な戦略なし）

結果：「戦略的」が、価値の低い機能を開発するための何にでも使える口実になります。

**対策：「戦略的」の意味（競争上の堀、プラットフォームの実現要因、コンプライアンス）を定義します。該当しないなら、戦略的ではありません。

---

落とし穴 7：利益率の希薄化を見落とす

症状：「この機能で売上が 50 万ドル増えます！」（ただし売上原価は 40 万ドル）

**結果：**粗利益率が 80% から 60% に低下します。この機能はユニットエコノミクスを損ないます。

**対策：**貢献利益率を計算します。利益率が 50% 未満なら、再検討するか、プレミアム料金を設定します。

---

落とし穴 8：見栄えだけの指標を喜ぶ

症状：「この機能でエンゲージメントが向上します！」（ただし売上にも継続率にも影響しません）

**結果：**気分はよくても、事業成果に影響しない機能を開発してしまいます。

**対策：**機能を売上または継続率に結び付けます。エンゲージメントは先行指標であり、成果ではありません。

---

落とし穴 9：貨幣の時間価値を忘れる

症状：「この機能は 5 年で投資を回収できます」

**結果：**5 年後の 1 ドルの価値は、現在では約 0.65 ドルです（割引率 9% の場合）。ROI が過大評価されます。

**対策：**投資回収期間が長い（24 か月超）場合は、将来のキャッシュフローを割り引くために NPV（正味現在価値）を使います。

---

落とし穴 10：声の大きい少数派のために機能を開発する

症状：「顧客 50 人がこれを要望しています！」（顧客 10,000 人中）

**結果：**顧客基盤の 99.5% を無視しながら、0.5% に最適化してしまいます。

**対策：**売上への影響または顧客セグメントに応じて機能リクエストに重み付けします。エンタープライズが戦略の中心なら、SMB 顧客 100 人よりエンタープライズ顧客 10 社を優先します。

---

参考資料

関連スキル

• saas-revenue-growth-metrics — 影響の計算に使う売上、ARPU、解約率、NRR の指標
• saas-economics-efficiency-metrics — ROI、投資回収、貢献利益率の計算
• finance-metrics-quickref — 数式とベンチマークをすばやく確認
• acquisition-channel-advisor — チャネルの意思決定に使う類似の ROI フレームワーク
• finance-based-pricing-advisor — 収益化機能の価格設定への影響分析

外部フレームワーク

• RICE 優先順位付け — リーチ、インパクト、確信度、工数を組み合わせます（このスキルでは財務的な観点を追加します）
• 価値対工数マトリクス — このスキルでは「価値」を財務的に定量化します
• Jobs-to-be-Done — 財務的影響を評価する前に、顧客の課題を理解します
• Opportunity Solution Tree（Teresa Torres） — ROI を計算する前に機会をマッピングします

出典

• research/finance/Finance_For_PMs.Putting_It_Together_Synthesis.md（意思決定フレームワーク #1）を基に作成
• クイズのシナリオは research/finance/Finance for Product Managers.md より