継続的なプロダクトディスカバリー🔍を通じてチーム間の隙間を埋める
📝 どんな方に向けて書いてみたか
1. プロダクトディスカバリーに興味がある方
2. スクラムにディスカバリーを組み込みたい方
-> 意義や進め方をサンプル・事例として知れます
-> 他者をどう巻き込んだかを記載しています
こんにちは。かつやま🌝です。
私はクライアントと共に、プロダクトの価値最大化を目指し、日々勤しんでいます。その中で継続的なプロダクトディスカバリー🔍(デュアルトラックアジャイル)にトライしました。振り返りも兼ねて本noteを記します。
本noteの位置付け
書籍📖「プロフェッショナルプロダクトオーナー」において、プロダクトマネジメントとは「すきまを埋めることである」とあります。継続的なプロダクトディスカバリーやUXリサーチはビジョンと開発チームの隙間を埋める手段です。より効果的なプラクティスとして、デュアルトラックアジャイルを採用しました。
本noteでは導入ステップとその際のチームビルディング周辺を書きました。
本note📝に記載されていること
なぜデュアルトラックアジャイルを導入したか
導入ステップとチーム・メンバーの流れ
注意：現時点ではデュアルトラックアジャイル(もどき)です
導入結果に対する主観感想（良い点・悪い点）
本note📝に記載されていないこと
デュアルトラックアジャイルとは何か
デュアルトラックアジャイルって結局何なの？ を参照ください
ディスカバリーのリサーチ手法に対する経験考察
インタビュー、コンセプトテストは説明無し
なぜデュアルトラックアジャイルなのか
最小単位で失敗し、反復して得た学びを共通理解できる点でデュアルトラックアジャイルを採用しました。特に 3️⃣ が採用を決定付けした要素です。
1️⃣ Verticalで狭い領域だった
取り組む領域がVerticalで市場が比較的小さいため、定量的な意思決定が困難でした。そのため、N1リサーチの積み上げがプロダクトをより良くする(逆にそれしかない)と考えました。また、ターゲットが個人事業主だったことも要因の一つです。toBでもありtoCでもあるため、価値観を理解して進める必要があると考えました。
2️⃣ ドメイン知識を保持していない
チームがドメイン知識を保有していませんでした。そのため、不確実性が大きく、それに対処するためにアジャイルになる必要がありました。これは「何をどのように作るか」だけでなく「なぜ必要なのか」も強く焦点が当たります。この点から、最小単位で失敗と学習ができるデュアルトラックアジャイルが適していました。
3️⃣ 会社間で情報の非対称性が生じる
クライアントワークとしてプロダクト開発に取り組んでいます。したがって、会社間では非常に大きな「情報の非対称性」が生じます。正直、これは努力・やる気やツール・仕組みではカバーしきれないものです。
その中でもユーザー・顧客からの「声」や「学び」を会社間で分断せず、蓄積することが重要と考えました。そのためには、インタビューやユーザビリティテストを通じ、自身で経験することが一番だと捉えています。本事象に対して、良いプラクティスと捉えました。
導入ステップとチームの隙間
ここでは、デュアルトラックアジャイルの導入ステップと、それにおけるチームの隙間が埋まる流れを記載しました。ただし、前提として、なぜデュアルトラックアジャイルなのか(課題)と実現に向けた進め方をチームや組織に宣言し、合意を得ることが重要だと思います。
デュアルトラックアジャイルの導入にあたって色々なものを参照しました。どの書籍やドキュメントでもディスカバリーとデリバリーが分離することはアンチパターンであるが、一度はその道を通ると書かれていました。上記を受けて、導入にあたって作戦を考え、実行しています。
ステップ ⌛
1️⃣ ディスカバリーとデリバリーを完全分断する
2️⃣ 横断したチームをPMが繋ぐ
3️⃣ デリバリーメンバーがディスカバリーに参加する
4️⃣ディスカバリーとデリバリーでチームがまとまる
用語 📝
- アイデア：ディスカバリーする最小単位です
- アイテム：デリバリーする最小単位です
ステップ 1️⃣ ディスカバリー島とデリバリー島を分けて作る
初めに、ディスカバリーとデリバリーを分離してチーム構成しました。ミニウォーターフォール状態を作りました。これはよくアンチパターンとして取り上げられていますが、中間地点として経由しました。まずは、私自身も含め、メンバーそれぞれがデュアルトラックアジャイルのイメージができる状態を目指しました。
ディスカバリー：アイデアのリサーチを行う（探索と検証の両方）
ディスカバリー：要求定義とUXを検討し、必要なら価値検証する
ディスカバリー：プロダクトバックログにアイテムを入れる
デリバリー：スクラムイベントに合わせて推進する（詳細省略）
このステップでは、メンバーに色々なモヤモヤが生まれる予感があり、課題感が進めていく中で色々出てきました。
ディスカバリーとデリバリーで無駄なコミュニケーションが発生する
ディスカバリーが製造に専念したチームになる
プロダクトオーナーが誰か曖昧になる（どっちの島？）
ディスカバリーを経由しないアイテムがオーナー不在になる
アイデアとアイテムの優先度が一致しない
︙ などなど
また、ディスカバリーとデリバリーでバックログも分離しました。それぞれ、Jira Product DiscoveryとJiraで取り組んでいます。ツールは何でもよいと思いますが、本ステップではそれぞれのチームができる限り疎な状態を作り、それゆえの課題を認知して潰していくことが目的だったため、バックログは分けました。
ステップ 2️⃣ ディスカバリー島とデリバリー島に架け橋を作る
次にPMがディスカバリーするアイデア単位で島を横断し、伝達し、広げていく役割を担います。この役割によって、そのアイデアが「どんな人が」「なぜ必要なのか」を伝え、デリバリー島民に要求を伝えることができます。
この状態を作ると無駄なコミュニケーションは無くなりますし、スクラムのプロダクトオーナーが明確になります。また、デリバリー島が孤立状態になることを避けられます。チーム全体でディスカバリーをしている状態ではないが、ディスカバリーで何を学んだかを知識として蓄えた状態にできます。
ステップ 3️⃣ デリバリー島民がディスカバリー島に移住する
次のステップです。デリバリー島民がディスカバリーに参加します。ただし、全員がディスカバリーの全てに参加することは不要ですし、無駄と考えます。気になるユーザー・顧客へのインタビューや興味を持ったアイデアに対するリサーチに絞りつつ、徐々に挙手制にします。結果的に、アイデア推進主体になってもいいです。
ステップ 4️⃣ 一つのチームになる
ステップ 3️⃣ が当たり前になれば、一つのチームになります。隙間(プロジェクトマネジメント的要素)が無くなり、メンバーから対等に議論が生まれる、そんなチームを目指しています。
導入してみてどう感じているか
さて、私たちはまだステップ 2️⃣ と 3️⃣ の段階です。そのため、デュアルトラックアジャイル(もどき)ではありますが、導入した結果としては色々な思いがあります。最後にその部分を簡単に記載します。正直、理想的にできているぞ！という感覚がまだそこまでなく、課題がたくさん出てきます。
デュアルトラックアジャイルはあくまで手段、ということを最近はふとした瞬間に思います。それに固執する必要も無いのではないか？と。これらを踏まえ、ディスカバリーをプロジェクト化するような進め方を最近はトライ中です。チームメンバーでディスカバリーをプロジェクトとして進める整理の方が、小難しくないようにも思います。
デュアルトラックアジャイルとカッコつけずに、もっとユーザー・顧客に真摯に真っ直ぐであれ！みたいな精神論・根性論が私は実は好きです。
このアイデア「やらない」という意思決定が素早くできる
ディスカバリーである程度具体化していく中で、このアイデア筋悪じゃね？ってシーンが度々あります。そのアイデアに対して「やらない」意思決定が数時間・数日で行えることは継続的なディスカバリーの強い価値に感じています。
学習と成長の繰り返しが生まれる
ディスカバリーを継続して行うため、ドメインやユーザー・顧客の価値観を知り、学習できるポイントはやはり大きな価値だと感じました。
また、特にディスカバリーに関しては都度進め方を検討する必要がありました。このアイデアを具体化するためには、これまでの取り組み(インタビュー、ユーザビリティテスト、コンセプトテスト…)は適していないかもしれない、じゃあどうしようか？という思考プロセスを辿ります。特に、不確実性に対する姿勢のようなものが身につきました。
油断するとプロダクトが大きな成長をしなくなる
油断していると、ディスカバリーサイクルに合った小さな課題を改善という負のスパイラルにハマります。プロダクトがほぼ変わってない状態に陥る未来がよく見えました。本noteでは言及しませんが、やはり「プロダクトビジョン」である意思決定の指針が必要と感じました。私たちも改めて言語化し、明確にした上で臨んだ結果、負のスパイラルから逸れられるようになった気がします。
手段が目的になる瞬間が「めちゃくちゃ」ある
とんでもなく、この瞬間が多いです。1週間に何回もヤベってなります。チームメンバーがふと「モヤモヤ」を感じているときは、大体この状態になっています。常に主観と客観を行ったり来たりしないと、成立しません。PMが俯瞰的に物事を見る瞬間を定期的に設けたり、チーム内で雑談したりして「モヤモヤ」をキャッチアップすることで、回避を試みました。
デュアルトラックアジャイルを辞めるのであれば、これが強い要素になりそうです。
小さなチームだからこそできる
デュアルトラックアジャイルを導入しているというnoteなどはいくつかありますが、正直一つのスクラムチームでも大変だった、というのが本音です。メンバーも10名を超えると厳しいと感じており、5名前後が妥当な感覚値です。島が3つ(デリバリー島が2つ？)はお手上げです。
さいごに
デュアルトラックアジャイルの導入までを振り返りしつつ、書いてみました。難しいものだなと改めて感じますが、それでも継続的なディスカバリーの学習・成長効率は非常に良かったとも思います。特にチームをリーディングするプロダクトマネージャーには良い経験でした。
今回のnoteは以上で終わりますが、ディスカバリー・デリバリーの具体経験や考察は別記事で言語化していきたいと思います。あまり、noteのようなものは続かないタイプなので、ゆるりと頑張ります。
導入にあたって参考にしたもの
この振り返りや言語化において、改めて全て読み直しました。皆様、お知恵頂きありがとうございます。