現場から事業の骨子をつくる考え方
新規事業を考えるときには、3C、SWOT、PEST、アンゾフのマトリクスなど、さまざまなフレームワークが使われます。これらは、新規事業を整理したり、検討漏れを防いだりするうえで有効な道具です。
一方で、最初からフレームワークに沿って企業の情報を整理しようとすると、その会社ならではの重要な事実が見えにくくなることがあります。新規事業支援で重要なのは、「どのフレームワークを使うか」よりも、その前に企業をどのような順番で見るかではないかと考えています。
基本となる流れは、次のようなものです。
現場を見る → 違和感を探す → 構造を捉える → 仮説を立てる → 検証する → 事業の骨子に落とす
フレームワークは、企業を最初から型にはめるためではなく、現場から考えた仮説に抜けや思い込みがないかを確認するために使います。
私が新規事業を整理するときは、理論に当てはめる前に、まず現場の事実を集めます。次に、「なぜこの顧客だけが困っているのか」「なぜこの作業だけ手間がかかるのか」といった違和感を、問いの形で拾います。その問いの背景にある構造を整理して、仮説を置きます。その仮説を疑うためにフレームワークを使い、最後に事業の骨子へまとめます。
フレームワークから入ると、企業固有の情報が薄くなる
例えば、新規事業について相談を受けたときに、最初から、
「ターゲット顧客は誰ですか」
「競合はどこですか」
「自社の強みは何ですか」
「市場規模はどのくらいですか」
と順番に聞いていけば、それなりに整った事業計画をつくることはできます。
しかし、実際の企業の中では、もっと具体的で、整理されていない出来事が起きています。
例えば、
- 最近、既存顧客から同じような相談を何度も受けるようになった
- ある営業担当だけ、この商品をよく売っている
- 10商品のうち1商品だけ、妙にリピート率が高い
- 試作品を見せると評判はよいのに、なかなか購入につながらない
といったことです。
こうした話を最初から3CやSWOTの項目に当てはめてしまうと、
「強みは技術力」
「弱みは営業力」
「機会は市場拡大」
といった一般的な表現に置き換わってしまうことがあります。
情報は整理されますが、その会社ならではの特徴が薄くなってしまいます。
重要なのは、企業固有の事実を、早い段階で一般論に変換しすぎないことだと思います。
新規事業のヒントは「例外」にあることがある
企業を見るときには、平均的な状態だけでなく、「なぜここだけ違うのか」という点にも注目します。
例えば、10商品ある中で、1商品だけリピート率が極端に高かったとします。
その場合、単に売上構成を見るだけではなく、
「誰が買っているのか」
「何に使っているのか」
「会社が想定していた用途と同じなのか」
「どのような説明をすると購入されるのか」
と掘り下げていきます。
すると、会社が想定していたものとは違う用途で使われていることが分かるかもしれません。
そこから、
新しい顧客課題があるのではないか
別の用途として展開できるのではないか
新しい市場になるのではないか
という仮説が生まれます。
市場分析や競合分析は、その後で行えばよいわけです。
現象ではなく「構造」を見る
現場で起きていることを聞くだけでは、単なる情報収集で終わってしまいます。
次に考えるのが、事実同士の関係です。
具体的には、
原因と結果
何度も繰り返していること
制約になっていること
ボトルネックになっていること
などを探していきます。
例えば、
問い合わせは多い → 見積もりまでは進む → しかし受注しない
という状況があったとします。
企業側では「価格が高いからではないか」と考えて、値下げをするかもしれません。
しかし、それでも受注が増えない。
そこで顧客の話を詳しく聞いてみると、
「導入した後、自社で本当に使いこなせるのか分からない」
という不安があることが分かったとします。
そうすると、問題は、価格が高いから売れないのではなく、
導入後がイメージできない → 導入リスクを感じる → 意思決定できない
という構造かもしれません。
この場合に必要なのは値下げではなく、デモ、PoC、導入事例、導入手順の説明、サポート体制の整備
などになります。
同じ「売れない」という現象でも、原因の捉え方によって打ち手は大きく変わります。
支援者は「仮説」をつくる
現場の事実を集め、構造を整理した後に行うのが仮説づくりです。
例えば、「営業力が弱い」と考える前に、
本当は、誰に売るかが決まっていないのではないか。
「市場がない」と考える前に、
顧客が現在使っている代替手段を見落としているのではないか。
「製品力が弱い」と考える前に、
企業が伝えている価値と、顧客が求めている価値がずれているのではないか。
と考えてみます。
もちろん、最初に立てた仮説が正しいとは限りません。
そのため、仮説を立てるだけではなく、
「この仮説が間違っているとしたら、何が考えられるか」
という視点も必要です。
フレームワークは「答え」ではなく「検証装置」
ここで、3C、SWOT、PESTなどのフレームワークが役立ちます。
現場を重視するからといって、理論やフレームワークが不要になるわけではありません。
むしろ、現場だけを見ていると、
「社長がそう言っているから」
「顧客1社が欲しいと言ったから」
「以前の経験ではうまくいったから」
といった理由だけで判断してしまう危険があります。
そこで、現場から作った仮説を、
顧客・市場・競合・自社の強み・代替手段・収益性・実現可能性
などの観点から確認していきます。
つまり、フレームワークは、企業を当てはめるための型ではなく、
自分たちの見立てに抜けがないかを確認する道具として使います。
「事業の骨子」は最後の整理形式にする
この考え方は、「事業の骨子」を作るときにも重要です。
事業の骨子では、最終的に、
顧客・顧客の課題・自社の強み・提供価値・差別化・製品・サービス・事業化方法・売上・利益
などを整理します。
ただし、この項目を上から順番に質問していく必要はありません。
むしろ、骨子そのものを質問票にしないことが重要だと考えています。
最初のヒアリングでは、
「この事業を考えるようになったきっかけは何か」
「最近、顧客から繰り返し言われることはないか」
「想定外に売れた商品はないか」
「反対に、評判はよいのに売れなかったものはないか」
「社内で、なぜかうまくいっていることはないか」
「顧客は現在、その問題をどのような方法で解決しているのか」
といったところから聞いていきます。
そこから、
現場の事実→ 違和感→ 構造→ 仮説→ 検証→ 事業の骨子
へ整理していきます。
事業の骨子は、考えるためのスタート地点ではなく、最後に整理するための形式として使う方がよいのではないかと思います。
生成AIを使う場合も「質問の順番」が重要になる
この考え方は、生成AIを使った事業計画づくりにも関係します。
事業の骨子をそのままAIに与えると、
「ターゲット顧客は誰ですか」
「顧客課題は何ですか」
「競合は誰ですか」
「自社の強みは何ですか」
と順番に聞くAIになりやすくなります。
これは便利ですが、入力フォームを対話形式にしたものに近くなります。
それよりも、
事実を集める→ 違和感を探す→ 構造化する→ 仮説を出す→ 仮説を疑う→ フレームワークで検証する
→ 骨子に整理する
という順番にした方が、実際の支援に近づきます。
AIに多くの知識を持たせることも重要ですが、それ以上に、
何を先に見て、どこで疑って、何を確認してから結論を出すのか
という「企業を見る順番」を設計することが重要だと考えています。
経営革新計画の支援経験を振り返って
経営革新計画の支援でも、企業から最初に出てくる話が、
「新規性」「市場性」「実現可能性」できれいに整理されているわけではありません。
企業から話を聞きながら、
「この会社が本当にやろうとしていることは何か」
「従来との違いはどこにあるのか」
「新しい部分をどう説明するのか」
「根拠が弱いところはどこか」
「計画として成立させるには、何を詰める必要があるのか」
を整理し、修正していきます。振り返ってみると、これも、
現場を見る→ 構造を整理する→ 仮説を立てる→ 制度や市場の視点から検証する→ 計画に落とす
という流れだったと考えることができます。
現場起点で事業の骨子をつくる
今後、新規事業の支援方法を整理していくうえでは、次の流れを一つの基本形として考えていきたいと思います。
現場の事実を集める
↓
違和感や例外を探す
↓
事実同士の構造を捉える
↓
事業機会や課題について仮説を立てる
↓
仮説を反証する
↓
顧客・市場・競合・自社・財務などから検証する
↓
事業の骨子に落とす
まだ完成された方法論というわけではありません。
これまでの支援経験を振り返りながら、今後さらに整理していく必要があります。
ただ、新規事業を考える際に、
「どのフレームワークを使うか」より先に、「実際に何が起きているのか」を見る。
ことが重要なのではないでしょうか。