システム活用法
変更管理プロセスの実践
変更を「決めてから進める」
プロジェクトの途中で「やっぱりここを変えたい」という要望が出るのは、ごく自然なことです。問題は変更そのものではなく、影響を確かめないまま引き受けてしまい、あとで予算やスケジュールが足りなくなることです。
本システムの変更管理は、変更を「決めてから進める」ための記録の場所と、承認の仕組み（承認ワークフロー）を用意しています。前提として、プロジェクトの機能スイッチで「変更管理」がオンになっている必要があります。
変更管理の流れ
変更要求は、次の段階を順番に進みます。判定で見送りになった場合は「却下」として記録を残します。
起票 → 調査 → 判定 → 承認 → 対応 → 完了（または却下）
この段階は、変更管理の「ステータス」で表します。標準では「起票」「調査中」「判定待ち」「承認待ち」「対応中」「完了」「却下」「保留」が用意されています。テンプレートで作ったプロジェクトなど、ステータスが「未着手・対応中・完了・中止」の簡易な構成のこともあります。管理画面の「ステータス」で、自分たちの流れに合わせて変えられます。
各段階で「誰が・何を書くか」
| 段階 | 主な担当 | 記録すること（変更管理の項目） | ポイント |
|---|---|---|---|
| 起票 | だれでも（利用部門・開発チームなど） | 発生日、変更したい内容、理由 | 「なぜ変えたいか」を1〜2文で書く |
| 調査 | 担当チーム | 影響範囲、工数見積（時間） | 画面・帳票・データ・他チーム・スケジュールへの影響を洗い出す |
| 判定 | PM・変更判定の会議体 | 判定結果（未判定／承認／却下） | 「今やる／次の段階でやる／やらない」を決める |
| 承認 | 予算・スケジュールの責任者 | 承認ワークフロー（下で説明） | 費用や日程が変わる場合は必ず責任者が承認する |
| 対応 | 担当チーム | 対応内容 | WBSのタスクや成果物と関連付けて進める |
| 完了 | 起票者・PM | 完了日 | 変更を求めた人が結果を確認してから閉じる |
| 却下 | PM・判定者 | 却下理由 | 理由を必ず書き、起票者に伝える |
承認ワークフローを使う
変更の詳細画面にある「承認」欄から、承認を依頼できます。使い方は次のとおりです。
- 承認者を順番に選びます（最大5人。このプロジェクトの会員から選び、自分自身は選べません）。必要なら依頼のメモを書きます。
- 「承認を依頼する」を押します。1人目に通知が届きます。
- 承認者は、詳細画面の「承認」欄で「承認する」または「却下する」を押します。却下のときは理由（コメント）が必須です。
- 前の人が承認すると、次の人に回ります。全員が承認すると承認済みになり、変更の判定結果が「承認」になります。誰かが却下すると、そこで終わり、判定結果が「却下」になり、却下理由にコメントが入ります。
完了にできないしくみ 承認の依頼中や、却下されたままの変更は、ステータスを「完了」（進捗率100）にできません。却下されたときは、内容を直してもう一度承認を依頼します。一度も依頼していない変更は、これまでどおり完了にできます。
承認者が退職・不在で順番が止まったときは、依頼者または管理員が、その承認者の行の「この承認者を外す」で、1人だけ外せます。依頼自体も「依頼を取り下げる」で取り下げられます。詳しくは記事「承認ワークフローで「決める人」を明確にする」を参照してください。
却下理由を残す意味
却下された変更は、つい記録を消したくなります。しかし、却下理由を残すことには大きな価値があります。
- 同じ要望の蒸し返しを防ぐ：半年後に同じ要望が出ても「前回はこの理由で見送った」とすぐに説明できます。
- 起票者の納得感が高まる：理由がわかれば、要望した人も受け入れやすくなります。
- 次の段階の候補になる：「今回は見送り、次の段階で検討」という却下は、将来の計画づくりの材料になります。
具体例：帳票を1つ追加したい
| 段階 | 記録の例 |
|---|---|
| 起票 | 営業部より「月次売上の部門別帳票を追加してほしい。会議資料を手作業で作っているため」 |
| 調査 | 影響範囲：帳票1本、データ抽出処理1本、テスト追加。工数見積：64時間（8人日）。結合テストの日程に影響あり |
| 判定・承認 | PMが「本番稼働後の次の段階で対応」と判定し、責任者が承認ワークフローで却下 |
| 却下理由 | 本番稼働日を守ることを優先。次の段階の最初の対応項目として検討する |
運用のコツ
- 小さな変更でも起票する：「このくらいなら」と口頭で引き受けた変更の積み重ねが、遅れの大きな原因になります。
- 判定の場を決めておく：週1回の定例会で変更要求を確認するなど、判定のタイミングを決めると滞留しません。
- 課題・WBSと関連付ける：変更のきっかけになった課題と、変更で見直すWBSタスクを関連付けると、経緯とスケジュールへの影響が一目でわかります。
- 滞留はダッシュボードで見つける：プロジェクトダッシュボードの「判断待ち」に、判断待ちの件数と最長の待ち日数が出ます。一覧やボードでも、「判定待ち」「承認待ち」に長く止まっている要求がないかを確認します。
- 計画が変わったらベースラインと比べる：承認された変更で日程が動いたら、WBSのベースラインとの比較で、どれだけずれたかを説明できます。
まとめ
変更管理は、変更を止めるための仕組みではなく、影響を理解したうえで「やる・やらない」を決めるための仕組みです。記録と承認ワークフローを使えば、誰が、いつ、何を根拠に決めたのかが自然に残ります。