こんにちは、検索・編成部ディレクターの原田です。検索・編成部では検索サービスをはじめとして、主にクックパッドでレシピを探す方に向けたサービス開発をしています。
さあ、しっかり企画を立てよう！の落とし穴
突然ですが、例えば
思いつきで施策をスタートしてしまって、後でチームのメンバーがバラバラになってしまった…
関連する部署を調整できなかった…
またその逆で、誰かの思いつきの施策によって翻弄されて大変だった…
という経験はないでしょうか。
個人の制約を超えて目的を達成できることがチームで仕事をすることの可能性ですが、チームワークの威力は各自が自発的に行動できるようになって発揮されるので、判断を支える明確な目標や指針を含む「企画」が必要になります。
一方で、さあちゃんとした企画を立てるぞ！ と意気込んでみても、ちゃんとしたどころか発想すら浮かばない…ということはないでしょうか。毎日の暮らしの中で使っていただくサービスであれば、ユーザーの生活をリサーチする中で、または自分自身が日常の中で感じた「何か」が大きな価値につながる可能性は信じたいものです。
今回はそのような「気づき」に明確な目標と実現までの道筋という力を与え価値を形にするために、クックパッドの検索・編成チームが使っている3つのフレームワークについてご紹介します。
気づきに力を与えるための3つのフレームワーク
1. 気づきを企画に組み立てる「価値仮説テンプレート」
何かの「気づき」を得てもそれを企画にするためには、まず何をどう進めるか・どう考えようかということが頭をよぎります。実際私が今のチームで開発をし始めた頃、何をどう進めるかを決めること自体に時間をかけてしまい、コアな議論を始めるのに時間がかかっていました。
そこで、考えなければいけない要素をテンプレート化し、チームでサービス開発用に活用しているGitHub Enterprise レポジトリのREADME.md上に置いています。なお、GitHub Enterpriseを活用したサービス開発についてはすでにこちらのエントリーに詳しいのでぜひご覧ください。私たちのチームでは主な要素として「ユーザー」「解決する問題（シーン）」「解決策（サービスの特徴）」「成功指標（KPI）」「テストの仕様と対象とユーザー」「TODO & 期限」の5つを設定しています。
これに沿って考えを組み立てることで、何をどう進めるか・どう考えようかということにエネルギーを消費することなく「気づき」をチームのメンバーが共有可能な企画にパワーアップさせることができます。
2. 根源的な欲求を見極める「なぜなぜnode」
ところが「価値仮説テンプレート」に沿って考えられるようになると、ある程度の完成度が担保できるという利点があるゆえに、企画のストーリーを都合の良いように（多くの場合は意図せずに）つじつまを合わせてしまうという新しい問題に直面するようになりました。部署としてKPIに置いている検索成功率から逆算して解決したいことを自分で作り出してしまい「そんな状況って本当にあったっけ？」ということが起き始めたのです。
そこで「価値仮説テンプレート」を検討をするときに、人間として根源的な欲求を定めてから、妨げになる理由をブレイクダウンしながら「価値仮説テンプレート」の各要素を紐付けられるやり方をフレームワーク化しました。
まず、人間の根源的な欲求としてクックパッドが大切にしている「毎日の料理を楽しみに」を出発点に、「毎日の料理が楽しく感じられないところにどんな悲しみや失望があるのか」をひたすら「なぜ、なぜ」とブレイクダウンします。
ポイントは、この時点ではアウトプットのことは一切考えないことです。また、出発点を「楽しく料理をしたい」というようなポジティブな感情にしないことも大事です。生活者の周りにある「悲しみ」や「失望」から出発することで「あったらいいかもね」というレベルの企画になってしまうことを防ぐことができます。
「なぜなぜ」を出し切ったところで、グルーピングして特に注力したい枝をチームのメンバーで決めていきます。
そこまでできたらようやく「価値仮説テンプレート」の次の項目である「解決する問題（シーン）」と「解決策（サービスの特徴）」を、疑いようのない欲求にどうつながるのかを見極めながら検討します。
ポイントは、この時点ではサービスの特徴を「機能」で考えないことです。そのサービスが実現する「状態」にこだわって言語化することで欲しいのは「ドリル」ではなく「穴」だったという話を防ぐことができます。
そしてそのサービスが実現する「状態」を数値化したものが「評価指標（KPI）」となるわけなのですが、ここでようやくチームの目標に対してどのくらい影響を与えそうかを他の施策と比較し、優先順位を判断することができるようになります。実際にはKPIから逆算することが悪ではなく、いったりきたりしながら考えるようにしています。
3. ”個人の制約”を乗り越える「価値形にする会」
ここまでツールについて話をしてきましたが、結局のところ一人で考えていては限りがあります。
そこで「価値形にする会」というMTGを週1回開催し、別の施策を担当するディレクターが集まり「なぜなぜnode」の元となる欲求の妨げ要因や、その先にある解決策の具体的な仕様についてのアイデアフラッシュをする場として、フレームワーク自体をサポートしています。
フレームワーク自体の磨き込み
以上、私たち検索・編成チームで使っている３つのフレームワークをご紹介しましたが、フレームワークは固定化されたルールではありません。それ自体が開発に関わる自分たち自身に向けたサービスの一つだと考えています。ゆえにフレームワーク自体もご紹介した3つのフレームワークに則り「自分たち自身の疑いようのない欲求（目的）」と「どのような状態になることを期待しているのか（ゴール）」を定めてPDCAを回しています。
そもそも、３つのフレームワーク自体「さあ作ろう！」と考えられたわけではなく、個々人が実務の中で生み出した素敵な知恵に名前をつけて体系化したものなのです。サービス開発で価値を生み続けるフレームワークであるためには、個々人の良いやり方を見つけて光を当て、不要なものはしっかり捨てることを続けることが大事です。そのためにフレームワークの運用自体をissue化したりもしています。
まとめ
ユーザーが最も大切にする価値を実現するにはエネルギーが必要です。企画を立てられたところで、そのあとにはあるべき形を目指し失敗と改善の繰り返しが待っています。
フレームワーク自体はそれを使うことで価値を実現できる魔法のツールではありません。フレームワークを持つことで、チームのエネルギーが考え方や進め方から解放されて「ユーザーの毎日の暮らしの中に起きていること」についての具体的な会話が溢れるようになる、そんな世界を目指しています。
検索・編成部では、「毎日の料理について起きていること」から発想して技術の力で笑顔を増やせることに無条件にワクワクしてしまうエンジニアを募集しています。