デザインと開発の分断を乗り越え、チームでアウトカム検証を回すプロセス
リーン開発の課題、Sense→Discovery→Deliveryのプロセス分断をどう乗り越えるか
リーン的なアウトカム検証には、不確実性が高い段階から「Sense（課題発見）」「Discovery（ソリューション発見）」「Delivery（製品開発）」の3つの仮説検証トラックが存在すると考え、Gaudiyでもこれに近い運用を行なっています。
「UXのダブルダイヤモンド」や「デュアルトラックアジャイル」などの
考え方を参考にこのように定義しています。
そして、リーンやアジャイル的な考え方では、これらはプロセスではなく考え方の区別であり、各トラックの仮説検証サイクルをチーム全員で回すマインドセットが重要とされます。
しかし現実では、タスクの性質や責務を担うメンバーの違いから、各トラックのプロセスが閉じることで「ウォーターフォール開発」に近い進め方なってしまう、なんてことが多々起きてしまいます。
特に多いのが、Discoveryがデザイナー中心に閉じたプロセスになることで、開発が受託的な進め方になってしまうパターンかなと思います。
これを回避するために、「Discovery段階から開発メンバー含めたチームをどう巻き込むか？」「どういう巻き込み方がコンテキスト過多にならない適切な範囲か？」などを考えながら日々試行錯誤しています。
この記事では、PdMとして自分が参加している開発チームで、こうした分断を避け、ワンチームでアウトカム検証を回すために、具体的にどういった取り組みをしているのかシェアできればと思います。
Sense→Discoveryの接続をなめらかにする
「グロースサイクル」を共通言語化し、「どこに向かっているか」の目線をすり合わせる。
チームで同じ目的意識を持ち、納得感のある開発をしていくためには、なぜこの機能開発がプロダクトの成長につながるか？を説明できる必要があります。
僕たちのチームでは、「グロースサイクル」を定義することで、プロダクトの重要な変数を可視化し、各施策がどの変数改善に繋がっているのかをチームで共通認識を持つようにしています。
実際作成している「グロースサイクル」👇
※内容は一般化しています。
「グロースサイクル」と「ソリューション仮説」を紐付ける。
Discoveryフェーズへの接続として、グロースサイクルの各変数を改善するための「ソリューション仮説」を発散、可視化します。（※実際には、この発散までに「ユーザーストーリー」や「B=MATモデル図」など、グロースサイクルをもう一段階具体化したモデリングを行う場合が多いです。）
Discovery以降は、「ソリューション仮説」ベースでチケットが管理されていきます。
また、各変数ごとに関連KPIを設定し、デイリースクラムのnotionのテンプレに、「現在どの変数を改善しようとしているか」「該当KPIに関するデータ」の情報を組み込み、毎日確認できるようにしています。
Discovery→Deliveryの接続をなめらかにする
「Lean UX キャンバス」で、「アウトカム」と「検証仮説」を明確にすることで、目的を絞り議論の焦点を合わせる。
Discoveryで発散した意見を収束させていく中で、共通の目的意識をチームで持てている状態は重要だと思います。
このソリューションで達成したいアウトカムは何か？最も優先的に検証すべき仮説は何か？この問いを明確にすることで、議論の無駄な発散を避け、目的に立ち返って、MVPをチームで議論することができます。
この際、便利なフレームワークとして「Lean UX キャンバス」を活用しています。この形式に沿って整理することで、ビジネス/ユーザー双方視点でのアウトカムと、最も学習すべき検証仮説を定義できます。
Deliveryに進まずストップすることもよくあります。
Discovery段階でも、重要な意思決定ポイントでは開発メンバーを巻き込み意思決定する。
Discoveryの全てのプロセスに開発メンバーが関わることは現実的ではありませんが、発散/収束で意思決定をする特定ポイントで、チームを巻き込んでいくスタンスがちょうどいい塩梅かなと感じています。
① プロトタイプを見ながら開発メンバーと仕様を議論。
だいたい1周目の発散→収束を回すとプロトタイプができてくると思うのですが、この段階で開発メンバー含むチームで仕様や実現するHowのアイデアを話し合います。
全員がこの段階から議論参加することで当事者意識を高め、また、発散後のタイミングで細かく、Howの実現可能性を開発メンバーと議論することで、不確実性を下げながらDiscoveryを進めることができます。
② PoC実装で不確実性を検証しながら、MVPラインを一緒に探る。
特に以下のような場合に、PoCを先に実装し検証を進めていきます。
・実装の不確実性が高く、実現方法を調査したい
・実際の挙動やアニメーションなどを含めた体験を確認したい
Deliveryに本格的に入る前に、こうしたPoC実装を挟む場合も多く、この結果も踏まえ、最小の開発コストで最大アウトカムを狙えるMVPラインを決めていきます。
③ 「ユーザーストーリーマップ」でMVPを可視化し、開発チケットと連携する。
こうして固まっていく仕様は、「ユーザーストーリーマップ」形式で可視化します。
ストーリーに基づいたユーザータスクの一つ一つが、開発チケット化としてバックログに追加されます。MiroとJiraを連携することで、Miroのユーザータスクから直接、Jiraの開発チケットを作成できるのでおすすめです。
また、改めて開発/Bizメンバーも含めたチーム全員で「ユーザーストーリーマップ」を確認し、仕様アイデアや、仕様の残論点、実装不確実性などを明らかにし、こちらもチケット化します。
開発する中で変更/追加される仕様や、QAで出た改善点なども、ユーザーストーリーマップに追加していくことでアップデートされます。
スクラム開発プロセスにDiscoveryを組み込む。
チームはスクラム開発のプロセスで運用されるため、このプロセスにDiscovery活動をマージし、統合された運用を構築します。
① スプリントでDiscoveryタスクを可視化する
スプリントプランニング時に、デザイナー/開発メンバー双方が参加し、Discovery / Deliveryそれぞれのプランニングを行います。
可視化されたタスクは、同じカンバンで管理され、開発チケットと同様に毎日のデイリースクラムで確認しています。
毎週のスプリントで、Discovery段階のエピックと、
Delivery段階のエピックが同時並行で進みます。
② スクラムイベントで同期で議論するタイミングを用意する
Discovery内容をチームで議論できる機会を、スクラムイベント内に用意しておくことで、アウトプットがリアルタイムでチーム全体に共有され、開発メンバー含めた議論を誘発できます。
毎日のよもやま会で、PdM/デザイナー/CSがDiscovery内容を議論し意思決定する。
毎日のデイリースクラムで、「デザイン確認」をアジェンダとして用意し、デザイナーがチーム全体に仕様やデザインを相談する。
週一のスプリントレビューで、Discovery/Deliveryそれぞれの成果を発表する。
最後に
今日上げた取り組みが、みなさまの何かの気づきになれば嬉しいなと思います。まだまだ、各トラックの仮説検証サイクルが融け合うプロセスを模索中かつ、悩みは尽きないので、同じ悩みをお持ちの方はぜひお話ししましょう笑
Gaudiyでは、カジュアルトークや、訪問ごはんもやっているので、お気軽にどうぞ！
この記事が気に入ったらサポートをしてみませんか？