テスティングビジネスアイデアの小さな実践の感想
ビジネスモデルキャンパスを作った人が書いている、ビジネスモデルの検証方法について「ビジネスアイデア・テスト（Testing Business Idea)」の日本語書籍が発売されたので、つまみ食いしてみました！
私が担当したクラウド会計システムを例に所感を述べたいと思います！
MoneyForward Kyoto Advent Calendar 2020の15日目の記事です。
私もこの記事で今年分終わりだ！！
今回ご紹介する書籍はこちらです。
ビジネスアイデア・テストとは
新規事業を検討する際に「ビジネスモデル・キャンバス」という有名なフレームワークがあるのはご存知でしょうか？そのフレームワークを作ったAlexander Osterwalder(アレックス・オスターワルダー)さんが、そのフレームワークの内容を検証する方法論について書いてあるのがこの書籍になります。
ビジネスモデルキャンパスをうーんうーんと唸りながら書いたとします。実際に事業を始めるとそのビジネスモデル通りになることなんて100%ないと思います。様々なPDCAサイクルを回しながらProduct Market Fit -> Go to Marketと通じてプロダクトは成長していきます。
ふと振り返ったときに最初のビジネスモデルと完全に一致する事はないでしょう。ではその差分を追いかける時に我々は何をすればいいのか？
それを明らかにする為の書籍が「ビジネスアイデア・テスト」です。
Alexander Osterwalder(アレックス・オスターワルダー)は他にもstrategyzer社でCanvasを公開しています。興味があれば見てみてください。
https://www.strategyzer.com/canvas
ビジネスアイデアテストの流れ
ビジネスアイデアの種があったとして、それを成功に導くにはユーザーにヒアリングしたり、A/Bテストをしたり、広告を出してみたり色々なアクションをすると思います。
それは○○をするとうまくいくかもしれない。という仮説を元に検証サイクルを回している事と同義かと思います。
その仮説を生み出し、整理し、着手していくサイクルをこの本では説明しています。本をまとめるとこんな感じです。
1. ビジネスモデルキャンパスを書く。
あなたが思い描いているビジネスを書き出してみてください。
チームでやっているなら複数人でブレストする方が様々な目線が入って良いと思います。
会計システムの場合は BtoBのサービスでしたので「Customer Segment」は 「Market Segment」と「User Role」の2つを書きました。
User Roleがある事で複数のロールに対して価値を提供する場合の情報整理が簡単になります。「IPO企業」(Market Segment) ×「経理部」「監査役」「経理部長」(Role)みたいな感じで書きます。
2. バリュープロポジションキャンバスをカスタマーセグメント毎に沢山作る。
バリュー・プロポジションは、そのカスタマーのジョブにおいて発生している問題、又はより良く出来る事が想像しているビジネスで解決できるのか？を整理するフレームワークです。"ジョブ(顧客のしたい事)" が大事です。ジョブ理論とも通じる所がありますね。
そのジョブで起きているPain/Gainを カスタマーセグメント毎に作っていきます。私の場合は Market Segment × Role で分けましたので人の顔の所に「Role」を書いたポスト・イットを貼っています。
これは同じシステムを作ってもRoleによってバリューやジョブが違う為に別々に作る事で情報を整理していきます。このキャンバスの目的は正しさよりも把握や想像が大事だと思います。
バリュープロポジションではまず、顧客の成し遂げたい事 ( = ジョブ ) を複数書きます。これは自分達がアプローチしようとしている課題が発生しているジョブを書きだすイメージです。同じドメインであれば何個も書いてみてもいいのではないでしょうか。
例えば会計システムの場合は、「仕訳を登録する」というジョブでもいいし「決算を締めて公知する」みたいなジョブでもいいと思います。そのRoleが行う仕事を書き出しましょう。既存の業務がある場合は先に現状のUSM (ユーザーストーリーマッピング)をやってみてもいいかもですね。(USMをやるとRoleが増えたりもします。情報が増えるのは良いことです。)
次にその仕事において発生しているPain/Gainを書き出します。例えば紙が多くて辛い = Pain、AIが自動で仕訳してくれる = Gain みたいな感じです。
最後に、今から作ろうとしているシステムは何を提供するのか(価値や機能)を書き出して、それはPain/Gainをどの様に加速 or 解決するのか、Pain/Gainと紐づく様に張り出していきました。
例えば紙が多くて辛い = スキャンするとOCRしてくれる = 嫌な事を減らす
AIが自動で仕訳してくれる = もっと精度を上げる = より嬉しさが増す
みたいな感じです。
これで現在のジョブと未来のジョブについて解像度が少し上がった気がします。(ここまで来るとランディングページや広告につかうキーワードが出そろっていたりします！便利！)
3. (1)と(2)の周りに仮説や想う所を沢山貼ります。
( ※ここからは実践途中なので、想像で書いています。)
一通り書き出した所で、これを作るぞー！と作っていってもいいわけですが
考えている暗黙知が沢山あると思いますので、それをダンプしつつ、それら全ては仮説に過ぎないので検証を行っていきます。
例えば先程の例で、「AIが自動で仕訳してくれる = もっと精度を上げる = より嬉しさが増す」と書きましたが本当でしょうか？前提として「200~500件/月の仕訳がある会社では。」とか前提がついたりすると思います。それらは仮説なのでこのキャンバスに貼っていくのです。
「1000件/月の仕訳を扱う企業にとってはAIが自動で仕訳すると最高に嬉しいはず。少ないと価値は薄い。」みたいな仮説。
他にも、「この機能があれば単価がxx円高められると思う」と仮説を持つとします。それもキャンバスに貼ると良いと思います。( ビジネスモデルキャンパスの "Revenue streams" 付近の仮説です。)
ビジネスモデルキャンパス、バリュープロポジションキャンバスの全てのエリアに対して仮説を張り出す事が可能です。
4. エビデンスの強さと、仮説を検証する重要度のマトリクスに展開します。
仮説を洗い出したら優先度をつけていきます。(このあたりまで来ると普段のスクラム開発みたいでイメージが湧きやすいですね。)
縦軸は重要度で横軸はエビデンスの強さです。
このマトリクスにプロットする事で、重要＆エビデンスが弱いものをあぶり出します。それが最も優先度が高くなります。
エビデンスの強さとは本にも書いてありますが、色んな検証方法によって得られるエビデンスには強さの違いがあるという事です。
既にユーザーヒアリングをしているという場合は、エビデンスはまぁまぁ強いでしょう。お金を払ってもらっている方がより強いエビデンスになります。エビデンスが弱いものは推測・仮説から飛びだつ事ができないので検証を行います。
5. エビデンスが弱くて、重要なモノから検証を行います。
ここからはスクラムな感じで。
エビデンスが弱くて重要なものから検証のサイクルに乗せていきます。
6. 検証方法を検討して検証します。
検証方法はいくつもあると思いますので、検証したい仮説毎に以下の様なカードを作って検証方法を決めていきます。
この書籍には検証方法が沢山乗っているので、そこから選ぶと良いでしょう！
検証方法を選ぶには
* かかるコスト
* 得られるエビデンスの強さ
という2点で違いが出るので、
早くて弱いエビデンスでいいのか、時間はかかるが強いエビデンスがいいのか、その間かを見極めながら検証方法を確定します。
検証が終わったらLearning Cardを書くことで得られた確証と反証を記録していきます。そして仮説が新たに生まれる場合は「3. (1)と(2)の周りに仮説や想う所を沢山貼ります。」から再度やっていく感じです。
この手法の魅力
この書籍で魅力に感じた点は2つです。
* ビジネスの仮説検証サイクルが属人性低く企画出来る所
* 仮説検証の歴史を記録として残せる所
* ビジネスの仮説検証サイクルが属人性低く企画出来る所
ビジネスや新規プロダクトを立ち上げる人の脳内やプロセスは非常に属人性が高いと感じていました。(スポットスポットで感覚的な判断や、言語化出来ていない経験的判断が沢山まざったりする)
新しくチャレンジするメンバーは何から手を付けるのか…時間がないにも関わらず手当り次第に手をつけて学習サイクルを回し始めるしか方法がなかった様に思います。手当り次第やるには、成功までのコストがかかったり、予定していた予算・期間で着地できない等の失敗の確率が上がってしまいます。
今回の手法ではビジネスモデルキャンパスから、実際の仮説検証サイクルをフレームワークを通じて回せる所に価値を感じました。
私がこのフレームワークで新規事業を立ち上げて成功した後、プロセス自体は引き継ぐ事が出来ます。また非常にプロセス自体は軽量です。
新規事業のレビューを通じても、今何をしているか可視化して説明する事ができるし、このボードを元に先輩プロダクトオーナーとディスカッションすることも可能なのではないか。と思った次第です。
可視性が高まる事でより多くの情報が集まり、より精度高く選択と集中が行える事。これをセンス以外の方法で強化出来る点は素晴らしいと思いました。
* 仮説検証の歴史を記録として残せる所
実際にプロダクト開発をすると多くのナレッジが時間と共に溜まってきます。それは仮説を裏付ける情報も沢山含まれていると思います。
まさに "経験値" です。
経験値はどうやって引き継いだり残したりすることができるのか。大きなテーマだと感じていました。もしこのプロセスでガンガン経験値を残しておく事ができれば、引き継ぐプロダクトオーナーや、新規に入ってくる開発メンバーにとって過去を追体験出来る最高の場所になるのではないか。と感じています！（ほんとうかな？）
まとめ
「ビジネスモデル・キャンバス」を作ったAlexander Osterwalder(アレックス・オスターワルダー)の、ビジネスを検証するフレームワークについて書いてある書籍についての学び記事でした。
ここ数年は属人性の低減をプロセスの中でどうやるか。というテーマが個人的にはホットです😁 もう少し実践してみたいと思います！
明日はインターン生の永田くんの パフォーマンスチューニングの記事の予定です！お楽しみに！
-----------------------------------------------------------------------
今年も本家アドベントカレンダーもやっています！
https://adventar.org/calendars/5401
京都アドベントカレンダーはこちらです。
https://adventar.org/calendars/5425
京都開発拠点では引き続き積極的に採用を行っております。ご応募お待ちしております！
マネーフォワード京都開発拠点
中途採用 | 株式会社マネーフォワード京都開発拠点
インターン | 株式会社マネーフォワード京都開発拠点