プロダクトマネージャー（PM）をしている澁田敦紀です。
この記事はリンクアンドモチベーション Advent Calendar 2021の25日目の記事になります。
まだまだ若い組織ですが、それ故に迷いや葛藤が多く、面白い記事が多いと思います。
他の社員が書いた記事も読んでいってください！
プロダクトマネージャー（PM）とは
プロダクトを育てる役目です。そのためには、経営層などのステークホルダーをまとめ、セールスやエンジニアからなるプロダクトチームを率いる必要があります。
その幅広い役割から、「ミニCEO」と呼ばれたりします。
プロジェクトマネージャーとは異なる役割です。※兼任することはよくあります
これはなにか
私がPMを担っているB2Bプロダクトのチームが行っている開発手法の"デュアルトラックアジャイル"について、
その概要を紹介します。
基本的に以下のnoteより抜粋しつつ、エンジニア向けに、デュアルトラックアジャイルで気をつけることを書きます。
私のチームで行ったデュアルトラックアジャイルの具体事例やより詳細な内容を知りたい方は、noteにて！
デュアルトラックアジャイルとは
本記事では、
「ディスカバリー（粗い検証）とデリバリー（細かい検証）の両トラックを並行して行う開発手法」
と定義します。
ディスカバリーとは
私は”粗い検証”と考えています。
この”粗い検証”を行わずに開発をしてしまうと、不要な機能を開発してしまうかもしれません。
プロダクトの価値を損なわないために、顧客課題とその打ち手の仮説検証を行います。
顧客へのヒアリングがよくディスカバリーとして取り上げられるため、デザイナーとPMがやるものと思われがちです。
しかし、あくまで”粗い検証”を行うフェーズのことのため、エンジニアがやることも十二分にあります。
デリバリーとは
ソリューション提供を行います。所謂コーディングを伴う開発がデリバリーになることが多いです。
一方で、「デリバリー ＝ 開発すること」ではありません。
デリバリーもまた、検証であり、むしろデリバリーこそが”細かい検証（＝本検証）”と考えています。
そのため、デリバリーは「実装してリリースしたら終わり」ではなく、その後のデータ分析を含んでいます。
アジャイルと何が違う？
よく言われることですが、アジャイルは状態です。
「Don’t just Do Agile, Be Agile」という言葉が有名かと思います。
とは言え、アジャイルな組織が行う開発として、「計画→設計→実装→テスト」のイテレーション（＝反復）を繰り返す形式を取ることが多いです。
また、その開発を進めるためには朝会を開いたり、カンバンを使ったりすると思います。
このような仕組みの中でパフォームする組織の状態がアジャイルです。
では、デュアルトラックアジャイルはアジャイルと何が違うのか？
チームの状態としては、アジャイル
チームの動きとして、デュアルトラック＝２つの領域で検証を行う
のがデュアルトラックアジャイルです。
なぜ「デュアルトラックアジャイル」を行うのか
そもそも、プロダクト開発は顧客の課題解決のために行います。
決して目的はプロダクト開発ではありません。目的はあくまで課題解決です。
と言うことは、顧客の課題を知ることが重要です。
また、明らかになった課題への打ち手を色々試し続ける必要があります。
この顧客の課題を知ることを、CPF（Customer/Problem Fit）
顧客の課題に対する打ち手を決めることを、PSF（Problem/Solution Fit）
打ち手をプロダクトとして提供することを、SPF（Solution/Product Fit）
と呼びます。
つまり、常に「CPF→PSF→SPF」の流れを作り、素早く仮説検証をし続けることが、
顧客の課題解決への近道になると思います。
これを実現する開発手法として、私はデュアルトラックアジャイルを選びました。
ディスカバリーでは、粗い検証としてCPFとPSFを目指し、
デリバリーでは、確度の高まった課題と打ち手のSPFによる顧客の課題解決を目指します。
エンジニアが気をつけるべきこと
私がデュアルトラックアジャイルを行う中でぶつかった大きな壁が3つあります。
- 言葉の壁
- PM・デザイナー・エンジニア間での言葉（の意味）の違い
- 空間の壁
- ディスカバリーとデリバリーで異なるタスクを行うメンバー間での亀裂
- 時間の壁
- 短期視点にとらわれ、目的を見失う
これらを乗り越えられたのは、チームのエンジニアのみなさんのおかげです。
エンジニアメンバーのどの様な働きかけによって壁を乗り越えたのかを書きます。
デュアルトラックアジャイルに限らずぶつかる壁だと思うので、ぜひ参考にしてください。
言葉の壁
私はよく、プロダクトの「Core-Why-What-How」について話します。
PMをしていると、当たり前に通じる言葉だと思って使ってしまっていました。
ある日、エンジニアより指摘を受け、チーム内で同じ言葉を発しても、それぞれの思っている意味が異なることに気がつけました。
PMやデザイナーの言葉で分からないものがあれば、聞き流すのではなく、
チーム内で共通の意味を理解できるよう働きかけてください。
また、エンジニアが普段使っている言葉も同様に、PMやデザイナーには伝わらない可能性も忘れないでください。
私のチームではこちらの書籍をみんなで読むことで、プロダクト開発で使う言葉の意味をチーム内で揃えました！
空間の壁
エンジニアは開発をメインで行うことになると思います。
そのため、ディスカバリーよりもデリバリーのフェーズにタスクを持つことが多くなり、
ディスカバリーの進捗への興味が薄れ、デリバリーの開発だけに目を向けてしまいがちです。
ディスカバリーから降りてきたタスクを開発する役目になってしまうかもしれません。
そうなると、デュアルトラックアジャイルの意味を失います。
ディスカバリーの内容はチームで理解すべきで、
チーム全体で課題解決のための検証を回すのがデュアルトラックアジャイルです。
エンジニアからディスカバリーの内容に興味を示し、情報を受け取り、PMやデザイナーに意見を言ってください。
そして、エンジニアは開発者ではなく、課題解決者であることを忘れないでください。
自分の記事にはなりますが、こちらの記事が関連するため、良かったら目を通してみてください！
時間の壁
アジャイルのスピード感で仕事をしていると、今に熱中してしまいます。
もちろん悪いことではありません。
しかし、ふと落ち着いて数カ月後や数年後のプロダクトのことを考えると、
今やっていることが間違いであることに気がつくかもしれません。
もしくは、今やっていることの意義を再認識し、更に熱中できるかもしれません。
未来を描くロードマップをつくるのはPMの役割かもしれませんが、
エンジニアが知らないで良いなんてことはありません。
ぜひ、未来の話をチームでしてみてください。
おわりに
デュアルトラックアジャイルはとても魅力的な開発手法です。
同時に、大きな壁があり、チーム全員で立ち向かわなければなりません。
私は、そんな挑戦を出来ていること、素晴らしいチームで働けることをとても嬉しく思います。