LEAN思考を学びながらビジネスモデルの価値検証にチャレンジ

＊この記事は2021年10月にnoteで書かれた内容を一部改訂しています

こんにちは。
LabBase（旧 株式会社POL）でコミュニケーションデザイン領域のアートディレクションをしている小田切です。
最近どんなことをしているか？というと、半分ぐらいは新規事業部でビジネスモデルの価値検証に関わっていて、もう半分はLabBaseのマーケティング領域や他の新規事業、コーポレートなどを含めたコミュニケーションデザイン全般のアートディレクターをしています。

さて、今回は個人的に大好きなリーンスタートアップの考え方をベースに、所属する新規事業部でおこなわれているBtoBビジネスモデルの価値検証に取り組んだことを書いていきます。リーンというとtoCサービスでの活用が一般的と思いますが、スタートアップのBtoB事業で適応させるためにどんな工夫をしたか？
この辺りの学びを書いてみました。

［ちなみにこの新規事業は現在進行形で動いているため詳細な情報は乗せられず、リーンの学びと実際の価値検証を進める中で使用したナレッジを紹介しています。］

なぜリーン思考を学び仕事に活かしたいと思ったか？

UIデザイナーやPdMをされる方などは存在を知ってることも多いと思いますが「UXの５階層モデル」というものがあります。プロダクトデザインのUXを考える時に用いられたり、更にはより広くWeb戦略を定める上でも活用されますが、実は「デザイナーのキャリアを考える上でもとても役立つな」と思っています。
ちなみに原点はJesse James Garrentt の「The Elements of User Experiene」、「JJGの5階層モデル」などと呼ばれるようです。

まずはこの5階層モデルを理解してみましょう。
まず1番上の表層はみなさんが目にするUI(ビジュアル)のデザインです。そこから情報設計（IAやwebだとワイヤーフレーム）、さらに仕様・要件と遡り1番底はそのプロダクト（サービス）の戦略になるというわけです。5階層モデルについて詳しく知りたい方はUX TIMESさんの記事を参考にされると良いでしょう。

この5階層モデルを見て、当時UI/UXデザイナーをしていた僕は「戦略の更に前でもデザイナーが活躍できることはないか？」と思ったわけです。
なぜなら自分がプロダクトのデザイナーとしてユーザーに分かりやすい導線、情報設計などをいくら考えて実装されても、サービス自体がユーザーにとってニーズがないものだったら何も意味がない。ということは、そもそもサービスの価値が存在するか？を知ることから関わることができたら、ユーザーが本当に求めてる価値のあるプロダクトに携わることができる。「5階層を超えた0→1のデザイナーになろう！」と思ったわけです。そしてこの0→1とはビジネスが生まれる場所、つまり新規事業開発になると考えました。

しかし言うは易しで、今までデザイナーというある意味守られたポジションにいた自分が、事業開発という別領域に入っていくのでデザインという武器は使えないし、コミュニケーション下手の僕にとっては困難なことも多かったです。ドラクエで言うとLv35ぐらいでそんな困ることなく冒険（デザインワーク）をしていた状態から一気にLv3ぐらいに戻る、けど敵の強さは変わらないような怖さやを感じました..

ビジネスモデル検証のUXリサーチャー

新たな武器として学び始めたのがリーンベースの新規事業開発における価値検証のメソッドです。使う技術は職種で言うとUXリサーチャーになりますが、通常は既にリリースされたプロダクトの改善にユーザーの体験価値を検証することが多いでしょう。

ただ僕の場合は既にリリースされたプロダクトより「これから世に出したいと思うビジネスアイデアの種」レベルからユーザーの反応を知り、プロダクトリリースするべきか？の分析や検証をおこないたいと思っていました。そして社内の色々なところでそのことを公言してるうちに、新規事業開発をおこなう部署でチャレンジをさせてもらえる機会を得られ、（結構レアなケースだと思うのですが）UXリサーチャーとしてビジネスモデルの検証に取り組めることとなりました。チャレンジさせてくれたことに大きな感謝です。

さて、ここからようやく本題っぽくなっていきます。
ビジネスの価値検証ってどうするの？という話です。

そのビジネスアイデアにユーザー（orカスタマー）がいるか？

よく混ざりがちなのが「デザイン思考」ですが、これはイケてるビジネスアイデアを思いつく思考法のため、今回は割愛します。よって、アイデアがある前提からのスタート。

目的は「渾身のビジネスアイデアって本当に使ってくれるユーザーがいるのか？」これを検証しましょうということです。
ちなみにエリックリース著書の「リーンスタートアップ」で定義されている。

［ムダのない起業プロセスでイノベーションを生み出す］

思い込みだけでいきなりプロダクトを作らない。コストと時間をかけずに最低限のプロトタイプをペルソナユーザー（orカスタマー）に試してもらい反応を知る。試した結果、一定の割合でお金を払ってもそのプロダクトを使いたいと思えるか？を検証をすることです。

僕が所属する新規事業チームで新たなビジネスモデルの検証をおこなうことになったので、前職から活用していたリーンの考え方を持ち込み実際にユーザーインタビューや学びの評価などに取り組んでいきました。
モデルとして、BtoB向けサービスのマッチングビジネスを例に書いていきます。

1. LEANでの検証プロセスをモデル図化

お作法通り全てフレームワークに沿ってやるわけではないが、リーンの検証方法をベースとし、ビジネスアイデアの価値検証を進めようと始めました。

Twitter,facebook,Instagram,AirB,Uber,Dropboxなど、市場をディスラプト（破壊）できるレベルのスタートアップ（短期間で急成長を遂げた企業）が、ビジネスアイデアの価値が本当に間違ってないか？を確かめる検証の方法。いわば企業の科学です。

もちろん、このリーン通りにやれば成功できるわけではない（今の市場スピードにあってるかの懸念も）ので、リーンをベースにしつつも、カスタマイズし自分たちにあったやり方を模索する必要があります。

2. リーンでの検証フローにならいCPFからはじめる

図のCPF（CustomerProblemFit）、PSF（ProblemSolutionFit）を注力して行う。

CPF＝ペルソナとなるユーザー/企業に自分たちがあると思っていた問題が本当にあるか？ PSF＝CPFで明らかになった問題の最適な解決策は何か？それが正しいかを確かめていきます。

CPF,PSFを達成する指標

リーン検証ではユーザー/企業に対してインタビューで答えてもらった回答の割合が判断基準になる。人数の制限は1ターム60%以上（10人中6人以上）が有効な課題の質問に対してYesと言えば一旦見込みはあると判断し、より精度の高い質問をしビジネスアイデアの成功確度を高めていきます。

僕たちのチームでは、インタビュイー人数を集める（インタビューで人を集めることを総称してリクルーティングと呼ぶ）ことも労力がかかり時間も伸びるので、課題によっては、質問に対してYes回答が早い段階で全体の3/4からの良い回答が得られれば先に進むカスタマイズをしました。

活用するフレームワーク

リーンの検証を進める順番と使用したフレームワークを紹介します。

1. LEAN CANVAS

事業アイデアの価値検証を進める上で1番最初につくるもの。

その事業アイデアがなぜやる価値あるか？を判断する。ユーザー/企業の課題と解決策、チャネルやマネタイズまでを1枚にまとめたシート。すべての検証の土台になり、ペライチの事業計画書のようなもの。

2. ペルソナ設定と行動分析

ペルソナがどんな人物なのか？分析をするためにPOEMSというフレームワークをカスタマイズしました。

toBサービスの場合、toCと異なりビジネスの中での「ボトルネック」と「理想の状態」があると考えます。業務のプロセスがいくつかある中で
・どんな業務フローなのか
・何のタスク（業務）で課題が発生するのか
・課題が発生した時に関わる人物
・ペルソナがその時に使っているサービスとその仕様はどんなものか
などをマッピングで簡易にわかるようにします。
これをmiroというツールを使いメンバー内で共有しながら分析を行うことで、個人がテキストで所感を書いて考えるよりも集合知を得られながら客観的に分析もしやすくなるのです。

3. ジャベリンボード

ジャベリンボード ・ジャベリンボードは仮説の設定と検証のフレームワーク・リーンキャンバスで固まった事業アイデアを、CPF（課題が本当にあるか？）,PSF（自分たちの提案する解決策は正しいか？）として課題設定するためのシート。またこのジャベリンボード をもとにユーザー（カスタマー）インタビュー設計をする。

ジャベリンボードで仮説設定し、検証できること
・ユーザー（カスタマー）は誰か？ ＊ジャベリンボード を作成する前にペルソナを定める
＊ちなみにこの時点までにペルソナを設定しておく必要がある
・何に困っているか？（対価を払ってでも解決したい課題か）
・ユーザー（カスタマー）が抱える課題の解決策は何で？それは対価を払ってでも採用したいか？
・影響度の高い質問＝この前提が間違ってたらその事業アイデアはそもそも成り立たないレベルのリスク高い質問。
例）業務の上での困りごとをある程度マスクかけながらも外部に出すことが会社の規定的に可能か？

ポイント
・まず影響度の高い仮説を決めて、優先度高く検証する。「ここが成り立たないと他の検証項目が意味なくなる！」というクリティカルな仮説が必ずあるはずです。

4. ユーザー（カスタマー）インタビューの実施

ジャベリンボードで仮説課題/解決策のセットを決めたら、その仮説があってるか？実際にユーザー（カスタマー）にインタビューをして検証をします。

・インタビューでは、ジャベリンボードで検証すると決めた内容をしっかり聞ける設計になっているか？誤解されやすい聞き方がないか？などを考え、内容の設計をする
・tips インタビューをするとペルソナでないケースもあるので最初の方で確認する。ペルソナでない場合は早めに質問を終える。
・NG：「●●の情報収集をしますか？」「します！」→「どんな方法で？」「技術ワードをネット検索で…」→沢山答えてもらったが、このユーザーは製品購入の目的ではなく、自分の勉強のために情報収集をしていたのでペルソナではなかった。
・OK：「情報収集します？」「します！」→「それはどんな目的でしますか？」「製品導入のため■■■をみます」・・・
上記のように購買目的でない人からどれだけ精度高く情報を得ても、ペルソナが違うので適したソリューションアイデアを出しても意味がなくなってしまいます。

インタビュー結果の分析（KA法）- 仮説は正しかったか？-
インタビューの結果はKA法という分析シートを用いて（内容をカスタマイズ）分析を行います。

KA法シートに記載する内容とその理由
・出来事：ユーザー（カスタマー）にとって困りごとがあると思えたエピソードを抜き出す。
・具体的に状況を理解し、困っていること（以下から課題と呼ぶ）の理解や解決策のヒントにする。
・ボトルネック：何が課題か？
・業務を進める上での困りごとを抽出し、解決策を導くヒントにする
・望む価値：課題を解決できる具体策を出す
・参考のカテゴリ：課題のタイプをラベル付け
・インタビュー結果を一覧で見たときに、どのタイプが多いかをすぐに判別できる。
・KA法で課題をグルーピングできたら、以下のようなマトリクスのあるシート上にプロットし、課題の深さや解決策に結びつくか？判別していく。

Miroやfigjamなどでマトリクスに並べ替えて、さらに課題と解決策の磨き込みをします。

ここまでのまとめ
まずインタビューベースでのCPFとPSFが達成を目指します。
課題の有無、解決策の検証結果に応じてビジネスアイデアの方向性を、より実現可能性があり且つスケーラブルなものにできることを目指します。

2. リーンでの検証プロセス_MVP

インタビュー上ではユーザー（カスタマー）の仮説課題が実際にあること、またその解決策の有効性が証明できたとします。ただあくまで口頭レベルの事なので事業として大きく投資するのは怖い。そこでMVP（Minimum Viable Product）を直接ユーザーに試してもらい、検証の精度をより高めていきます。

MVPとは？

MVPとは、顧客のニーズを満たす最小限のプロダクトです。
MVP（Minimum Viable Product）とは、顧客に価値を提供できる最小限のプロダクトのことを指します。完璧な製品・サービスを目指すのではなく、顧客が抱える課題を解決できる最低限の状態で提供します。提供後は、顧客からのフィードバックなどを参考にし、新機能の追加や改善点の見直しを図ります。
MVPを作る目的は、想定しているプロダクトの検証です。
「顧客に価値を提供できる完璧なプロダクトができた！」と思っても、実際に市場に出るまではそのプロダクトが本当に顧客に価値を提供できるのかはわかりません。
そこで、MVPを作るのです。
MVPを作って一度市場にリリースすれば顧客の反応が伺え、その反応をもとに自身の想定は正しかったのか検証することができます。
そして顧客の反応に応じた改善を繰り返すことによって、より顧客のニーズを満たしたプロダクトの完成に繋がるのです。
また、MVPを作れば、最適なプロダクト作成に費やす時間・コストを削減できます。
本来、1つのプ ロダクトを作る場合は、計画段階から市場にリリースするまで膨大な時間とコストが必要です。もしプロダクトリリース後に大幅な修正点が浮上したら、費やした時間とコストが無駄になってしまいます。
しかし、MVPは必要最小限の状態でリリースするので、時間とコストはそれほどかかりません。
さらに、顧客からの反応をもとにプロダクトの根本的問題を早く発見することも可能です。
参照元 MVP（Minimum Viable Product）とは？MVPのつくりかたは？

流れに沿って書くと、
1. CPF,PSFがインタビューレベルで確認できた
2. そのPSF内容を実際に使えるカタチでユーザー利用してくれるか？を検証する。
という流れとなります。

MVPキャンバス

MVP検証で「優先的検証する仮説は何か？」「（どんな方法で）検証して何を明確にしたいか？」などを明確にするためMVPキャンバスを用意します。

作り方はリーンキャンバスと同じ考え方で、MVP検証から「優先的検証する仮説は何か？」「（どんな方法で）検証して何を明確にしたいか？」などを明確にしておくためのシートです。

どうやってMVPを作るか？

・原則MVPは必要最低限の工数（ものにもよるが1,2日-1週間以内程度）で、事業アイデアの有効性を確かめる手法。
・ユーザーがよく接するチャネル、試してくれそうな方法を知る必要がある。
・且つ自分たちが負担のなくでき、しっかりと得たい検証の結果も得られるという条件のもと（そんな都合の良いものあるか？と思いつつ。。）何をどう作るか決める。

MVPの検証とリリースに向けて

ここから先はMVPをペルソナに定めたユーザー/カスタマーに体験してもらい「本当にサービス登録してもらえるか？」「利用料金を払って頂けるか？」の評価に移っていきます。

今回の記事内容はMVPを作るところまででとしますが、この後のフェーズでは「MVP検証の結果の評価」を受けて「ユーザー登録率などどんな指標でビジネスモデルを成功とみなすのか？」＝PMF達成を目指すフェーズに入っていきます。
そしてPMF達成を果たせたMVPプロダクトのみがサービスローンチを迎えられるのですが、まだまだ検証の道は続くと考えています。次回この続きを書ける時にはまた新たな学びがきっとあるはずなので、またの投稿までを楽しみにして頂けるとうれしいです。