version: "1.0.0" name: project-management description: プロジェクトのスコープ・スケジュール・品質・コストを管理するスキル。計画立案からリスク管理・進捗可視化・ステークホルダー報告まで、プロジェクト全体を通して使う。

プロジェクト管理

目的

スコープ・スケジュール・品質・コストの4変数を意図的にコントロールし、チームが「何を、いつまでに、どの品質で届けるか」を共有した状態で開発を進める。計画を作って終わりではなく、現実との差分を週次で縮め続けることが本質である。

使うタイミング

• プロジェクト開始時の計画書策定
• マイルストーンの設計・見直し
• 週次進捗確認・ステークホルダー報告
• スコープ変更要求の受け付け判断
• マイルストーン後の振り返り

進め方

1. トレードオフを先に決める

スコープ・スケジュール・品質・コストの4つを全部守ることはできない。プロジェクト開始時に「固定する変数」と「可変にする変数」を明示的に合意する。例: 「期限は固定、スコープは削減可能」

1. プロジェクト計画書を作る

下記テンプレートを使い、目的・スコープ・マイルストーン・体制・リスク登録簿・コミュニケーション計画を1文書にまとめる。

1. マイルストーンを「動くものが見える」単位で設計する

「設計完了」「実装50%」は中間成果として機能しない。「ユーザーがログインしてダッシュボードを見られる」のように価値が検証できる単位で区切る。中間価値の設計は [[mvp-development]] を参照。

1. タスクを分解して追跡する

[[task-breakdown]] でタスクを細分化し、WIP(仕掛かり中)を制限する。完了の定義は「done/not done」の二値のみ。「90%完了」は not done として扱う。ブロッカーは即座に顕在化させ、担当者を決めて48時間以内に解消策を立てる。

1. リスク登録簿を週次で見直す

リスクを登録し、毎週「兆候が出ていないか」「対応策は有効か」を確認する。「気づいていたのに言わなかった」を組織的に防ぐ仕組みとして機能させる。

1. 進捗を可視化する

完了タスク数 / 全タスク数を週次で集計する。バーンダウンチャートや累積フロー図を使う場合も、元データは done/not done の二値カウントに基づく。

1. ステークホルダーに結論先行で報告する

冒頭に「順調 / 遅延リスクあり / 遅延確定」を明示する。遅延の場合は必ず選択肢(スコープ削減 / 期限延長 / 品質調整)と影響を添えて提示し、決定を委ねる。

1. スコープ変更は影響試算とセットで受ける

変更要求は拒否するのではなく、「この追加をすると期限がN日延びる / スコープAを削る必要がある」と影響を試算してから合意する。無条件受け入れ禁止。

1. 振り返りを行う

週次またはマイルストーン後に「続けること / やめること / 試すこと」の3点で振り返る。アクションは担当者と期限を付けて次週に持ち越す。

成果物テンプレート

プロジェクト計画書

# プロジェクト計画書
 
## 基本情報
-プロジェクト名:
-目的（Why）:
-期間: YYYY-MM-DD 〜 YYYY-MM-DD
-PM:
-作成日 / 最終更新日:
 
## スコープ
### In Scope（対象）
-
 
### Out of Scope（対象外）
-
 
## トレードオフ合意
| 変数       | 固定 / 可変 | 備考 |
|-----------|------------|------|
| スコープ   |            |      |
| スケジュール|           |      |
| 品質       |            |      |
| コスト     |            |      |
 
## マイルストーン
| # | 名称（動く成果物） | 期限       | 完了条件 | 状態 |
|---|------------------|------------|---------|------|
| 1 |                  | YYYY-MM-DD |         |      |
| 2 |                  | YYYY-MM-DD |         |      |
 
## 体制
| 役割 | 担当者 | 責任範囲 |
|------|--------|---------|
| PM   |        |         |
| Dev  |        |         |
 
## コミュニケーション計画
| 会議体             | 頻度 | 参加者 | 目的 |
|-------------------|------|--------|------|
| 週次進捗ミーティング | 週1回 |       |      |
| ステークホルダー報告 | 隔週  |       |      |
 
## 変更管理
-変更要求受付方法:
-影響試算の責任者:
-承認者:

リスク登録簿

# リスク登録簿（最終更新: YYYY-MM-DD）
 
| ID | リスク内容 | 発生確率(H/M/L) | 影響度(H/M/L) | 兆候 | 対応策 | 担当 | 状態 |
|----|-----------|---------------|--------------|------|--------|------|------|
| R1 |           |               |              |      |        |      | 監視中 |
| R2 |           |               |              |      |        |      | 対応中 |
 
※ 週次ミーティングで全行を確認し、「兆候なし」も明示的に記録する

チェックリスト

• [ ] トレードオフ（固定/可変）をステークホルダーと文書で合意した
• [ ] マイルストーンは「動いて価値が検証できる」単位になっている
• [ ] 完了の定義が「done/not done」の二値になっている
• [ ] リスク登録簿を作成し、週次レビューの場が設定されている
• [ ] ブロッカーの解消プロセス（担当者・期限）が決まっている
• [ ] スコープ変更の承認フローが決まっている
• [ ] ステークホルダー報告に「遅延時の選択肢」が含まれている
• [ ] 振り返りのアクションに担当者と期限が付いている

アンチパターン

• 計画を作って更新しない: 計画書は週次で現実と差分を埋める生き文書。作成で満足しない。
• 悪い報告を遅らせる: 遅延の兆候を掴んだ時点で報告する。「確定してから言う」は手遅れを生む。
• スコープ追加を無条件に受ける: 追加要求を断らなくてよい。ただし影響試算なしの受け入れは禁止。
• 「90%完了」が数週間続く: 残り10%に本当の難問が潜む。進捗会議では done カウントのみ使う。
• マイルストーンを「作業完了」で設定する: 「設計書提出」は内部完了であり価値検証にならない。

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

関連スキル

• [[orchestration]] — マルチエージェント協調の共通原則
• [[requirements-definition]] — スコープ定義の上流工程
• [[estimation]] — 期間・コストの見積もり
• [[task-breakdown]] — タスク分解と WIP 管理
• [[mvp-development]] — 中間マイルストーンでの価値検証
• [[architecture-design]] — 技術的リスクの早期評価
• [[testing]] — 完了定義に組み込む品質基準