デュアルトラックアジャイル虎の巻 ver1.0
本記事は
「プロダクトづくりのための挑戦とその成功・失敗談を綴るアドベントカレンダー powered by プロダクト筋トレ Advent Calendar 2021」
の12/25枠として投稿します。
リンクアンドモチベーションでPM（プロダクトマネージャー）をしている
澁田敦紀です。
私がPMを担っているB2Bプロダクトのチームが行っている
デュアルトラックアジャイルについて
その概要と実際に行ったこと、得られた成果、苦悩と対策
を書きます。
これからデュアルトラックアジャイルを行おうと考えている方、すでに行っている方の参考になれば良いと思います。
当記事はかなり長くなってしまいましたが、エンジニア向けに軽く書いたものをQiitaに投稿しましたので、主にエンジニアの方はそちらから読んでもらうと良いかも知れません。。
超まとめ
デュアルトラックアジャイルは素晴らしい開発手法である
チームの言葉を揃えるのが大切
デュアルトラックアジャイルはデュアルトラック化すべきでない
PMは未来と意味を語れ
デュアルトラックアジャイルとは
本記事では、
「ディスカバリー（粗い検証）とデリバリー（細かい検証）の両トラックを並行して行う開発手法」
と定義します。
ディスカバリーとは
先述の通り、私は”粗い検証”と考えています。
この”粗い検証”を行わずに開発をしてしまうと、不要な機能を開発してしまうかもしれません。
プロダクトの価値を損なわないために、ユーザー課題とその打ち手の仮説検証を行います。
デリバリーとは
ソリューション提供を行います。所謂コーディングを伴う開発がデリバリーになることが多いです。
一方で、「デリバリー ＝ 開発すること」ではありません。
デリバリーもまた、検証であり、むしろデリバリーこそが”細かい検証（＝本検証）”と考えています。
そのため、デリバリーは「実装してリリースしたら終わり」ではなく、その後のデータ分析を含んでいます。
最初はこちらの記事を参考にはじめました↓
なぜ、デュアルトラックアジャイルを行うのか
そもそも、プロダクト開発はユーザーの課題解決のために行います。
決して目的はプロダクトを作るためではありません。
目的はあくまで課題解決です。
と言うことは、ユーザーの課題を知ることが重要です。
また、明らかになった課題への打ち手を色々と試し続ける必要があります。
このユーザーの課題を知ることを、CPF（Customer/Problem Fit）
課題に対する打ち手を出すことを、PSF（Problem/Solution Fit）
打ち手をプロダクトとして提供することを、SPF（Solution/Product Fit）
と呼びます。
（諸説あると思いますが、私はこう考えています）
SPFでユーザーの課題が解決されていないことが分かれば、次なる打ち手の提供を行います。
また、明らかに課題への打ち手となっていない機能になってしまっていた場合、その機能を消す決断を迫られることもあります。
SPFはただの「開発」ではなく、「ユーザーの課題が解決されたのか？」を検証するフェーズです。
つまり、常に「CPF→PSF→SPF」の流れを作り、素早く仮説検証をし続けることが、ユーザーの課題解決への近道になると思います。
これを実現する開発手法として、私はデュアルトラックアジャイルを選びました。
ディスカバリーでは、粗い検証としてCPFとPSFを目指し、
デリバリーでは、確度の高まった課題と打ち手のSPFによるユーザーの課題解決を目指します
実際に行ったこと
ここでは、CPF〜SPFの各フェーズにおいて、直近私のチームで行ったことや注意すべきことについて書きます。
CPFに向けて
まず、ユーザー課題（＝ プロダクトで提供したい価値が実現できない理由）の仮説検証を行いました。
方法はいたってシンプルで、実際にユーザーの声を聞くために、ヒアリングを実施しました。
PMが実際にヒアリングを行うことが良いのかもしれませんが、私が複数プロダクトのPMを兼務しており時間を割きにくいこと、チームのデザイナーがリサーチに強いこともあり、ヒアリングはデザイナーにおまかせしました。
しかし、デザイナーに投げっぱなしではなく、以下のような方法で密に連携しました。
検証する仮説を立てる
そりゃそうだろって感じだが、検証の対象になる仮説が超重要
ペルソナやジャーニー、現状の利用データなどから仮説を立てる
ヒアリングの目的をすり合わせる
ヒアリングシートの内容はもちろん、ヒアリングの目的も含め、しっかりとすり合わせる
デザイナーのヒアリングを録画してもらい、視聴する
デザイナーが記入したヒアリングシートも見ながら認識を合わせる or 自分の認識と異なる部分を抽出する
ヒアリング結果をすり合わせる
ユーザーのインサイトを見抜くために議論
PMとデザイナーで見解が異なる場合や、複数のインサイトを考慮できる場合、追加のヒアリングを行う
PMとデザイナーで閉じない
上記のヒアリングシートや動画、結果の議論内容などをチームのエンジニアにも展開する
どんな些細なものでも良いので、エンジニアからも意見をもらう
このヒアリングを経て、ユーザー課題を抽出し、より課題感が強く、プロダクトで提供したい価値の実現に影響するものを複数ピックアップしました。
すべて大事だと思いますが、実は4つ目が一番重要だと感じています。
理由は「SPFに向けて」の部分にて！
PSFに向けて
CPFとして定めたいくつかのユーザー課題に対して、その打ち手を考案し、ユーザーに当てることで確度の高いものへと磨きました。
方法は、プロトタイプを用いたヒアリングを行い、ユーザー課題が解消されそうかを検証しました。
ここでも実際に注意していたことを挙げます。
CPFのヒアリングと同じく、密に連携を取る
プロトタイプを作り込まない
XDやFigmaでさっと作れる人はそれでも良いかもしれないが、
数pxの調整に時間をかけない既存の画面のスクショに切り貼りをしたものなどで、
「要するに何が出来るようになるのか」を伝えられればそれで良いクソコラ能力を鍛えましょうなんならスライドで十分
SPFに向けて
PSFでユーザー課題が解決できると思えた要件をプロダクトに乗せて提供し、実際にユーザー課題が解決されたのかを検証しました。
まず、プロダクトに機能として作っていきましたが、極力研ぎ澄ました最小の要件での提供を目指しました。
所謂MVP（＝ Minimum Viable Product）ってやつです。
このMVPの要件を開発するためには、ユーザー課題の解像度をチーム全体で高めておく必要がありました。
だからこそ、CPFやPSFを目指すディスカバリーをPMとデザイナーで閉じないことがとても重要だと感じました。
こうして実装を終えた機能をリリースして完了ではありません。
ユーザー課題を解消できたのか？を検証しました。
まずは、redashやGAを用いて定量的なデータ分析を行いました。
そのために、予めユーザーの成功指標を定め、指標を計測するためにデータ分析が出来るように開発をしておきました。
もちろんユーザーの声も重要です。
課題が解決されたか？に加え、新たな課題は生まれていないか？についても注意して検証を行いました。
MVPで開発する
そのために、チーム全体でユーザー課題の解像度を上げる
検証のための準備をしておく
成功指標を定義しておく
計測出来るように開発する
リリースして終わりではない
リリース後の検証こそ本番！！
この検証もチームで行い、密に連携する
得られた成果
まず、確度の高い機能を提供することができ、ユーザー課題を確実に解決していけたと思います。ユーザーや社内からポジティブな声を多くいただき、事業も前進したと感じています。
また、社内で初めての取り組みだったこともあり、他のプロダクトでも同様に仮説検証という考え方やユーザーヒアリングの重要性が広まりました。
さらに、顧客の理解が深まったこともあり、ペルソナのアップデートも行いました。
ペルソナの作り方については、この記事では詳細を書きませんが、以下の記事を参考に目的に応じて複数種を使い分けています。
苦悩と対策
ここでは、赤裸々に私が苦悩した３つの壁（現在進行系で苦悩しながら進んでいますw）と、その対策として行ったことを書きます。
３つの壁
言葉の壁
PM・デザイナー・エンジニアで使う言葉（の意味）が違う…
空間の壁
ディスカバリーとデリバリーでチームが分断しそうになる…
時間の壁
スプリントに注力しすぎて未来が見えなくなる…
言葉の壁と対策
これはデュアルトラックアジャイルを行う前からの苦悩でもありましたが、密に連携をしようとすると必ず現れる大きな壁です。
チームで仕事をしていて忘れがちなのは、前提知識が違うということです。
前提知識が違えば、使う言葉も意味も変わります。
そのままではチームとして同じ課題解決に向かうことはできません。
この数ヶ月の話になりますが、私のチームでは、プロダクトマネジメントの前提知識を揃えたいと考え、「プロダクトマネジメントのすべて」を全員で読みました。ただ読むだけではなく、章ごとに区切って感想と議論したいポイントを持ち寄ることで、共通言語にすることができました。
特に、私がよく使っていた「Core-Why-What-How」が実は全く通じていなかったことが明らかになったのが良かったですw
「Core-Why-What-How」についてはこちらの記事を参照↓
空間の壁と対策
ディスカバリーでユーザーの課題とそれに対する打ち手を探している間、デリバリーでは確度の高い課題と打ち手の開発を行います。
そうなると、各々のフェーズを担っているメンバー間で自分のフェーズにしか注意が向かなくなりがちです。
「事件は現場で起きてるんだ！」と言わんばかりに自分の仕事に向かうと思います。
しかし、その状態ではデリバリーはディスカバリーで決まったものを作るだけになり、デリバリーが細かい検証として機能しなくなります。
もしくは、せっかくディスカバリーで粗い検証を行ったにもかかわらず、デリバリーで考慮しなくても良い案が現れ、二度手間になってしまいます。
さらに、ディスカバリーがデリバリーの視点を持てていないと、せっかくユーザー課題の特定をしておいて、本当に課題が解決されたのかまで検証をしなくなってしまいます。本末転倒！！！
私は、以下の方法で極力コミュニケーション量を増やしました。
毎日30minのDailyMtgにてディスカバリーとデリバリーそれぞれの進捗共有を行う
slackにディスカバリーの話をするチャンネルを作り、デリバリーメインのエンジニアも巻き込んで議論する
ヒアリング動画を見る習慣を持ってもらい、些細なことでも良いので感想や意見を出してもらう
Gatherに集まって仕事することで、コミュニケーションの量を担保する
私の考えは以下です。
デュアルトラックアジャイルは、デュアルトラック化すべきでない
より正確に言うと、
デュアルトラックアジャイルを行うチームは、全員でディスカバリーとデリバリーを行うべきである
あくまで、デュアル（＝2つ）なのはトラック（＝検証する領域）であって、チームではないです。
しかし、デュアルトラックと聞くと2つのチームを連想する方が多いのではないかと思います。私も最初はそう考えてしまっていました。
実際には2つの検証を同時に行うためには、それぞれにメインで行うメンバーは固定されると思います。
それでも、決して2つのチームではなく、あくまでワンチームでデュアルトラックに挑むことでデュアルトラックアジャイルはその真価を発揮します。
時間の壁と対策
最後の壁は、チームの壁であるとともに、第一にPMの私が乗り越えるべき壁だと思います。
ここまで書いた通り、デュアルトラックアジャイルはかなり忙しい開発方式です。（楽な開発方式なんてないと思いますがw）
チームの全員が、ディスカバリーとデリバリーで異なる思考を行き来することになります。
そうなると、短期視点に陥りがちです。目の前のスクラムをこなすことだけに注力してしまいます。
その結果、確かにユーザーの課題ではあるが、長期的な事業インパクトにはあまり影響のない課題に時間を割いてしまうこともあります。
プロダクトとしての究極の目的は何なのか？
そのために解決すべき課題は何なのか？
目先のディスカバリーやデリバリーだけにとらわれず、長期の視点で未来を語り、本当に解決すべき課題のためにデュアルトラックアジャイルを行うことがPMである私の役割です。
意識していれば出来るのか？というと結構きつかったですw
私は、以下の方法で自分及びチームの長期視点を担保しました。
ロードマップにディスカバリー・デリバリーで検証したいことをそれぞれ書く（機能名では書かない）
※確度が高まって機能まで落とせた場合は機能で書きますロードマップはチームの全員がいつでも見れるようにしておく
（自分）ロードマップを毎日見る
4半期や月などの節目のタイミングで、直近のディスカバリー・デリバリーがどんな意味を持っているのか、今後のディスカバリー・デリバリーを何のためにするのかをロードマップ等でチームとすり合わせる
おわりに
長々と書いてしまい、めっっちゃ読みにくくなってしまいましたが、ありのままに書きました。
誰か一人でも参考になれば嬉しいです。
結局の所、デュアルトラックアジャイルは粗い検証と細かい検証を行い、ユーザーの課題解決をするものです。
そのためには、チームの一体感が必要となります。
そんなチームのメンバーと一緒に仕事ができていることを自慢させてください！！日々苦しくも楽しくやらせていただいています！！！w
おまけですが、チームのエンジニアの方から言われて嬉しかった言葉についてQiitaに記事を書きました。良かったら読んでください！
この記事が気に入ったらサポートをしてみませんか？