こんにちは、会員事業部の新井（@SpicyCoffee66）です。今年はレシピサービスにおける体験改善を主な業務としていました。
サービス開発かラブライブ！の話をすると早口になります*1。今日はついにスマブラが発売されるのでおそらく早退します。
さて、本記事ではサービス開発において重要な要素である施策結果・知見のプールや共有について、社内でどのような取り組みが行われているのかを紹介したいと思います。
施策の結果から最大限に学びを得たい
私たちはサービス開発を進める中で日々多くの施策を実施することになります。
サービス開発のプロセスにおいて、施策は実施して終わりではなく、その結果からいかに多くの学びを得るのかということが重要になります。
施策の結果から学びを得るためには、その施策の意図や結果を可能な限り 正しく 解釈し、それを（将来入ってくるメンバーを含めて）より多くの人に 共有 することが必要です。
しかし、サービス開発の現場では以下のようなことが往々にして発生します。
- 間違った知見が共有される
- 結果の数字の読み取り方がおかしい
- そもそもKPIの設定がおかしい
- 検証の期間が短すぎて正確性に欠ける
- 施策の目的と手法が噛み合っていなかった
- といったようなことに気がつかず正しい知見として共有される
- 知見がまるで共有されない
- どこにプールされているか判然としない
- 知見が属人的になる
- ならまだいい方で時が経って本人もはっきり覚えていない感じになる
- 最悪プールすらされてなくて闇に消える
- 結果新規メンバーが似たような失敗を繰り返す
僕自身、入社して間もない時期には過去に実施された施策の詳細を探すも見つからず、歯がゆい思いをしたことが数多くありました。
クックパッドのように歴史の長いサービスであれば、自分が思いつくアイディアについて過去に誰かが似たような施策に取り組んでいたことも多く、その時の結果を参照できないのは非常にもったいないと感じました。
このような問題を解消するため、社内では昨年度途中から Report.md という仕組みが利用され始めました。
Report.md
Report.md を一言で言うと「施策の結果を Pull Request で管理する仕組み」となります。
具体的には
- 担当者は施策の終了後、Markdown形式でその内容をまとめた report を作成し、PRを送信する
- チームメンバーがその report をレビューする
- いい感じになったらマージし、report をプールする
という手順を踏んで施策の結果をレビューし、ストックしていきます。
こうすることで
- 施策の結果を正しく解釈する → レビューを通すことによって精度が上がる
- 多くのメンバーに共有する → report のプール箇所が明確になり参照しやすくなる
といった効果が上がり、前述した二つの目的を果たすことが可能になりました。
コードをレビューして（質を高めて）、マージする（永続化する）という普段エンジニアがやっているフローが、施策の結果に対しても有効だったわけです。
いつ書くか？
上記手順では、Report.md のイメージを持っていただくために施策終了後としましたが、施策の実施前に Report.md を作成することで、仮説や検証内容が明確になり、施策がブレにくくなるという効果があります*2。
導入初期は施策後に作成して「結果の共有」のためにのみ利用するのもよいと思いますが、慣れてきたらぜひ施策の実施前に作成するフローで運用することをオススメします。
その場合の手順は
- 担当者は施策の実施前に、Markdown形式でその内容をまとめた report を作成し、PRを送信する
- チームメンバーがその report をレビューする
- いい感じになったらマージし、 report をプールする
- マージされた report をもとにして施策を実施する
- 施策終了後、その結果を report に追記する
- チームメンバーが report をレビューする
- いい感じになったらマージし、完成版の report としてプールする
といった形になります。
何を書くか？
Report.md に何を書くかについては、運用しているチームによって様々です。
ここでは、私が見た事例の中で一番よくまとまっていると感じたテンプレートをもとにして内容を紹介していきます。
また、以下にあげる内容のうち、「仮説」「仮説分析」「検証方法」「結果の想定」については、施策の実施前に記載することでその指針とすることができる内容になります。
3 行まとめ
作成された report を読むのは自分だけではないことを考えると、まずは概要を読んでから詳細を読むべきか判断できる構造になっていた方が親切です。
仮説
report の中でも非常に重要な項目です。
仮説をしっかり定義できていないと検証設計がぶれ、結果を次に活かすことが難しくなります。
仮説をどのように表現するかはチームによりますが、社内独自のフレームワークである価値仮説シート*3に沿って表現することが多いです。
形式に迷う場合は
(ターゲット) は (ジョブ/インサイト) したいが (何らか要因でそれができていない状況) なので、 (体験) すると (目的) になる
といったフォーマットで表現してみるのがよいと思います。
仮説分析
そもそも上記の仮説はどこからきたのか、その妥当性はあるのかといったような仮説の価値自体やその詳細を示す項目です。
具体的には
- ターゲットボリューム
- 「仮説」で定義したターゲットの条件に当てはまる人がどのくらいいるのかを試算する
- 事前検証・前回施策の結果
- この施策に繋がる情報を持った施策 report へのリファレンスを貼っておくとわかりやすい
- 落としてはいけないコア機能
- 「仮説」の内容をより明確にするためにコアとなる要素を明記する
- 諦めること
- 検証のブレを無くすためにやらないことを明記する
- 技術的に難しいこと
- 期間やリソース都合を含め、実装側の都合で諦めたことを明記する
「仮説」を所与のものとしても report は成立しますし、あまり情報量が多くなっても report の骨子が読みづらくなるため、施策によって項目は柔軟に変更するのがよいと思います。
なるべく外部資料や別 report への参照を貼るよう工夫したり、<details> タグを利用して情報を畳んでおくのもおすすめです。
検証方法
「仮説」の項目で書いた「体験」を実現するための方法を示し、その内容を具体的に解説します。
- 検証項目
- 施策によって答えを出したい問い
- 仮説そのものに対する問いになることもあれば、仮説をもとに考えた機能の有用性に対する問いになることもあります
- 検証方法・提供機能
- 仮説に対してどのような機能を提供してそれを検証するか
- あるいはどのような資料をもとにユーザーにヒアリングを行うか
- 検証資料・機能詳細
- それらの機能や資料の詳細
- 検証期間・人数
- 評価方法
といったような内容を盛り込むとよいでしょう。
結果の想定
「検証方法」で定義した「評価方法」に対し、どのような結果が出たときに「仮説」をどう評価すればよいかについて可能な限り明記しておく。
- 定量検証の場合
- CVR が x % 以上向上した場合は仮説が正しかったと考える
- 定性検証の場合
- ユーザーインタビューで y というような反応が z 人以上見られた場合は仮説が正しかったと考える
根拠を持って詳細な数値を設定するのは難しいことが多いですが、過去の施策やチーム内での議論をもとに目安を設定してメンバーの目線を揃えておくことが重要です。
検証結果
検証の結果をまとめます。
主観的な考えや分析は後の「考察」に記載するとし、ここではそれに必要な結果のみを記載します。
考察・ギャップ分析
「結果の想定」と「検証結果」を比較し、自分たちの仮説や認識について合っていたことと間違っていたことを明らかにしていきます。
長文で書き綴るよりも検証項目ごとに箇条書きで簡潔にまとめる方が振り返りやすくてよいかと思います。
Next Action
「考察・ギャップ分析」の内容を受けて、この施策を次にどうするか、具体的なアクションを記載します。
Report.md 運用の所感
メリット
Report.md を社内で運用していくうちに、以下のようなメリットがあることが感じられるようになりました。
- 施策結果の解釈の精度が上がる
- 施策そのものがブレづらくなる
- 施策の結果を気軽に共有できるようになる
- Slack で「こういう感じのことやったことある人いないですか？」「お、それなら前にやりましたよ（report のリンクを貼る）」といったやり取りが数多く見られるようになりました
- サービス開発者の成果が可視化されやすくなった*4
- 期末の評価期間に自己評価を執筆する際に上長に成果を提示しやすくなりました
デメリット
個人的には非常に有用な仕組みだと感じてはいますが、デメリットも存在しているとは思います。
最も大きいのは「施策に関して目先の実行速度が遅くなる」ことです。
Report.md をしっかり作成しようとすると、それ相応のコストが掛かります。
その分施策に対する理解が深まったり、後々参照できる資産になったりという大きなメリットがあるとは思いますが、サービスのフェーズやチームの雰囲気によっては、メリットがコストに見合わないかもしれません。
そういった場合には、記載する項目を取捨選択したり施策と同時並行で作成するなどの工夫によって、report 作成のコストを抑えるのがいいでしょう。
今後の課題
今後の課題として、report を通した情報共有をより活発にしたいと思っています。
Report.md 自体はあくまでも「施策の結果がチームごとに一箇所に集まる」ものでしかなく、組織横断的に情報を提供してくれる仕組みではありません。
したがって、より容易に情報が社内に行き渡るような仕組みと組み合わせることでその効果をさらに高めることができるのではないかと考え、その方法を模索しています*5。
まとめ
本記事では、サービス開発において実は失敗しがちな知見のプール・共有について社内でどのような取り組みがなされているかを紹介しました。
クックパッドでは、技術力を大切にしているのはもちろんのこと、サービス開発そのものについてもその手法を洗練させていくことで、よりすばやくユーザーに価値を届けようと日々努力しています。
そして、そういった想いのもと一緒にサービスを作り上げていってもらえるメンバーを募集中です！
このような姿勢や働き方に興味を持っていただけたなら、ぜひ一度採用サイトをチェックしてみてください。
興味はあるけどいきなり採用の話は……という方は、気軽に @SpciyCoffee66 まで連絡してください。
クックパッド名物の（？）キッチンラウンジで美味しいご飯を食べながら社内の様子についてお話しましょう！
*1:早口になるほど好きなのでサービス開発者のコミュニティである s-dev talks を運営しています。
*2:施策の実施前にどのようなことを考えればいいかについては別の記事を投稿させていただいているので、興味のある方はご一読ください。
*3:具体的なフォーマットは TechConf 2018 での講演や、この夏に開催されたインターンシップの資料をご参照ください。
*4:Report.md の前身となった取り組みに関する記事でも少し触れられています。
*5:最近になってまずは専用のドメインを切った社内ブログに集約してみるという動きが始まりました。
