事業開発部のデザイナー平井です。Cookpad Do!というサービスの運営をしているチームに所属しています。
Cookpad Do!は、前身サービス「Cookpad料理教室」のブランド再開発として2018年8月8日に生まれた新サービスで、食・料理をコンテンツとした体験型イベントを開催するオーナーがイベントを掲載し、参加する人がイベントの予約・決済を行えるプラットフォームサービスです。
今回はグロース期に入ったサービスの開発・運営していく中で、何を考え、どのように企画し、何を気をつけながら価値創出をしようとしているかの話をしようと思います。
料理を「楽しみ」にする
世に存在するサービスデザインは、よく「顧客の問題の解決」という言葉で説明されることがありますが、クックパッドが目指す「毎日の料理を“楽しみ”に」というビジョンを目指す上では、痛みや不満などの問題の解決という文脈だけで語れない側面があると考えています。
例えば「今日の献立を決めきれない」「失敗したくない」「人気のレシピを参考にしたい」…という、面倒な工程を少しでも“楽”にするという価値は、レシピサービスを通して多くの人に提供できており、素晴らしいことです。
しかし、“楽しみ”にというステージまでシフトするには、「今見えている問題の解決」という視点から外れて「料理の楽しさを創出する」というチャレンジを行っていかなければなりません。そんなチャレンジをCookpad Do!で実践しています。
ユーザーさんのPainは目に見えるが、Gainは見えづらい
ユーザーさんの隠れたニーズを発見するための手法として、ユーザーインタビューやプロトタイプを用いたユーザーテストは、今やどのサービス開発会社でも当たり前に行われています。
しかし実際には、「あぁやっぱりね」といった具合に自分たちが考えていたソリューションを正当化してみたり、「問題なかった！よかった！」と、インタビューの時間で新たな発見を生まない結果にしてウヤムヤにしてしまった…なんてケースがあるのではないでしょうか？
私の良くない経験としては、インタビュー中ユーザーさんから発せられた表面的な不満や課題にどうしても目が行ってしまい、いきなりソリューションの説明をして、ユーザーさんをその場で納得したような気持ちにさせてしまう…ということがありました。
なぜそういった事態に陥ってしまうのでしょうか？ それは、「痛み」はユーザーさん自身が一番先に意識していて、表現しやすく、話題にしやすいからです。
また、ユーザーさんの「快楽」は、いざ口に出して説明しようと思っても説明できないことが多く、絞り出した結果も「なんとなくかっこいいから」「自己満足」のように曖昧だったり、普遍的な欲求の言葉で語られます。 （あと、「異性にモテる」など、単純に恥ずかしかったりします…）
例えば「料理教室」を商品とした場合「基本を理解できていない」「料理のレパートリーを増やしたい」といった話になりやすいです。
私たちが実現したいのは「楽しみの増幅・創出」であり、本質的にフォーカスすべきなのはPainではなく、Gainです。
楽しみを見つけるアプローチ
当たり前のようですが、私たちは日々、楽しみを何かに「見出して」います。
言い換えれば「これをやったら楽しいのでは？」と自分で動機づけを行い、いろいろ試したりして、発見しています。 （逆に緊急性が高い「問題」に対しては、解決策となる多くのサービスが向こうからやってきます）
「楽しみ」を求める能動的な行動は、各々の「価値観」によって左右されることから、「楽しみ」は「価値観」から洞察されることがわかります。
問題ではなく、人の「価値観」を探りましょう。
価値観を知るためには、その人が何を「問題」として認識しているかという事実も洞察のヒントになり得ます。
例を挙げると、「料理のレパートリーを増やしたい」という声をあげている人が「子どもが最近ご馳走様でしたの挨拶をしなくなった」ことに悲しい顔を浮かべている…という生活背景を持っている場合は、「子どもの喜ぶ顔に価値がある」といった価値観を持っているのではないか？という洞察が得られます。
「子どもの喜ぶ顔を見る」手段は「料理のレパートリーを増やす」に限った話ではないはずです。
同じ「料理のレパートリーを増やしたい」と言っている人でも、「毎日同じご飯だと栄養が偏る」という「健康な生活」に価値を置いているかもしれません。
このように一つの課題感から、生活背景や価値観を抽象化して属性分けできるレベルまでターゲットを言語化すれば、どのようなコンテンツで訴求をして動機付けることができるのか打ち手が考えやすいですよね。
本当に価値のあるアイデアとは？
さて、ここまでどのように「楽しみ」のアイデアの種を生み出すかの話をしてきましたが、プロダクト開発現場でよくある問題が「やりたいことリスト」が溢れてしまって、ただ読むのにすら時間がかかってしまう…というケースです。
そのため、実行優先順位や期待効果を相対的に判断しにくくなり、結果よくわからないまま、数カ月後には誰も話題にしないアイデアがこんなに…なんて経験はありませんか？
そういった事態に陥ってしまう原因の一つに「具体的な要件」を主語としてしまうから、というものがあると考えています。
例えば、「◯◯という訴求文言を設置する」「メッセージ機能をつける」などです。
タスクのラベリングとしては管理しやすいため、実行フェーズに移った際には上記のような共通言語を用いたほうが良いと思いますが、アイデアの価値を測るフェーズでは問題になりやすいです。
そこでCookpad Do!チームで行っている対策として、アイデアには必ずユーザーニーズと価値仮説を、価値仮説には必ず事実と洞察をセットにして起票することにしています。
仮説はほとんどの場合、何らかの事実や背景から洞察されます。
たとえばCookpad Do!の場合「よく知らない人の自宅に上がることに抵抗がある」「イベント参加前に、イベントの内容ページよりもイベントオーナーのプロフィール画面を閲覧している傾向が強い」といった声やデータの事実が背景にあった場合、「イベントのコンテンツ以上に、イベントオーナーの人となりを気にしているユーザーさんが多いのではないか？」といった洞察がなされます。 よって、「人にフォーカスしたコンテンツをより露出させてあげたほうが良いかもしれない」といった具合に仮説が立ち、新たな要件が生まれ、開発の糸口になります。
このような仮説の種となる事実や背景を得るために、普段からユーザーインタビューをする際に意識したり、ユーザーさんの行動ログを見ていると良いですよね。
最後に
「問題を解決すること」は「楽しいこと」ではありません。
よく「ユーザーファースト」と言いますが、ユーザーの希望する機能を聞いたまま開発するのではなく、「なぜこのような事実になっているのか」を深く洞察し、驚きや楽しみを実現するプロダクトを創り出していくことが本当の意味でユーザーファーストな考え方であると思っています。
ユーザーさんが「楽しそう！」と喜んで選んでくれるプロダクトを作るために、常にユーザーファーストの気持ちを忘れずに、時には大胆にユーザーさんにボールを投げかけてみたりしてチャレンジしていきましょう！
