ある企業の新規事業におけるリーンスタートアップのコンサル事例をちょっとだけ紹介します。

テーマは「課題仮説インタビューからの脱却」です。

 

リーンスタートアップの実践を目指す多くの方が、キャンバスに描き出したターゲットユーザの抱える課題仮説をインタビューによって検証するという作業を行っているかと思います。

 

率直に伺いますが、そのインタビューはうまくいってますか？

 

実際のところ、多くの方が仮説検証のインタビューは難しいと感じているのが本音ではないでしょうか。私のクライアントもまったく同じ状況でした。

 

課題仮説検証のインタビューによって効果的にフィードバックを得るには、多くのスキルセットが必要です。仮説設定（特にサイズと言語化）の適切さ、インタビューシナリオ、インタビュー先（ターゲットユーザ）の選定、インタビュー環境作り、インタビュー時のラポール、バイアスの回避などなど…。

 

これらがすべて上手く進んだとき、インタビューほど効果的にフィードバックを得る手段はないのですが、逆に言うと、これらのどれかひとつが失敗するだけでも、不適切なフィードバックしか返ってこないというのが「インタビュー」という仮説検証手段でもあるのです。

 

私のクライアントは、仮説の立て方に失敗する典型的なチームでした。課題の設定が常に大きすぎて、何度インタビューを実施してもYes/Noの回答しか返ってこないという、よくある失敗パターンです。

 

そもそもインタビューという手段を選択する目的は、ターゲットするユーザに「ホンネ」を語ってもらうことによって、仮説に対し「立証された」または「立証されず、新たな仮説案を見いだした」かのいずれかの結果を導き出すことです。つまりこの結果を得られるのであれば、なにもインタビューにこだわる必要はありません。

 

私のクライアントのように、仮説の設定で苦しむチームは多いと思います。普段から仮説ドリブンでロジックツリーのようなフレームワークを使いこなすことに慣れているひとでないと、正直なところ、適切な仮説を設定するのは難しいです。まして、バイアスをかけずにホンネを引き出す雰囲気作りや質問までできるとなると、ごくわずかな人しか出来ないと判断した方が良いかもしれません。

 

普段やり慣れてないやり方を採用することでチーム全体のスピードが下がるようでは、リーンスタートアップの概念からすれば本末転倒です！

 

しかし、この本末転倒状態を「リーンスタートアップの実践」だと言うチームが少なくないのも残念ながら現実です。

 

そこで、クライアントチームが２回目のインタビューに失敗した時、私はチームリーダーにインタビューを止めることを提案しました。

これ以上インタビューを継続しても急に仮説の精度が上がる訳ではないこと、実際にチームのスピードが上がっていないこと、インタビューはあくまで手段であることなどを理由に、リーダーには別の手段を検討することを提案したのです。

 

当初は「課題仮説インタビュー」を行うことこそがリーンスタートアップの実践だと思っていたリーダーも、リーンの本質を理解するにつれてインタビューはあくまでひとつの手段であることを納得頂き、別の手段を模索し始めました。

 

世間的に「これがリーンだ」と言われているやり方を真似るのではなく、自分たちでやり方を考え始めたのです。

 

仮説検証の目的は単純に「ターゲットするユーザのホンネ」を理解し、言語化することです。課題に対するニーズの存在が確認でき、かつそのニーズをマーケットサイドがどのように表現するかが分かればいいのです。これらはインタビューでしか検証できない訳ではありませんので、チームが速実行に移せるやり方を「自分たち」で見つけるのです。

 

ここに気づいてからのクライアントチームの動きはとても速いものになりました。

 

まず最初に気づいたのは、チームメンバーにプログラマとデザイナーの両方がいたため、3-4日あればモックアップが出来るということです。モックアップをターゲットするユーザに触ってもらいながら、ホンネを語ってもらえることとが出来るのではないか？と。

 

ただし、モックアップを利用する際の注意点はきっちりと守らなければなりません。被験者から「モックアップへのアドバイス」が欲しい訳ではないこと、つまりデザインや操作性への意見は必要ないこと、ユーザビリティテストを行う訳ではないこと、こうしたサービスを欲しいか欲しくないかの回答を得るためではないことなどの注意点をアドバイスしつつも、すぐに実行に移してみました。

 

そこで設定した検証シナリオは、モックアップを声に出しながら自由に使ってもらい、最後にある質問に回答頂くことです。その質問とは、

 

「さわって頂いたサービスについて以下の空欄を埋めてください」

 

『これはa.　　　　という課題をb.　　　　という方法で解決するサービスです』

 

だけです。

 

つまり、本来であれば自分たちで考えなければならない課題仮説とソリューション仮説を、ユーザに言語化してもらうというやり方にしたのです。

 

このやり方は実に多くのフィードバックをもたらしました。課題をユーザがどのように表現するのか、そもそも想定しているアイディアでユーザは課題が解決できると感じてくれるかが、多くの方からたった１行の回答を頂くだけでフィードバックを得ることができたのです。

 

例えば、a.に記入してくれる言葉が自分たちが想定していたものであれば、少なくとも課題の存在は立証されたことになります。マーケットサイドが言語化できるのですから。逆に想定外の言葉が記載された場合には、ソリューション・アイディアが不適切か、または新たな課題仮説案が言語化されたのかということになります。この場合には、ソリューション案とターゲットニーズのいずれかをピボットするためのデータとして蓄積しておきます。

 

クライアントチームにこうしたやり方を見いだして頂いたポイントはただひとつ。

課題仮説を立て、インタビューシナリオを作り、ターゲットユーザを探し、インタビューを実施するという行程よりも短い時間で完結するか？と言うことです。

 

リーンスタートアップを実践するというのは、インタビューを実施することではありません。チームの事業設計が格段にスピードアップし、かつ正確なフィードバックを得ることができる手段を見つけ出すことこそが、リーンスタートアップの実践なのです。

 

残念ながら事業案を公表することが出来ないので具体的なフィードバック事例を記載することができませんが、インタビューという手段を止めても、同様またはそれ以上の検証結果を得る手段は見いだせます。

 

この事例が、インタビューで苦しんでいるスタートアップへのヒントになることを願って！

 

※本事例はクライアントの承諾を得て公開しています。いずれ実名でご紹介できる日が来ることを願って！