CCF（Concept Company Fit / 自社適合検証）

前章でコンセプトを固め、最初の検証ステージに入ります。
手元にあるコンセプトは魅力的で、自分でもこれならいけると手応えを感じているはずです。しかし、いざ事業案を社内で報告すると、上層から「良い案だと思う。でも、なぜうちがこれをやるの？」「これで本当に勝てるの？」と問われて言葉に詰まってしまうことは、よく起こります。

どんなに画期的なコンセプトでも、自社で取り組む必然性がなければ、会社のリソースは割けません。事業開発はコンテストではないからです。

本章では、この問いに答えるための準備として、CCF（自社適合検証）のステージを扱います。

ここでの約束は、仮説の正しさは問わないことです。
「この市場規模は本当に100億円あるのか」「顧客は本当にこの金額を払うのか」といった確度をここで議論し始めると、机上の空論が続いてしまいます。正解は外に出て検証しなければ分かりません。本章では代わりに、何をどこまで言語化しておけば、次の検証へ出られるかを示します。

なお、ここはコンセプトを一から作り直す場ではありません。仮説を組み立てる中で「そもそも誰のどんな課題を解くのか」が揺らいでしまったときは、このステージで立ち止まらず、前章の事業開発の始め方（テーマ設定・アイデア創出・コンセプト化）に戻ってください。

このステージの問いとゴール

CCF の問いは、「自社がこのコンセプトを今実行する意義があるか？」です。
アイデアの良し悪しではなく、あえて自社が、今取り組む意味があるかを問います。

このステージのゴールは、コンセプトを土台に、ターゲット顧客・競合・稼ぎ方と「自社が今やる意義」の仮説が、顧客に聞きに行けるだけ具体的に固まっている状態です。

なぜ、自社が今やる意味を最初に問うのでしょうか。
それは、自社がやる必然性のないアイデアは、あとで必ず「なぜうちがやるのか」と問い直されて立ち往生するからです。この問いに答える過程で、仮説も必然的に具体化されます。

では、なぜ正しさではなく具体性を求めるのでしょうか。
もし「なんとなくニーズがありそうだから」と具体性のないまま顧客へインタビューに向かえば、相手は気を遣って「面白そうですね」と言ってくれるかもしれません。しかし、それは事業の期待値と不確実性を更新しません。本当に困っているのかという核心には届かないまま、時間だけが過ぎてしまいます。

この仮説は、顧客の時間を奪ってまで聞きに行くに足る具体性を持っているか？

正解は、あとで顧客が教えてくれます。今は正しさを証明するより、検証の俎上に載せられるだけの具体性が求められます。
たとえば「新しいコミュニケーションツール」という漠然としたアイデアでは、誰に何を聞けばいいのか定まりません。「リモートワークで新人の不調に気づけないマネージャー向けの、兆候検知ツール」と具体化して初めて、聞くべき相手と質問が決まります。

ゴールを状態で定め、達成条件を先に決めるというすべての根本となるスキルの手順が、ここからそのまま適用されます。ここで解像度を上げておくことが、次以降の検証スピードを引き上げます。

成立条件と達成条件

CCFの論点（成立条件）は、「コンセプト由来」と「自社適合」の2つの群に分かれます。
前半の群で「誰の・何を」を具体化し、後半の群で「なぜ自社が・なぜ今」を言語化します。

以下は、このステージを通過するための成立条件と、何が言えれば十分かを示す達成条件です。

これらの条件を一つずつ埋めると、曖昧だったアイデアが検証可能な仮説へと変わります。各論点に答えを出す中で、自身の思い込みを排除し、独自の提供価値を浮き彫りにします。

特に「ペルソナ」と「ジョブ」の論点では、解像度の高さが求められます。
「30代の働く女性」や「ITリテラシーの高い若手」といった漠然とした属性では、誰の連絡先を調べればいいのか分かりません。これを、その人が何を負っていて何を求めているかで定義します。

toB なら「部門のIT予算管理を任されており、毎月の稟議処理に追われている担当者」のように、責任が軸になります。
toC でも責任（家計を預かっている、親の介護を担っている）はありますが、それ以上に欲求（時間を取り戻したい、人に見せたい）が軸になることが多いでしょう。
責任や欲求が明確になれば、その人が何を達成したいのか（ジョブ）、何が障害になっているのかが見えてきます。

UVP（独自の提供価値）の仮説とは、単なる機能の羅列ではありません。顧客がその解決策を生活や業務の中に「雇う」理由です。競合の製品ではなく、自社の製品でなければならない理由が明確でなければ、いずれ価格競争に巻き込まれます。

また、toB の事業であれば、企業ペルソナと関連役職ペルソナをセットで定義します。
toC やマッチングモデルであっても、実際にサービスを使う本人だけでなく、購入の意思決定者、許可する人、影響を受ける人など、すべての関係者を洗いざらい考えます。
これらは前章のコンセプト化で関係者を洗い出したときに、ある程度固まっているはずです。そこで書いたものを持ってきて、聞きに行ける精度まで具体化すれば足ります。

条件を洗い出すときは、反事実思考による検査が有効です。
「この条件が欠けていても、顧客は本当に今のやり方を変えるだろうか？」と問えば、過剰な機能や不要なムダを事前に削ぎ落とせます。

Why us と Why now を分けて答える

自社適合の群にある「なぜ自分たちがやるのか（Why us）」と「なぜ今やるのか（Why now）」は、プレゼンテーションなどでは一つの項目にまとめられがちです。
私たちは、これらを明確に分けるべきだと考えています。

なぜなら、この二つの答えの出どころは全く違うからです。
「Why us」は、自社の内側にあるものが根拠になります。ミッションや理念、培ってきた組織能力、そして資産です。圧倒的な顧客基盤がある、独自の特許技術を持っている、長年培ってきた業界の信頼がある、といった自社特有の強みです。

対して「Why now」は、外部環境の変化が根拠になります。
新しい法規制が施行される、画期的な技術が普及し始めた、顧客の購買行動が大きく変わったなど、自分たちではコントロールできない市場の波です。

これらを一つにまとめてしまうとどうなるでしょうか。
ある報告会で、担当チームが「我が社にはこれだけの技術力と販売網がある」と自社の強み（Why us）を熱弁し、経営陣もそれに納得して承認を出したとします。
しかし、参入タイミング（Why now）の視点が抜け落ちていたため、リリースしてみるとすでに競合他社がシェアを固め終わっていたという事態が起こります。これは自社の都合だけで事業を作ろうとした失敗です。

それぞれ独立した粒度で答えるために、次のように反対から問うとスムーズです。

自分たちでなくても成立するか？

他社が同じ事業計画を描いたとき、自社でなければならない決定的な差が生まれるでしょうか。もし「資金力があればどこでもできる」「同じ機能を作られれば負ける」なら、それは自社でやる理由になっていません。

3年前ではなぜ駄目で、3年後では何が遅いか？

「なぜ今か」に答えるには、この両側の期間への視点が必要です。
3年前には技術的な制約や市場の未成熟があって不可能だった。しかし、3年後まで待ってしまうと先行者に市場を取られ、参入の窓が閉じてしまう。この両方に答えられないなら、今急いで案件リソースを割く理由はまだありません。

撤退基準はここで宣言する

成立条件の最後にある「許容できるリスク」の論点は、どこまでのリソース投下と、どのシナリオの消滅までなら許容するかを、企画段階で言語化しておくためのものです。

事業開発の現場では、撤退は失敗としてネガティブに捉えられがちです。しかし、撤退基準を持たずに進むことは、ブレーキのない車で走り出すようなものです。
探索を進めるうちに、かけた時間や予算、チームの愛着が積み上がっていくと、人間の判断は必ず歪みます。「あと1ヶ月だけ検証させてほしい」という楽観的な見通しがあがり、冷静な期待値の比較ができなくなります。

基準がないまま進むと、止める理由を誰も言い出せず、投資回収の見込みが薄いまま活動だけが続きます。これがゾンビ化とは何かで触れた、案件がリソースをロックし続けるという一番の痛手です。

検証を始める前の、不確実性が最も高く感情移入も少ないこのタイミングで、撤退基準を宣言しておく必要があります。

どんな事実が観測されたら、この仮説を潔く手放せるか？

収支シナリオをざっくりと試算しておくのも、この判断ラインを引くためです。
ここでの試算は、銀行から融資を引き出すような精密な事業計画ではありません。想定する工数、単価、市場規模を掛け合わせ、そもそも自社が取り組むに足る事業規模になるのか当たりをつけます。
もし、楽観シナリオでさえ自社の基準とする事業規模に届かないのであれば、その時点で撤退を判断できます。

出口の判断は、ここで宣言済みの撤退基準と、今後の検証での実測を突き合わせて行います。基準を先に立てれば、自分たちの感情から事業を守る防波堤になります。

次の検証への橋

仮説が固まったら、次の CPF（課題検証）へ向けて検証の準備をします。
ここで扱うのは「論点ツリー」と「インタビューの質問設計」です。

論点ツリーは、「この事業の最大の不確実性は何か？」を起点に展開します。
最大の不確実性が、顧客が本当に課題を感じているかにあるのか、それとも代替手段から乗り換える動機があるかにあるのかは、案件によって大きく異なります。
それらをツリー状に整理し、不確実性ランキング上位5つの論点を言語化します。これは、外れたら計画全体が崩れる最大の不確実性から順に潰すという三原則の実装です（事業開発の進め方）。

次に、それらの論点を検証するためのインタビュー質問を設計します。
ここで、質問の構成が自分の仮説を肯定するものになっていないか注意します。

その質問は、自分が聞きたい答えに誘導していないか？

「こういう機能があれば便利だと思いませんか？」といった質問は、相手から「はい」を引き出すだけの誘導であり、何の検証にもなりません。
「過去半年間で、その課題を解決するためにいくら使いましたか？」のように、過去の事実と行動を問う質問へと変換します。

バイアスを避け、本音を引き出す質問を組み上げたら、チームメンバーやAIを相手にした模擬インタビューを実施します。
模擬インタビューでは、チームメンバーに意地悪な顧客を演じてもらいます。「今の業務フローで特に困っていない」「新しいシステムを入れる方が面倒だ」といった手厳しい反論に対して、仮説がどう機能するかをシミュレーションします。
模擬の段階で自らの仮説を揺さぶり、質問の意図が正しく伝わるかを確認できれば準備は完了です。この論点ツリーと質問ガイドを、次のステージへ引き継ぎます。

通過の目安と出口

このステージの通過は、審査会で承認のハンコをもらうことではなく、次の CPF に進んで、実際に会ってくれる顧客の時間を無駄にしない状態を作ることです。
具体的には、以下の目安を満たしているかを確認します。

• ペルソナが責任ベースで説明でき、関係者どうしの関係が描ける
• 責任からジョブ、障害、解決策への連鎖が説明できる
• Why us が自社の資産や立場で説明でき、他社が同じ絵を描いても差がつく理由が言える
• Why now が外部変化で説明でき、遅れた場合の損失が言える
• 市場の全体像と主要プレイヤーが構造的に説明できる
• 不確実性ランキング上位5つの論点が言語化され、質問が論点に紐づいている

また、このステージで終わる案件の典型的な理由は、「自社適合しない」「市場が小さすぎる」「先行プレイヤーが強すぎる」のいずれかです。
ここでお蔵入りにする判断は、本格的な投資が始まり、多くの人を巻き込んでしまう前の、最も安い撤退です。

事業を生み出す方程式で言えば、案件リソースを早々に解放し、次の探索へと回すことができたことになります。無駄な開発費を使わず、貴重なチームの時間を温存できるため、この段階で退くことは立派な前進です。

よくある落とし穴

最後に、CCF で陥りやすい落とし穴を挙げておきます。

MVPの計画やインタビュー依頼の先取り
プロダクトの検証計画は、後のステージである SPF（プロダクト検証）で立てます。また、インタビューを顧客に依頼するのも次の CPF の仕事です。
顧客の課題が実在するかも分からないうちに、解決策のプロトタイプを作り始めると、後戻りの修正コストが高くつきます。焦って行動を急ぐよりも、ステージごとの役割を混ぜないことが、結果的に事業化への最短ルートになります。

Why us と Why now を畳む
先述の通り、自社の強みの説明は社内で歓迎されやすいため、市場のタイミングの欠落が見過ごされがちです。スライドの構成上まとめやすかったとしても、必ず欄を分けてください。答えられないなら、空欄を空欄として見えるようにしておくことが誠実な計画です。

企画書の体裁を整えることが目的化する
机上でどれだけ美しいスライド資料を仕上げても、仮説の確からしさは顧客に会うまで上がりません。きれいな図解作りにこだわるのではなく、Quick & Dirty の精神で、論点の網羅と優先順位づけに時間を使ってください。

コンセプトを作り直し始める
議論が行き詰まると、コンセプトそのものを白紙から考え直したくなります。「ターゲットを変えよう」「提供価値を変えよう」と何度もいじり始めると、いつまで経っても検証に出られません。
ここは仮説を具体化する場です。根本のコンセプトが崩れているなら、無理に取り繕うのではなく、セットアップの工程へ正式に差し戻すべきです。

準備が整ったら、次章のCPF（Customer Problem Fit / 課題検証）に進みます。いよいよ、設計したインタビューを実際に顧客へ持ち込みます。