この記事はモチベーションクラウドシリーズ Advent Calendar 2022 23日目の投稿です。
はじめに
弊社の開発組織では、新たな機能をリリースする際に必ずアウトカム(得たい成果)を定義しています。定義したアウトカムをリリース後に測定しリリースの成功・失敗を判断しているのですが、アウトカムを測定して終わりになるケースが多く、その後の動きに個人・チームとして課題感を持っていました。
その課題感からリリース後に新たな取り組みを行ったので、開発サイクルに沿って紹介させていただきます。
アウトカムの設定（リリース前）
前述したように、弊社の開発組織ではリリース機能に対するアウトカムの設定を必須としています。
アウトカムは必ず要件定義段階で設定し、開発メンバー間で目線を揃えることでどこを目指して開発しているかの認識がずれないようにしています。
アウトカムとなる指標は観測可能にする必要があり、基本的に定量的な数値目標を設定しています。(例えば「◯◯の閲覧率◯%向上」など)
アウトカム観測（リリース後）
設定したアウトカムがリリース後に実際どのような結果になったのか観測します。(ここまでは以前から行っていた取り組みです)
アウトカムの観測準備はリリース前に済ませておき、リリース後は見るだけの状態になります。
リリース直後に結果が出るアウトカムは少ないので、通常リリース後1ヶ月後等に観測を行います。
利用状況の深掘り
アウトカムを達成するか否かに関わらず、実際の利用状況の深掘りを行います。
やり方は様々あると思いますが、私の開発組織ではリリースした機能のカスタマージャーニーに沿ってユーザーが期待した行動をとっているかどうかをGoogleAnalyticsやRedashを使って分析を行いました。
その分析結果を元に、プロダクトマネージャーやUXデザイナーも交えて改善に向けてどこがボトルネックになっているかを特定し、考えられる解決方法となるような仮説を立てます。
この利用状況の分析を開発に関わった全ての役割で行うことで、様々な角度から分析を行うことができたと感じています。
アウトカムの見直し
利用状況の分析のなどや単純な時間経過により、当初の要件定義段階とは前提としていた状況が異なりアウトカムが本来の目的とずれる可能性が往々にしてあります。
その場合は状況に合わせてアウトカムの再設定を行います。
一度設定したアウトカムはずらさないものと考えてしまいがちですが、より良いアウトカム設定が見つかれば大胆に変更することも大事だと考えています。
再リリース
「利用状況の深堀り」で得ることができた仮説を元に、改善方針を具体化して再度要件定義に落とし込み、開発後再リリースを行います。
この改善方針できちんと課題解決ができているか確認するために、再度アウトカムの観測・利用状況の深堀りを行うというフローを回します。
まとめ
いかがでしたでしょうか。
私の開発組織でもまだ課題を解決しきるまでこのフローを回しきってはいないのですが、リリースした機能に全員で責任を持って改善していくことで、役割に限らずプロダクトの価値を考えるいいきっかけになっていると思います。
補足として、当然この改善フローを回すことが自体が目的ではないので、アウトカムの観測や利用状況を深堀りする中で「この機能では狙った価値が実現できない」となったり、「狙っている価値自体がプロダクトにとって不要」という結論になれば機能自体を無くす判断も大事だと思っています。（ちょっと悲しい気持ちにはなりますが。。。）
興味持っていただけた方は、試してみてはどうでしょうか！うちではこういう風に改善してるよーという意見なども大歓迎です。