サービス企画やグロース施策を考えるとき、思考があちこちへ移動したり、毎回場当たり的に考えていたり、暗黙的に考え方を共有できていると思い込んだりしてしまうことに課題を感じていました。

無自覚的に行っている活動を体系的に整理することで「今何をしていて、何をアウトプットする必要があるか」が明らかになり、チームでの活動効率を高めることができました。

今回は、活用しているプロダクト改善サイクルをご紹介します。

プロダクト改善サイクル

外周にある4つの円がフェーズを示し、四角に書いてあるものはアウトプットを示します。

リーン・スタートアップ、デザイン思考、デュアル・トラック・アジャイルなどの考え方をベースにアレンジしています。Goodpatchのデザインプロセスの取り組みも参考にしています。

1. Leaning（学習）フェーズの目的

取り組むテーマの定義に責任を持ちます。
Leaningフェーズは、定量データ・定性データを活用し課題を明らかにします。

定量データから傾向を事実として捉え、定性データと照らし合わせて行動の原理を理解したり、定性データから定量データを分析してボリュームを測ったりします。データを解釈する活動の中で、どんどん想像が膨らんで目から鱗が落ちることがしばしばあります。

アイデアの種がぽろぽろと出はじめるので、楽しくなって解決方法の話ばかりしてしまっている状況になることがあります。このフェーズの目的からはズレるので、思いついたことはメモしておいて次のフェーズで存分に語りましょう。

責務が明確に分かれていることで議論の脱線から戻すことができます。

2. Discovery（発見）フェーズの目的

テーマに対する解決案の定義に責任を持ちます。
Discoveryフェーズは、課題に対する解決案を見つけ出します。

Leaningフェーズで明らかになった、ユーザー課題やサービス課題と向き合い、どのような方法が課題の解決に導くかを見つけ出します。PSF（プロブレム・ソリューション・フィット）とも言えます。

チームでアイディエーションしてみたり、プロトタイピングを実行したりして、より望ましいと考えられる解決手段の発見を目指します。目に見え、触れられるものを創造する楽しいフェーズですね。

3. Delivery（開発）フェーズの目的

解決案を実現することに責任を持ちます。
Deliveryフェーズは、作り上げユーザーに届けます。

Discoveryフェーズで見つけ出した解決手段をテストするため簡易実装を行うケースもあれば、本腰を入れて実装するケースもあります。

素早く要求に応えられるよう腕前を磨き、技術負債が溜まらないよう品質を保つ仕組みを考え、安定した動作が求められます。非エンジニアにとって理解しづらいことかもしれませんが、非常に重要なことです。

4. Measure（計測）フェーズの目的

測定可能な状態にすることに責任を持ちます。
明らかになった課題に対する解決案をユーザーに届けたあと、効果を測定します。

このフェーズは仕組みさえ整っていればとくに毎回する設計する必要はなく、必要に応じてログの仕組みを構築したり分析ツールを導入したりします。解決手段に対して何を計測するかはDiscoveryフェーズで定義します。

さいごに

厳格に責務を定義することで息苦しさのようなものを感じる方もいるかもしれませんが、実際は前後を相互に行き来したりすることはあります。

個人で活動するときは問題ないかもしれませんが、複数人で活動を行うときは「何をするための活動であるか」が定まっていると議論が拡散することを防ぎ活動効率を保てます。

この考え方をベースに、スキルや肩書を捉えるスライドも公開しているので、気になった方はぜひ読んでみてください。