事業開発の本質である検証（事業開発の進め方）を進めるには、その手前の設計が重要です。実験をデザインするにも、顧客や社内外の関係者に動いてもらうにも、「何が達成された状態を目指すのか」というゴールの明確な設計、利害管理、そこへ至るロードマップが常々必要になるからです。
本章はその設計の技術を扱います。
検証を進めるためには、解決した状態を想像しきる、要するに良い仮説を立てる、という一点に尽きます。そして「想像しきる」は才能ではなく、手順のある動作に分解できます。
ゴールを明確にする
フレームワークやツールは、必要に応じて選択する道具に過ぎません。
まず第一にやるべきことは、「そもそも何が達成された状態を目指すのか」を想像しきることです。目指す状態が決まっていなければ、何も言語化できません。ましてや、周囲を説得することさえ叶いません。
この時大事なのは、ゴールを行動や目標ではなく状態で書いていくことです。
例えば、「インタビューする」は行動で、「顧客が困っていると判断できている」は状態です。
行動で書くと、「やること」を並べてしまいがちです。インタビューをするためには、対象者を探して、質問を作って、日程を調整して・・・といったイメージです。
一方で状態で書くと、「その状態が成り立つ条件」を列挙していくことができます。
これが本書の前提の一つ、「特別なフレームワークやスキルは不要」と主張していた根本です。業界知識も分析手法もあれば速くなりますが、ゴールを想像できていないなら、たどり着きようがありません。
ゴールを成立条件に分解する
その状態を成立させるのに1つでも欠けてはならない条件はなにか？ と考えると、あれもこれもと出せると思います。
実際に一つ、書き切ってみます。題材は、前章のBチームが企画を割った成立条件のひとつ「保全部門は点検記録の紙運用に困っている」。論点「顧客は本当に困っているか？」に対する仮説です。この仮説を状態として置き、それが成立しているなら支えているはずの条件（原因仮説）に分解し、各条件に達成条件（何が観測できたら成立と言えるか）を付けます。
「保全部門は点検記録の紙運用に困っている」が成立している状態
| 成立条件（原因仮説） | 達成条件（何が観測できたら成立か） |
|---|---|
| 転記に実時間が割かれている | 担当者が、紙台帳からの転記を週次で行っていると答える |
| 業務に実害が出ている | 転記ミスや記録の欠落による手戻り・事故の実例が語られる |
| 自力で解決を試みた形跡がある | Excel化や外注など、過去の試行とその挫折理由が語られる |
| 解決に資源を割く意思がある | 困りごとを自分の言葉で語り、時期や予算の話が先方から出てくる |
「ニーズはありそう」「手応えがあった」のような曖昧な語を、観測できる事実まで落とすのが達成条件の役割です。加えて、「10人中何人で観測できたら成立とするか」という判定ラインも先に決めておきます。前章の「完了条件を、検証方法より先に決める」はこのことです。
分解したら、各条件の計画における現状（As-Is）を考えます。過去の問い合わせや商談メモで、すでに成立が言える条件は閉じられます。残っている条件が、インタビューで確かめる対象です。条件が大きすぎて動けないなら、その条件をさらに成立条件に分解します。
反事実思考で検査する
分解の品質は、反事実思考（「もし〜だったら」の世界を想像すること）で検査できます。方向は二つあります。
- 十分性の検査（モレを見つける）: 挙げた条件がすべて成立した世界を想像して、親の状態は必ず成立しているか。成立しない筋書きが描けるなら、条件が欠けています。
- 必要性の検査（ムダを見つける）: この条件が不成立のままでも、親が成立する世界はあるか。あるなら、その条件は必須ではありません。過剰な要件は着手を遅らせるだけです。
先ほどの表を検査してみます。
十分性
「4つすべて観測できたのに、まだ『困っている』とは言えない世界」は描けるでしょうか。
...描けますね。どの条件も成立しているのに、先方の課題リストではもっと大きな課題が上にあり、紙運用の解決は毎年後回しにされ続けている世界です。条件が一つ欠けていました。「解決の優先順位が上位にある（今期の取り組み候補として名前が挙がっている）」を表に追加します。インタビューは盛り上がったのに商談が一向に進まない、という事故はこのモレから生まれがちです。
必要性
逆に「すべてが成立していなくても、困っていると言える世界」は描けるでしょうか。
...これも描けます。「自力で解決を試みた形跡」は、諦めていて試行すらしていない顧客もいるため、必須の条件ではありません。観測できれば強い傍証、という扱いに降格させます。
こうして検査をするのは、モレは事故を生み、ムダは速度を落としてしまうからです。「モレなくダブりなく」を掛け声ではなく手順にするのが、この二方向の反事実思考です。
モレやすい条件には共通項があります。今回の「優先順位」がそうであるように、自分の仮説に都合の悪いケースに潜んでいる、という点です。よって、
- 「この状態に『待った』をかけられるのは誰か・どんな事実か」を（顧客・パートナーも含めて）書き出す
- 同型のゴールを先に経験した他社事例やチームの型から条件を借りる
というプロセスを踏んでおくとスムーズです。AIやWEBで十分にベストプラクティスやアンチパターンを見つけることは難しいことではありません。
「判断できる」までを計画に落とす
検査を終えたら、あとは「判断できる」状態までの計画を立てるだけです。達成条件（何が観測できたら成立か）は分解の表ですでに付けてあるので、足りていなければここで補います。計画として新たに書き出すのは、役割と責任（Role & Responsibility / RnR）とアクションプランの二つです。
まずRnR。必要な役割と責任を書き出し、担当者（Assignee）を当て込みます。社内に限らず、紹介元の顧客や外部パートナーも役割として書きます。兼任でも構いません。担当者が空欄の役割が見つかれば、それ自体が計画の穴です。
| 役割（Role） | 責任（Responsibility） | 担当者（Assignee） |
|---|---|---|
| 検証リード | 判定ラインの設計と、最終判定の起案 | 自分 |
| インタビュアー | インタビューの実施と記録（メモ・逐語） | 自分＋チームの若手（兼任） |
| 紹介窓口 | 保全部門の担当者の紹介 | 既存事業の営業（兼任） |
| レビュー役 | 誘導・解釈のバイアスチェック | マネージャー |
次にアクションプラン。成立条件ごとに「その条件を確かめる質問を考える」タスクがあり、それらが一つの質問ガイドに統合されて、対象者集め・インタビューの実施・判定という共通の行程に流れ込みます。タスクを各自に割り振り、期日と依存関係を張ると、「判断できる」に着くまでの行程の長さが見えてきます。紹介経由のアポは週に2〜3人が限度、のような動かせない制約が、計画を停滞させそうな要素（クリティカルパス）になっていることも、並べて初めて分かります。
目標達成（プロジェクトマネジメント）も同じスキル
ここまで検証の論点を例にしましたが、この手順は検証専用ではありません。「A社との間で受注が成立している」のような目標達成のゴールでも、まったく同じスキルが回ります。
検証では「成立していると仮説する状態」を原因仮説に割りましたが、目標達成では「未来に成立させたい状態」を条件に割ります。向きが違うだけで、状態を条件に分解し、達成条件を付け、反事実で検査し、RnRとロードマップに落とす、という手順は同一です。ちなみに、こちらのモレの典型は、セキュリティ審査や法務のような拒否権を持つ関係者に由来する条件です。
受注の例で、手順の全体を一枚にまとめます。
まとめ
検証を進めるにしても、目標を達成するにしても、やることは同じです。ゴールを状態として明確にし、成立条件に分解し、逆算でやるべきことを設計する。本章の手順は、ひとことで言えば計画力です。
ただし、計画ができても、動いてもらえなければ元も子もありません。RnRの表にも、既存事業の営業、マネージャー、チームの若手と、自分以外の担当者が並んでいます。分解のおかげで依頼は相手に出せるサイズになっていますが、相手が動く理由は、依頼のサイズとは別に設計が要ります。この利害の設計を、次章合意形成と巻き込み方で扱います。
なお、本章の手順（状態化・成立条件への分解・反事実の検査・計画化）を対話しながら回すためのAIスキル（SKILL.md＋参照資料）を、資料として配布しています。