プロジェクト・マネジメント-課題

課題

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

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

基本定義

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

運用の考え方

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

マネジメントのためのガイダンス

課題マネジメント・アプローチは、プロジェクトにおける変更や諸問題を適切に管理するために、以下の要素で構成される。

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

1. ベースライン

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

• 1.1. ベースラインの役割と管理 効果的な課題管理と変更コントロールには、成果物のベースライン作成が不可欠となる。
  • 変更の可視化: 変更が承認・実施されるたびに新しいバージョンが作成される。変更コントロールにより、変更の時期や決定権限を追跡できる。
  • アプローチの決定: 課題マネジメントのアプローチは、成果物の性質(何を作るか)とデリバリー活動(どう作るか)によって決まる(通常、成果物記述書やワーク・パッケージ記述書の作成後に策定される)。
  • 整合性の検証: 成果物の実際の状態が承認された状態と一致しているかを定期的に検証(レビューや監査)する。一般的には各ステージの終了時やプロジェクト終了時に実施される。
• 1.2. 判断すべき事項 プロジェクトの規模に関わらず、チームは以下の内容を定義しなければならない。
  • ベースライン化のレベル
    • 成果物を単独でリリースや修正が可能なレベルまで分解する。
    • プロジェクトの重要性や成果物間の複雑な関係性を反映する。
  • 識別方法: 各成果物に固有の識別子(ID)を付与するシステムを確立する。
  • 記録情報: バージョン、ステータス、他の成果物との依存関係など、プロジェクト・ログに保持すべき情報を決定する。
  • 承認権限: ベースラインの承認に必要な特定の権限や認可フローを明確にする。
  • 管理手順: 課題や変更を把握して管理するための手順。
• 1.3. 管理システム
  • マネジメント成果物: 文書として維持し、バージョンと承認日を簡潔に記録する。
  • スペシャリスト成果物: 内容に応じて専用のシステム(構成管理ツール等)。
  • 成果物登録簿: プロジェクト・ログの一部として、ベースラインに対するすべての変更承認と実施記録を保持する。

2. 課題解決

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

• 2.1. 課題の分類 課題は以下のいずれかに分類する。
  • 問題 (Problem): すぐにマイナスを受ける課題。
  • 懸念事項 (Concern): 適時性と影響を評価すべき事象。
  • 外部のイベント: プロジェクトの外部環境で発生し、プロジェクトに影響を及ぼす可能性のある事象。
  • ビジネス機会 (Business Opportunity): プロジェクトやユーザー組織にとって、予期していなかったプラスの結果をもたらす事象。
• 2.2. 運用のポイント
  • リスクとの区別 課題を評価する際、それが 不確実な事象(リスク) か 既に発生した事象(課題) かを確認する。不確実性がある場合は、リスク登録簿に移転して管理する。
  • 適切なフィルタリング
    • 些細な事項まですべて課題として扱うと、重要な意思決定が埋もれてしまう。
    • プロジェクトマネージャーは重要な情報を独断で排除(検閲)してはならない(許容度の範囲内で早期に解決することが最も効果的である)。
  • 記録と分析
    • 課題登録簿: すべての課題を記録する。
    • 課題報告書: 詳細な分析が必要な場合に作成し、種類、ベースラインへの影響、推奨される解決策をまとめる。
  • 変更への移行
    • 課題の解決策がプロジェクトのベースライン(計画や成果物の仕様など)の修正を伴う場合は、通常の課題解決から変更コントロール手順へと移行して対処する。

3. 変更コントロール

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

• 3.1. 基本定義
  • 変更要求 (Request for Change): ベースラインに対する変更の具体的な提案。
  • 仕様外項目 (Off-specification): 品質仕様(期待される機能や基準)を満たしていない成果物。
  • 条件付き承認 (Concession): 仕様外項目のうち、プロジェクト委員会が是正処置を求めずに現状のまま受け入れること。
• 3.2. 運用
  • 手順の明確化: 課題マネジメント・アプローチにおいて、変更の提案をどのように記録し、誰が決定するかの手順を詳細に説明する。
  • 変更要求の要件: 対象となるマネジメント成果物を特定し、変更の正当な理由を提示しなければならない(コストが発生する場合は、資金源(変更予算または追加資金)を明確にする)。
  • 仕様外項目への対処:
    • 主にサプライヤーが仕様通りの成果物を提供できなかった場合に発生する(ベースラインと実態の相違であるため、必ず変更コントロール手順を通して処理する)。
      • 受け入れる場合: 成果物記述書を修正してベースラインを更新し、条件付き承認として記録する。
      • 却下する場合: プロジェクト・マネージャーとチーム・マネージャーが協力し、変更予算の活用や例外報告書の提出など、修正方法を検討する。
• 3.3. 意思決定の迅速化 課題解決のために変更や仕様外項目の承認が必要な場合、課題報告書に詳細な変更内容を記載し、関係者がタイムリーに判断できるようにする。

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

変更要求や仕様外項目のレビューおよび承認に関する最終権限はプロジェクト委員会が持つ(効率的な運営のために、この権限を他の役割へ委任することが可能である)。

• 4.1. 権限委任のバランス 効果的な変更コントロールには、効率性とコントロールのバランスが不可欠である。
  • 委任が少なすぎる場合:
    • 些細な変更決定のためにプロジェクト委員会の判断を仰ぐことになり、意思決定の遅延や進捗の停滞を招く。
  • 委任が多すぎる場合
    • 多くの役割に権限が分散しすぎると、ビジネス正当性との整合性が取れなくなり、プロジェクト全体のベネフィットが損なわれるリスクがある。
• 4.2. 運用上のポイント
  • ワーク・パッケージ・レベルでの対応
    • 実務上、変更の多くはワーク・パッケージ・レベルで発生する。このレベルでの変更を迅速に承認できるよう適切な権限を委任しておくことで、不要なエスカレーションを防ぐことができる。
  • 変更許可委員の設置
    • プロジェクトの規模や複雑性に応じて、プロジェクト・マネジメント・チーム内の複数のレベルで変更許可委員を任命すると便利である。
  • パラメーターの定義
    • どの程度の変更までを誰が承認できるかという具体的な基準(パラメーター)は、課題マネジメント・アプローチにおいてあらかじめ指定しておく必要がある。

5. 変更予算

プロジェクト中に発生する変更要求や仕様外項目への対応に備え、あらかじめ計画の中で確保しておくリソースである。

• 5.1. 定義と性質
  • 変更予算の形態
    • 通常は変更対応のために特別に確保された 資金(金額) を指すが、状況によってはトレードオフ(調整)が可能な認可された制約条件として定義される。
  • 割り当ての権限
    • 変更を承認・提供するための委任された権限を持つ者によって割り当てられ、使用される。
• 5.2. 運用のポイント
  • 権限と予算のセット運用
    • プロジェクト・マネージャーは、変更に関する委任された権限に対し、その変更を実際に実行できるだけの適切な変更予算が伴っているかを確認しなければならない。
  • 目的の限定
    • この予算は承認された変更を実施するためにのみ使用され、プロジェクトの他の目的や当初のスコープ外の活動に無計画に流用してはならない。

コントロール

課題マネジメントは、以下の標準的な5ステップの技法を用いて実施される。これにより、発生した事象を体系的に評価し、プロジェクトのベースラインを適切に維持・更新する。

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

1. 課題を把握する

プロジェクトの全期間を通じて、公式・非公式を問わずあらゆるコミュニケーション・チャネルから発生する。

• 効率的な変換 口頭やメールなどの様々なチャネルで提起された課題を、公式な課題報告書や課題登録簿へ変換する仕組みを整える。その際、管理上の負担が最小限になるよう、効率的なプロセスを構築することが重要である。
• 定期的なレビュー 新規および未解決の課題の確認は、プロジェクトにおけるあらゆるレビュー活動に組み込まれる。
  • 定期的なステータス会議(進捗確認)
  • ステージ境界レビュー(各ステージの節目)
  • その他の随時レビュー

2. 課題を評価する

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

• 2.1. 適用とコンテキスト
  • 組織方針: 既存の標準や手順をプロジェクト独自のルールに組み込む。
  • 商業環境: 契約上の変更コントロール手順が優先される場合がある。サプライヤーとの間でツールや登録簿の共有が必要な場合は、契約内で明記する。
  • デリバリー手法による違い
    • ウォーターフォール: ライフサイクルが進むにつれ、変更の数と規模は減少していく傾向にある。
    • アジャイル: 課題管理が開発サイクルに組み込まれている。短いサイクルで頻繁にレビューを行い、プロダクト・バックログを進化させることで、成果物とニーズの整合性を保つ。
  • 持続可能性: 規制変更などが重大な課題の原因となりうるため、外部環境をモニタリングする責任者を明確にする。
  • 規模と複雑性:
    • 大規模プロジェクトでは専用の支援体制(変更許可委員など)を検討する。
    • 斬新な試みや複雑な成果物を扱う場合、課題管理の作業量は増大する。
  • 機密性: ディスベネフィット(不利益)を含む課題など、機密性の高い情報が含まれる場合は、課題登録簿へのアクセス権限を厳格に管理する。
• 2.2. 支援技法 課題の評価と原因特定には、以下の技法が活用される。
  • 根本原因分析 (RCA): 問題を要素分解し、表面的な現象ではなく真の主要原因を特定する。
  • パレート分析 (80/20ルール): 結果の80%は、原因の20%から生じるという法則に基づき、最も影響の大きい原因を優先的に特定する。
  • 原因と結果の分析 (フィッシュボーン図): 重要な要因をカテゴリー別に分類し、視覚的に整理する。
  • 故障モード影響分析 (FMEA): 成果物やプロセスで発生しうる故障をすべて洗い出し、その結果を評価する。プロトタイプ等が存在する場合に有効。
  • 5つのなぜ (5 Whys): **なぜ？**を繰り返すことで問題の深層を探る。統計データが不足している場合でも使えるシンプルなツール。
• 2.3. 統合評価の視点 重要な課題やベースラインへの変更案については、プロジェクト計画全体への影響を考慮した統合的な評価が必要である。
  • ターゲットと許容度: 承認済みの目標値や許容範囲に収まるか。
  • ビジネス・ケース: プロジェクトの妥当性や投資対効果を維持できるか。
  • 他の成果物: 他のワーク・パッケージや成果物との依存関係に影響しないか。 プロジェクト・マネージャーは、単一の解決策だけでなく、複数の選択肢(オプション) を提示することを目指す。これには、納期の延期と引き換えに品質を高めるなどのトレードオフや条件付き承認の検討も含まれる。

3. 解決を勧告する

評価結果に基づき、意思決定権限を持つ個人(プロジェクト・マネージャーなど)やグループ(プロジェクト委員会、変更許可委員など)に対して解決策を提案する。

• 選択肢の提示 単一の案だけでなく、複数の解決策を提示することが望ましい。
• 影響の明確化 変更要求を承認する場合と却下する場合、それぞれの選択がプロジェクトに及ぼす結果(コスト、スケジュール、品質、リスクへの影響)を明確に記述する。
• 根拠の提示 なぜその解決策を推奨するのか、ビジネス・ケースやプロジェクト目標との整合性から妥当性を示す。

4. 変更を決定する

変更勧告を受けた際、意思決定者は以下の選択肢から適切な対応を決定する(決定にあたっては、コストの調達方法やビジネス正当性への影響を十分に考慮する必要がある)。

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

• 意思決定の透明性 決定の内容とその理由は、必ず課題登録簿に記録し、関係者に通達する。
• 権限の遵守 決定がプロジェクトマネージャーに委任された許容範囲を超える場合は、速やかにプロジェクト委員会へエスカレーションしなければならない。

5. 変更を実施する

承認された変更内容を正式に反映し、プロジェクトの状態を最新のベースラインへと移行させる。

• 記録と更新 承認された変更要求および仕様外項目の内容をプロジェクト・ログに記録し、影響を受けるすべてのマネジメント成果物(計画書、成果物記述書など)に反映する。
• 構成コントロールの維持 各マネジメント成果物は、その性質に応じて異なるシステムで管理される場合があるが、以下の機能を備えていなければならない。
  • 変更の記録: 誰が、いつ、どのような変更を加えたかの履歴。
  • アーカイブ: 置き換えられた旧バージョンの保存と復元。
• 一貫性の確保 変更実施後は、プロジェクト・ログと各成果物のステータスが一致していることを確認し、チーム全体が最新のベースラインに基づいて活動できるようにする。

マネジメント成果物

アウトプット

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

• 目的: プロジェクトでのリスク・マネジメント方法を説明する。適用される特定の手順、技法、標準、責任が含まれる。
• コンテンツ概要
  • スコープ: 課題マネジメント・アプローチのスコープの説明
  • プロジェクトベースライン要素: プロジェクトのベースラインを構成するマネジメント成果物のリスト
  • 課題の報告と解決の手順: 課題の発生、報告、解決の説明(ビジネス標準からの逸脱は、逸脱の正当性とともにハイライトする)。
  • 変更コントロール手順: プロジェクトのベースラインに対する変更の要求、決定、組み込み、検証方法の説明(ビジネス標準からの逸脱は、逸脱の正当性とともにハイライトする)。
  • 変更予算: 認可された変更予算と、ステージまたはワーク・パッケージ・レベルでの割り当て
  • 正式な課題マネジメント活動のタイミング: 課題をレビューおよび決定する時期と頻度
  • 責任: 変更許可委員の委任など、課題マネジメント・アプローチに関連する役割の実行責任を担う人物を定義
  • サポートするツールまたはシステ: バージョンコントロールシステムなど、課題マネジメント・アプローチを実施または支援するために使用されるツールまたはシステム
  • 標準: 課題の優先度と重大度を評価するために使用される格付けシステムなど、課題マネジメントに適用される標準(標準では、課題登録簿およびその他の変更コントロール・レコードの構成と形式も指定する)

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

• 目的: プロジェクト・ライフサイクル中に発生したすベての課題報告書、現在のステータス、終了日を記録する
• コンテンツ概要
  • 課題の識別子: 課題の一意の参照コード
  • 課題の記述書: 課題の概要
  • 課題の種類: 問題、懸念事項、外部イベント、ビジネス機会、変更要求、仕様外項目
  • 格付け: 優先度と重大度の評価
  • 課題のオーナー: 課題の担当者
  • 決定: 課題に対応する決定のレコード。仕様外項目の場合、受け入れを記録し、決定した条件付き承認の概要を提供する
  • ステータス: 課題の現在のステータス(記録済み、レビュー済み、処置済み、エスカレーション済み、解決済みなど)
  • 課題に関連する日付: 提起日、最終レビュ一日、処置の期日、解決日など
  • レコード: 課題とその場所に関連付けられている文書のリスト

課題報告書

• 目的: プロジェクトのベースラインに対する課題のインパクトを説明し、課題を解決する方法や仕様外項目に対処する方法を特定し、決定を推奨する
• コンテンツ概要
  • 一意の識別子: 課題の一意の参照コード
  • 成果物識別子: 課題の影響を受ける成果物の識別子
  • 提起日: 課題が最初にログに記録された日付
  • 課題の種類: 問題または懸念事項、外部イベント、ビジネス機会、変更要求、仕様外項目
  • 格付け: 重大度と優先度(使用する場合)
  • 記述書: 課題の要因、原因、インパクトの概要
  • インパクト分析: プロジェクトのベースラインへのインパクトの分析
  • オプション: プロジェクト、ユーザー、サプライヤーが課題に対応する方法
  • 勧告: プロジェクト・マネージャーまたはチーム・マネージャーが推奨する決定
  • 決定: 課題に対応する決定のレコード。仕様外項目の場合、受け入れを記録し、決定した条件付き承認の概要を提供する

主要な役割

役割	責任
ビジネス・レイヤー	ビジネス・レイヤーの責任
プロジェクト・エグゼクティブ	プロジェクト・エグゼクティブの責任
シニア・ユーザー	シニア・ユーザーの責任
シニア・サプライヤー	シニア・サプライヤーの責任
プロジェクト・マネージャー	プロジェクト・マネージャーの責任
チーム・マネージャー	チーム・マネージャーの責任
プロジェクト保証	プロジェクト保証の責任
プロジェクト支援	プロジェクト支援の責任

ビジネス・レイヤーの責任

• 課題マネジメントと変更コントロールのためのビジネス・レイヤーの方針、標準、手順を提供する
• プロジェクト・レベルの変更予算を承認する(使用している場合)
• プロジェクト・エグゼクティブからの助言の要求やエスカレーションされた課題に対応する

プロジェクトエグゼクティブの責任

• プロジェクト・レベルの変更予算が必要かどうか、および必要な金額を判断する
• ステージ・レベル変更予算を設定する
• 変更を承認するための委任された権限が必要かどうか、および必要な場所を判断する
• 課題マネジメント・アプローチを承認し、それがプロジェクト目標に適していることを確保する(課題の重大度と優先度を評価するためのスケールを設定)
• プロジェクト・マネージャーからの助言の要求に対応し、特にビジネス正当性の継続を重視して、エスカレーションされた課題に対する意思決定を行う

シニアユーザーの責任

• プロジェクト・マネージャーからの助言の要求に対応し、特に予想ベネフィットを守ることを重視して、エスカレーションされた課題に対する意思決定を行う
• 課題マネジメント・アプローチに合意する

シニアサプライヤーの責任

• プロジェクト・マネージャーからの助言の要求に対応し、特にソリューション全体の完全性を守ることを重視して、エスカレーションされた課題に対する意思決定を行う
• 課題マネジメント・アプローチに合意する

プロジェクトマネージャーの責任

• 利害関係者と協議して課題マネジメント・アプローチを準備および維持し、成果物がベースライン化されるレベルに合意する
• 可能な場合は、プロジェクト支援のサポートを受けて、課題および変更コントロール手順を管理する
• チーム・マネージャーがワーク・パッケージ記述書で合意された課題と変更コントロール手順を実施するようにする
• 可能な場合は、プロジェクト支援のサポートを受けて、課題登録簿を管理する
• 是正処置を実施する

チームマネージャーの責任

• ワーク・パッケージ記述書で合意された課題と変更コントロール手順を実施する
• 是正処置を実施する

プロジェクト保証の責任

• 課題マネジメント・アプローチについて、プロジェクト・マネージャーに助言する
• 課題マネジメント・アプローチがビジネスの方針に準拠していることをプロジェクト委員会に確認する
• 課題の評価および解決について助言する
• プロジェクト委員会とプロジェクト・マネージャーを支援するために、依頼に応じて課題報告書と例外報告書を確認する
• 課題と変更コントロールのプラクティスをレビューして、課題が適切に管理されていることをプロジェクト委員会に保証し、課題がプロジェクトの課題マネジメント・アプローチに沿って実施されていることを確認する

プロジェクト支援の責任

• 次によって変更コントロールと課題手順を管理する
  • 課題登録簿の維持
  • プロジェクトのベースラインの維持
  • プロジェクト・マネージャーによる課題報告書の作成支援
  • プロジェクトのリスク・マネジメント手順の適用について、プロジェクト・マネジメント・チームを支援