目次
はじめに
ゼロイチで事業創る時に難しいのが、 「まず何からやれば良いんだっけ？」 状態になることです。
足りないことが多すぎて、どうタスク化してどう優先順位をつけるのかが難しい。
ということで、個人的な備忘録も兼ねて新規事業創りのプロセスをまとめてみました。
スタートアップの始め方になると人集めとか資金調達とかの話になるので、今回は事業創りにフォーカスしています。
新規事業作成プロセス
大きくまとめると以下の4つのプロセスが必要。
- 調査(Research)
- 戦略(Strategy)
- 設計(Design)
- 実行(Sprint)
特にエンジニア中心のプロダクト開発になると、前半の調査、戦略が疎かになりがちなので、コードを書きたい気持ちをグッと抑えて取り組む べし。
調査編(Research)
まずはその業界を深く理解すること。
事業の成否の9割はマーケットの場所と参入のタイミングで決まる。
市場の理解度と事業の解像度を上げること。
市場調査
まずは市場調査から。
- 市場規模を算出する
スタートアップでよく問題になるのが市場規模の考え方。
とはいえ慣れないうちはどれだけ数字を集めても結局えいや感になりがち。実際に市場に投入してみないと分からない部分も多々あるので数字として算出するのが難しい。
よく投資家向けの説明資料として使われるのがTAM/SAM/SOMという考え方。
市場を評価するための指標としてシンプルであり、事業(プロダクト)が将来どこに向かっていくのかを整理できるので少し時間をかけても作ってみると面白い。
Coral CapitalさんがTAM/SAM/SOMについて説明している。
TAM、SAM、SOMとは？ 市場規模の投資家への伝え方 | Coral Capital
coralcap.co- 競合を調査する
市場を定義できたら今度は競合となる企業について調査する。
新しい市場なので競合はいません、といった言葉を言いたくなる気持ちも分かるが、世の中に誰も競合がいないなんてことはまずありえない。
同じ課題を現在代替的に解決している企業やサービスがいるはずだし、直接ではなくても間接的に競合している場合もある。
競合分析については以下の記事を参考にして欲しい。
http://ykubot.com/2018/11/26/competitive-analysis/
また、海外の企業を調べるのであれば世界最大の企業データベースサービスであるCrunchBaseがよく使われる。
http://ykubot.com/2018/11/20/crunchbase/
Problem/Solution検証
そのサービスは本当に必要なのか？ を検証する。
アイデアそのものの検証はどれだけ時間をかけてもかけ過ぎることはない。書き出すとキリがないので重要なところだけ。
- 課題(Problem)の検証
まずは誰(Who)のどんな課題(What)をなぜ(Why)解決するのか？を明らかにするために課題(Problem)の検証を行う。
方法としては、市場調査やユーザーインタビューを通して定量・訂正的なファクト(事実)を集める。
現状明らかに困っているユーザがいる(ペインがわかりやすい)ケースなら簡単だが、ユーザ自身も気づいていない潜在的な課題もあるので、インタビューの仕方には注意したい。ユーザの言葉をそのまま鵜呑みにするのではなく、本質的なニーズを探る。
- 解決方法(Solution)の検証
次にその課題をどうやって解決するのか(How)？という解決方法(Solution)についての検証を行う。
検証可能な最低限の機能を備えたプロトタイプ(MVP)を作り、検証→改良しながら本当に課題を解決できる形を探る。
これらの検証はトライ＆エラーを繰り返し、確信が持てるレベルにまで磨き込む。
リーン・キャンバス(Lean Canvas)やバリュー・プロポジション・マップ(Value Propositon Map)といったフレームワークを使うとチーム内の共有もスムーズにでき、仮説検証が無駄なく実行することができるのでおすすめ。
ただし、フレームワークやツールはあくまで手段の一例に過ぎないのでその通りにやればうまくいくものでもない。結局どれだけ泥臭くやれるか が勝負だと思っている。
技術調査
- フィージビリティ（今の技術で実現可能かどうか）
ユーザに価値あるものを提供するためにどのような技術要素が必要か？それは実現可能か？そもそも現在の技術で実現できなければ事業として成り立たない。
- コアとなるテクノロジーは何か？今後5年でどう変わるか？
価値の源泉となるテクノロジーは何かを理解しておく。もしくはテクノロジーによってどれだけ事業にインパクトを与えられるのか？
そしてそのテクノロジーは今度どうなっていくのか？その進歩によって事業がどう変わっていくのか？を考えておく。
技術トレンドに関してマクロの予想をしているガートナーのハイプサイクルを参考にしてもいい。
https://www.gartner.com/jp/newsroom/press-releases/pr-20180822
https://www.gartner.com/jp/newsroom/press-releases/pr-20181011
https://www.gartner.com/jp/newsroom/press-releases/pr-20181031
リソース調査
事業を行うにあたって、チームのスキル、稼働（工数）、モチベーション、予算は確保できるのか？
- スキルセットおよび稼働(工数)
事業を成功させるためにどのようなスキルセットが必要か？社内でまかなえるか？もしまかなえないのであればどうやって調達するのか？
どれだけコミットできるメンバーが集められるか？ 兼務だとしたらどれだけスピード感が出せるか？ -
モチベーション
チームビルティングが出来ていないのなら早めに行う。
ゼロイチフェーズはチームメンバーのモチベーションが特に重要になってくる。
チームの事業に対するモチベーションは出来るだけ高い位置に置き、それを持続させなければならない。
キックオフという形でスタートを切っても良いし、事業の成功に結びついたOKRを設定する。ビジョン、ミッションを定義するワークショップするのも良い手だ。
事業の進捗をダッシュボードなどで共有しておける仕組みを作っても良い。
- 予算
これは完全に経営的なタスク。事業のP/Lを把握しておき、マイルストーンなどのスケジュールを組む。
逆算して初期から撤退戦略を検討しておくと、事業判断がスムーズにいくのでおすすめ。
無理だと思ったら早めに決断すること。
損切りのタイミングはとても大事。
戦略編(Strategy)
ビジネス戦略
事業タイプにもよるが、大抵の場合 スモールスタートを考える べき。
エリアが重要になる事業なら、都心の渋谷区、港区などエリアを絞って始めるべきだし、プラットフォーム系でも取り込むカテゴリーはなるべく絞った方が成功する確率は高い。
どこから展開すれば広がるか？ を中心に考える。
大抵最初のアイデアは失敗するので、早めにトライ＆エラーを繰り返す。
それでも突破できそうにないときは市場選択が誤っていないか？タイミングが間違っていないか？を自問自答する。
リスクマネジメント
事業的なリスクや課題を洗い出し、それぞれについてどうマネジメントしていくか考える。
以下は一例。
- 法律、規制的なリスクはないか？
今は大丈夫でも、将来的に規制される可能性はないか？もしあるなら事業を継続させていくためにどういう打ち手が考えられるか。
例えば、仮想通貨や新しいモビリティといったサービスは前例がなく革新的ではあるが法整備が追いつかず、社会的にネガティブな側面が取りざたされやすい。
そこで 国や業界などを巻き込んで議論を重ねながら進める 必要がある。また社会的な雰囲気づくりにも注力したい。 -
技術的リスクは？
ユーザに十分な価値を提供するまでにどんな技術的ハードルがあるか？
ユーザの個人情報を保有する場合、セキュリティ対策などの優先順位を上げる必要がある。 -
大企業や競合スタートアップが参入してくる可能性はあるか？
他社の資本が入ってくるのであれば、早めにアライアンスを組むか、資金調達の必要性が出てくる。 -
他社のプラットフォームに依存していないか？
昔Facebook、Twitterアカウントありきのサービスが流行ったが、プラットフォーマーの規約の変更でサービスの撤退を余儀なくされたケースがかなりあった。
プラットフォームに乗っかると時間とコストが抑えられる反面、リスクについても考えておく必要がある。
リスクは考えだすときりがないが、それでも 常に考えながら検討しておく。
UX戦略
このあたりはものづくりの範囲になってくるが、まずは ユーザ体験を中心に考える。
コアとなるUXは何か？競合との違いは？
どういった心理でユーザはこのサービスを使う？を深く定義する。
UX戦略という言葉にあまり馴染みがなければ以下の書籍がおすすめ。
テクニックというよりも、考え方やプロセスについて事例を中心に紹介されているのですぐ行動に移せやすくなっている。
このタイミングでブランディングもからめてしっかり定義できていると、後々PRやマーケティングなどの展開がしやすくなる。
技術戦略
技術が競合優位性となるのであれば中・長期的に投資すべき。
技術的に高いところを目指すのであればどうステップを置いて登っていくか、十分議論を尽くしてロードマップを引く。
リソース戦略
ヒト・モノ・カネをどう集めて配置するか。
D2CやIoTなど、Webで完結しない物理的なモノが必要な事業であれば戦略の中心になってくる。
調達コスト、在庫コストなど、考えることはとても多い。キャッシュフロー的な観点も必要になってくるから経営に近い。
またビジネスモデル次第で最適な組織の形も変わってくるため、どのフェーズでどのようなリソース(組織)が必要か中・長期的に検討する。
例えば、業界特化のSaaS型事業であるならバックグラウンドが業界と関係のある人をセールスチームに加えるなど。
撤退戦略
損切り大事(2回目)。
ロードマップやマイルストーンに対してランニングコストを引いて、どのポイントまで走れるかを計算する。
重要なマイルストーンを置いて、それがクリアできないことを条件に加えるのもよし。
可能ならば チームにオープンにしておくと透明性が上がり、モチベーション向上にもつながる のでおすすめ。
設計編(Design)
ここからはより具体的なアウトプットを生み出していくフェーズ。
ビジネス、デザイン、技術的な設計(Design)を相互に連携させながら組み立てていく。
ビジネス的な設計
事業のステークホルダーは誰で、どこから収益を得るのか？顧客は誰になるかを設計する。
パイプライン型か2サイドプラットフォームか、B2B/B2C/B2B2Cかなど、商流を組み立てる。
デザイン的な設計
- UX設計
ペルソナ、カスタマージャーニーマップなどのツールを使ってユーザを理解して機能に落とし込む。
画面やアクションのデザインは、ワイヤーフレームやインタラクション型のプロトタイピングツールなどを使用する。
技術的な設計
設計フェーズはチームによってまちまちだが、ゼロイチフェーズだとまずはチーム内で共有できていればいいのであまり設計書にリソースは割かない。（もちろんケースバイケース）
- アーキテクチャ設計
まずはプロダクトの全体の構成を設計する。クライアント側（Web/Mobile）、サーバサイド側などのアプリケーション設計からインフラまで。
IoT系ならハードウェアの設計も必要。 -
技術選定
事業やプロダクトの要件などから技術を選定する。チームの状況や方針なども考慮する。
初期のフェーズはスピード重視なので、学習コストとのバランスをとらなければならないこともある。
実行編(Sprint)
実際にPMF(Product Market Fit)を目指していくために、どういうプロセスでプロジェクトを進めるのか方針を決める。
実行に関してはたくさん手法やツールが存在するため、詳しくは説明しない。
また、組織の状況によっても変わってくるので、ここではゼロイチのチームを回すときに最低限考えたいことについて触れる。
- ロードマップおよびマイルストーンの設定
プロダクトロードマップ、開発ロードマップなど、チームや事業の進捗を適切に管理できるように最終的な目的地とそこに至るまでの目標を設定する。 -
スプリント計画
開発→検証のサイクルをできるだけ短いバッチで回していくために、スプリント計画を立てる。
フェーズによって巻き込む部署(開発、デザイン、CS、マーケティング、セールス)が変わってくるので柔軟に計画していくことが重要。
スクラムやアジャイルなど、様々な方法論があるのでチームに合った形を探す。 -
タスクの洗い出し、見積もり、アサインなど
JiraやTrelloなどでタスクの担当と進捗を管理。
様々なツールや手法があるが、重要な観点はプロジェクトの異常（ボトルネックになっているところ）をチームがいち早く察知できること。
実行に関してもそうだが、当然絶対的な解はない。試行錯誤して見つけていくしか方法は無い。
ただ重要視したいのは、事業についてどうやって学んでいくのか という視点で考えること。そしてチームや業務フローをどう設計していくべきかを考える。
最後に
最近だとリーン・スタートアップを始めとして、課題・ソリューションの仮説検証については浸透してきたように思います。
しかし一方、高い視点から俯瞰して事業を検証するということにはあまり触れられていません。
スタートアップの文脈だと まずやってみるが強調されてしまいがち なので調査や戦略が後回しにされてしまう雰囲気があると思います。
実行が重要なのは間違いありませんが、だからと言って何も考えずに前進してもどこかで行き詰まってしまいます。
重要なのは 走りながら考え続ける ということなので、今回は調査、戦略の方を厚めに説明しました。
自分自身いくつか事業創りにチャレンジしてきて、今現在(2019年)これらの観点(プロセス)が重要だな、という考えに至っているだけなので将来は変わってるかもしれません。
むしろ将来どう変わっているのか楽しみでもあります。
全然違うこと言ってる気がしますが笑
もし誰かの参考になったら幸いです。