こんにちは、安元一耀です。

そろそろ８月も終わりですね。（本ブログの公開日：８月１０日）

今年の４月にディップに新卒入社し、４月中頃に研修を終えて配属。そして、リーンな新規サービス開発を仕事として約４ヶ月が経ちました（早い！）

この４ヶ月で細かい失敗を何度かしたり、リーンなサービス開発について自分で調べたり、本を読んだり、実際に実践したりしたことで、自分の中でリーンなサービス開発の「型」みたいなものがなんとなくできてきました。

なので、今回は自分のためにもそれを記録しておきます。

本ブログでは、新規サービスがPSF（Problem Solution Fit）を達成したか？の判断を行うまでに、自分がどんなことをことをやったのか？をなるべく詳しく書いています。

新規サービス開発や事業開発担当者の方に少しでもお役に立てれば嬉しいです。

リーンなサービス開発の流れ

今回、自分が行ったリーンなサービス開発の流れ（PSFを達成したか？の判断フェーズまで）について振り返ります。途中には、「ここはこうすればよかった」とか「ここミスったw」などの学びも記します。

①：ターゲットユーザーに普段の生活状況に関するインタビュー

まずは自分がどんな人たちをターゲット（小さな子供のいる主婦・大学生・OL・30代サラリーマンなどなど）にしてサービス開発を行っていくのか？を決めました。

そして、ターゲットとなるユーザー20人に対して「普段どんな生活をしているの？」「何に興味関心があるの？」「普段どんなことにお金を使っているの？」など、普段の生活に関するインタビューを行いました。

インタビューではユーザーの意見や一般論ではなく、なるべく行動・事実を聞くことが重要です（いわゆる「観察」です）

※インタビューで気をつけることについては以前のブログにも書きましたので、ぜひご覧ください。

インタビューの中で、インタビュイーが変わった行動をしていたり、その人の熱量が高い分野を発見したら、そこに関して深堀りを行いました。インタビュー終了後は、そのインタビュイーについてのペルソナシートを軽く作成して記録しました。

※ペルソナシートを作る目的などについては以前のブログに書きましたので、そちらもぜひご覧ください。

すでにターゲットユーザーについて知見があるなどの場合はこのフェーズは飛ばしてもいいでしょう。

②：ペルソナシートを俯瞰し、粒度の大きい課題の洗い出し

①で作成したペルソナシートを俯瞰して見てみます。同じような行動を取っているグループなどで、グループ分けを行うこと、共通している課題や行動がいくつか出てきますので、それらを洗い出します。

ここでは、課題の粒度は気にする必要はありません。「出会いが少ない」「友達と遊びに行く場所などをなかなか決めれない」「スクショがたくさん貯まっている人が多い」など、ざっくりした（粒度の大きい）課題でOKです。

③：ドメインの決定

②で課題をざっくり洗い出したら、ターゲットユーザー10名に「どの課題を一番解決して欲しいか？」を問いました。そして、一番回答が多かった課題をサービス開発を行うドメインとして選定しました。

※今回は「ユーザーに問う」ということをやりましたが、これはPMが判断して良いなと感じました。ドメイン＝市場規模に直結してくるので、ユーザーの回答が多かったドメインの市場規模が小さかった場合、後戻りできなくなってしまいます。

※①でも述べたように、ターゲットユーザーに対して知見がある場合は、このフェーズまでを飛ばせる可能性があります。

④：課題インタビュー

③にてドメインを決定したら、そのドメインで課題を抱えていそうなユーザー３〜５人に対して課題インタビューを行いました。

※課題インタビューとは何か？についてはこちらの記事を参照。

課題インタビューにおいては、予めユーザーが抱えている課題の仮説を持ってインタビューに臨みます（事前にネットでググるなどしておきましょう）

課題インタビューでは、以下３点を洗い出すのが重要であると考えています。

①：選定したドメインにおいて、ユーザーがどんな課題・欲望を抱えているか？（自分の仮説と合っているか？）

②：その抱えている課題・欲望に対して、現状どうやってそれを解決しているか？また、そこにお金や時間を投じているか？

③：その課題・欲望を解決するまでの一連の流れ（カスタマージャーニー）

課題インタビューを通してユーザーの課題・欲望を洗い出せたら、それらを以下のようにマッピングして整理しました。

今回は「課題」と「欲望」に分けてマッピングを行いましたが、ここに関しては反省があるなぁと感じています。

後のフェーズで「どの課題・欲望を一番解決して欲しいか？」をユーザーに問うのですが、「〇〇に困っていますか？」と聞くよりも「〇〇したいですか？」の方が「YES」の回答を得られやすいという現象が起きてしまうからです。

欲望形式を課題形式に変更（「効率的に学習したい」→「効率的に学習できていない」など）する作業は次回からあってもいいなあと思いました。

【参考記事】リーンキャンバスの「課題」を「願望」にしてしまったので考えたこと

⑤：解くべき課題の設定

課題インタビューを終えてマッピングが終了したら、そのマッピングの中で解くべき課題（欲望）を選定します。

マッピングした中で登場した多くの課題の中には、解くべきでない課題も含まれています。それらを排除し、解くべき（であると思われる）課題の洗い出しを行うのもPMの仕事の１つです。

「解くべき課題」とは以下の４点を満たしていると個人的には考えています。

①：課題の粒度が大きすぎない（小さすぎてもNG）

②：その課題を解決するために、ユーザーが現時点でお金や時間を投じている

③：その課題に対して「解」を提供できる可能性が高い

④：言語化できている

課題の粒度が大きいとどうなるか？

①に関してですが、粒度の大きい課題とは例えば、「彼氏が欲しいけどなかなかできない」などです。一見良さげな課題設定に見えますが、この課題を構成している要素が多数あるのが問題です。

例えば、「自分のスタイルに自信がなくて行動できない」「そもそも出会いの場所が少ない」「デートで緊張しすぎて失敗が多い」などです。

粒度が大きい課題に対してのソリューションは、その課題のどの構成要素を解決しているのか？が不明確になりがちです。粒度が大きい課題の中には、解くべきではない（可能性が高い）構成要素も混在しており、（無意識のうちに）それを解こうとしてしまうかもしれません。

※例えば、「ユーザーがその課題に対して、既に存在しているソリューションで満足できている」などが解くべきではない課題（構成要素）に相当します。

解くべき課題の洗い出しが完了すれば、ユーザーに「どの課題を一番解決して欲しいか？」を問い、解くべき課題の決定を行いました。

※今回は解くべき課題をユーザーに問いましたが、ここもPMが自分で決定して良い気がしました。

⑥：ソリューションのパターン出し

⑤で解くべき課題が設定できれば、それを解決できそうなソリューションをいくつか考えます。いわば「アイデア出し」です。

今回はこのフェーズでソリューションを数多く出すことができず、個人的に苦戦してしまいました。ソリューションを多く出すには、日頃から色んなサービス（ビジネス）を見て、そのサービスの本質は何なのか？を見抜く（抽象化する）ことを意識すべきだと感じました。

その抽象化したものを他の分野などに当てはめてみたらどうか？（掛け算）などを考えることでソリューションの引き出しが増えます。

⑦：どのソリューションが良いか？のアンケート

⑥にてソリューションをいくつか出したら、筋が良さそうなソリューションを選び、１つのソリューションにつき１枚のパワポ資料でそのソリューションの概要をまとめました（１枚企画書的な感じです）

そして、それらのソリューションのうちどれが良いか？（使いたいと思うか？）をターゲットユーザーにアンケートで問いました（今回は３つのソリューションを５人に提示）

『Running Lean』なんかでは、「ソリューションインタビューを実施する」などの記述がなされていますが、これはガン無視しましたw

今回はインタビューではなく、アンケートでターゲットユーザーに問いました（アンケートに先ほど作ったパワポの１枚資料×３枚も埋め込みます）

⑧：決定したソリューションのブラッシュアップ＆再びアンケート

⑦にて、ソリューションが決定したら、そのソリューションの内容をブラッシュアップしました（⑦では１つのソリューション概要をパワポ１枚にまとめてましたが、それにもう少し詳細を詰め込んだ３枚のパワポ資料にしました）

そして、再びユーザー（今回は１４人）に決定したソリューション（３枚のパワポ資料）を埋め込んだアンケートを送付しました。

アンケート内容としては、

・序盤（質問①〜③辺り）で回答者がターゲットユーザーであるか？が確認できる質問

・決定したソリューションを使ってみたいと思うか？（価値仮説）

・「使いたくない」など、否定的な回答の場合はその理由

・決定したソリューションを周りの人に勧めたいと思うか？（成長仮説）

辺りをメインに設計しました。

⑨：MVPの制作

⑧にて「使ってみたいと思うかどうか？（価値仮説）」の質問に肯定的ではない意見が多かった場合は「解くべきユーザーの課題変更」や「ソリューションの変更」などを行います。振り出しに戻る感じですね（辛い）

逆に、肯定的な回答が多かった場合はいよいよMVP（Minimum Valuable Product）の制作に入ります。

※MVPの制作に入るかどうかの判断基準は曖昧ではありますが、個人的には「価値仮説の質問に対して肯定的な回答をした人の割合が60%を超えていればクリア」という判断指標にしています。

ちなみに弊社では、MVPとしてティザーサイトを制作することが多いです。今は「strikingly」や「ペライチ」など、コードを書かなくてもサイトが作れる時代なので大変便利で助かってます（良き時代！）

⑩：広告やプレスリリースでPSFの確認

⑨までが終了すれば、MVPを広告（Twitter・Facebook広告）として出したり、プレスリリースを出したりすることで、世の多くのターゲットユーザーにリーチさせます。

ティザーサイトには事前登録フォームを設置しておき、そこに何人のユーザーが登録したか？がKPIとなります。弊社では、そのKPIを達成できればPSF（Problem Solution Fit）のフェーズはクリアしたという判断基準です（このKPIの設定方法については省略します）

※「SmartHR」もティザーサイトを作って広告を投下 → 事前登録者数でニーズを検証したという実話があります

→「その業界を知らなくてもBtoB事業は立ち上げられる」-やり方とコツ-

PSFまではコードを書かずに素早く検証

読者の皆様は、ここまで僕が一切コードを書いていないということにお気づきかもしれません（使ったのはGoogleフォーム・XMind・パワポ・strikinglyぐらいです）

新規サービス開発に携われるエンジニアがたくさんいるなどの場合は話が別ですが、コードを書くというのは大きなリスクの１つですので、弊社ではPSFを達成するまではなるべくコードは書かずに仮説検証を行っています。

コードを書いて、ある程度のプロダクトができてしまうと、それに愛着が湧いて後戻りできなくなる可能性もありますし。。。

MVPの制作までを３〜４週間で行うのが理想のスピード感です。

やっと終わりました。長くなってしまいましたが、弊社で行っているリーンなサービス開発の流れがざっくりお分りいただけましたでしょうか？

有益だと思ったらシェアしてくださると喜びます！

安元の一言

安元一耀

リーンなサービス開発と言うと、PMF（Product Market Fit）の話が多いですが、PMFの前にはPSFがあります。PMFはこれを達成してからの話なので、まずはPSFをしっかり目指したいものですね（これすらも難しい。。。）

投稿者プロフィール

KAZUKI YASUMOTO

最新の投稿

• 2018.08.17小ネタデザイン初心者はまずこれを覚えろ！明日から使える便利な基本テクニック１８選まとめ
• 2018.08.10小ネタ最短3週間！「その新規サービスは世にニーズがあるか？」を検証するまでの10ステップ（体験談）
• 2018.08.03小ネタ女性100人のうち何人がマッチングアプリを使ってるの？サクッと推測してみた
• 2018.07.27小ネタBUYMAで1万円の商品を購入すると、どれくらい利益が出ているか調べてみた