読み込み中...
投稿日
新規事業開発の考え方 ― ステージ・ゲートプロセスの全体像
はじめに
ここでは、新規事業立ち上げのプロセス「ステージ・ゲートプロセス」における新規事業開発の考え方を解説します。
新規事業立ち上げの全体概要を掴みたい方は、まず新規事業開発 ― ステージ・ゲートプロセスによる新規事業立ち上げを一読頂くことをお勧めします。
新規事業開発の考え方
改めてステージ・ゲートプロセスの全体像と、個々のステージの流れを示すと以下のようになります。
ステージ・ゲートプロセス
ステージ・ゲートプロセスの2つの考え方
このステージ・ゲートプロセスに沿って行われる新規事業開発は、大きく以下の2つのフェーズに大別されます。
- 事業仮説を構成する「顧客」「課題」「ソリューション」を”探索し検証”するフェーズ
- 実際に事業を”ローンチさせ、ユニットエコノミクス1を健全化”するフェーズ
それぞれのフェーズの目的は明確に異なります。
そして目的が異なる以上、それぞれのフェーズに対し、異なるアプローチ・異なるエンジニアリングが必要になります。
例えば「事業仮説の探索と検証」フェーズにて構築したMVPを「ローンチとユニットエコノミクスの健全化」フェーズには持ち越すことを前提として考えてしまうと、
前者のフェーズのスピードが上がりません。両フェーズは明確に切り分けましょう。
事業仮説の探索と検証
このフェーズで必要なのは、仮説検証サイクルの高速化です。
これは新規事業開発チームの思い込み・検証されない仮説の下で大きなコストを投入し市場に求められない製品を作ってしまわないよう、細かく仮説を設定・検証し、進むべき道を探索していく必要があるためです。
このフェーズでは、事業仮説を構成する以下の仮説を構築し、検証しなければなりません。
- 「顧客」は誰か
- お金を払ってでも解決したい「課題」は何か
- 課題を解決できる「ソリューション」は何か
- ソリューションは製品として実現できるのか
仮説検証によって、これらの問いへの確度と解像度を高めていかねばなりません。
そしてMVPにより、確かに顧客が存在し、ソリューションによって課題が解決され、お金を支払ってもらえることを検証します。
これらの検証は、仮説を形にし、顧客のところに持っていき、顧客の反応に応じて仮説を修正するというサイクルをひたすら回すことによってのみ行えます。
有限の時間とコストの中で、不確実性を下げ、プロダクトの解像度を上げていくために、事業オーナー・エンジニア・デザイナーはこの仮説検証サイクルをどうすれば高速に回せるのかを真剣に考える必要があります。
まず全員が最初に考えるべきなのは、「いかに作らず、いかに高速に検証するか2」でしょう。
仮説検証サイクル
『新規事業の実践論』3では、「仮説を顧客のところに持っていく」回数として300回が必要だとされています。このフェーズに半年をかけるとすると、1営業日2.5周が必要になる計算です。
ローンチとユニットエコノミクスの健全化
このフェーズで必要なのは、事業の迅速なローンチと、顧客を観察した上での素早い改善の積み重ねです。
本フェーズに至ったということは、課題を持った顧客が確かに存在しており、私たちのソリューションによってその課題を解決でき、お金を支払ってもらえることがわかったという状態にいます。
つまり、MVPのような「実験」をするプロジェクトではなくなり、ビジネスとして収益を追い求める4フェーズになります。
このフェーズにおいては、課題を解決するソリューションは定まっています。
従って、事業計画を作成してビジネスとして成立することを確認し、まずはサービスを早期にローンチすること、そしてその後はユニットエコノミクスを健全化することがPMFへ至る道です。
ユニットエコノミクスとは、顧客1人あたりの採算性を示す指標のことです。具体的には、顧客1人あたりの生涯価値(LTV)と顧客獲得コスト(CAC)の差で定義されます。
『新規事業の実践論』5では、それぞれのメトリクスを以下のように定義しています。
| メトリクス | 意味 |
|---|---|
| LTV (Life Time Value) | 一顧客が、最初の接触時点から、関係性が継続する限りの期間にもたらす利益の総額 |
| CAC (Customer Acquisition Cost) | 一顧客を獲得するのに要した営業およびマーケティングのトータルコスト |
ユニットエコノミクス
ユニットエコノミクスの成立に向けて「LTV ＞ CAC」の構造を作る(『イノベーションの再現性を高める 新規事業開発マネジメント──不確実性をコントロールする戦略・組織・実行』6より)
「LTV > CAC」ならば顧客が増えれば増えるほど利益が積み重なる構造になるため、顧客数拡大に邁進すれば良くなり、ユニットエコノミクスは健全といえます。従って、この状況に達するためには、LTVを高め、CACを下げなければなりません。
LTVを高めるには、事業から「お金を払ってよかった」いう体験を作り出すことが重要です。そしてそのためには、提供するサービス上での顧客の行動を観察した上で、顧客価値を向上させる仮説を立て、改善・改良を短いサイクルで積み重ねることが必要です。
新規事業開発のエンジニアリング
我々は、本書における「エンジニアリング」を以下のように定義しています7。
- Boost new business with technology (技術で新規事業開発をBoostする)
この定義に従い、新規事業開発のエンジニアリングについて以下にまとめています。
なお、先のステージ・ゲートプロセスにマッピングすると以下のような形となります。
ステージ・ゲートプロセスのエンジニアリング
2つのフェーズの考え方
不確実性の海の中を泳いでいく新規事業開発のエンジニアリングでは、検証された学び (Validated Learning)を積み重ねていくことになります。
限りある時間と予算の中で多くの仮説検証サイクルを回さなければ、学びを得られないまま、ユーザーの求めないものを作り続けてしまうことにもなりかねません。
繰り返しになりますが、私たちは、新規事業開発が大きく以下の2つのフェーズに大別されると考えています。
- 事業仮説を構成する「顧客」「課題」「ソリューション」を”探索し検証”するフェーズ
- 実際に事業を”ローンチさせ、ユニットエコノミクスを健全化”するフェーズ
それぞれのフェーズの目的は明確に異なるため、異なるエンジニアリングが必要になります。
事業仮説の探索と検証
このフェーズで行うことを一言で表現すると、「事業の進むべき方向を決める」です。
「顧客」「課題」「ソリューション」
仮説検証によってこれらの問いへの確度と解像度を高めていかねばなりません。そして、MVPによって確かに顧客が存在し、ソリューションによって課題が解決され、お金を支払ってもらえることを検証します。
これらの検証は、仮説を形にし、顧客のところに持っていき、顧客の反応に応じて仮説を修正…というサイクルをひたすら回すことによってのみ行えます。有限の時間とコストの中で、不確実性を下げ、プロダクトの解像度を上げていくためには、この仮説検証サイクルを高速に回す必要があります。
私たちの行うエンジニアリングも、この高速な仮説検証サイクルを支えていかなければなりません。
つまり、「如何にして顧客のフィードバックを得られるアウトプットを素早く作り上げるか」が求められます。
また、顧客からフィードバックを得ることによって、顧客課題を解決するソリューションはどんどん変わっていきます。したがって、このフェーズのエンジニアリングには以下の事柄が求められます。
エンジニアリングに求められるもの
このようなエンジニアリングを行うためには、エンジニアには「作る」だけでなく、「使う」ための知識も必要でしょう。
- アイデアを受けて、顧客の反応を得られる形にアウトプットする力 (プロトタイピング力)
- 特定の機能を提供してくれる外部サービスやOSSプロダクトの理解とその選択のための審美眼
- それらサービスを利用するための技術的知識、ライセンスの知識
- インフラを所有することなくサービスを構築できるクラウドアーキテクティング力、実装力
本フェーズではこれらを総動員し、仮説検証のためのプロダクトを素早く形にしなければなりません。
試行錯誤を繰り返し、作るものも頻繁に変わる中でのエンジニアリングが前提となるため、多くの場合は作り直しを余儀なくされます。このため、「保守性 (Maintainability)」は切り捨てても構わないと考えています。
その先に、「顧客」の「課題」を解決できる価値ある「ソリューション」が見定められるはずです。
ローンチとユニットエコノミクスの健全化
MVPのような「実験」をするプロジェクトではなくなり、ビジネスとして収益を追い求めるフェーズです。
この後にエンジニアが行わなければならないことは、以下になるでしょう。
- 事業(サービス)を素早く市場に展開するための高速なサービス開発の計画と実行
- サービスのブラッシュアップと、フィードバックに基づく迅速な機能追加やUX改善
- 顧客数の拡大に耐えられるようなサービスのスケーリング
このフェーズにおいては、課題を解決するソリューションは定まっていますが、最初から「詳細な要件」が定義できるわけではありません。
ローンチする前においても、自分たちが作ったものから自分たち自身が学びを得ることで作るべきものも変わっていきますし、
それに対する素早い適応が求められます。ローンチ後もユーザーの反応をみながらプロダクトを進化させねばなりません。
プロダクトを高速に「進化」させること、それが本フェーズのエンジニアリングには求められます。
本書で扱う技術
我々は多様化する技術の中から、適切な技術を選定しなければなりません。
新規事業開発のエンジニアリングにおいて、使用すべき技術は何でしょうか。
我々は以下の技術スタックを選定しました。
アーキテクチャ
新規事業開発においては、ユーザー数やトラフィック量が予測し難いものです。
このため、基本的には「使われた分」だけ課金されるようなアーキテクチャが望ましいでしょう。
事業アイデアが技術的な制約を課さない場合、我々はSPA+REST APIでのサーバーレスアーキテクチャを基本に考えています。
もちろん事業ごとに細部は異なるでしょうが、AWS上で実現するときは以下のようなアーキテクチャ8になるでしょう。
REST APIを提供するバックエンドを含めサーバーレスアーキテクチャを前提とすると「使われた分」だけ費用が生じる形のアーキテクチャが実現できます。
一方で、API仕様が複雑になりそうなら、Amazon ECS (ECS)を利用してAPIを構築します。
基本アーキテクチャ
プロトタイピング
プロトタイピングツールについてはFigmaを利用します。
クラウドインフラ
上記のアーキテクチャ図からもわかるように、我々の新規事業開発ではクラウドサービスとしてAWSを利用します。
また、Infrastructure as Code (IAC)のツールとしてはTerraformを使用します。
これは、習熟している開発者が多いことと、DevOps環境構築キット Eponaで両者をサポートしているためです。
言語
言語としては、型の存在による生産性の向上と安全性の確保のため、JavaとTypeScriptを選択しました。
| 言語 | 理由 |
|---|---|
| Java | ・習熟している開発者が多い言語である ・エコシステムが充実しており、フレームワーク・ライブラリ等も充実している ・静的型付けのため、開発効率が上がりやすい |
| TypeScript | ・フロントエンドアプリケーションはJavaScriptが必須となるが、それに対して静的型付けを提供してくれ、開発効率が上がりやすい |
フレームワーク
| フレームワーク | 主な利用場所 | 理由 |
|---|---|---|
| Nablarch | バックエンド | ・後方互換性が保証されるとともにセキュリティも強固であり、事業価値とは必ずしも関係しないアップデートに関する負荷が少ない ※ただし、Nablarchが事業で必要なクラウドサービス等とのインテグレーションや処理方式に対応していない場合は、Spring Frameworkも検討する |
| React | フロントエンド | ・自社内で経験者が多い ・対応するUIライブラリが豊富にある |
| React Native | モバイル | ・Reactの知見を転用できる ・クロスプラットフォーム対応のため、Android、iOSの双方に対応できる |
VCS Provider
VCS Providerとしては、GitLabを使用します。
技術の選定基準
なぜ上記のような技術スタックを選定するに至ったのかは、以下の3つの基準に依ります。
- 利用する技術の数を少なくすべき
- 作らないエンジニアリングを支援できる
- インフラを所有しない
利用する技術の数
さまざまな分野の事業開発に取り組みながら組織学習をしようと思うと、扱う技術の数は少数に抑えるべきです。これにより、特定技術に関する知識を、組織の中で共有・応用できるようになります。
例えばプログラミング言語などはその良い例で、新規事業開発に取り組む組織の中でよく使われている言語を選択すると、組織から技術的なサポートも得られやすくなります。
また、本章の冒頭で述べたように新規事業開発では2つのフェーズがあり、それぞれで求められるエンジニアリングが異なります。
その異なるエンジニアリングにおいても技術は「使いまわせる」方が学習効率も良いでしょう。
2種類のエンジニアリング
| フェーズ | 求められるエンジニアリング |
|---|---|
| 事業仮説の探索と検証 | 事業仮説に対する高速・高頻度の検証のためのエンジニアリング |
| ローンチとユニットエコノミクスの健全化 | 事業の高速な展開・成長のためのエンジニアリング |
作らないエンジニアリングを支援できる
事業には、競争力のコアとなる箇所と、競争力のコアではないが事業を成立させるために必要な箇所があります。
「競争力のコアとなる箇所」は、市場競争にさらされながら生き残っていくために頻繁な改善が必要となる一方で、
「競争力のコアとならない箇所」は変化することも少ないでしょう。そして、このような「コアとならない箇所」には、利用できる外部サービスやOSSプロダクトが多くあります。
例えば、モニタリングSaaSであるDatadogやNew Relic、カスタマーサポート用SaaSであるZendeskなどはその一例でしょう。
変化することが少ない「競争力のコアとならない箇所」まで自分達で開発してしまうと、莫大な費用が必要になります。そのような不要な開発コストを避け「専門家」の構築したサービス品質を得るためには、それらを自分達で「作らず」、サービスを「つなぐ」ためのテクノロジーが必要になります。
つまり、「業界で多く使われているSaaSやOSS」を使うのに適したテクノロジーを選択すべきということになるでしょう。例えばSaaSがSDKを提供しているのであれば、そのSDKを利用できる言語を使う、といったことが考えられます。
インフラを所有しない
新規事業開発では仮説検証を繰り返すことになります。
その際、多くの場合においては、サーバーやネットワークが必要になるでしょう。
しかし、それらを所有していたのでは、大きな初期投資が必要になるとともに、その維持管理にも多大なコストが必要になります。
このため、いかにして「所有せずに済む」エンジニアリングを完徹できるかという点も重要になります。
その代表的な例がAmazon Web Services (AWS)や
Microsoft Azure (Azure)といったクラウドサービスの利用です。
クラウドサービスは、必要な時に必要なだけリソースを作成でき、破棄することも簡単です。
クラウドサービスには様々なアーキテクチャがありますが、その中でも注目したいのがサーバーレスアーキテクチャです。
実際にサーバーを用意する必要はなく、クラウド事業者が用意した環境上にユーザーがソースコードを配置することでアプリケーションを運用できます。
サーバーレスアーキテクチャの場合、アプリケーションが実行されている時間での課金になりますので、例えばWebアプリケーションでしたら、アクセスがあった時にだけアプリケーションの実行時間に応じて課金されます。アクセスがない時間は課金されません。
アプリケーションの規模にもよりますが、ユーザー数の読めない段階では多くの場合メリットを享受できるでしょう。常時起動が必要なサーバーと比べて費用がかからない上、サーバーOSの管理といった作業からも解放されます。
- 顧客1人あたりの採算性のこと。↩︎
- 麻生要一、『新規事業の実践論』、NewsPicksパブリッシング、2019。↩︎
- 麻生要一、『新規事業の実践論』、NewsPicksパブリッシング、2019。↩︎
- 田所雅之、『起業の科学-スタートアップサイエンス』、日経BP、2017。↩︎
- 麻生要一、『新規事業の実践論』、NewsPicksパブリッシング、2019。↩︎
- 北嶋貴朗、『イノベーションの再現性を高める 新規事業開発マネジメント 不確実性をコントロールする戦略・組織・実行』、日経BP、2021。↩︎
- 単純に「エンジニアリング」というとさまざまな定義があり、例えば、エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリングでは「エンジニアリング」を「曖昧さを減らし具体性・明確さを増やす行為」と定義しています。一方で本書の「エンジニアリング」を「不確実性を下げる行為」と定義してしまうと、新規事業開発そのものが「エンジニアリング」と同義となり焦点がぶれてしまうため、本定義を採用しました。↩︎
- Reactのロゴは、Creative Commons Attribution 4.0 Internationalで提供されているものを利用しています。↩︎
