見出し画像

ディープテック企業におけるビジネスモデル検討のポイント

「ビジネスモデル」という言葉は、古くから事業戦略を考える上でセットで出てくる言葉であり、大企業、スタートアップ問わず、事業企画に関わる様々なビジネスパーソン(BizDev/エンジニア/経営者など)にとって重要検討テーマかと思います。

ただ、その検討の現場においては、そもそもビジネスモデルとは?も曖昧だったり、ややもすれば「とりあえずフォーマット(ビジネスモデルキャンバスなど)を埋めてみました」状態だったりして、あまり本質的な議論に行き着いていないケースもあるように思います。

また、ビジネスモデルに関する書籍は世に多く存在して、非常に参考になるのですが、ビジネスモデル全般論となると、そこから皆様が取り組まれている個々のビジネスに適用して考えるにはややハードルが高い印象もあります。
(例えば、Googleを引き合いに「こんなビジネスモデルがある」と言われても自分たちのビジネスとは遠すぎて考えづらい、など)

こうした背景認識のもと、特にB2B系のディープテックの事業(AI、ロボット、脱炭素何でも良いのですが)のビジネスモデル論に焦点をおいて、具体的に何をどう考えたら良いのか整理したいと思います。

本稿のまとめチャートはこちら

まとめチャート
~ちゃんと重要論点を正しく深掘りしよう~


ビジネスモデルとは?

まず本稿におけるビジネスモデルの定義づけをしておきたいと思います。
一言で言えば「どうお金を稼ぐか?」を表したものです。
もう少しちゃんと理解する上で「戦略」という言葉との違いで理解したいと思います。

従来の戦略論は「誰に何(どんな価値)を売るのか」という市場の選択を主眼に置いています。(所謂CS/VP=Customer Segment/Value Proposition=の話)
代表的な伝統的戦略論であるポーターの論では、戦略の種類を「ニッチ戦略」「低コスト戦略」「差別化戦略」と分類して、
例えば「ニッチ戦略」であれば、ターゲット市場、すなわち「誰に」を比較的競争の少ないセグメントにおいて、そこでのニッチなニーズを満たすことを提供価値に置きます。

それに対してビジネスモデル論では、(誰に何を売るのかを定義したうえで)「どう稼ぐのか」という問に答えます。
例えば、代理店戦略などのチャネル戦略は、(従来の)戦略論には主題として登場せず、ビジネスモデル論で登場する観点になります。

一般的に、ビジネスモデルで検討すべき観点の全体像を示したものとして、ビジネスモデルキャンバスがあります。

ビジネスモデルキャンバス
(出所: JAJAAN

戦略論で議論されるCS/VPの他に、
・顧客チャネル
・キーとなるパートナー
・キーとなる活動(研究開発とか)
・キーリソース (xxのスキルを持ったプロダクトマネージャー、とか)
などが挙げられます。

ビジネスモデルキャンパスの限界と、ビジネスモデル論で本当に議論すべきこと

しかし、戦略検討の実務をやる中で、ビジネスモデルキャンバスを埋めよう!というのはあまりワークしないことが多いという実感があります。
それは、ビジネスモデル論で考えるべき本質があまり論じられないからです。

考えるべき本質は、「儲けのストーリー」であり、大きく以下2点と考えます

  • お金を誰からどうもらうのか?(なぜもらえるのか?)

  • どのようなダイナミズムで成長するのか?

そもそもなぜビジネスモデル論を考えたいのでしょうか。
一つの考え方として、「世の中において、様々な儲け方が生まれ、その巧拙が勝敗を決めた例が多くある」という点が挙げられると考えます。

極端に言えば、仮に世の中において、単に「良いものを作って売る」だけのビジネスであれば、勝敗の巧拙は"良いものを作る"だけであり、ビジネスモデル論には至らないと思われます。
実際には古くより、こうした"単なるモノ売りではない"様々なビジネスが生まれてきました。
例)

  • リクルート社のリボン図モデル → 企業と消費者のマッチングモデル(1960年頃~?)

  • 各社のフリーミアムモデル → 例えば、基本サービスを無料にして利用者を集め、一部の利用者を購買者とする、など

ポイント1)多様なステークホルダーを考慮する

上記の例も念頭に置きつつ、ビジネスモデルキャンパスで不足していると感じる観点の1つ目は、

  • 多様なステークホルダーの考慮
    です。

ありがちな議論として、ビジネスモデルキャンパスの顧客セグメント=xx業界 とか 高齢者 とかと書いてシャンシャンとなっていることを見受けますが、本質的に論ずるべきは、誰が「なぜお金を払うのか」であり、昨今のビジネス上、それを明確化するうえで多様なステークホルダーを考慮する必要性が高い事が多いです。

例えば、ディープテック企業であれば、「テクノロジーでXX業界のYY業務を自動化する」なんていうのが、ありがちなビジネスですが、
大体、世の中に残存する業務は、技術的難易度が高かったり、費用対効果があいづらかったり、組織/業界慣習的に自動化しづらかったり、、などの事情を抱えてることが多いです。

その中で、"現実的にある程度実現性のイメージのわく"レベル感での価値提供(例えば半自動化的な)を考えたときに、
「それでもお金を払ってくれそうな顧客はどんな人かな?なぜ払ってくれるのかな?」を具体的に考えること(仮説を出すこと)が重要だと考えます。

例えば、「XX業界」という粒度ではなく、「XX業界の現場系の人に行っても微妙だけど、本社でこういう業務の統括している人にいったら興味持ってもらえるかな」とか
「だって、個々の業務の自動化のインパクトって、今できるレベル感だと個別に見ると微々たるものだけど、全社俯瞰的に組合せたら、これくらいのお金を払っても費用対効果合うのでは」とか。

そして、実際に顧客から満足の行くソリューションを提供しようと思ったら、実際には社内だけで開発してても限界があって、色々なプレイヤーを巻き込むことになります。
例えば、「顧客セグメントはXX業界!」で終わりではなくて、「XX業界の中でも、まずはシンプルな業務をしているXX-1セグメントで(稼げなくても)経験を積んだ上で、本当に困ってて支払い意欲のあるXX-2セグメントでガッツリお金をもらおう」
といった議論が重要になります。

こうした議論を経ることで、具体的なアクション(優先的に営業すべき対象や開発アイテム)が明確になっていくものです。

ポイント2)成長のダイナミズムを検討する

ビジネスモデルキャンパスで不足していると感じる観点の2点目は、

  • 成長のダイナミズムの考慮
    です。

ビジネスモデルキャンパスは、時間軸でいうとイチ断面(スナップショット)での記載になるのですが、特にディープテック系の事業、スタートアップなどでいうと、どう時間発展させていくのか(ダイナミズム)の重要性が高いと感じます

(このあたりは、「ストーリーとしての競争戦略」等で論じられている趣旨とも近いと思います)

典型例としては、AmazonのECでしょうか。
サービスとして出来上がったあとを見れば、「消費者に手軽かつ安価になんでも揃えられるサービスを提供することで稼ぐ」ということなんでしょうが、
ポイントは、そこというよりは、そこに至るまでのダイナミズム(所謂Amazonのナプキンチャート)であろうと考えます。

Amazonのナプキン(に書いたとされる)ビジネスモデルチャート
表しているのは「成長のダイナミズム」

特に、ダイナミズムを考える≒好循環系を考えるとも言えると考えます。
この文脈でIntelの事例もよく挙げられる所です。
CPUのスペックの良さだけでなく、インターフェイスを標準化(PCI)して、互換デバイスを広げることで、更に商品価値を高める→更に互換デバイスが増える→・・・というやつです。

Intelの好循環モデル

ディープテック企業であれば特に重要な検討観点です。
この観点がないと、個別顧客ごとの対応で工賃を稼ぐ、所謂受託ビジネスになりがちである一方で、ダイナミズムの観点を取り入れることで、個別顧客の対応を線で繋ぎ、大きな成長に繋げられます。

例えば、ある自動化系の事業を立ち上げるとして、頑張って初期の顧客対応をすると同時に、汎化性を高めるための技術開発・データ基盤整備などに投資をすべき、という具体アクションがダイナミズムの観点から導かれます。
ダイナミズムの視点から、「案件対応をする」→「汎化性を高めて次の案件を低コストで実現する」→「更に案件を獲得する」→・・・などといった好循環を回すことが肝だからです。

これは言うは易しでは(リソース観点・顧客関係性観点など)、という見方もあるかと思いますし、そうだとは思います。
ただそれでも実務的に、こうした観点を持つことで、新たに投資すべき技術開発要素に気づけたり、知財の持ち方を工夫することで、顧客にとっても自社にとってもハッピーな形を作り上げることも出来ます。
(例えば、ここまでは自社開発にして知財を持ちながら、ここからは顧客向けのカスタマイズ開発にして権利も移転する等)

また、スナップショットの議論だけだと中々具体アクションに結びつきづらいのに対して、ダイナミズムを明確化することで、具体アクションに結びつきやすいとも感じられます。

ポイント3)リアルな課題(構想)を起点に考える

ここまでで以下の2点の重要性に言及しました。

  1. 多様なステークホルダーを考慮する

  2. 成長のダイナミズムを検討する

ここで1, 2, どちらを考える上でも、以下の観点が前提として重要であるという点を付記したいです。

  • リアルな課題(構想)を起点に考える

ビジネスモデル検討の現場では、往々にして独りよがりな課題設定が見受けられます。
例えば、何かしらのセンシングを自動化するソリューション(AIカメラでも新たなウェアラブルでも何でも良いです)の検討をしていたとします。

そこで、「課題は、ユーザが〇〇のセンシングが簡単にできないこと」などと書かれたりするのですが、本当にそれはリアルな課題=ユーザが実際にお金を払ってでも解決したい課題=なのか、というと大いに議論の余地があります。
代替品で何かしら測れたりするかもですし、そもそも測れるだけでは意味なくて何かしらの解決策(例えば疲れを計測した上で、疲れをなくす、など)とセットではじめて課題解決になるのかもしれないです。

設定した課題がゆるいと、1の検討も2の検討も緩くなります(実効性が弱くなります)。
1.の検討の中で、支払い社になる顧客セグメントを定義するわけですが、課題設定を「〇〇のセンシングが出来ないこと」レベルに留めると、顧客セグメントは、例えば「toB全般」みたいな形になって「そんなtoB全般がこのサービスにお金を払う、ってホントに?!」という話になりがちです。

で、どうすべきかというと、ユーザの視点にたって「確かにこれが解決されたら本当に意味があるよね」というリアルな課題の気づきを得る必要があります。これは、ユーザとのディスカッションや、真にユーザの視点に立つためにユーザ企業の中で実際に働くなどによって実施されます。

先程のセンシングソリューションの例でいうと、「一般論としてセンシング出来ないことが課題なのではなくて、色々な代替手段はあるのだが、このユースケースにおいては、センシングしたときのこの情報がが足りないことがシステム全体の大きなボトルネックとして課題になっている」といった様に、具体的に何が出来たらどう嬉しいかのイメージが湧く形に落とし込めると良いです。
そうすると顧客セグメントも「toB全般」とかではなく、もっと特定のセグメント(例えば、◯☓を作っている自動車部品メーカーみたいな)を定義すること出来ます。

なお、「toB全般」をターゲット顧客セグメントにすることが悪いと言っているわけではなく、顧客像がぼやけて課題設定にリアリティがないことが悪いという話をしています。
実際に、SmartHRさんなどを始めとしたバックオフィス業務効率化SaaS郡は、大なり小なり「toB全般」をターゲットとしている側面があると考えられます。
それでも、特にローンチ初期の段階で狙う顧客イメージは具体的に持っていたはずです(例えば、労務系の紙業務に対する拒否感が強いと思われる中小規模のIT系の会社/etc.)

また、この手の分かりやすい紙業務のデジタル化課題は、関連ソリューションが概ね出尽くされた感もあり、より一層"自明的でない"課題を深掘りしていく必要性も感じます。

まとめると、「リアルな課題を起点に考えよう」「独りよがりな課題設定はやめて、ユーザ視点で何が解決できたら本当に意味があるのかの気付きを得よう」「代替手段などの世の現状も踏まえて、ユーザとのディスカッションやユーザ側での実務などを通じて課題を深掘りしよう)」です。

ディープテックにおけるビジネスモデルの考え方

ここまでで以下3点のポイントを示しました。

  1. 多様なステークホルダーを考慮する

  2. 成長のダイナミズムを検討する

  3. リアルな課題を起点に考える

この3点はディープテックに限らず重要ですが、特にディープテックならではで重要な考え方がそれぞれありました。

  1. (労働集約とは異なり)システムには再利用性があることを踏まえ、システムを育てる先とお金をもらう先をそれぞれ考える

  2. 汎化性を高め、ユーザの増加を次のユーザ獲得に繋げる構造を作る

  3. (ディープテックこそ特に、)代替手段やユーザ側での実務を踏まえて、独りよがりではない課題の気づきを得よう

実務的な検討ステップとしては、上記1~3を逆順に考えることが多いです。(結局、課題設定が肝なので。)

Step1) リアルな課題を特定する(ただしある程度顧客共通性のあるもの)
Step2)ユーザの増加を次のユーザ獲得に繋げる成長のダイナミズムを明確化する
Step3)お金のもらい方・ユーザの広げ方を整理する

Step1では、リアルな課題の特定が重要だという話をしていますが、とはいえその課題が当てはまるのが1-2社では普通は少なすぎます。業界などの区切れる単位の中である程度共通性のあるものか検証は必要です)

例えば、あるITベンダーは、食品業界において商習慣を背景にデジタル化が進まないという課題を特定していましたが、良い例だと思います。

Step2では、主に汎化性を構築するための技術的・運用的な仕組みをどう作るかが論点です。

例えば、ある会社は、ソフトウェアをすべてワンパッケージで管理してすべての開発を汎用的に利用可能なようにしていたり、またある会社ではどうしても発生してしまう個別要素を極力自動化する技術を開発したりなどしています。

Step3では、やはりお金のもらい方の確からしさを高めることが主なタスクになります。

例えば、あるロボットの会社では、あるセグメントに対してある機能を提供すると、大量導入によって大きなユーザメリットをもたらせることを認識して、(色々なセグメントに展開して知見やデータ収集を行いつつ、)その大量導入によるマネタイズのシナリオを深めていきました。

まとめ

ビジネスモデル検討のポイントについてご紹介しました。
ざっくりいうと、「課題特定」「ダイナミズム」「多様なステーク」の3点でした。
ディープテックにおいて特にポイントとなる点として「ユーザの実務を踏まえて、脱独りよがり」「汎化性高めて、ユーザ増加をさらなるユーザ獲得へ」「システムを育てる先とお金をもらう先」という点を挙げました。

まとめチャート(再掲)

皆様のビジネスモデル検討の一助になれば幸いです。

この記事が気に入ったらサポートをしてみませんか?