2023.06.14
こんにちは、ビジネスデザインチームの内田です。
この度、弊社mctの新サービスとして「プロトタイプ・サーキット -アイデアを高速でビジネスに-」をリリースいたしました。
今回リリースするプロトタイプ・サーキットは【１】Build: アイデア仮説の構築、【２】Measure: アイデアの実験や検証、【３】Learn: 検証のレビューと学習 という３ステップで構成されています。
サービスの詳細はこの「BUILD」「MEASURE」「LEARN」のステップに沿って5月31日からの連載ブログでお伝えしています。
プロトタイプ・サーキットに関するお問い合わせや資料請求などは、こちらからお気軽にご連絡ください。
| ＜Prototype-Circuit：ブログ連載予定＞ 第一弾：Build：仮説を素早く形にしよう（5/31から公開中） 第二弾：Measure：つくった仮説を検証しよう（6/4から公開中） 第三弾：Learn：検証結果から学びを得よう |
Learn：検証結果から学びを得よう
こんにちは、ビジネスデザインチームの内田です。
これまでの2回のブログでBuild、Measureについてご紹介してきましたが、今回はLearnについてです。
この記事では、仮説検証で得られた膨大なデータを分析し学びを得る、そして改善策を決める際に陥りがちな間違いについて触れながら、最後にさらなる検証にどう繋ぐかについてお話しします。
間違った学び方
どのような検証プロセスを辿るかはとても大事ですが、ただプロセスをなぞっていくだけで全てがうまくいくわけではありません。いざ検証リサーチを終えたのちに以下のような行動を取ってしまっていないか注意してください。
①「だってお客さんがこれがいいって言ったんですよ！」-顧客の声を鵜呑みにするな-
よく陥りがちな失敗として、インタビューで得た意見をそのまま改善に反映してしまうことが挙げられます。顧客の声を聞くことは大事です。しかし注意しなければならないのは、顧客の声が常に正しいというわけではない、ということです。
「意見」は嘘をつく、「事実」だけに耳を貸せ
（『Google×スタンフォード NO FLOP! 失敗できない人の失敗しない技術』より引用）
人は意図せず嘘をついてしまう
もし、何かアイデアを提示した時に「すごくいいと思います！」と言ってもらえたらあなたはどうするでしょうか？その結果に自信をつけて、「10人中8人が良いと言ってくれました！」とプレゼン資料に書いてしまいますか？
アイデアを提示して良い評価をされることは多々あります。ただ果たしてそのサービスが実際にリリースされた時、彼らは本当に買ってくれるのでしょうか？疑ってかからなければなりません。そういった嘘を見破り、本気度を測るための質問も存在するので、検証の質問設計の中にそれらを組み込んでおきましょう。
課題の重要度を測る質問：既存の代替手段
→本当に困っていると言う人は既に何かしら別の手段で解決しようとしているはず
例）本気でダイエットしたい人→既に「運動」「食事制限」などしているはず
あるいはインタビュー以外での検証としては、アイデアが固まっていればクラウドファンディングなどで実際に投資を募ってみるなどしてみるとリアルな反応が得られるかもしれません。
②「あんなに時間かけたのに…」-作り込みに夢中になるな-
検証活動の際に陥りがちなのが、しっかり準備して臨んだ方がより有益な意見が聞けるのでは、という誤解です。それによって準備に時間をかけすぎるにつれて段々と自分たちのアイデアへの固執が始まります。これらは検証の準備段階（Build）でうまくやっておけばいい話ですが、そこで間違ってしまったツケがここで回ってきます。
まずこの認識を持ってしまっていると、アイデアの評価に向けて機能アイデアやビジュアルを必要以上に作り込んで検証に臨んでしまいがちです。そして厄介なことに、何かモノを作っていることで前進しているように感じられたり、作ること自体が楽しく夢中になってしまいます。そうして大事に大事に育て、愛着も湧いてきたアイデアが否定された時、あなたは躊躇なくそれを捨てることができるでしょうか？
アイデアを手放すことができなくなり、終いにはマイナス意見を過小評価して都合の良いように解釈してしまうかもしれません。そうなればピボットとも言えないようなマイナーチェンジでお茶を濁して解決したことにするでしょう。
他には、検証に時間や費用を費やしていた結果、後戻りできなくなるケースもあります。
学びを得たと言っても、プロジェクトに関与していない上司から見れば進展もないまま時間もお金も溶かしたように見えてなかなか評価されにくいはず。それを避けようと、アイデアが成功しないだろうことを認められないまま取り繕って進まざるをえないようになってしまいます。
こういった事態を避けるため、リサーチを行う上で大事なのは素早くつくって素早く検証することです。もしアテが外れても小さな傷で済ませられるようにすること、それによって引き際や方向転換（ピボット）を正常に判断することができます。そしてきちんとモノを作った上でも、調査結果から学ぶ際にはバイアスがかかってしまわないよう注意しておくことが大切だということは忘れないでください。
「強くてニューゲーム」-検証を周回しよう-
今回のブログではLearnについてお話ししました。しかしこのLearnが終わった後はまたBuildについて考えていかなければなりません。お忘れかもしれませんが、今回私たちが提案させていただいているメニューはプロトタイプ・”サーキット”。サーキット、と言うからには当然これが何周も続いていくわけです。
Buildのブログでもご紹介しましたが、ビジネスを検討する上では下図のピラミッドのように下から検証を始め、それぞれの段において、Build→Measure→Learnのサイクルを回す段階的な検証のもと丁寧に土台を築きながら進めていきます。そうした中で、検証の1サイクル1サイクルが成功したにしろ失敗したにしろ、抱えているビジネスアイデアについての学び、そしてどう検証すべきかというやり方についての学びを深めながら進めていきましょう。
まとめ
今回は仮説検証サイクルの「Learn」についてご紹介しました。
Learnにおけるポイントは、
①顧客の声を鵜呑みにしないこと
分析においては、インタビュー対象者が良いと言ったことが大事なのではなく、なぜ評価されたのかされなかったのかの価値観を探ることが大事です。
②正しい姿勢で分析に臨めるよう準備をすること
素早くつくって素早く検証するのマインドを持って、Buildの段階に設計することができなければ正しく学び、正常な判断をすることができません。
③検証は周回するもの
Build,Measure,Learnの流れにおいて、Learnは終わりではなく次のBuildに向けた第0ステップです。1サイクルで完結するのではなく継続的に検証を繰り返し周回していくものです。
プロトタイプ・サーキットでは、お客様の検証目的に合わせてプロトタイプを作成し、最適なリクルーティングの元、仮説検証を支援いたします。
本ブログがみなさまの事業開発プロジェクトに何かお役に立てたら幸いです。
ここまでお読みいただきありがとうございました！
プロトタイプ・サーキットについてのお問い合わせや資料請求は下記ページよりご連絡ください！
