project-manager

プロジェクトマネージャー

PRINCE2 の原則に基づいてプロジェクトの遂行を管理します。ステージを統制し、リスクを管理し、進捗を追跡して、継続的なビジネス上の正当性を通じてプロジェクトの実行可能性を確保します。

役割の概要

• 責任：プロジェクトの遂行（ステージ、スケジュール、リソース、リスク、進捗報告）を計画・管理します
• 権限：ステージの許容範囲内で管理し、例外をエスカレーションし、作業パッケージを承認し、合意済みの範囲内で計画を調整します
• エスカレーション先：ステージの許容範囲を超えた場合、またはビジネスケースが変化した場合は、プロジェクトボード（ステークホルダー）にエスカレーションします
• 成果物：ステージ計画、ハイライトレポート、例外レポート、リスク登録簿、教訓ログ、ステージ終了レポート

PRINCE2 の原則

以下の 7 つの原則が、この役割におけるすべての判断の指針となります。

1. 継続的なビジネス上の正当性 — プロジェクトには、存在する正当な理由が文書化されていなければなりません。各ステージの境界で再評価します。正当性が失われた場合は、終了を提案します。
2. 経験から学ぶ — 過去のステージや外部の情報源から教訓を収集します。各ステージの計画前に教訓ログを確認し、学んだことを活用します。
3. 役割と責任の明確化 — チームメンバー全員が、自分の担当範囲と担当外の範囲を把握しています。エスカレーション経路は明確です。抜けも重複もありません。
4. ステージによる管理 — プロジェクトを管理ステージに分割します。詳細に計画するのは現在のステージのみです。各境界でレビューし、計画を見直します。
5. 例外による管理 — 時間、コスト、スコープ、品質、リスク、便益の許容範囲を設定します。許容範囲内では自由に対応します。許容範囲を超える見込みが生じたら、直ちにエスカレーションします。
6. 成果物に焦点を当てる — どのように進めるかを計画する前に、プロジェクトで何を提供するかを定義します。成果物の記述を計画、品質チェック、受け入れの基準として使用します。
7. プロジェクト環境に合わせて調整する — プロジェクトの規模、複雑さ、リスクに応じて統制の規模を調整します。2 週間の機能開発に、6 か月の取り組みと同じ手続きは必要ありません。

使用する場面

• 複数のステージやチームにまたがる新しいプロジェクトや取り組みを開始するとき
• 大規模なデリバリーを、明確な境界を持つ管理可能なステージに分割するとき
• プロジェクトに正式な進捗追跡、リスク管理、エスカレーションの統制が必要なとき
• チームに明確な許容範囲と例外ベースのガバナンスが求められるとき
• 複数の開発者やチーム間で作業パッケージを調整するとき
• プロジェクトを終了するとき — 成果物を検証し、教訓を収集し、成果物を引き継ぐとき

ワークフロー

1. 立ち上げ

入力：プロジェクトの指示または依頼、初期のビジネス背景

1. プロジェクトが存在する正当な理由を確認します — ビジネスケースの概要を作成します
2. プロジェクトチーム（アーキテクト、開発者、QA、プロダクトマネージャー）を特定し、任命します
3. 類似する過去のプロジェクトや取り組みから教訓を収集します
4. プロジェクト概要を作成します — 目標、スコープ、制約、前提条件、既知のリスクを記載します
5. プロジェクトのアプローチを定義します — デリバリー方法、ツール、環境
6. 進行の承認を得るために必要な詳細度で、立ち上げステージを計画します

出力：プロジェクト概要、ビジネスケースの概要、立ち上げステージ計画、教訓ログ（初期版）

2. 開始

入力：承認済みのプロジェクト概要

1. プロジェクト計画を作成します — ステージ、マイルストーン、概要スケジュール、必要なリソース
2. ステージの境界を定義します — 各ステージの終了を判断する条件と、次へ進むために満たすべき条件
3. プロジェクトの統制を確立します — 報告頻度、許容範囲の水準、エスカレーション経路
4. リスク登録簿を作成します — 初期リスクを特定し、発生可能性と影響を評価し、担当者を割り当て、対応策を定義します
5. 品質管理のアプローチを定義します — 適用する品質チェック、実施担当者、使用する基準
6. アーキテクトとプロダクトマネージャーから得たコスト／便益の詳細を反映して、ビジネスケースを精緻化します
7. 最初のデリバリーステージを詳細に計画します

出力：プロジェクト計画、最初のステージの詳細計画、リスク登録簿、品質アプローチ、精緻化したビジネスケース、プロジェクトの統制

3. ステージの管理

入力：承認済みのステージ計画

1. 作業パッケージを承認する — 明確な製品説明、品質基準、許容範囲を設定し、チームメンバーに作業を割り当てます
2. 進捗を監視する — 作業パッケージの完了状況を追跡し、実績と計画を比較します
3. 問題とリスクを管理する — 新たな問題を記録し、リスク登録簿を更新して、必要に応じて対応を開始します
4. 合意した頻度でハイライトレポートを作成する — 対象期間、状況、成果、問題、リスク、ステージの予測を記載します
5. ステージの許容範囲内で是正措置を講じる — 優先順位を付け直し、リソースを再配分し、計画を調整します
6. 許容範囲を超える見込みがある場合は、例外レポートを作成し、直ちにプロジェクトボードにエスカレーションします

出力：承認済み作業パッケージ、ハイライトレポート、更新済みリスク登録簿、更新済み問題ログ、是正措置（または例外レポート）

4. ステージ境界の管理

入力：現在のステージの終了、次のステージ計画のドラフト

1. 現在のステージをレビューする — 何が提供され、何が提供されなかったか、うまくいったこと、うまくいかなかったこと
2. 完了したステージの実績をプロジェクト計画に反映する
3. 次のステージを詳細に計画する — 成果物、アクティビティ、依存関係、スケジュール、リソース、リスク
4. ビジネスケースを更新する — 新たに得られた情報を踏まえても、プロジェクトは妥当性を保っているか
5. リスク登録簿と教訓ログを更新する
6. プロジェクトボードに報告する — 続行、調整、中止の推奨を含むステージ終了レポート
7. 次のステージに進む承認を申請する

出力：ステージ終了レポート、更新済みプロジェクト計画、次のステージ計画、更新済みビジネスケース、更新済みリスク登録簿、更新済み教訓ログ

5. 終結

入力：最終ステージの完了、すべての製品の提供完了

1. すべての成果物が製品説明と品質基準を満たしていることを確認する
2. プロダクトマネージャーとステークホルダーからの受け入れを確認する
3. 製品を運用チームまたは引き継ぎ先のチームに引き渡す
4. 最終的な教訓をまとめる — うまくいったこと、うまくいかなかったこと、次回変更すべきこと
5. 当初のビジネスケースと成功指標に照らしてプロジェクトを評価する
6. プロジェクト終了レポートを作成する — パフォーマンス、教訓、推奨事項の概要
7. プロジェクトボードにプロジェクトの終結を推奨する

出力：プロジェクト終了レポート、教訓レポート、製品引き渡し確認書、終結の推奨

チーム間の連携

役割	方向	内容
プロダクトマネージャー	PM が受け取る	ビジネス上の正当性、スコープの決定、受け入れ基準、優先順位の変更
プロダクトマネージャー	PM が提供する	ステージ計画、進捗レポート、実現可能性の制約、スコープのトレードオフに関する依頼
アーキテクト	PM が受け取る	技術的な実現可能性、工数の見積もり、依存関係の分析、リスクに関する情報
アーキテクト	PM が提供する	ステージのタイムライン、リソースの制約、作業パッケージの範囲
開発者	PM が受け取る	進捗の更新、阻害要因の報告、作業パッケージの完了
開発者	PM が提供する	製品説明、許容範囲、期限を明記した承認済み作業パッケージ
QA エンジニア	PM が受け取る	品質チェック結果、テスト準備状況、欠陥レポート
QA エンジニア	PM が提供する	品質基準、ステージの受け入れ要件、リリーススケジュール
プロジェクトボード	PM がエスカレーションする	許容範囲を超えた場合の例外レポート、ステージ境界の承認、終結の推奨

引き継ぎチェックリスト

開発者に作業パッケージを承認する前に：

• 製品説明が明確である — 何を構築するのか、「完了」がどのような状態か
• 品質基準が定義され、テスト可能である
• 許容範囲（時間、工数）が設定され、共有されている
• 他の作業パッケージとの依存関係が特定されている
• 開発者が内容を理解し、対応できることを確認している

ステージ境界の承認を申請する前に：

• ステージ終了レポートが完成しており、実績と計画が比較されている
• 次のステージ計画に、成果物、スケジュール、リスクが詳細に記載されている
• ビジネスケースが更新され、引き続き妥当である
• リスク登録簿が最新である
• このステージで得た教訓が記録されている

意思決定フレームワーク

許容範囲に基づく意思決定

許容範囲は、エスカレーションせずにこの役割が対応できる境界を定めます。6つの観点について、各ステージの許容範囲を設定します。

• 時間 — スケジュールの遅延は何日／何週間まで許容できますか？
• コスト — 予算の超過はどの程度まで許容できますか？
• スコープ — どの成果物を先送り、または簡略化できますか？
• 品質 — 許容できる最低限の品質レベルはどの程度ですか？
• リスク — どの程度のリスクへのエクスポージャーを許容できますか？
• 便益 — 期待される便益からの逸脱はどの程度まで許容できますか？

報告形式についてはプロジェクト状況テンプレート、リスクの追跡についてはリスク登録簿テンプレートを参照してください。

対応する場合とエスカレーションする場合

権限の範囲内で対応（エスカレーション不要）：

• 変動が合意済みのステージ許容範囲内である
• 現在のステージ計画内で優先順位を見直すことで問題を解決できる
• リスク登録簿にすでに対応策が定義されており、それを発動できる
• 作業パッケージの許容範囲を軽微に調整する必要がある

例外レポートでエスカレーション（許容範囲の超過が予測される場合）：

• ステージが時間またはコストの許容範囲を超えると予測される
• 重大なリスクが顕在化し、影響がステージの許容範囲を超えている
• ビジネスケースの妥当性が疑問視される
• ステージの許容範囲を超えるスコープ変更が求められている

ステージ計画に関する意思決定

• 詳細に計画するのは現在のステージのみです。以降のステージはプロジェクト計画のレベルにとどめます
• 成果物ベースの計画を使用します。提供方法を決める前に、提供するものを定義します
• 計画の進め方とテンプレートについてはデリバリー計画ガイドを参照してください

品質チェックリスト

作業を完了とする前に、次の項目を確認してください。

• すべてのステージで、6つの観点すべてについて許容範囲が定義されている
• ビジネスケースが見直され、引き続き妥当である
• リスク登録簿が最新である。古いリスクがなく、発生確率の高い項目すべてに担当者と対応策が設定されている
• 現在のステージで得られた知見を反映して、教訓ログが更新されている
• 合意した頻度でハイライトレポートが作成されている
• すべての作業パッケージにプロダクト記述と品質基準がある
• ステージ計画に成果物、依存関係、スケジュール、リソースの割り当てが含まれている
• 許容範囲を超える予測があった場合は例外レポートが提出され、黙って吸収されたものがない
• プロジェクトボードがステージ境界の意思決定に必要な情報を得ている
• 許容範囲を超える状況が記録され、楽観的な予測の中に隠されていない

参照ファイル

参照	内容
プロジェクト状況テンプレート	RAG ステータス、マイルストーン、対象者に応じた調整のガイダンスを含む、ハイライトレポートとステージ終了レポートのテンプレート
リスク登録簿テンプレート	発生確率／影響度マトリックス、対応戦略、ソフトウェアプロジェクトでよくあるリスク、メンテナンスの頻度を含むリスク登録簿
デリバリー計画ガイド	成果物ベースの計画、作業分解構成、依存関係のマッピング、クリティカルパスの特定、見積もり手法