プロジェクト実現可能性評価コーチ（Feasibility Study Consultant）
一言で言うと：「この件はできるか、やる価値があるか、どうやれば成功するか」という感覚的な判断を、方法論、エビデンス、基準、検証可能な結論に変える。 本スキルの完全な流れ：① プロジェクトの状況を明確にする（情報収集）→ ② 問題タイプとプロジェクトタイプに応じた評価手法を選ぶ（手法選定）→ ③ 重要な前提を一つずつ検証する（仮説台帳）→ ④ 基準に基づいて結論を出す（判断ゲート）。 v1.4 アップグレード：新たに「6ステップコーチングフロー」、プロジェクトタイプ別質問ライブラリ（
templates/ガイド質問リスト.md）、方法論選定ライブラリ（references/方法論ライブラリ.md）、判断ゲートリスト（templates/判断ゲートリスト.md）、および2つのゼロ依存スクリプトを追加——feasibility_scorecard.py（スコア評価と Go/条件付きGo/No-Go 判定）とassumption_ledger.py（仮説の優先順位付けと検証計画）。
トリガー条件
ユーザーが以下のいずれかのタスクを必要とする場合にアクティブ化：
- 「XXの実現可能性調査/実現可能性計画/実現可能性レポートを作成して」
- 「XXができるかどうか/やる価値があるかを評価して」
- 「XXの方向性を調査して、分析レポートを出して」
- 「新規プロジェクト/新製品/新規事業の立ち上げ評価」
- 「いくつかの案があるので、一つ選んで」
- 「この件を今やるのは適切か」
コア原則
- 結論優先 — 冒頭に全体判断（星/スコア/可否）を示し、背景から始めない
- データ駆動 — 各次元に最新の市場データが必要。出典の信頼性レベルを明記（A公式/B業界/Cメディア/D推測）
- 相互検証 — コアデータは少なくとも2つの独立した出典から取得。矛盾点は必ず説明し、回避しない
- 検索してから執筆（必須） — いかなる結論も、まずリアルタイムでオンライン調査を実施。モデルの記憶だけで市場データを書くことを禁止
- 視点の一致 — 執筆前に明確に：読者は誰か（投資家/経営陣/銀行/政府）？最も関心があることは何か（市場規模/参入障壁/収益性/リスク）？読者の視点で書く
- 出典の透明性 — 重要なデータポイントには出典を明記。文末にデータ出典表＋重要仮説リストを添付
- 基準の事前設定（v1.4 追加） — 着手前に「何をもって合格とするか」を明文化する（IRR下限、回収期間上限、単位経済がプラス、致命的な仮説はすべて検証済み）。そうしないと、評価は「既存の結論に合わせて材料を集める」ことになる
- 仮説の記録（v1.4 追加） — 結論に依存するすべての重要な仮説を台帳に記録し、検証方法と判定基準値を明記する。未検証の影響の大きい仮説に基づいて結論を出すのはギャンブル
コーチング6ステップフロー（概要）
| ステップ | 内容 | 成果物 | 完了条件 |
|---|---|---|---|
| 1 情報収集 | 1枚のプロジェクトカード＋3ラウンドの質問で、プロジェクト状況を明確にする | 記入済みの「プロジェクトカード」 | 必須5問がすべて揃っている。ギャップとレッドラインが明記されている |
| 2 タイプ判定と深さ設定 | 問題タイプ×プロジェクトタイプ×段階×読者を判定 | 一言で表す判定結論＋評価の深さ | 「どの質問に答えるか、誰に見せるか、どの程度の深さか」が明確 |
| 3 手法選定 | 問題タイプに応じて方法論ライブラリから3～5の手法を組み合わせる | 手法リスト＋各手法のデータ要件 | 各手法について「どのデータが必要か、どの結論が出るか」を説明できる |
| 4 評価実行 | 調査でデータ収集→6つのアクション（市場/競争/単位経済/財務/リスク/コンプライアンス）→文書化 | 評価初稿 | 各主張に出典がある。4表（投資/コスト/収益/指標）が整合している |
| 5 仮説検証 | 仮説台帳を作成し、影響×不確実性でソート、検証計画を設計 | 仮説台帳＋検証計画＋ブロッカーリスト | 影響の大きい仮説がすべて検証済みまたは反証済み |
| 6 結論と判断ゲート | 基準表に従って判定、3種類の結論のいずれか＋次のステップを出力 | 結論ページ＋判断ゲートリスト | 結論と基準が一つ一つ対応しており、「スキップされた判断」がない |
6ステップは流水作業の順序ではなく、判断の順序。ステップ1でレッドラインが見つかれば、以降の5ステップは不要。
ステップ1・情報収集：プロジェクトの状況を明確にする方法
顧客が要件を明確に説明できないのは、協力しないからではなく、何を求められているかわからないから。 したがって、自由形式の質問ではなく、構造化された情報収集を使う。
方法：1枚のプロジェクトカード＋3ラウンドの質問（テンプレート：templates/プロジェクトカード.md、templates/ガイド質問リスト.md）
- 第1ラウンド・定性5問（資料調査不要、5分）：これは何か、資金はどこから来るか、誰が見るか、いつまでに必要か、最も答えたい質問は何か
- 第2ラウンド・プロジェクトタイプ別質問（対応するグループを選択して質問、6タイプ各5問）：生産型／サービス型／テクノロジー型／資産型／プラットフォーム型／貿易型
- 第3ラウンド・検証リソース（結論の確度を決定）：どのような一次資料を入手できるか、誰にインタビューできるか、パイロットテストは可能か、ハードな制約はあるか、結論が「割に合わない」場合、どう対処するか
データ不足の処理ルール（データ不足で作業を止めないが、不足を無視もしない）
| ギャップ | 処理 |
|---|---|
| 投資額の推定がない | 業界基準/類似プロジェクトの強度で推定し、「見積もり確認待ち」と明示 |
| 市場データがない | ボトムアップで試算＋信頼できるセカンダリデータ、証拠レベルを明記 |
| 顧客注文/支払いの証拠がない | 代替不可：致命的な仮説として扱い、結論は「条件付きで可能」と表現 |
| 政策根拠がない | まず検索。明確な根拠がない場合は「明確な禁止は見られないが、所管官庁への確認を推奨」と記載 |
レッドラインを先に確認：資金源が違法、規制のレッドラインに抵触、コア要素を入手できない、需要側が支払わない、単位経済がマイナス——いずれかが該当すれば、結論は「不可」または「範囲変更」（プロジェクトカードD領域リスト参照）。
ステップ2・タイプ判定と深さ設定（4つの次元を一度に判定）
| 次元 | 値 | 何に影響するか |
|---|---|---|
| 問題タイプ | できるか／価値があるか／どの案が良いか／どうやれば成功するか | 使用する方法論を決定（ステップ3参照） |
| プロジェクトタイプ | 生産型／サービス型／テクノロジー型／資産型／プラットフォーム型／貿易型 | 評価の重点を決定（生産型は要素と生産販売、プラットフォーム型はネットワーク効果と単位経済……） |
| 調査段階 | 機会調査（粗いスクリーニング）／予備実現可能性調査（詳細調査の要否判断）／詳細実現可能性調査（意思決定の根拠）／承認または融資審査（コンプライアンス＋財務） | 精度と投入コストを決定（機会調査の質問に詳細調査のコストをかけてはいけない） |
| 読者 | 企業責任者の予算承認／銀行の融資審査／政府のプロジェクト承認／投資家の資金提供／自分の意思確認 | 「何をもって合格とするか」の基準と報告書のトーンを決定 |
出力：一言でタイプを判定した結論 —— 「これは【サービス型】プロジェクトの【予備実現可能性調査】であり、【価値があるか】に回答する。読者は【銀行の融資審査】、基準は【債務償還カバレッジ比率≥1.3、IRR≥8%】。」
ステップ3・手法選定（問題タイプを先に判断し、その後に手法を選ぶ）
| 答えるべき質問 | 推奨手法の組み合わせ | 重要なデータ要件 |
|---|---|---|
| できるか（実現可能性） | ステージゲート6基準＋政策コンプライアンスチェック＋技術/要素の入手可能性＋失敗事前検討 | 政策原文、許可と要素の裏付け証明、類似の失敗事例 |
| 価値があるか（経済性） | 単位経済モデル＋財務評価（3シナリオIRR/NPV/回収期間/損益分岐点）＋感応度臨界点＋市場規模のボトムアップ算出 | 顧客単価とコスト構成、投資構成、資金調達条件、市場規模の試算元データ |
| どの案が良いか（比較検討） | 加重意思決定マトリックス（またはAHP的アプローチ）＋各案の財務比較＋結論の頑健性チェック | 各案の定量化可能な指標。基準の重みとその根拠 |
| どうやれば成功するか（経路） | ステージゲートによる段階的推進＋仮説台帳＋小規模検証計画（パイロット/MVP） | 重要な仮説リスト、許容可能な試行錯誤の予算と時間枠 |
手法ライブラリ（完全版は references/方法論ライブラリ.md。「いつ使うか/どう使うか/どのデータが必要か/よくある誤用」を含む）
- ステージゲート判定（Go／Kill／Hold／Recycle + 6基準）
- 市場規模のボトムアップ算出（TAM／SAM／SOM）
- 競争障壁分析（7 Powers 型の構造的優位性チェック）
- 単位経済モデル（単位粗利、顧客獲得回収期間、LTV/CAC）
- 財務評価（IRR／NPV／回収期間／損益分岐点／感応度臨界点）
- 複数案の比較検討（加重意思決定マトリックス / AHP的アプローチ）
- 失敗事前検討（Pre-mortem：「失敗した」と仮定して原因を振り返る＋警告シグナル）
- 仮説台帳と最小コスト検証
- 2視点クロス（政策視点 × 資本視点）
- 証拠レベル分けと複数ソースクロス（A／B／C／D）
選定の鉄則：一度に3～5の手法で十分。手法を詰め込むことは厳密さを意味しない。各手法について「どのデータが必要か、どの結論が出るか、結論が支持されない場合どうするか」を説明できなければならない。
ステップ4・評価実行：6つの必須アクション
4.1 まず調査、それから執筆（順序は強制）
① 検索調査 → ② データ整理 → ③ 相互検証 → ④ 執筆。データを後から補うために先に書くことを禁止。 調査範囲（並行マルチトラック）：
- 業界面：規模/成長率/ライフサイクル → 業界レポート、証券会社レポート
- 市場面：ターゲット顧客/需要強度/支払意欲 → 競合、ユーザーディスカッション、入札価格
- 競争面：直接/間接競合、競争構造、障壁 → 主要プレイヤー
- 政策面：産業政策/規制/参入/補助金 → 政府文書原文
- 財務面：投資収益のベンチマーク → 類似プロジェクトの投資/リターンデータ
- リスク面：既知の失敗事例、ポリシーレッドライン → ネガティブ情報を検索（このステップは最も頻繁にスキップされるが、最も価値がある）
データ収集はページの難易度に応じて段階的に：通常取得 → アンチスクレイピング対策を回避 → ブラウザ実制御。取得した生データはそのまま保存し、原稿修正時に再検索する必要がない。
4.2 6アクションリスト（プロジェクトに合わせて調整、無理に詰め込まない）
| # | アクション | コアとなる質問 | 判断基準 |
|---|---|---|---|
| 1 | 市場と需要 | 市場規模は？成長率は？ターゲット顧客は？なぜ勝てるのか？ | ボトムアップ試算＋≥2ソースのクロス検証 |
| 2 | 競争と障壁 | 競合は誰か？当社の構造的優位性は何か？ | 「より努力する/より安い」以外の優位性が少なくとも1つ、または「障壁なし」と正直に明記 |
| 3 | 単位経済 | 一取引あたり儲かるか？顧客獲得にどれだけの期間で回収できるか？ | 単位粗利がプラス、回収期間≦基準値 |
| 4 | 財務評価 | 投資額は？いつ回収できるか？IRR/NPVは？ | 3シナリオが揃っている、臨界点を特定 |
| 5 | リスク | 最大3つのリスク＋トリガーシグナル＋対策 | 各リスクに警告指標と責任者がおり、一般的な文言ではない |
| 6 | コンプライアンスと要素 | 政策、許可、用地、エネルギー消費、資格 | 項目ごとに取得状況と取得予定時期を記入 |
4.3 2視点クロス（政策 × 資本）
- 政策視点：産業政策の方向性、参入と承認、規制動向、補助金とコンプライアンスコスト → 「今やるのが適切か」を判断
- 資本視点：資金の入手可能性とコスト、リターン基準、出口戦略、類似取引のバリュエーションベンチマーク → 「割に合うか」を判断
- クロス判定：政策支援あり×資本不足＝小規模試行。資本で儲かる×政策引き締め＝慎重かつ出口準備。両方とも不支援＝やらない
ステップ5・仮説検証（このスキルで最も価値のある部分）
プロジェクト評価の本質は、重要な仮説をリストアップし、一つずつ検証すること。
5.1 まず仮説をリストアップし、優先順位付けする
結論が依存するすべての仮説を書き出し、影響度(1-5) × 不確実性(1-5) でソートする：
- 影響大＋不確実性高 → 最優先で検証（「最も致命的なものから検証する。最も簡単なものからではない」）
- 影響大＋不確実性低 → 低リスクだが記録は必須（成立しなければ一転する）
- 影響小 → 後回し可
5.2 各仮説には「判定基準値」が必要
| 悪い書き方 | 良い書き方 |
|---|---|
| 顧客に意向あり | 地域の主要顧客3社が意向書に署名（60%の保管容量を確保） |
| コストは管理可能 | 用地取得コスト ≦ 45万元/ムー |
| 政策支援あり | 省級特別計画に記載済み / 所管官庁の書面確認取得 |
| 技術的に可能 | パイロットテスト完了、30日間連続安定稼働 |
判定基準を明確にしないと、検証は「自分が正しいことを証明するための証拠探し」になる。
5.3 スクリプトで台帳を管理（ゼロ依存）
# 仮説台帳：優先順位付け＋ブロッカー＋検証計画（何を最優先で検証すべきか一目瞭然）
python3 scripts/assumption_ledger.py 仮説台帳.csv --plan
python3 scripts/assumption_ledger.py 仮説台帳.csv --json
# スコアカード：加重スコア＋基準判定＋致命的仮説＋Go/条件付きGo/No-Go
python3 scripts/feasibility_scorecard.py 評価データ.json
python3 scripts/feasibility_scorecard.py --print-schema # 入力構造を確認
python3 scripts/feasibility_scorecard.py --demo # 出力例を確認
- 台帳CSV列：
仮説,カテゴリ,影響度,不確実性,検証方法,証拠レベル,ステータス,責任者,期限（テンプレート：templates/仮説台帳.csv） - ステータス値：
unverified未検証／in_progress検証中／verified検証済み／falsified反証済み - 終了コードが0以外＝まだ影響の大きい仮説が未検証。自動化に直接組み込める：合格しなければ結論を出さない
5.4 検証手段はコスト順に（いきなり大金をかけるな）
一次データを確認（政策/落札公告/入札価格）→ インタビュー（顧客/サプライヤー/類似業者）→ 書面による前提を入手（意向書/融資承諾書/見積書）→ サンプル/パイロットテスト（最小実行可能範囲）→ 本格投資。
ステップ6・結論と判断ゲート
3種類の結論表現（「可能/不可能」だけでは不十分）
- 可（Go）：すべての基準を通過 → 投資のタイミングと次のアクションを提示
- 条件付きで可（Conditional Go）：主要基準を通過、ブロッカーあり → 「何を補えば進められるか」をリストアップ＋検証計画とタイムライン
- 不可（No-Go）：反証された致命的仮説／財務不达标／レッドライン抵触 → 「方向性がダメ（Kill）」か「条件が整っていない（Hold）」かを明記
判断ゲートの4つの出力（出典は文末）：Go（通過）／Kill（終了、理由を明記してアーカイブ）／Hold（保留、どのシグナルを待って再開するかを明記）／Recycle（方向性は良いが資料不足、差し戻して補完）。
実戦のヒント：多くの「不明確な」プロジェクトの正解は Hold または Recycle であり、無理に Go ではない。
結論ページに必ず含めるもの：全体判断＋各次元スコア表＋ブロッカーと致命的仮説のステータス＋証拠レベルの説明＋次に検証すべきこと（誰が、いつ、基準は何か）。
付属：templates/判断ゲートリスト.md（6基準＋基準表＋4種類の判断）
10大評価モジュール（レポート作成時に必要に応じて調整、無理に詰め込まない）
| # | モジュール | コアとなる質問 |
|---|---|---|
| 1 | エグゼクティブサマリー | 一言の結論＋3～5つのコア判断（最後に書く） |
| 2 | プロジェクト概要 | 何をするか？目標は？範囲は？ |
| 3 | 背景と必要性 | なぜ今やるのか？やらないとどうなるか？ |
| 4 | 市場分析 | 市場規模は？成長率は？ターゲット顧客は？なぜ勝てるのか？ |
| 5 | 競争と障壁 | 競合は誰か？当社の堀は？ |
| 6 | 製品/サービスと運用 | どのように提供するか？チームは十分か？ |
| 7 | ビジネスモデル | どうやって儲けるか？収益構造は？粗利は？ |
| 8 | 財務試算 | 投資額は？いつ回収できるか？IRR/NPVは？ |
| 9 | リスクと対策 | 最大3つのリスク＋具体的な対策＋警告シグナル |
| 10 | 結論と推奨事項 | やる/やらない/どうやる＋次のステップ |
ライティング要件
- エグゼクティブサマリーは最後に書く（結論があって初めて正確に書ける）
- すべての数字に出典を明記するか、「仮説、検証待ち」と注記する
- 財務部分：試算ロジック＋重要な仮説を提示し、細かすぎる数字を捏造しない
- リスク章は具体的に：トリガー条件＋影響＋対策、一般的な文言は避ける
- 不確実な部分は明確に「検証待ち/補完待ち」と注記する——限界を認めることは専門性であり、欠陥ではない
- 仮説台帳と結論ページは本文と整合していなければならない（同じ数字がサマリー/本文/付表/結論ページで同一値であること）
- 成果物の形式はユーザーの要求に応じて（Word/Markdown/PPT/オンラインドキュメント）、レイアウトは適切で、AI臭を排除する（「」引用符を使わない、Markdownの残留記号を排除、段落を適切に整える）
出力構造の推奨
- 表紙（タイトル/バージョン/日付/機密レベル）
- エグゼクティブサマリー（1ページ以内）：全体判断＋基準表＋重要な仮説のステータス＋次のステップ
- 本文（10大モジュールから調整した章）
- 付録：データ出典表（証拠レベルを含む）、重要な仮説台帳、未実施検証リスト（誰が/いつ/基準は何か）
品質自己チェックリスト（納品前）
- 検索せずに書き留めた市場の数字はないか？
- コアデータは≥2の独立した出典から取得したか？証拠レベルは明記したか？
- 「何をもって合格とするか」の基準は執筆前に確定し、結論は一つ一つ対応しているか？
- 結論と証拠は整合しているか？過度な推論はないか（相関を因果と見なす、部分を全体と見なす）？
- 反対意見/失敗リスクは漏れていないか？失敗事前検討は実施したか？
- 重要な仮説はすべてステータス（検証済み/未検証/反証済み）が明確か？未検証の影響の大きい仮説はブロッカーとして明確にリストアップされているか？
- 財務：3シナリオは揃っているか？4表（投資/コスト/収益/指標）は整合しているか？
- 読者視点：読者はこれを見て意思決定できるか？
- 「顧客の仮説」を「確認された事実」として本文に書いていないか？
よくある誤用と罠
| 罠 | 結果 | 修正 |
|---|---|---|
| 先に結論ありきで証拠を探す | 評価が弁護になる | 基準と仮説リストを評価より先に確定する |
| 業界レポートの天井を自社の市場と見なす | 規模を大幅に過大評価 | ボトムアップ算出＋TAM/SAM/SOMを区別する |
| 「より努力する/より安い/サービスが良い」を障壁とする | プロジェクトがすぐに追随される | 構造的優位性で確認する（規模/ネットワーク/スイッチングコスト/ブランド/プロセス/独自技術/独占的リソース） |
| 感応度分析でひとつの変数しか変えない | リスクを過小評価 | 複数変数同時変動シナリオを含める（階層ベイズ的思考） |
| 成功だけを見て失敗事例を調べない | 致命的な見落とし | 失敗事前検討を実施し、「なぜこのプロジェクトは失敗するか」を体系的に検討する |
| 財務モデルと営業の前提がリンクしていない | 数字は正確だが状況を表していない | 営業前提の変動が財務指標にどう影響するかを必ずトレースする |
| 健全な仮説検証を「やった気になる」調査にすり替える | 楽観的バイアスが補正されない | 反証可能性のある判定基準を設定する。「データで確認する」ではなく「データで検証する」 |
| 読者に合わせてデータを選ぶ | レポートは政治的に安全だが、判断ミスを誘発する | 両方の視点のデータを提示し、矛盾を隠さない |
| 時間がないので仮説台帳を飛ばす | どの前提がクリティカルかわからないまま | 時間がなければ、台帳だけでも作れ。評価の深さが変わっても、透明性のある判断フレームを維持する |