本稿では、筆者が実践してきた、①大企業のシガラミに絡みとられることなく、②自由に大企業のアセットを使いこなし、③事業を成功に導くヒントを紹介したい。本稿が、少しでも新規事業開発に取り組む皆様の参考になれば幸いである。

1. 最初のテーマを選ぶまで出来るだけ時間稼ぎをする

私は、大企業の新規事業開発では、できるだけアングラで初期仮説の検証を進めることが一番成功確率の高い方法だと考えている。

事業開発では、初期のテーマ選定において、紆余曲折あることが普通だ。軌道修正や方向修正を何度も行いながら仮説検証を進める中で、ようやくPMFにたどり着くことがほとんどである。

一方で、安定的なオペレーションを効率的にこなすことに慣れきってしまった人の多い大企業では、方向転換や軌道修正自体がネガティブに捉えられてしまいがちだ。"ピボット"は理解されないし、許されない。それが普通である。

だから、「報告すべきテーマは固定しつつも、実際は流動的にテーマを入れ替えながらより有望なテーマを探していく」というダブルスタンダードでの運用が必要となる。これをやらないと、組織の信頼を得て、裁量と権限を得ることが難しい。

組織では大きな方向性について承認を得る必要はあるが、事業開発では詳細な内容を都度報告してはいけない。勝てる仮説を限られた時間内で発見しなくてはいけないのに、それ以外の重要度の低い項目に対応している時間はない。

そして、可能性が見えないのに、テーマをパブリックにしてはいけない。大企業で事業開発を進める上で理解しておかないといけないのは、パブリックにするテーマは必ず「上司がその上司に説明できるものでなくてはならない」というものだ。

上司がその上司に説明できなければ、結局、上で止められてしまう。もちろん自分で説明するのもいいが、第三者、それも自分の評価者である上司から説明してもらえる方が、会社では絶対的にメリットがある。自分も評価されて仕事がやりやすくなるし、レポートラインを守っているので無駄な軋轢が生まれる可能性も抑えられる。

逆に、パブリックにしないテーマは上司が説明できなくても許されるので、アングラで進めることができる。（ここでいう"パブリックである"とは、公式に設定した会議で説明を求められること、年間計画に組み込まれること、上司から定期的に進捗を確認されるプロジェクトになること、というイメージだ。"アングラ"はその逆である。）

最初から「これをやります！」と言ってはいけない。できるだけ方針設定は引き伸ばすこと。時間稼ぎしつつ、確実に勝てるテーマを探して仮説検証の数をこなす。これしかない。

2. 全体像をイメージを作り、目指すべき姿を示す（〜半年）

最初のテーマを選ぶまで時間稼ぎをすることが重要だが、それまでにやるべきことが一つある。それは「大きな方向性を示す」ことである。

・どんな方向性で仮説検証を進めていくのか

・どこに向かおうとしているのか

これらを明確にしておくと、自分が居場所を見失いそうになった時の拠り所になる。

様々な観点から、様々なテーマの仮説検証を数多く進めていくと、何を目指してやっているのか、焦点がぼやけてくることがある。やっている本人ですらそうなのだから、他人から見ると本当に何をやっているのか分からない。そこで「大きな方向性」があれば、かなり説明がしやすくなる。

「大きな方向性」に関しては、何をやっても包含されるくらい大きな範囲で括ってしまうことが望ましい。「意味はないけど、意味があるように見せかけるセグメンテーション」をベースに、自分の仮説検証テーマを当てはめていくのが理想である。

このステージでの工数配分としては、

・"硬いテーマ"の調査 30%
・"硬いテーマ"探索の仮説検証 50%
・"ハイリスクテーマ"の調査 10%
・社内説明 10%

実際は「社内説明」の工数をどれだけ抑えられるかがポイントかもしれない。最初の半年は何も口出しされず自由にやれる執行猶予期間であることが多い。この半年の間にどれだけ目処をつけられるかが成否を分ける。

初期調査では、広く浅くテーマ探索することをお勧めする。最終的には、テーマを適宜入れ替えながら進めていくのが理想的だ。いまはダメでも時間が経てば、そのタイミングとなるテーマもある。大切なのは、固執しないこと。有望なバックアップテーマがあれば、一つダメでも次があるという、精神的な安心感にもつながる。ここで時間をかけて選択肢を広げておくことが、後々に効いてくる。

3. 硬いテーマを選び、パブリックにする（〜1年）

しばらくすると、上から具体的なテーマを出せと言われ始める。その時までにうまくいきそうなテーマを複数ピックアップしなくてはならない。ここが最初の一番重要なイベントである。うまく行く可能性の高いテーマを"硬いテーマ"と呼んでいる。

"硬いテーマ"は、以下のような条件を満たすテーマのことだ。

ここで選んだ"硬いテーマ"が、自分の事業開発プロジェクト全体を守る盾となる。「上手くいっています」「少しずつ成果も出始めてきました」と、小さな成功を小出しにアピールすることで、事業開発への投資を打ち切られないよう、そして自分の首が飛ばないようにポジションを守ることができる。

"パブリックにしたテーマ"は、基本的に下ろすことができない。常に説明の機会に晒されて、進捗と成果をチェックされる。このテーマが優等生でなければ、他の有望な事業の種を守ることができない。優等生は小さくまとまってしまうが仕方ない。ポートフォリオ全体の守護者でなければならない。

"パブリックにしたテーマ"は固定しなければならない。コロコロ変えると印象がよくない。前述の通り、会社では基本的に"ピボット"は理解されないし、許されない。それが普通である。社内説明用と、実際の運用は切り離して考えるのがベストである。

なお、今、振り返ってもパブリックにする最初の"硬いテーマ"の選定は、最も緊張する瞬間だった。上手くいくかどうかなど分からない。その時ある情報を元に決断しなくてはならない。このテイクオフが最も自力が試される瞬間なのかもしれない。

有望なテーマを早く見つけるコツがある。それは、初期仮説（アイデア）に対して、出来るだけ早く市場でヒアリングを行うことだ。早く間違いを見つけ、修正する、ダメなら違うものを試す。このサイクルを早く多く回せるかどうかが、限られた時間の中で筋の良いテーマにたどり着けるかどうかのカギである。

4. アングラでハイリスク案件を温め、育てる（〜2-3年）

"硬いテーマ"を設定できれば、ひとまず安心。でも、まだ二合目くらい。ここから「どうやって大きく売っていくか？」に少しずつ考えをシフトさせていく。

"硬いテーマ"は「社内でどう説明し生き残っていくか」という投資家対策的な意味合いが強かったが、それだけでは本当の意味で生き残ることは出来ない。最後、必要なのは、結果であり、成果である。

成果を得るために必要なのは、リスクを取ってリターンを狙っていくことだ。大きく勝つためには、"ハイリスク案件"を仕込んでいく必要がある。

ハイリスク案件とは「これは社内説明できない」というような、不確実性が高いが当たれば大きそうな案件のことだ。上手くいくか分からないことが多く、未来予想もどちらに転ぶかわからない、何となく面白そうだけど、よくわからない。そんな案件のことである。

ハイリスク案件は、分からないことが多いので、まず話が怪しい。「本当かそれ？」と直感的に引っ掛かったら、それは見込みある案件かもしれない。もしくは「他の人は微妙な反応だけど、自分だけが強くそれが正しいと信じている」ものも見込みある案件だと思う。

ただ、どちらにしても、社内では理解されないし、理解されようと説明するだけ時間の無駄になる不毛なテーマ。だからこそ、大化する可能性を秘めている。自社も他社も他に誰も信じていないところに、ブルーオーシャンが存在している（可能性がある）。

リスクはリターン。リスクを取らなければリターンは得れない。リスクを取らなければ、既存事業を超える新規事業を生み出すことは絶対に不可能だ。

しかし、なかなかリスクを取りたがらないのが、大企業の性だ。どうやれば、大企業でリスクを取ることを認めてもらえるか？幸運なご縁があり、某自動車メーカーの元CTOから上手い方法を教えていただくことができた。

「説明がつかないようなよく分からない案件」をポートフォリオに組み込むには、全体方針を大きな枠で取ること。そして、出来るだけ自分の裁量の範囲内で隠し持つことである。

「自分の責任となる失敗の種は潰す」というのは大企業の生存戦略では合理的である。逆に「自分の責任となるような失敗になりそうにないレベルの将来への種蒔き」として理解されれば、訳のわからない説明できないようなハイリスク案件への投資も許される。

事業開発担当者が、「将来的に化ける可能性があるから少しだけ張っておく」というスタンスであれば、リソースに余裕のある大企業であれば、看過されることが多い。

この絶妙のバランス感覚が重要である。ギリギリのラインでポジショニングすることで、ハイリスク案件を守るスキルは、大企業の事業開発リーダーとしてはすごく役に立つし、これがないとやっていけない。

将来への種まきとし、面白そうな案件も仕込んでおくことを許してもらえれば、ハイリスク案件をポートフォリオに組み込むことに成功した。あとは、ハイリスク案件のどれかが運良く噴いてくれることを期待して待つだけだ。全てはタイミング次第。いつ来るか分からないので気長に虎視眈々と準備しておこう。

ただし、うまく可能性ありそうなハイリスク案件を仕込めても、そればかりやっていては絶対にダメだ。メインで進めていくのは硬いテーマであるべき。何度も言うがポートフォリオ（事業開発プロジェクト自体）を守るためには、硬いテーマで早期に成果を出すことが何より必要だ。

"硬いテーマ"で早期に成果を上げて自身のビジョンの正しさを証明し周囲の理解を確立した上で、大きく成果を出すのが"ハイリスク案件"。この役割分担と順番を間違ってはいけない。

5. 実行し、成果を出す（〜5年）

ポートフォリオを守る盾（硬いテーマ）と、大きな成果をもたらす鉾（ハイリスク案件）の準備が出来たら、あとは行動あるのみだ。

「硬いテーマ」はできるだけ早く成果が出ることを期待して動く。「ハイリスク案件」は成果が出る時期や大きさはあまり期待せずに、機が来た時にそのチャンスを掴めるように粛々と準備しておく。

事業開発ポートフォリオは、鉾盾が揃えば完成ではない。常にアップデートしていく必要がある。盾はある程度の年月使える（それを見越して選んでいる）が、鉾はどんどん入れ替えていかなければポートフォリオが錆び付いてしまう。

そこで重要なのが「探索テーマ」というワードだ。

コロコロとテーマを変えるのはよくない（と大企業ではされる）が、継続的にテーマを入れ替えることは成功のために必要なことだ。矛盾する様だが、このふたつを上手くやるテクニックが、この「探索テーマ」である。

私は以下の３つのカテゴリにテーマを仕分けることで、説明に使用している。

「探索テーマ」は、技術開発を伴わない市場ヒアリングのみの調査テーマだ。ここでは事業開発担当だけで、可能性を調査できる範囲までを行う。着想ステージだ。

「重要探索テーマ」は、技術開発を伴う仮説検証まで実行するテーマだ。探索テーマで可能性を感じたいテーマを昇格させ、技術開発を伴う仮説検証まで行う。PMFステージだ。

「開発テーマ」は、プロポジションを実現する技術開発を行うテーマだ。それまでの仮説検証の結果、テーマとして有望なことが示され、プロポジションを実現する製品開発を行う。MVPステージだ。

この３つのカテゴリ間でテーマの入れ替えを行いながら、常に最善でより可能性の高いポートフォリオを作り上げていく。

このカテゴリ分けの使えるところは、異なる部署間の横断プロジェクトでも説明しやすく、相互の共通認識の形成に役立つ点である。

例えば、事業開発チーム（Market Development）と技術開発チーム（Technical Developmet）で認識が異なるために、思ったほど成果を上げられないような場面に多く出くわす。事業開発サイドとしては可能性があると思って提案しているが、技術開発サイドとしては可能性を感じていないため後回しにしがち。結果、機を逃して、遺恨だけが残る。だから、新規開発に誰も手を出したくなくなる。そんな光景をよく目にする。

三段階のテーマ設定は、テーマごとの重要性と位置づけを可視化し、関係者のコミットメントを引き出すことに役立つ手法だ。

なお、本質からは逸れるが、事業開発プロジェクトを守っていくには「やってる感」を出すことも大事だと思う。政治的で、官僚的な、ネガティブな印象があるが、そこを飲み込んで、実を取ることをお勧めする。

実際に自分のプロジェクトを評価するのは周囲の人だ。人が評価を下す際に、直属の上司でもない限り、KPIやその達成度なんてわざわざ確認することはない。何となく頑張ってるか、成果が出ているのか、印象や雰囲気が支配的な要因となる。

応援してもらえる雰囲気、何となく上手くいきそうな雰囲気があれば、ポジティブなフィードバックをもらいやすくなる。周囲の協力も得やすくなる。もし、全然うまくいっていないプロジェクトを手伝ったら、何の成果にもならないよく分からない仕事になんで工数割いているんだ、とその協力者が被害を受けてしまう。そうならないためにも、レピュテーションマネジメントは重要だ。

・結果が出るまでの過程をいかにやり過ごすか
・結果がまだ出ていない間にどう周囲の応援や協力を取り付けることができるか

これは大企業で、新規事業開発を実行していく上で重要である。

探索テーマがあれば、「こんなアイデアはどうなんだ？」と突然上層部の思いつきで、新規プロジェクトを作らされたりすることも少なくできる。「それはここまで仮説検証していますが、こういう理由でいまは優先順位下げています」「それはこういう理由でまだ仮説検証していません」と理由を説明できるし、探索テーマがあルことでより建設的な議論ができるからだ。

この考え方は事業開発だけでなく、技術的な研究開発に応用できそうな気がする。新規開発はビジネスサイドもテクノロジーサイドも本質的なところは共通するものがある。

参考) 事業開発を助けるフレームワーク

私自身が実際に使えると感じている事業開発の社内突破（上申）を助けてくれるフレームワークを紹介したい。

１）企業内の上申プロセスの理解を助けるフレームワーク

重要なのは、①コンセプトの検証、②プロダクトの検証、③投資の判断、と仮説検証のレベルをそれに係るコストと比べて、段階的にステップアップしていく点である。社内で「ダメと言われない」で進める技術にも通じるところがある。

出所: "なぜ事業開発は“アイデア発想”で頓挫するのか──顧客課題から始まる“ストーリー開発”アプローチとは？

２）上申プロセスにおいて回答を用意すべきポイント

重要なのは、事業の説明ではない。それが「会社で取り扱えるものなのか」「実現できるのか」「勝てるのか」「売れるのか」の４点である。これは投資提案する際の回答を準備するにあたり、これ以上ないほど参考になる。

出所:"なぜ事業開発は“アイデア発想”で頓挫するのか──顧客課題から始まる“ストーリー開発”アプローチとは？

参考文献

社内突破術を含めた事業開発手法に踏み込んだ内容の書籍は少ないが、以下の二冊が参考になる。やって覚えていくしかないのだが、最初に理論を頭に叩き込んでおくと何かと理解が早いのでオススメだ。