はじめに
プロジェクト計画書は「誰のための文書」なのかで、スコープの「対象外」を明記する重要性に触れました。ただ、どれだけ丁寧にスコープを定義しても、プロジェクトが進む中で変更要求はほぼ必ず発生します。問題は変更が起きることではなく、それが正式なプロセスを経ずになし崩しに反映されてしまうことです。
SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応してきた経験から、変更管理表の運用について解説します。
口頭・チャットだけで決まった変更は、記録に残らない
要件定義後の仕様変更は、会議の場やチャットのやり取りの中で「じゃあそれでいきましょう」と軽く決まってしまうことがよくあります。これ自体は現場の機動力として悪いことではありませんが、正式な記録を経ずに決まった変更は、後から追跡できません。
誰がいつ、どんな理由でその変更を決めたのかが分からなくなると、プロジェクトの終盤で「なぜこの仕様になっているのか」を説明できなくなります。すべての変更要求を、たとえ軽微なものであっても一度この表を通すというルールにしておくことで、変更の経緯が記録として残ります。
影響度に応じて承認プロセスを変える
すべての変更要求に同じ重さの承認プロセスを課すと、現場の動きが遅くなります。重要なのは、影響度（QCDへの影響）に応じて承認プロセスの重さを変えることです。
予算の5%以上やスケジュールに2週間以上影響する変更は運営委員会レベルの承認、軽微な調整はプロジェクトマネージャーの承認のみで済ませる、というように基準を事前に決めておくことで、重要な変更は慎重に、軽微な変更はスピーディーに処理できます。
却下も立派な記録として残す
変更管理表のもう一つの価値は、「却下した」という判断も記録に残せることです。要望が出たものの、スコープ外として却下した変更は、プロジェクトが進む中で再び同じ要望として出てくることがあります。却下した経緯と理由が記録されていれば、「それは以前検討して見送った」とすぐに説明でき、同じ議論を繰り返す無駄を省けます。
まとめ
変更管理表は、変更を止めるための道具ではなく、変更を正式なプロセスに乗せて記録するための道具です。口頭だけで決めずに必ず記録し、影響度に応じて承認プロセスの重さを変え、却下した判断も記録として残す。これにより、スコープがなし崩しに拡大することを防ぎつつ、現場の機動力も損なわずに済みます。
実際に使っている変更管理表のテンプレートは、noteで配布しています。
執筆者プロフィール：SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応。基幹システム刷新・DX推進プロジェクトに多数従事。
コメント