feasibility-assessor

実現可能性評価者

ビジネスアイデアや機能を、財務的な実現可能性と技術的な実現可能性の両面から評価します。実行可能なリスク低減策を含む、統合的な結論を提示します。

フェーズ 1：入力の分類

入力の種類を判断します。

• アイデアの提案：コンセプトの非公式な説明
• 機能仕様：製品への追加に関する明確な要件
• リポジトリ／コードベース：拡張または方向転換の評価対象となる既存コード
• 事業計画：財務情報を含む構成済みの文書

入力から以下を抽出します。

1. 価値提案（どのような問題を誰のために解決するか）
2. 対象顧客セグメント
3. 価格設定の意図または収益モデル
4. 技術スタック（明記されているもの、または推定されるもの）
5. 競争環境に関する認識

重要な情報が不足している場合は、先に的を絞った確認質問をします。最低限必要な情報は、価値提案と対象顧客です。

フェーズ 2：財務分析

参照：references/unit-economics.md、references/financial-viability.md

依頼が純粋に技術的な場合（例：「Y のスタックで X を構築できますか」）に限り、このフェーズを省略します。

ユニットエコノミクス

1. **顧客獲得コスト（CAC）**を算出します。マーケティング費用、営業コスト、獲得顧客ごとの間接費配賦を含めた全コストを対象とします。
2. **顧客生涯価値（LTV）**を算出します。ARPU に平均顧客継続期間を乗じ、粗利益率で調整します。
3. LTV：CAC 比率を算出します。実現可能な最低水準は 3：1 です。
4. 販売単位またはサービス提供顧客ごとの限界利益を算出します。
5. 回収期間を算出します。顧客からの累積粗利益が CAC を上回るまでの月数です。

すべての仮定を明示します。小さな変化で結果が変わる可能性のある、感度の高い仮定にフラグを付けます。

収益モデル

1. すべての収益源を特定し、それぞれの規模を見積もります。
2. 価格設定戦略との適合性を評価します：コストプラス、価値ベース、競争力重視、フリーミアムから有料への移行。
3. コンバージョン率の仮定を適用します。参照資料にある業界ベンチマークを使用します。
4. 解約と継続率をモデル化します。可能であれば、コホートの減衰曲線を適用します。

損益分岐点分析

1. 固定費（家賃、給与、インフラの基本費用）と変動費（売上原価、取引手数料、ユーザーごとのサポート費用）を分けます。
2. 損益分岐点を販売単位、顧客数、または売上高で算出します。
3. 次の 3 つのシナリオをモデル化します。
   • 悲観的：コンバージョン率は中央値、高い解約率、低成長
   • 基本：業界平均の仮定
   • 楽観的：上位四分位のパフォーマンス

収益化までの道筋

1. 12～24 か月にわたる粗利益率の推移を予測します。
2. 営業費用の拡大をモデル化します（線形、段階的、または規模の経済）。
3. 現在のバーンレートに基づいて、必要な資金とランウェイを見積もります。
4. 収益化までの期間について、業界ベンチマークと比較します。

フェーズ 3：技術分析

参照：references/technical-risk.md

依頼が純粋に財務的な場合（例：「月額 29 ドルの SaaS でユニットエコノミクスは成り立ちますか」）に限り、このフェーズを省略します。

アーキテクチャ評価

複雑さを分類します。

レベル	説明	例
1 — シンプル	標準的な CRUD、単一サービス	ランディングページ、基本的な CMS、フォームベースのアプリ
2 — 中程度	複数サービスの統合、認証、決済	E コマース、SaaS ダッシュボード、API プラットフォーム
3 — 複雑	分散システム、リアルタイム、高可用性	マーケットプレイス、ストリーミングプラットフォーム、フィンテック
4 — 未開拓	研究開発が必要、スケール時の実績がない	ML を活用した製品、新しいプロトコル、ハードウェア＋ソフトウェア

以下を評価します。

• 技術スタックの成熟度とエコシステムのサポート
• インフラ要件とコストの拡大曲線
• サードパーティ依存関係の数と重要度

開発見積もり

1. MVP の範囲を定義します — 中核となる価値提案を検証するための最小限の機能セットです
2. 開発スケジュールを見積もります：
   • 楽観的：経験豊富なチーム、熟知した技術スタック、未知の要素が最小限
   • 現実的：標準的なチーム、ある程度の学習期間、通常の障害
   • 悲観的：新しい領域、統合上の課題、規制対応の負担
3. 必要なチームのスキルと稼働状況を特定します
4. 主要なコンポーネントごとに、内製・購入・提携の分析を行います

リスク評価

各項目を1〜5で評価します（1＝リスク低、5＝重大なリスク）：

項目	測定内容
技術の新規性	実績のある技術（1）対、積極的な研究開発が必要（5）
統合の複雑さ	単独で完結（1）対、多数の外部 API を利用（5）
スケールへの対応力	設定変更で100倍の規模に対応（1）対、アーキテクチャの再設計が必要（5）
データリスク	公開データ／自社所有データ、規制なし（1）対、制限対象データ、厳格なコンプライアンス（5）
セキュリティ／コンプライアンス	機密データなし（1）対、PCI/HIPAA/SOC2 への対応が必要（5）

技術リスクの総合評価 ＝ 加重平均です。4以上の評価がある項目は、軽減策が必要な阻害要因としてフラグを付けます。

フェーズ4：統合実現可能性スコア

財務的な実行可能性

• 実行可能：LTV:CAC > 3:1、回収期間 < 18か月、ユニットエコノミクスがプラスになる明確な道筋がある
• リスクあり：LTV:CAC 1.5-3:1、回収期間 18-36か月、ユニットエコノミクスが規模に左右される
• 実行不可能：LTV:CAC < 1.5:1、回収期間 > 36か月、貢献利益率がマイナス

技術的な実現可能性

• 容易：複雑さのレベルが1〜2で、すべてのリスク項目が3未満
• 困難：複雑さのレベルが2〜3で、3〜4の項目が1つまたは2つ
• 高リスク：複雑さのレベルが3〜4で、4以上の項目が複数
• 研究レベル：複雑さのレベルが4で、いずれかの項目が5

総合判定

財務面	技術面	判定
実行可能	容易	Green — 進めます
実行可能	困難	Yellow — 注意して進め、技術リスクを軽減します
リスクあり	容易	Yellow — まず財務上の前提を検証します
リスクあり	困難	Yellow — 不確実性が高いため、低コストの実験を行います
実行不可能	いずれでも	Red — 根本的な前提を見直します
いずれでも	高リスク／研究レベル	Red — コミットする前に技術上の未知要素を減らします

前提の感度

判定に最も影響する上位3〜5個の前提を特定します。それぞれについて、以下を記載します：

• 現在想定している値
• 評価が逆転するしきい値
• 低コストで検証する方法

リスク軽減の推奨事項

実行コストと情報価値に基づいて実験の優先順位を付けます。最もリスクの高い前提を最低コストで検証できる実験を優先します。

フェーズ5：レポートの作成

出力は次の構成にします：

エグゼクティブサマリー

• Go／No-Go のシグナルを含む、判定を1段落で記載
• 上位3つのリスクと上位3つの強み

財務ダッシュボード（該当する場合）

• ユニットエコノミクス表：CAC、LTV、LTV:CAC、貢献利益率、回収期間
• 3つのシナリオでの収益予測（表または説明）
• 損益分岐点とその時期

技術評価表（該当する場合）

• 複雑さの分類
• リスク項目の評価（表）
• MVP の範囲とスケジュールの見積もり
• 重要な依存関係と軽減策

感度分析

• 誤っていた場合に判定が逆転する前提
• 各重要な前提のしきい値

推奨される次のステップ

• 検証コストの低いものから順に、実施するアクションを列挙します
• 各ステップの担当者または必要なスキルを明確にします
• 判断基準を示します。どのような根拠があれば続行、方向転換、中止するのかを明確にします