Product Roadmaps Relaunched - アジャイルにおける正しいロードマップの形とコミュニケーション
さて、プロダクトマネージャーとプロダクトチームにとって、プロダクトロードマップは常に議論の中心です。今回この本をあらためて学習しようと思ったのは、プロダクトマネージャーのキャリアを通じて、いつもロードマップとそれにまつわるコミュニケーションは悩みの種だったからです。
機能ベースで書かれたロードマップの締切と遅延について、ビジネスチームとプロダクトチーム双方がひどいストレスを抱えている。
顧客からの要望が列をなしており、場合によっては新規契約獲得のための実装が優先されたりもしている。
ほとんどの場合にスケジュールが優先され、スコープや品質が許容範囲以上に犠牲になってしまう。
思い当たるフシのある方いますか？僕はぜんぶ思い当たります。
Product Roadmaps Relaunchedのスコープ
この本のスコープは、プロダクトロードマップそのものに留まらず、プロダクトマネジメントの上流部分を広範囲にカバーしています。以下のような内容が網羅的に説明されており、かなり実践的な内容になっています。
ロードマップにおける必須要素と任意要素
その材料となる情報のインプットとまとめ方
プロダクトビジョンと戦略の立て方
テーマを使った顧客ニーズの深堀り
優先順位付けのロジック
ステークホルダーとの合意の方法
シェアとプレゼンテーションの方法
ロードマップを常に最新の状態に保つ方法
日本語版が発売されていないので、読むのにかなり時間が掛かりました。内容としてはアジャイルを前提としたプロダクトマネージャーにとって理解しておくべきコアに触れられているので大変おすすめです。ちなみにScrum Alliance の Certified Scrum Professional Product Owner(CSP-PO) の講義の内容とかなり近かったなと感じました。
アジャイルが前提に書かれている
本の内容を実践に移す前の大前提として、すべてはアジャイル開発を前提として書かれています。つまりプロダクトチームが能動的に顧客のインサイトを理解し、解決方法を考えて実装するような組織を前提として書かれているので、そうでない場合は全くフィットしないでしょう。
特に大事だと感じたポイント
この本は広範なテーマを扱っているため、すべてについて言及するのは難しいですが、特に印象に残った（あらためて気付かされた）部分だけ書いておこうと思います。
１．ロードマップはアウトカムベースで書かれるべきで、リリースプランとは明確に異なる。
こんなロードマップはだめ
よく見るスタイルのロードマップで、本書が明確に「悪いロードマップ」として定義しているのは、機能ベースで書かれたWBSのような詳細計画です。これはデリバリー計画書、もしくはプロジェクトプランで、ロードマップではありません。すべてのデリバリーには期限が書き込まれていて、それらはステークホルダーに約束として認識されています。
それによりプロダクトチームは、デリバリー期日を守る守らないというやり取りに疲弊し、無駄な事前の設計や見積もりの要求を受けるとこになります。
こういったロードマップとコミュニケーションがもたらすものは、アジャイルに必要な失敗を前提とした柔軟性の喪失と、目的を見失ったビルドトラップ（本書ではフィーチャーファクトリーと言っている）です。対して、それらを避けるための「良いロードマップ」の条件としては以下のように定義されています。
よいロードマップとは何なのか
組織全体からの賛同と、期待を超えたデリバリーを促す
どのようにプロダクトビジョンを達成しようとしているのかの意図を表す
組織のストラテジーが反映されている
価値のデリバリーにフォーカスされている
失敗から学ぶことを奨励している
組織を単一の優先順位にアラインする
顧客をプロダクトの方向性に熱狂させる
基本となるのは、「アウトプットよりアウトカム」であり、コミュニケーションの軸をアウトカムに移していくことによって、柔軟性をもった正しい価値提供ができる状態にしていこうというのがメインテーマです。
プロダクトロードマップはデリバリー計画書とは明確に異なるものであり、これらを混同してはならないのです。
ロードマップの具体例
これは必須要素だけをシンプルに記載した例（本の中で紹介されている架空の園芸用ホースの会社）ですが、基本的なコンセプトはこの中に十分表現されています。
ロードマップの必須項目が含まれている：プロダクトビジョン・測定可能なアウトカム（Objective）、タイムフレーム、Disclaimer（免責事項）
すべてのテーマ（「壊れないホース」など）はプロダクトビジョンとアウトカムを達成するためのものが配置されている。
タイムフレームは細かすぎないこと。Now/Next/Futureぐらいがちょうどよい。全体の期間はプロダクトステージによって異なる。
また、これらの必須要素に加えて以下のようなコンポーネントを加えることができるが、必要最低限にとどめることが推奨されています。
プロダクトエリア：大規模で複雑なプロアクトの場合
機能/ソリューション：前回からの持ち越し、または確実性が高い場合
ターゲットカスタマー
確信レベル：テーマに対処する自信の度合い
なるべく要素を排除したほうが理解がしやすく、誤解が生じにくいというのは直感的に理解できます。これであればテーマと目的（Outcome）に主軸を置いた共通理解が図れるし、各機能のデリバリー期日について不要な（不毛な）コミュニケーションも減るでしょう。
また、場合によってはこれらにConfidence Level （確信度）を加えます。
２．優先順位付けは公式に基づいてやる（それだけではないけど）
ロードマップのアイテムの順位づけは、常に一番の関心事項かもしれません。この本では、優先順位付けのアンチパターン、フレームワークと公式を使った科学的な（？）優先順位付けの方法について説明がなされています。
こんな優先順位づけはだめ
だれかの直感
アナリストの意見
顧客からの要望の頻度、顧客のサイズ
セールスやサポートからのリクエスト順
他社製品の模倣競争
エグゼクティブの直感やアナリストの意見を検証なしにロードマップにするのはいかにもダメとわかります。また、顧客からの要望はより根源的な問題の一部であることが多いので、より顧客のJTBD（ジョブ）を解決するための良い方法を主体的に考えるべきでしょう。
また、一時的にセールスの数字を向上させるよりも、本来的には市場全体にどう貢献するかを優先させるべきだし、既存顧客の要望に応えることが新規顧客獲得につながるとは限らないからです。
公式を使った優先順位
CN: 顧客価値、B: ビジネス価値、E: エフォート、C: 確信レベル、P: 優先度
基本的な考え方として、Value（価値）を構成するのは顧客価値とビジネス価値の合計と定義されています。これはプロダクトビジョンの項でも出てきましたが、どちらかに偏ってはいけないというものです。
つまり、顧客価値とビジネス価値を両方とも高め、少ないエフォートで、最も実現の確信度が高いものが優先されるという考え方です。エフォートはTシャツサイジングします。
価値を定義するためのフレームワークは以下のようなものがあります。それぞれの説明については割愛します。
クリティカルパス: ユーザーのJTBDを叶えるために必要不可欠なフロー
Kanoモデル
Feasibility, Feasibility, Desirability, Viability
スコアリングの例
３．顧客とロードマップを共有する
ベンチャーは当たり前にやっている、お客を味方にするやり方。
自分はベンチャー企業でプロダクトマネジメントをやるかたわら、自分で営業もやっていたとき（なにしろ2人で立ち上げたビジネスだったので）、強く実感していたことがあります。
それは、商品を売るのではなく、顧客に自社のファンになってもらうことの大切さです。つまり、「売る人と買う人」という関係値ではく、「僕たちこういうことを成し遂げたいので、協力してくださいっ！」という、いわば顧客にステークホルダーの一員になってもらうのです。
もちろん新しいアイデアを顧客とディスカッションしますし、プロトタイプを見てもらったり、時には先行投資のような意味合いでローンチカスタマーになってもらったりするのです。
ロードマップをお客さんに公開しよう
本書でも「顧客とロードマップを共有する」ことの可能性について言及されていて、それを読んだときに「これだ」と思いました。もちろんリスクもあり、たとえばコミットのように受け取られてしまったり、ユニークなプロダクトの情報がリークしてしまう可能性もあります。
しかし、自分の感覚としてはそれらのリスクをも上回るメリットがあるのではと感じます。そもそも、具体的実現方法に触れなければ決定的な情報がリークする危険性は少ないですしね。
ということで、個人的にはお客さんにどんどん、「自分たちの考えているビジョンとロードマップはこれなんです。アドバイスしてくださいね。そして、できればこの未来にを実現する手助けをしてくれませんか？」と語りかけてしまって良いと思うんです。
まとめ
ここに書いたこと以外にもたくさんの良いアイデアが載っているので、ロードマップにかかわるプロダクトマネージャーには包括的なおさらいの意味も含めて（プロダクトマネージャーになりたての人は学習のために）、ぜひ読んでみてください。英語の長編なので、ある程度歯ごたえはありますが。