こんにちは。投稿開発部エンジニアの角田と申します。投稿開発部は、クックパッドの中でもレシピを投稿するユーザーに向けた機能の開発を行っている部署です。
私達の部署では、エンジニアも仮説検証の段階からディレクターやデザイナーと一緒に取り組むことが多く、本稿では投稿開発部で行っている仮説検証についてご紹介します。

Webやアプリでサービス提供している方なら、新しいアイディアの価値は最速・最小限で確かめたいものですよね。特に大規模な実装になりそうなアイディアであればあるほど、本当に価値があるのか、ユーザーに使われそうかを先に確かめたいものです。

私達は、本実装する前に「実際のユーザーの反応を見ながら、新しいアイディアの価値を短期間で確認する」取り組みを行っています。私達のチームに合わせた手法になっているので、そのままは活用できないかもしれないですが、同様に仮説検証に取り組んでいる、もしくは取り組もうとしている方々の参考になればと思い、ご紹介します。

プロダクトの価値を短期間で確認するために

クックパッドでは、この本でも有名なGoogleのデザインスプリントを全社的に取り入れ始めています。こちらの記事にて取り組みの内容について取材していただいております。

ここでは、投稿開発部での最新の取り組みを紹介しますが、ところどころスプリントの手法を参考にしている部分があるので、気になった方はそちらも読んでいただけると、より理解が深まるかもしれません。

私達の場合は、仮説の設定を含め、概ね1週間以内でプロダクトや機能の発案とその評価を行っています。この検証では、定性調査(ユーザーインタビュー)のみを行いますが、検証の結果が良さそうであれば本実装を行い、そこで定量調査を実施します。
1サイクルの中で、以下のようなステップを踏んでいます。

1）　部orチームの目標から、仮説を設定する
2）　定性評価の精度を上げるための「問い」を設定する
3）　ソリューションを考える
4）　ソリューションの共有と決定を行う
5）　問いを見直し、ストーリーボードを作成する
6）　プロトタイプを作成する
7）　ユーザーインタビューと評価を行う

1）部orチームの目標から、仮説を設定する

ここでは各部署や各チームの長期的な目標から、それを成し遂げるために検証したい仮説を設定します。

投稿開発部では、「レシピを投稿し始める人を増やすこと」を長期的な目標のひとつとして設定しています。例えば、その目標を実現するために、「料理の工程や工夫の話が出来て反応が嬉しい反応がもらえることで、レシピ投稿を始めるのではないか」といったような仮説を設定します。複数の仮説を確かめたい場合もありますが、仮説をひとつに絞った方が評価もしやすく、インタビューでも深く聞くことができるため、個人的にはひとつに絞ることをおすすめします。

仮説のタネは、自分たちで日頃から料理やレシピ投稿の経験を積んだり、課題抽出のためのユーザーインタビューを行うことによって得ています。

この後、1週間でこの仮説にYes/No の結論を出すための検証を設計していきます。

2）定性評価の精度を上げるための「問い」を設定する

検証したい仮説にYes/Noを下すためには、仮説が成り立つ条件をすべてクリアしている必要があります。ここではその条件を問いにします。

例えば、上記で挙げた「料理の工程や工夫の話が出来て反応が嬉しい反応がもらえることで、レシピ投稿を始めるのではないか」という仮説は、以下の条件から成り立つとします。

そもそも料理の工夫や話したいネタがある
料理の話をして反応が欲しいと思っている
レシピを投稿すれば、反応が得られる思える
レシピ投稿の方法が分かり、投稿できる

これを疑問系に置き換えて問いを定義します。そして、ユーザーインタビューの際にこれがクリアできているかを観察します。

3）ソリューションを考える

ここでは、1）で立てた仮説を、ユーザーに体験してもらうためのソリューションを考えます。全チームメンバーが考えを持ち寄る事を大切にしていて、同日に制限時間を設けて案を出すこともありますが、難しければ1~2日後に個々人が考えた案を持ち寄ることもあります。ソリューション案は、後ほど壁に貼って見比べるので、検討しやすいよう項目を以下のように共通化しています。

仮説
- 1）で立てた仮説をより具体的なシーンに落とし込んで、ソリューションと紐づけたもの
ターゲット
- 仮説にあてはまる人の具体的な属性(ex: 主婦、仕事あり..etc)や、心理的な背景(ex: 日々の料理が作業になっていてモチベーションが上がらない)など
体験
- そのソリューションで実現したい具体的な体験
方法
- 定義した「体験」を実現する方法
- 簡単な画面遷移図などを添えることが多い

4）ソリューションの共有と決定を行う

2）で考えたソリューションを、共有し、そのプロジェクトの意思決定者が採用する案を決めます。

こちらは、スプリント本で言及されている「ソリューション決定」を参考にして、おおまかに以下の流れで実施しています。詳細はスプリント本をご確認ください。

各ソリューションをB4の紙に印刷もしくは書き出して、ホワイトボードに貼り出します（考案者の名前は記述しません）
各メンバーは<無言で>気になった点に小さな丸シールを貼り、感想や質問を付箋紙に書いてはります(5-10分程度)
全員貼り終わったら、各考案者が付箋に対し回答し、他のメンバーと不明点の解消を行います
議論が完了したら、各メンバーが採用したいソリューションに大きめの丸シールを貼ります(2-3枚程度)
意思決定者は、各メンバーが選んだ理由を聞いて、最後にどの案を採択するか決めます

5）問いを見直し、ストーリーボードを作成する

問いの見直し

ここでは、2）で設定した問いをソリューションに合わせて見直します。問いの本質を変えるわけではなく、問いをそのソリューションに合った表現に置き換えます。インタビューや評価する際に、問いに対して判断をしやすくするために行います。

ストーリーボード作成

こちらもスプリント本の「ストーリーを固める」を参考にしていますので、詳しくはそちらをご覧ください。簡単に言うと、ユーザーに私達のソリューションを正しく体験してもらうために、プロトタイプの絵コンテを10~15コマ程度で作成します。これをもとに、具体的なプロトタイプやインタビューの設計に落とし込みます。

f:id:kaktaam:20181129155405j:plain:w350

6）プロトタイプを作成する

このプロトタイプでは、設計した検証に必要な体験をしてもらうための、最低限・最小限の画面・機能を用意します。短期間での検証なので、不要な詳細は省きます。

プロトタイプを作る場合、大きく2パターンの方法を採用しています。ひとつは、静的なプロトタイプを作成するパターンで、もうひとつは実装するパターンです。

静的なプロトタイプの場合

Marvelというプロトタイプツールを使います。この場合は、デザイナーが作ったプロトタイプ用の画像をこのツールに反映し、画面遷移をできるようにします。
どのインタビューイーに対しても、同じ文言やUIを見せられれば良い場合などは、この方法を選択します。簡単に作ることができますし、Marvelの専用アプリを用いて操作することで本物のサービスのように見せることができるので、この方法で十分かと思います。

実装する場合

投稿開発部では、レシピ投稿についての仮説検証を行うことが多く、検証の中でユーザー自身が投稿したレシピや、それに関連する複数の情報をプロトタイプ上で表示したい、操作してもらいたい場合がよくあります。そうなると、静的なプロトタイプではなく実装をします。
具体的には、React Native製の「クックパッド MYキッチン」アプリにプロトタイプを実装し、インタビューで使うことが多いです。インタビューにおいても、ユーザー自身のデータを表示することにより、素直で本音に近い回答が得やすいと感じています。

クックパッド MYキッチンについては、こちらの記事に詳しく書かれています。
React Nativeの開発環境については、iOS・Androidともに記事を公開していますので、よろしければご覧ください。

7）ユーザーインタビューと評価を行う

最後にインタビューと評価についてです。

ユーザーインタビュー

インタビューは一人30分×5名を1日で行うことが多いです。
事前に決めた問いを判断できるようなインタビュースクリプトを用意して臨みます(インタビューに関してはこちらの記事に詳しく書いています)。インタビューは数名が行い、その内容をインタビュー中継用の別室で他のメンバーが観察します。

中継室のメンバーは、各問いに対するユーザーの反応や発話内容を付箋に書いておきます(付箋の色は、ポジティブ・ネガティブ・どちらでもないに分けると良いです)。
事前に、問いと各ユーザー概要を記した以下のような表をホワイトボードに書き出しておき、インタビューが終わるたびに付箋を貼り出しておきます。

f:id:kaktaam:20181129162208p:plain:w400 f:id:kaktaam:20181129155421j:plain:w398

評価

インタビューと同日に評価を行います。
まずは、各インタビューイーに共通して見られた反応や発話内容をホワイトボードに書き出し、チーム内でインタビューの結果について理解を深めます。
次に、2）で出した問いに対して、○、△、✕ で結果を評価します。私達は以下のような基準で評価を行っています。

○：仮説とソリューションがマッチしていて、このまま本実装して問題ない
△：この仮説や方針は悪くないが、ソリューションのピボットが必要
✕：この仮説や方針自体、見直す必要がある

この結果をもって、次のアクションを決めます。全て○になるようであれば本実装と定量調査に進み、それ以外であれば課題になった箇所についての検証を進める形になるでしょう。

さいごに

投稿開発部では、発案したプロダクトや機能の価値を事前に検証することで、根拠を持って新しい機能を実装できるよう取り組んでいます。こういった事前の検証サイクルをまわすことで、想定しなかった問題が明確になったり、意外なところでポジティブな発見を得ることができる等、利点は多くあるように感じます。

もちろん、週単位で仮説検証を回すのは正直楽ではないし、ディレクター・デザイナー・エンジニアで顔を突き合わせて議論する中で、途方に暮れる...ということもあります。ただ、そうやって考えた仮説に対して早期にユーザーの反応が分かること、そして直接聞くことで具体的にその理由が分かることが非常に良いと感じています。
そして、ユーザーインタビューを通し、改めて料理をする人の考え方やリアルな生活感を理解することで、次のアクションのヒントにも繋がっていると実感しています。

こういったチームでのサービス開発、興味ありませんか？クックパッドでは一緒に開発に取り組んでいただけるメンバーを募集中です！ぜひ興味を持っていただけた方は、採用サイトをご覧ください。