はじめに
わたしが Google プロジェクト管理:プロフェッショナル認定証で得られた素晴らしい体験を、要点をまとめ小さく分割して、わかりやすく簡潔に紹介していきます。
興味があれば、ぜひ "Google プロジェクト管理:プロフェッショナル認定証" を受講してみてください。
リリース計画の変更を実施する際に重要な考慮事項
アジャイルはその4つの価値の1つを "計画に従うことよりも変化への対応を"に捧げています。今回、リリース計画の変更を実施する際に重要な考慮事項を紹介します。
計画の変更について考える最良の方法は、それを3つの段階に分けることです。
- 必要な変更を特定する
- 変更を行うことを決定する
- 変更を実行する
1. 必要な変更を特定する
まず、計画を変更する必要があるかどうかは、どのように判断すればよいのでしょうか。
ここでは、変更候補となりうるプロジェクトの側面として、「スコープ、時間、コスト(またはリソース)」を挙げます。これらは「三つの制約」と呼ばれ、アジャイルや従来のプロジェクトにおける変更を評価するための素晴らしいフレームワークを提供します。
-
スコープ
- ロードマップの内容、バックログの項目、プロジェクトの意図する成果物、意図するユーザーや顧客のことを指す。
- これは、プロジェクトの「何」である。
-
時間
- 時間的な要素や一定期間の成果物の配置を指す。
- ロードマップのタイムライン、リリーススケジュール、あるいはスプリントの期間などが含まれる。
- これは、プロジェクトの「いつ」である。
-
コストやリソース
- 開発チーム、プロジェクトマネージャー、プロダクトオーナー、その他の「ビジネスパーソン」の構成や、成果物を作成するために利用できる設備などを指す。
- これは、プロジェクトの「方法」である。
アジャイルプロジェクトは、これら3つの領域のいずれにおいても、変更に対してオープンであり、必要な変更は、プロダクトオーナー、プロジェクトマネージャー、スクラムマスター、または開発チーム自身を含む、プロジェクトのあらゆるステークホルダーによって特定される可能性があります。
特定された変更の情報源は以下の通りです。
- 初期プロトタイプに対する顧客フィードバックの結果、新機能が追加され、一部機能が削除される (スコープ変更)。
- レトロスペクティブにより、人員不足のエリアが特定された (コストまたはリソースの変更) 。
- プロジェクトの重要な依存関係または成果物の日付がシフトしたため、プロジェクトのロードマップが変更された (スケジュールまたは時間の変更)。
2. 変更を行うことを決定する
次に、実際に変更させることをどのように決定するのか?意思決定のモデルは数多くあり、参考にすることができます。ここでは、これらのモデルの多くに含まれる基本的なステップを紹介します。
-
決定権者を特定する。
- 一貫性と説明責任を確保するために、プロダクトオーナーや上級ステークホルダーなど、一人の人間が決定者の役割を担うのがベストです。
- 意思決定において重要な要素は何かを検討・共有し、決定者が意思決定するのに役立つ データを収集する。
- 意思決定のメリットとコスト をオープンに議論する。不確実性のある領域を特定し、前提条件を把握する。
- 決定を文書化する。
3. 変更を実行する
変更が承認されたら、いくつかのことを行うことが重要です。
-
変更と意思決定のプロセスを文書化する。
会議のメモ、賛否両論リスト、仮定、プロジェクトの変更を決定するために使用したデータなどを含める。 -
影響を受けるすべての成果物に変更を記録する。
ロードマップ、バックログ、人員配置計画、統合期日を更新し、利害関係者が参照できるように、変更元への参照を含める。ドキュメントが変更されたことをチームが明確に認識できるように、影響を受けるドキュメントに「バージョン1.2」や「12月20日更新」などのリビジョンラベルや日付を使用することを検討します。 -
影響を受けるすべてのステークホルダーと変更内容を共有する。
ミーティング、文書、ミーティングノート、電子メールによる告知など、さまざまな方法で行うことができます。 -
一定期間、変更を監視する。
これにより、チームがサポートされ、変更を認識することができます。
決定段階で変更が承認されなかった場合でも、決定に使用した情報と論理を文書化する必要があります。より信頼性の高い決定を下すために、より多くの情報を待つ間、変更を保留にすることも検討できます。