build-business-case

ビジネスケースの構築

ばらつきのあるアカウント情報を、顧客主導で意思決定に役立つ価値ケースにまとめます。このスキルが担うのは、ビジネスケースのロジックと草案の作成です。一般的な製品のポジショニング、プレゼンテーションのデザインワークフロー、書き戻しのワークフローではありません。

製品ではなく、顧客を起点にします。実行するたびに、次の流れに沿って進めます。

customer context -> account-native anchor -> workflow -> use case -> value drivers -> metrics -> quantified impact -> narrative -> public research when useful

信頼できる数値を裏付ける証拠がない場合は、構造を示すケースであることを明記し、財務部門が判断できる状態にするために必要な最小限の検証計画を作成します。

共通スキルの指示

必須：まだコンテキストにない場合は、plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practicesを読み、内容を厳密に遵守してください。

主な依存カテゴリ

ケースの改善に実質的に役立つ情報源のみを使用します。

• [ブロッキング] ~~CRM：アカウント、商談、担当者、ステージ、金額、成約時期、連絡先、商業的背景の正確な情報源です。権威あるアカウント情報と商業的背景がすでに確認できていない場合、顧客やアカウントに固有のケースの作成には必須です。一般的なシナリオケースは、これがなくても作成できます。
• ~~Meeting Transcripts：ディスカバリーの証拠、関係者の言葉、ワークフローの課題、反論、数値化された主張、決定事項、検証の不足点
• ~~Knowledge & Files：アカウント計画、ソースパック、ディスカバリーノート、過去の価値ケース、実績、アカウント固有の指標
• ~~Sales Intelligence：会社、適合性、関係者、市場に関する情報によって、具体的な証拠の不足が補われる場合にのみ使用します

公開情報の調査は、戦略的な優先事項、経営層向けの表現、事業運営上の圧力、または「今なぜか」を明確にする場合にのみ行います。企業が管理する情報、投資家向け情報、規制関連情報、その他の一次情報を優先してください。公開情報やエンリッチメント情報を、顧客が確認した課題、ワークフロー指標、意思決定プロセス、またはCRMが管理する正確な情報の代わりにしてはなりません。

参照資料の読み込み

通常の顧客主導の進め方、証拠の優先順位、ガードレール、デフォルトの成果物はSKILL.mdが定めます。追加の詳細が必要な場合にのみ、参照資料を読み込みます。

• 入力にばらつきがある場合、ユーザーが出力モードを指定している場合、または必須コンテンツの要件全体を確認する必要がある場合は、入力と出力を使用します。
• 複雑なケースで、顧客から価値に至るまでの手順を詳しく確認し、例を参照する必要がある場合は、ワークフローを使用します。
• 数値化、確信度のラベル付け、証拠の矛盾、または価値カテゴリのロジックについて、より詳しい情報が必要な場合は、価値モデルと証拠を使用します。
• 形式を整えた成果物、プレゼンテーションや出力に関する具体的な要件、または動作テストが必要な場合にのみ、出力とプレゼンテーションを使用します。

ワークフローのガイダンス

1. 顧客と意思決定の基準点を特定する

• 顧客／アカウント／シナリオに加え、ワークフロー、取り組み、課題、指標の目標、または意思決定の背景を必須とします。十分な情報がある場合は、貼り付けられたメモ、リンク、エクスポートデータ、または明確な基準点があるスレッドから進めます。
• 推定された必須の基準点が曖昧な場合は、情報源の読み取りを最大3回に抑えて範囲を限定して調べ、具体的な候補を最大5つ提示し、広範な情報収集を始める前にユーザーに選択を求めます。
• 企業名らしき名称は、アカウントの基準点である可能性があるものとして扱います。~~CRMが利用できる場合は、間接的な情報を頼りにする前に、アカウントと対応する商談を特定します。
• 顧客とワークフローの両方が仮説を安定して立てるには不十分な場合は、必要最小限の確認質問だけをします。

2. まずアカウント固有の根拠となる情報を見つける

• ユーザーから提供された指標、メモ、リンク、エクスポートから始めます。提供されていない場合は、広範な検索を始める前に、アカウント固有の情報の中から最も有力な資料を探します。まず、[customer] business case、value case、ROI、pilot target、expansion path などの完全一致検索で ~~Knowledge & Files を検索し、次に該当する ~~CRM の商談を確認し、その後、関連する ~~Meeting Transcripts を確認します。
• 最も有力な根拠資料を最初に取得します。顧客名、ワークフロー、意思決定者、商業上の重要事項、指標、緊急性、注意事項が含まれる資料は、特に有力です。
• ワークフロー上の課題、承認経路、予算の所管、時期、リスク、顧客へのフォローアップなど、重要な不足情報を検証する場合に限り、関連する情報源を追加で確認します。
• パイロット金額、拡大の道筋、目標価値、予算範囲、成約時期、有料パイロットの条件など、アカウント固有の根拠に含まれる商業上の重要情報を保持します。CRM の情報が不十分な場合は、出典のある事実を残し、CRM に不足している情報を別途明記します。
  • 例：Known from ~~Knowledge & Files source pack: SGD 420K pilot target and SGD 1.8M expansion path. Missing from ~~CRM: opportunity stage, owner, and close date.
• 根拠を示して重要な論点を裏付けられた時点で、最初の調査を終えます。情報源が他にもあるという理由だけで、成果の少ない検索を続けないでください。
• 企業名が指定された上場企業の場合、ユーザーが無効にしていない限り、またはアカウント固有の根拠だけですでに重要な「なぜ今なのか」という問いに答えられていない限り、対象を絞って一次公開情報を調査します。これにより、戦略上の優先事項や経営層向けの表現を明確にします。ただし、最初に有用な事例を作成するのを遅らせたり、アカウント固有の根拠を置き換えたりしてはいけません。

3. 顧客価値のロジックを構築する

• 自社の能力を挙げる前に、顧客の目標、事業上のプレッシャー、関係する購買担当者やチーム、制約、実際のワークフローを明確にします。
• ワークフローをビジネス用語で説明します。関係者、手順、引き継ぎ、ボトルネック、ツール、KPI、そして望ましい状態を含めます。
• ユースケースを1～3件に絞ります。それぞれについて、ワークフロー上の課題、今それが重要な理由、関心を持つ人物、裏付けとなる証拠、未検証の事項を説明します。
• 各ユースケースを、該当する価値分類のうち最も少ない数に対応付けます：Enhanced Productivity、Cost Reduction、Risk Reduction、Revenue Acceleration、Time to Market。
• 因果関係を明示します：ワークフローの変化 -> 業務上の効果 -> ビジネス成果 -> 指標。

4. 証拠で裏付けられる範囲でのみ定量化する

• 重要な主張と入力値に Known、Inferred、Assumed、Missing のラベルを付けます。
• 情報源が食い違う場合は、次の優先順位に従います：顧客提供の指標、製品テレメトリーまたは利用データ、ディスカバリーまたは文字起こしの情報、~~CRM、~~Knowledge & Files、社内のアカウントメモ、一次公開資料、類似事例または参考ベンチマーク。
• 財務部門で利用できる事例にするには、数式、入力値、出典／ラベル、低位／基本／高位のシナリオ、注意事項、確度を示します。数式の例：
  • 生産性：users x tasks per period x time saved per task x labor cost x adoption rate
  • コスト：current cost baseline - future cost baseline
  • リスク：incidents avoided x average cost per incident x confidence factor
  • 売上：impacted revenue pool x improvement rate x confidence factor
  • 市場投入までの時間：cycle-time reduction x value of earlier release or deployment
• 必要な入力値が不足している場合は、計算の構造を示すにとどめます。数式を示し、不足している入力値に印を付け、方向性として言えることを述べ、財務部門で利用できる形にするために必要最小限の質問を列挙します。

5. 意思決定に役立つ資料を作成する

• 業務への影響を顧客のビジネス成果に結び付けてから、自社のソリューションがこのワークフローと購買担当者のニーズに適合する理由を説明します。
• 公開情報に基づく戦略的な背景と、アカウント固有の根拠を分けて示します。類似事例は仮説を補強する材料として使い、この顧客に関する証拠として扱わないでください。
• 重要な主張には、利用可能な場合は役立つクリック可能なリンクを付けます。安定したリンクがない場合に限り、出典名をテキストで記載します。

次のステップの選択肢

最初の出力の後、以下の選択肢から最も関連性の高いフォローアップを提示してください。メニュー形式ではなく、明確な次のステップを1つ提示してください。別の選択肢のほうが有用だと確信できる場合を除き、以下のみを提案してください。

• ユーザーのガイダンスを反映して内容を改善する、または重要な検証上の不足を最小限に補う。
• 確認用に、顧客向けのエグゼクティブサマリーまたは価値を伝える説明を作成する。
• 確認用に、推進者向けのトークトラックまたは社内のアカウントチーム向けメモを作成する。
• 価値モデルの表またはスプレッドシートに取り込めるモデル構成を作成する。
• 内容の確認後、簡潔な会議前資料または意思決定文書にまとめる。

避けるべき次のステップ：

• ユーザーが内容を確認し、明示的に依頼する前に、保存、共有、投稿、文書の作成、システムの更新を行うこと。

モード

• Default Package — 以下の完全なビジネスケース。
• Structural Case — 顧客とワークフローは明確だが、信頼できる定量的な入力情報が不足している場合に使用します。
• Finance-Ready Case — 情報源に基づく入力値が数式と低位／基準／高位のシナリオを裏付ける場合に使用します。
• Focused Output — ユーザーがエグゼクティブサマリー、ROI表、顧客向け説明、差別化要因、検証の質問のみを求めている場合に使用します。簡潔なエビデンスの状況と不足情報を含めてください。

出力形式

デフォルトパッケージでは、以下の構成を使用してください。

# Business Case: [Customer / Initiative]

## Executive Summary
[Customer objective, why now, priority workflow/use cases, likely value story, seller fit, and confidence.]

## Strategic Initiatives
- [Known/Inferred/Assumed/Missing: initiative + source]

## Key Challenges
- [Customer or workflow challenge + evidence label/source]

## Priority Workflows
- **[Workflow]:** [Actors, bottleneck, KPI, and why it matters]

## Priority Use Cases
1. **[Use case]** — [Problem, buyer/team, why now, evidence, validation gap]

## Value Hypothesis by Use Case
| Use Case | Value Bucket | Causal Chain | Evidence Posture | Confidence |
| --- | --- | --- | --- | --- |
| [Use case] | [Exact bucket] | [Change -> effect -> outcome -> metric] | [Known/Inferred/Assumed/Missing] | [High/Medium/Low] |

## Metrics and Assumptions
| Metric / Input | Value | Label | Source | Why It Matters |
| --- | --- | --- | --- | --- |
| [Input] | [Value or Missing] | [Known/Inferred/Assumed/Missing] | [Link/label] | [Formula role] |

## ROI or Value View
| Use Case | Formula | Low | Base | High | Caveats |
| --- | --- | --- | --- | --- | --- |
| [Use case] | [Formula] | [Value/Structural] | [Value/Structural] | [Value/Structural] | [Gap/confidence] |

## Solution Differentiators
- [Differentiator tied to workflow, buyer need, and expected business effect]

## Proof Points or Analogous Wins
- **Account-native proof:** [Evidence or Missing]
- **Analogous / public support:** [Evidence, clearly not customer proof]

## Caveats and Open Questions
- [Most important validation gap and smallest next collection step]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

ルール

• 顧客の数値、購入担当者、ワークフローの責任者、ツール、承認、取引条件、ROI、情報源へのリンクを捏造しないでください。
• 公開されている戦略的な表現、ベンチマーク、類似事例の成果を、顧客が確認した効果として扱わないでください。
• 洗練された文章でデータ不足を覆い隠さないでください。ケースが構造的なものか、財務検討に使えるものか、その理由とともに明記してください。
• 意思決定の説明に必要なユースケースと価値の分類は、1～3件に絞ってください。
• このワークフローは読み取り専用です。後のステップでユーザーが明示的に依頼しない限り、投稿、送信、共有、文書の作成、CRMの更新を行わないでください。

エラー処理

信頼できる顧客またはワークフローの根拠がない場合は、障害となっている点を示し、最小限必要な情報を尋ねてください。任意の情報経路を利用できない場合は、最も確かな根拠を使って続行し、そこから生じる確信度の限界を明らかにしてください。