読者の皆様、
Scrum.orgのプロフェッショナルスクラムトレーナー（Professional Scrum Trainer・PST）をしております、グレゴリー・フォンテーヌと申します。このブログでは、今後シリーズとして、海外のPSTが投稿した英文ブログの中から、質が高く日本の読者の皆様に関連性の高い記事の日本語翻訳版をご紹介していく予定です。このシリーズのブログ記事の全リストをご覧になりたい方はAgorax.jpのホームページから見ることができます。また、すべてのブログ記事には、私自身の短いコメントを添えております。
はじめに
この記事では、PSTであるロビン・シュアマン氏が、製品ロードマップについて考えるとき、単なる製品フィーチャーのリストを超えるものを作ることの重要性を説明しています。また、アジャイルチームとプロダクトオーナーのために、すぐに実行可能なテクニックとヒントも共有しています。機能開発よりも問題解決と価値創造に焦点を当てたより良い製品ロードマップは、よく見られるアンチパターンの解毒剤です。ぜひご一読ください！
----------------
著者：ロビン・シュアマン氏
英語版：Tips for Agile product roadmaps & product roadmap examples
あなたはプロダクトオーナーとして、プロダクトバックログやステークホルダーの管理、そして予測を担当します。そのため、進捗を追跡し、期待値を管理し、人に情報を提供するために、さまざまなツールやテクニックを使うことになるでしょう。プロダクトオーナーにとって便利なツールの1つが、製品ロードマップです。しかし、製品ロードマップを効果的に活用するのは難しいことです。製品ロードマップは、次の期間にわたる製品の開発可能性を記述した、ハイレベルで戦略的な計画であるという概念に基づいています。製品ロードマップは製品の目的とビジョンをサポートするものでなければならず、プロダクトオーナーがステークホルダーの足並みを揃えるのに役立ちます。製品ロードマップはまた、異なる製品の開発を調整しやすくし、顧客の期待値を管理するために透明性を促進する役割も担います。
多くの組織では、プロダクトオーナーがフィーチャーの開発に集中しているため、多くの製品ロードマップも提供すべきフィーチャーや機能で占められています。フィーチャーにフォーカスしすぎることのデメリットは、常に付加価値を生むフィーチャーが多くあるため、ビジョンやゴールへのフォーカスが欠けてしまうことです。フィーチャーにフォーカスしすぎることで、ロードマップは、プロダクトの将来的な開発のためのハイレベルな戦略的計画ではなく、過搭載のプロダクトバックログになってしまいます。
私はこれまで様々な製品ロードマップを見てきました。下記の3つのロードマップにはそれぞれ長所と短所がありますが、私はこれらのすべてが、プロダクトオーナーの業務に付加価値を与えるのを見てきました。個人的にも常にこれら3つのロードマップを組み合わせて使っています。特にプロダクト開発の初期段階では、プロダクトの機能に関してのインサイトをステークホルダーに伝えたるため、ストーリマップを使うことが多くあります。
目標指向製品ロードマップ（Goal Oriented・GO製品ロードマップ）
私が個人的にGO製品ロードマップで気に入っている点は、実際に行うべき作業（フィーチャー）よりも、プロダクトオーナーとして達成したいゴールに焦点を当てることができる点です。GO製品ロードマップはフィーチャーを追加する可能性を提供しますが、私は最終目標を念頭に置いて物事を始めるのが好きですし、すべてのプロダクトオーナーがそうすべきだと信じています。GO製品ロードマップならびに目標へ注力することは、ワークパッケージ（アウトプット）の舵取りではなく、価値の舵取り（結果への舵取り）を可能にします。GO製品ロードマップのこの点は、あなたがプロダクトオーナーとしてプロダクトのビジョン・戦略・ロードマップに責任を持たなければならない中で、貴重な点であると思います。
GO製品ロードマップのもう一つの側面は、目標の達成を可能にする上で、最も価値のあるフィーチャーについて考えさせられることです。アジャイル原則の一つに 「シンプルさ ー 無駄なく作れる量を最大限にすること」（アジャイル原則#10）があります。GO製品ロードマップのコンセプトの良いところは、僅かなスペースしかないため、必然的にリリースを実現する上で最も重要なフィーチャーの上位3つに集中せざるをえないというところだと思います。また、私がとても気に入っているのは、次のリリースまでの製品開発の概要を一目で把握できることで、ステークホルダーを管理するのにとても便利です！
組織の状況にもよりますが、私はGO製品ロードマップの日付とリリース名のセクションを省くことがあります。過去に、かなり多くのステークホルダーがロードマップの日付（私の視点から見て、それは予測にすぎませんでしたが）を見て、その日に確実に機能を受け取れると結論づけてしまうのを見てきたからです。私たちは変化する複雑な環境の中で仕事をしており、人は時間と共に考えを変えるため、これは必ずしもうまくいきません。そのため、私は状況に応じて日付とリリースのセクションを使ったり使わなかったりして、コミュニケーションを促し、ロードマップ項目の間違った解釈を防ぐようにしています。このような場合、私はGO製品ロードマップとNow-Next-Later製品ロードマップを組み合わせることが多くあります。
Now-Next-Later 製品ロードマップ
Now-Next-Later製品ロードマップは、どのような人にとっても理解しやすいため、私がとても気に入っている視覚化方法です。「Now （今）」の部分に現在取り組んでいること、「Next （次）」は間もなく取り組むこと、「Later（今後）」は時間的にさらに先のことであり、まだこれから優先順位をつけなければならないことなどを表示しますが、誰にでも簡単に理解できるため、全てのステークホルダーがこのモデルコンセプトを理解することができます。
私から見たこのロードマップのマイナス面は、プロダクトオーナーとして達成したいゴール／目標よりも、むしろフィーチャーに焦点が当てられていることです。それに加えて、このモデルにはKPI、リリース、日付を含める余地があまりありません。日付やタイムラインはステークホルダーにとって重要な情報であるため（私が経験したほとんどの状況で）、このロードマップを適用する際には、その点は考慮する必要があるかもしれません。一方、日付が含まれていないことで、ステークホルダーがロードマップを読むかわりに、あなたがステークホルダーと対話をする機会が生じますので、この点は実は利点と同じかもしれません。前述したように、私はNow-Next-Later製品ロードマップとGO製品ロードマップを好んで組み合わせて使っています。
ストーリーマップ
ストーリーマップはロードマップの一種で、私は新しいプロジェクトやプロダクトの初期に関わるときに好んでよく使っています。ストーリーマップは、あなたとあなたのステークホルダーが思いつく、製品にとって重要なフィーチャーすべてを網羅的に把握するための優れた方法です。考え方としては、将来どこかで開発される可能性のあるすべてのフィーチャーや機能の無制限のリストを作成することではありませんが、プロダクトの創造的なアイデアを促進するための素晴らしい出発点を提供します。私がストーリーマップで最も気に入っている点は、システムでカバーする必要のあるすべてのユーザーアクティビティの概要を提供することです。これにより、小さくて価値のあるユーザーストーリーを作成することができ、段階的かつ反復的に開発・提供することができます。
私がストーリーマップについて気に入っているもうひとつの側面は、ストーリーマップはユーザーの行動を起点としているので、プロダクトについてユーザーの視点を取り入れることができるという点です。このコンセプトの良いところは、ユーザーの視点からのブレーンストーミングを可能とするところです。結局のところは我々はユーザーや顧客のために製品を開発するのですから。
ストーリーマップの活用において、私が実際に目の当たりにしてきた主な欠点は、ストーリーマップはプロダクトのすべてのフィーチャーが開発されるかのような錯覚を引き起こしてしまうことだ。しかしながら、アジャイルである以上、プロダクトの完全な計画やブレイクダウンを作成することが目的ではないので、私のアドバイスとしては、新しいプロダクトの開発プロジェクトの初期段階にストーリーマップを使用することです。そうやって期待値をうまく管理するのです！
アジャイル 製品ロードマップのための11のヒント
こうした様々なタイプの製品ロードマップの情報が皆様のお役に立つことを願っておりますが、併せて覚えておいていただきたいのが、
「アジャイルとは、プロセスやツールよりも個人と対話のことである」ということです。そこで、インスピレーションを与えてくれたローマン・ピクラー氏に感謝しつつ、アジャイルな製品ロードマップを作成するための11のヒントを紹介いたします：
製品ビジョンから始める（ヒント：Roman Pichlerの製品ビジョンボードを使う）
プロダクト戦略を説明し、検証する
目標指向の製品ロードマップ（または、前に説明した他のタイプの1つ）を作成し、ゴールとベネフィットに焦点を当てる
プロダクトの成長見込みについて一貫したストーリーを語り、売り込みすぎないこと
シンプルにする！ロードマップに詳細を追加しすぎる誘惑に負けない
ステークホルダーと積極的に協力し、賛同を得る
ロードマップにフィーチャーが過剰になるのを防ぐために、ノーと言う勇気を持つ
ロードマップにタイムライン、日付、期限を追加することについて、熟考する
測定可能な目標やKPIを追加して、ロードマップが測定可能であることを確認する
機能の実行可能性を判断するために、各機能の概算見積もり（#人+必要スキル）を作成する
製品ロードマップを定期的に見直し、適応させる。