プロジェクト・マネジメント-課題 | 治事 / PRINCE2 / 注疏

課題

PRINCE2 課題プラクティスの目的は、課題を収集して評価し、プロジェクトのベースラインに対する変更をコントロールすること。

プロジェクトは絶え間なく変化する組織的・環境的状況の中で進められる。プロジェクトのスコープが広く期間が長いほど、課題や変更への対応が必要になる確率は高くなる。課題マネジメントはプロジェクト・モニタリングの中核であり、情報をフィルタリング(検閲)せずに適切に扱うことが、変化への対応力を維持する鍵となる。

基本定義

用語	定義
課題	プロジェクト・マネジメント上の検討を必要とする、プロジェクトに関連するイベント。チームメンバーや利害関係者によって随時提起され、プロジェクト・ログに記録される
変更	プロジェクトのベースラインを構成する承認済み成果物に対する修正。適切な権限を持つ個人または役割によって承認されるまでは、ベースラインには組み込まれない
プロジェクト・ベースライン	変更コントロールの対象となるマネジメント成果物およびプロジェクト成果物の現在の承認済みバージョン

事前判断の回避: 評価を行う前に課題の良し悪しを判断してはならない。
変更への姿勢: 変更は回避すべきものではなく、すべてのプロジェクトで必然的に発生するものである。対応力のあるコントロールされた方法で対処することが重要である。

課題マネジメントの構成(ガイダンス)

課題マネジメント・アプローチは、以下の要素で構成される。

ベースライン: 変更コントロールの対象となる成果物やドキュメントを明確に定義したもの。
課題解決: 発生した課題を特定・把握・評価し、最適な解決策を提案するための手順。
変更コントロール: プロジェクトのベースラインに対する修正や変更を、どのように管理・制御するかを説明するもの。
変更に関して委任された権限: 迅速かつコントロールされた対応を可能にするため、プロジェクト委員会から特定の個人や役割に割り当てられた意思決定権限。
変更予算: 予測される変更や課題への対応に備え、計画段階であらかじめ確保しておく資金。

1. ベースライン

変更の影響を評価するには、プロジェクト委員会が承認したベースラインが必要である。

変更の可視化: 変更が承認・実施されるたびに新しいバージョンが作成される。変更コントロールにより、変更の時期や決定権限を追跡できる。
判断すべき事項: プロジェクトの規模に関わらず、チームは以下の内容を定義しなければならない。
- ベースライン化のレベル: 成果物を単独でリリースや修正が可能なレベルまで分解する。
- 識別方法: 各成果物に固有の識別子(ID)を付与するシステムを確立する。
- 記録情報: バージョン・ステータス・他の成果物との依存関係など、プロジェクト・ログに保持すべき情報を決定する。
- 承認権限: ベースラインの承認に必要な特定の権限や認可フローを明確にする。
整合性の検証: 成果物の実際の状態が承認された状態と一致しているかを定期的に検証する。一般的には各ステージの終了時やプロジェクト終了時に実施される。

2. 課題解決

すべての課題は適切に分類・評価され、プロジェクトマネジメントのどの側面が機能していないかを特定するための貴重なデータを提供する。

課題の分類: 課題は以下のいずれかに分類する。
- 問題(Problem): すぐにマイナスのインパクトを受ける課題。
- 懸念事項(Concern): 適時性と影響を評価すべき事象。
- 外部のイベント: プロジェクトの外部環境で発生し、プロジェクトに影響を及ぼす可能性のある事象。
- ビジネス機会(Business Opportunity): プロジェクトやユーザー組織にとって、予期していなかったプラスの結果をもたらす事象。
リスクとの区別: 課題を評価する際、それが**不確実な事象(リスク)か既に発生した事象(課題)**かを確認する。不確実性がある場合は、リスク登録簿に移転して管理する。
記録と分析:
- 課題登録簿: すべての課題を記録する。
- 課題報告書: 詳細な分析が必要な場合に作成し、種類・ベースラインへの影響・推奨される解決策をまとめる。

3. 変更コントロール

プロジェクトのベースラインに影響を与える可能性のある変更を特定・評価し、承認、却下、または延期を決定する。

変更要求(Request for Change): ベースラインに対する変更の具体的な提案。対象のマネジメント成果物を特定し、変更の正当な理由を提示しなければならない。
仕様外項目(Off-specification): 品質仕様(期待される機能や基準)を満たしていない成果物。必ず変更コントロール手順を通して処理する。
条件付き承認(Concession): 仕様外項目のうち、プロジェクト委員会が是正処置を求めずに現状のまま受け入れること。

4. 変更に対する委任された権限

変更要求や仕様外項目のレビューおよび承認に関する最終権限はプロジェクト委員会が持つ。

委任が少なすぎる場合: 些細な変更決定のためにプロジェクト委員会の判断を仰ぐことになり、意思決定の遅延や進捗の停滞を招く。
委任が多すぎる場合: 多くの役割に権限が分散しすぎると、ビジネス正当性との整合性が取れなくなりプロジェクト全体のベネフィットが損なわれるリスクがある。
変更許可委員の設置: プロジェクトの規模や複雑性に応じて、プロジェクト・マネジメント・チーム内の複数のレベルで変更許可委員を任命することで不要なエスカレーションを防げる。

5. 変更予算

変更予算の形態: 通常は変更対応のために特別に確保された資金(金額)を指すが、状況によってはトレードオフが可能な認可された制約条件として定義される。
権限と予算のセット運用: プロジェクト・マネージャーは、変更に関する委任された権限に対し、その変更を実際に実行できるだけの適切な変更予算が伴っているかを確認しなければならない。

5ステップの課題マネジメント技法

課題マネジメントは、以下の標準的な5ステップの技法を用いて実施される。

課題の把握(Capture): 課題を特定し、その内容を正確に認識した上で、課題登録簿または課題報告書に記録する。
課題の評価(Assess): プロジェクトのビジネス目標・スケジュール・コスト・品質・リスクに対する課題の影響度を分析する。
変更の勧告(Propose): 複数の解決策を検討し、コスト・ベネフィットのバランスが最も良い解決策を推奨事項としてまとめる。
変更の決定(Decide): 適切な権限を持つ者が、提案された解決策を承認・却下・または延期するかを決定する。
変更の実施(Implement): 決定に基づいた処置を実行する。これにはベースラインの更新やワーク・パッケージの修正・追加などが含まれる。

課題を評価する

課題をレビューする際は、その種類を特定し、プロジェクトへの具体的な影響度を明らかにする。

統合評価の視点: 承認済みのターゲットと許容度・ビジネス・ケース・他の成果物との依存関係への影響を考慮した統合的な評価が必要である。
トレードオフの検討: 納期の延期と引き換えに品質を高めるなどのトレードオフや条件付き承認の検討も含まれる。

変更を決定する

種類	対応	検討内容
変更要求	承認	変更コストの調達源を特定する(変更予算の使用・他スコープの縮小・または追加資金の要求)
変更要求	却下	変更を拒否してもビジネス正当性は維持され、予想ベネフィットが実現可能かを確認する
変更要求	例外計画書の要求	品質仕様が厳しすぎることが原因で、承認された許容度の変更による解決できる場合に適切な対応となる
変更要求	詳細情報の要求	決定を延期し、承認・却下によるインパクトが複雑な場合にさらなる分析を求める
仕様外項目	受け入れる	ビジネス正当性への影響を評価する。ベースラインを更新し条件付き承認として記録する
仕様外項目	却下	解決策を検討する(変更予算の活用・例外計画書の提出・契約上の救済手段)

支援技法

根本原因分析(RCA): 問題を要素分解し、表面的な現象ではなく真の主要原因を特定する。
パレート分析(80/20ルール): 結果の80%は原因の20%から生じるという法則に基づき、最も影響の大きい原因を優先的に特定する。
原因と結果の分析(フィッシュボーン図): 重要な要因をカテゴリー別に分類し、視覚的に整理する。
故障モード影響分析(FMEA): 成果物やプロセスで発生しうる故障をすべて洗い出し、その結果を評価する。プロトタイプ等が存在する場合に有効。
5つのなぜ(5 Whys): 「なぜ?」を繰り返すことで問題の深層を探る。統計データが不足している場合でも使えるシンプルなツール。

プラクティスを支援するマネジメント成果物

課題マネジメント・アプローチ(プロジェクト立ち上げ文書の一部)

目的: 課題を把握して報告する方法を記述し、プロジェクトのベースラインに対する変更を評価およびコントロールする方法を説明する。
コンテンツ概要:
- スコープ: 課題マネジメント・アプローチのスコープの説明
- プロジェクトベースライン要素: プロジェクトのベースラインを構成するマネジメント成果物のリスト
- 課題の報告と解決の手順: 課題の発生・報告・解決の説明
- 変更コントロール手順: プロジェクトのベースラインに対する変更の要求・決定・組み込み・検証方法の説明
- 変更予算: 認可された変更予算と、ステージまたはワーク・パッケージ・レベルでの割り当て
- 責任: 変更許可委員の委任など、課題マネジメント・アプローチに関連する役割の実行責任

課題登録簿(プロジェクト・ログの一部)

目的: プロジェクト・ライフサイクル中に発生したすべての課題報告書・現在のステータス・終了日を記録する。
コンテンツ概要:
- 課題の識別子: 課題の一意の参照コード
- 課題の種類: 問題・懸念事項・外部イベント・ビジネス機会・変更要求・仕様外項目
- 格付け: 優先度と重大度の評価
- ステータス: 課題の現在のステータス(記録済み・レビュー済み・処置済みなど)
- 決定: 課題に対応する決定のレコード

課題報告書

目的: プロジェクトのベースラインに対する課題のインパクトを説明し、課題を解決する方法を特定し、決定を推奨する。
コンテンツ概要:
- 記述書: 課題の要因・原因・インパクトの概要
- インパクト分析: プロジェクトのベースラインへのインパクトの分析
- オプション: プロジェクト・ユーザー・サプライヤーが課題に対応する方法
- 勧告: プロジェクト・マネージャーまたはチーム・マネージャーが推奨する決定

主要な役割と責任

役割	主要な責任
ビジネス・レイヤー	課題マネジメントと変更コントロールのためのビジネス・レイヤーの方針・標準・手順を提供する。プロジェクト・レベルの変更予算を承認する(使用している場合)。エスカレーションされた課題に対応する
プロジェクト・エグゼクティブ	プロジェクト・レベルの変更予算が必要かどうかおよび必要な金額を判断する。ステージ・レベル変更予算を設定する。課題マネジメント・アプローチを承認する。ビジネス正当性の継続を重視してエスカレーションされた課題に対する意思決定を行う
シニア・ユーザー	予想ベネフィットを守ることを重視してエスカレーションされた課題に対する意思決定を行う。課題マネジメント・アプローチに合意する
シニア・サプライヤー	ソリューション全体の完全性を守ることを重視してエスカレーションされた課題に対する意思決定を行う。課題マネジメント・アプローチに合意する
プロジェクト・マネージャー	利害関係者と協議して課題マネジメント・アプローチを準備および維持する。課題および変更コントロール手順を管理する。課題登録簿を管理する。是正処置を実施する
チーム・マネージャー	ワーク・パッケージ記述書で合意された課題と変更コントロール手順を実施する。是正処置を実施する
プロジェクト保証	課題マネジメント・アプローチについてプロジェクト・マネージャーに助言する。課題マネジメント・アプローチがビジネスの方針に準拠していることをプロジェクト委員会に確認する
プロジェクト支援	課題登録簿の維持・プロジェクトのベースラインの維持・プロジェクト・マネージャーによる課題報告書の作成支援を行う

原則との主要な関係

原則	達成方法	結果
ビジネス正当性の継続の確保	課題と変更がビジネス・ケースへのインパクトとプロジェクトの正当性の観点から評価されるようにする	課題と変更に対処し、プロジェクトが全体的なビジネス戦略に合っている
成果物重視	課題と要求された変更をプロジェクトのベースラインにリンクする	変更のトレーサビリティと成果物との明確な連携が確保される
例外によるマネジメント	課題マネジメントの権限と手順を確立する	プロジェクト・マネージャーがプロジェクト委員会から委任された権限内で課題を管理し、決定を下し、例外を報告するための効率的な手段
プロジェクトに合わせたテーラリング	プロジェクトの重要性と複雑性、選択したデリバリー手法、成果物の特徴に適したレベルの変更コントロールのみを要求する	コントロールと対応力の適切なバランス

他フレームワーク補足

概念	PRINCE2	PMBOK	PgMP
課題・変更管理の文書	課題マネジメント・アプローチ・課題登録簿・課題報告書	変更管理計画書・変更ログ	(今後追記)
変更の種類	変更要求・仕様外項目・問題/懸念・外部イベント・ビジネス機会	変更要求(是正処置・予防処置・欠陥修正・更新を含む)	(今後追記)
変更承認権限	プロジェクト委員会(変更許可委員への委任可)	変更コントロール委員会(CCB)	(今後追記)