紹介〜こんにちは、会員事業部の新井(@SpicyCoffee66)です。今年はレシピサービスにおける体験改善を主な業務としていました。サービス開発かラブライブ!の話をすると早口になります*1。今日はついにスマブラが発売されるのでおそらく早退します。本記事ではサービス開発において重要な要素である施策結果・知見のプールや共有について、社内でどのような取り組みが行われているのかを紹介したいと思います。施策の結果から最大限に学びを得たい私たちはサービス開発を進める中で日々多くの施策を実施することになります。サービス開発のプロセスにおいて、施策は実施して終わりではなく、その結果からいかに多くの学びを得るのかということが重要になります。サービス開発の現場では以下のようなことが往々にして発生します。間違った知見が共有される結果の数字の読み取り方がおかしいそもそもKPIの設定がおかしい検証の期間が短すぎて正確性に欠ける施策の目的と手法が噛み合っていなかったといったようなことに気がつかず正しい知見として共有される知見がまるで共有されないどこにプールされているか判然としない知見が属人的になるならまだいい方で時が経って本人もはっきり覚えていない感じになる最悪プールすらされてなくて闇に消える結果新規メンバーが似たような失敗を繰り返す僕自身、入社して間もない時期には過去に実施された施策の詳細を探すも見つからず、歯がゆい思いをしたことが数多くありました。クックパッドのように歴史の長いサービスであれば、自分が思いつくアイディアについて過去に誰かが似たような施策に取り組んでいたことも多く、その時の結果を参照できないのは非常にもったいないと感じました。いう仕組みが利用され始めました。管理する仕組み」となります。プールするという手順を踏んで施策の結果をレビューし、ストックしていきます。プール箇所が明確になり参照しやすくなるといった効果が上がり、前述した二つの目的を果たすことが可能になりました。コードをレビューして(質を高めて)、マージする(永続化する)という普段エンジニアがやっているフローが、施策の結果に対しても有効だったわけです。作成することで、仮説や検証内容が明確になり、施策がブレにくくなるという効果があります*2。導入初期は施策後に作成して「結果の共有」のためにのみ利用するのもよいと思いますが、慣れてきたらぜひ施策の実施前に作成するフローで運用することをオススメします。してプールするといった形になります。何を書くかについては、運用しているチームによって様々です。ここでは、私が見た事例の中で一番よくまとまっていると感じたテンプレートをもとにして内容を紹介していきます。想定」については、施策の実施前に記載することでその指針とすることができる内容になります。読むのは自分だけではないことを考えると、まずは概要を読んでから詳細を読むべきか判断できる構造になっていた方が親切です。中でも非常に重要な項目です。仮説をしっかり定義できていないと検証設計がぶれ、結果を次に活かすことが難しくなります。仮説をどのように表現するかはチームによりますが、社内独自のフレームワークである価値仮説シート*3に沿って表現することが多いです。なるといったフォーマットで表現してみるのがよいと思います。仮説分析そもそも上記の仮説はどこからきたのか、その妥当性はあるのかといったような仮説の価値自体やその詳細を示す項目です。骨子が読みづらくなるため、施策によって項目は柔軟に変更するのがよいと思います。項目で書いた「体験」を実現するための方法を示し、その内容を具体的に解説します。いったような内容を盛り込むとよいでしょう。「検証方法」で定義した「評価方法」に対し、どのような結果が出たときに「仮説」をどう評価すればよいかについて可能な限り明記しておく。人以上見られた場合は仮説が正しかったと考える根拠を持って詳細な数値を設定するのは難しいことが多いですが、過去の施策やチーム内での議論をもとに目安を設定してメンバーの目線を揃えておくことが重要です。検証の結果をまとめます。主観的な考えや分析は後の「考察」に記載するとし、ここではそれに必要な結果のみを記載します。「結果の想定」と「検証結果」を比較し、自分たちの仮説や認識について合っていたことと間違っていたことを明らかにしていきます。長文で書き綴るよりも検証項目ごとに箇条書きで簡潔にまとめる方が振り返りやすくてよいかと思います。Action「考察・ギャップ分析」の内容を受けて、この施策を次にどうするか、具体的なアクションを記載します。社内で運用していくうちに、以下のようなメリットがあることが感じられるようになりました。リンクを貼る)」といったやり取りが数多く見られるようになりましたサービス開発者の成果が可視化されやすくなった*4期末の評価期間に自己評価を執筆する際に上長に成果を提示しやすくなりましたデメリット個人的には非常に有用な仕組みだと感じてはいますが、デメリットも存在しているとは思います。大きいのは「施策に関して目先の実行速度が遅くなる」ことです。作成しようとすると、それ相応のコストが掛かります。その分施策に対する理解が深まったり、後々参照できる資産になったりという大きなメリットがあるとは思いますが、サービスのフェーズやチームの雰囲気によっては、メリットがコストに見合わないかもしれません。作成のコストを抑えるのがいいでしょう。通した情報共有をより活発にしたいと思っています。自体はあくまでも「施策の結果がチームごとに一箇所に集まる」ものでしかなく、組織横断的に情報を提供してくれる仕組みではありません。したがって、より容易に情報が社内に行き渡るような仕組みと組み合わせることでその効果をさらに高めることができるのではないかと考え、その方法を模索しています*5。まとめ本記事では、サービス開発において実は失敗しがちな知見のプール・共有について社内でどのような取り組みがなされているかを紹介しました。クックパッドでは、技術力を大切にしているのはもちろんのこと、サービス開発そのものについてもその手法を洗練させていくことで、よりすばやくユーザーに価値を届けようと日々努力しています。いった想いのもと一緒にサービスを作り上げていってもらえるメンバーを募集中です!このような姿勢や働き方に興味を持っていただけたなら、ぜひ一度採用サイトをチェックしてみてください。まで連絡してください。*2:施策の実施前にどのようなことを考えればいいかについては別の記事を投稿させていただいているので、興味のある方はご一読ください。講演や、この夏に開催されたインターンシップの資料をご参照ください。前身となった取り組みに関する記事でも少し触れられています。*5:最近になってまずは専用のドメインを切った社内ブログに集約してみるという動きが始まりました。紹介〜Tweet関連記事2018-11-301週間で仮説検証を繰り返す、サービス開発のための取り組みこんにちは。エンジニアの角田と申します。~A/Bテスト実践~会員事業部エンジニアの佐藤です。使ったセキュリティログ検索基盤の構築サービス特性にあった検索システムの設計戦略クックパッド採用説明会「クックパッドはサービスの作り手を採用したいんです。/*}*/スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。