Googleプロジェクト管理：バリュー・ロードマップ

はじめに

わたしが Google プロジェクト管理:プロフェッショナル認定証で得られた素晴らしい体験を、要点をまとめ小さく分割して、わかりやすく簡潔に紹介していきます。

興味があれば、ぜひ "Google プロジェクト管理:プロフェッショナル認定証" を受講してみてください。

バリューロードマップ

プロジェクトマネージャーとしてのあなたの仕事は、チームが価値を提供することに集中できるよう支援することです。そのための素晴らしい方法は、バリューロードマップを作成することです。

ロードマップは、製品開発プロセスのタイムラインと要件をマッピングするアジャイルな方法であり、あらゆる種類のビジネスで使用することができます。

『ロードマップは、価値を最大化するために、どこに行き、どのようにそこに到達し、その過程で何を達成すべきかを示すガイドである』

ロードマップの作成は、チームが製品のビジョンを説明するのに役立ち、また重要なマイルストーンを特定するのにも使用されます。

バリューロードマップの要素

典型的なバリューロードマップは、

• プロダクトビジョン
• プロダクトロードマップ
• リリース計画

の3つの要素で構成されています。

1.プロダクトビジョン

バリューロードマップの最初の構成要素は、プロダクトビジョンです。プロダクトビジョンは、新しいスクラムプロジェクトを開始するための重要なステップである。ビジョンはユーザーインタビューと市場分析に基づいており、あなたのチームを導くものです。

プロダクトビジョンは、

• 製品が何であるか？
• それが顧客のビジネス戦略をどのようにサポートするか？
• そして誰がそれを使うか？

を定義します。

2.プロダクトロードマップ

次に、プロダクトロードマップです。これは、プロダクトオーナーが作成と維持に責任を持つものです。

ロードマップは、

• 期待される製品の上位概念
• 要件
• マイルストーン達成のための推定スケジュール

を提供します。これは、あなたのチームが正しいものを作っているかどうかを確認するための鍵です。

3.リリース計画

バリューロードマップの3つ目の構成要素は、一連のリリース計画です。プロダクトオーナーとプロジェクトマネージャが協力して、この計画を策定します。製品のリリースは、チームが特定の機能または要件の基本的な実用版を開発したときに発生します。リリース計画には、チームが特定の機能をリリースし、顧客やユーザーに提供する予定のおおよその日付が含まれています。

アジャイルチームは、プロジェクトが完了したとみなされるまで、プロジェクト期間中に何度かリリースを行うことがあります。このため、最初のリリース日だけが確定している と考えるべきです。リリース計画の残りの部分は、初期の見積もりに基づいており、プロジェクトの進行に伴って変更される可能性があります。

リリース計画には、

• リリースに含める予定の機能に関する全体的なビジネス目標であるリリース目標、そのリリース目標に必要なエピック、ユーザーストーリー
• 機能などのBacklog項目のリスト
• 推定リリース日
• コンベンションや大型連休など、リリースに影響を与えるその他の関連する日付

が含まれます。すべてのリリース計画をバリュー・ロードマップに追加して、全体的なバリュー・ゴールへの道筋に集中できるようにすることが重要です。

この3つは、アジャイルチームが複数のイテレーションを通じて目標に到達するために協働します。バリューロードマップは、チームが協力的で、すべてのステークホルダーが定期的に一緒に仕事をする場合にのみ機能します。これによって、プロジェクトがアジャイルの価値観と原則に沿った結果を達成することが保証されます。

プロダクトロードマップ

プロダクトロードマップを作成し、維持することのメリットは数多くあります。

• 成果物の順序を明確にする。
• チームの取り組みが北極星のビジョンにどのように関係しているかをチームに示す。 言い換えれば、彼らの究極の目標。
• プロジェクトの過程で達成される増分値をステークホルダーに示す (終了時に１つの大きな成果としてレビューするのではなく)。
• ステークホルダーが、成果物の背後にある作業のレイアウトをおおまかに理解できるようにする。

避けるべき落とし穴

また、ロードマップには、避けるべき落とし穴があります。

• ステークホルダーに、ロードマップは決まっていて変更できないものだと思わせてしまうことです。これは、ステークホルダーが新しい情報に対応するチームの能力を阻害し、何が何でも納期を達成しなければならないというプレッシャーをチームに与えることになりかねません。
• 納期の微調整に多くの時間を費やし、納期が近づくにつれ、大まかな納期を維持し、具体性を高めていく。
• 成果物を作るより、ロードマップを作ることに全力を注いでしまう。

ベストプラクティス

ロードマップを最大限に活用するためのベストプラクティスを紹介します。

• ロードマップはチームの目に留まるようにし、頻繁に参照する。
• 最も優先度の高い項目を明確に示す。
• 可能であれば、最も価値の高い項目を明確に示す。
• ロードマップを幅広いステークホルダーから見えるようにし、彼らの計画立案に活用できるようにする。
• スポンサー、ステークホルダー、チームと定期的にロードマップのレビューを行い、ロードマップがプロジェクトの青写真を提供し続けていることを確認する。

効果的なバリューロードマップを作成するためのヒント

ヒント1: プロダクトロードマップの作成

マイルストーンの多くは、製品のリリース日です。製品リリース日は、あくまでも 概算 であることを確認する必要があります。

これは、アジャイルチームとして、物事は変わる可能性があり、実際に変わるからです。もし、ロードマップが具体的すぎると、日付が保証されないので、チームが失敗する可能性がある。

ヒント2: リリース計画

プロダクトオーナーとプロジェクトマネージャーまたはスクラムマスターが協力して各リリース計画を作成する ことが非常に重要です。

なぜなら、リリース計画では、プロダクトロードマップとチームのキャパシティとベロシティを結びつける必要があるからです。キャパシティとベロシティは、チームが一定のペースで仕事を完了する能力を示すものである。チームの仕事を完了する能力と結びついていないリリース計画は、非現実的であり、チームのペースを維持できなくなる可能性があります。

これは、アジャイルの原則の1つである「アジャイル･プロセスは持続可能な開発を促進します。」 に違反することになります。スポンサー、開発者、そしてユーザは、いつまでも一定のペースを維持することができるはずです。ロードマップにハードデートやデッドラインがある場合、つまり変更できない日付がある場合は、影響を受ける可能性のあるリリース計画にそれらを織り込んでください。

アジャイルは変化を受け入れ、予測することが重要なので、リリース計画を持つことは、計画に従うことよりも変化に対応することの実際の価値に反するように思われるかもしれません。

しかし、リリース計画を持つことは、あなたが変化に抵抗することを意味するものではありません。そして、アジャイルチームは、リリース計画を生きた成果物として扱います。ですから、計画は環境や受け取った新しい情報に基づいて変更することができます。

リリース計画の変更につながる可能性のある一般的な要因

• チームのベロシティ。これは、チームメンバーの追加や脱退、あるいは単に作業方法の効率化などによるものかもしれません。
• 製品スコープの変更である。プロダクトオーナーが製品への変更を承認した場合です。
• 特定の機能を構築するためにどれだけの労力が必要なのかの理解を深めることです。あるユーザーストーリーやエピックが、当初考えていたよりも難しい、あるいは難しくないことが、調査や製品スペースの理解を深めることで判明するかもしれません。

ヒント３: リリース計画のレビュー

スクラムマスターやプロジェクトマネージャは、スプリントプランニングセッション開始前に、常にリリース計画をレビュー すべきだということです。彼らは、チームが軌道に乗っているかどうかをチェックするためにリリース計画を見直します。

もしチームが軌道から外れていたら、スクラムマスターはプロダクトオーナーやビジネス担当者とオープンな会話をし、軌道に乗るために何を調整すればよいかを考える必要がある。ここで、スクラムの価値である「透明性」が重要になります。