スコープ変更の承認フローをどう設計するか

はじめに

「ついでにこれも」が積み重なってスコープが崩壊する前に｜変更管理表の作り方では、変更内容を記録・管理するための変更管理表について解説しました。しかし、変更管理表という「記録のツール」を用意しただけでは、スコープの崩壊を防ぎきれません。記録の前段階にある「承認フロー」の設計について整理します。

変更管理表は、発生した変更を記録し、履歴として残すためのツールです。しかし、「変更を記録する」ことと「変更を適切な人が適切な基準で承認する」ことは、別の話です。

変更管理表に記録さえすれば管理できていると考えてしまうと、実際には現場レベルの判断で次々と変更が承認され、気づけば当初の予算・スケジュールと大きく乖離していた、という事態が起こり得ます。記録と承認は、セットで設計する必要があります。

スコープ変更の承認フローを設計する際は、少なくとも次の3つの要素を明確にしておく必要があります。

① 誰が承認するのか（承認権限の階層化）

すべての変更を一律にプロジェクトマネージャーが承認するのではなく、変更の影響度に応じて承認者を階層化することをおすすめします。例えば、予算・スケジュールへの影響が軽微な変更はPM権限で承認、一定額・一定期間を超える影響がある変更はプロジェクトオーナーの承認が必要、というように段階を設けます。

② 何を基準に承認するのか（影響評価の必須化）

変更要求が出た際、「対応できそうだから」という感覚的な判断ではなく、予算・スケジュール・品質・他の機能への影響を必ず評価した上で承認するプロセスにします。影響評価を省略して承認してしまうことが、スコープ崩壊の最大の原因です。

③ 承認前は着手しない、というルールの徹底

承認プロセスを待っていると現場の作業が止まってしまうという理由で、承認前に開発側が先行着手してしまうケースがあります。これが常態化すると、承認フローは事実上の形骸化してしまいます。緊急性が高い場合の簡易承認ルートを別途用意しておくなど、承認前着手を誘発しない設計が必要です。

スコープ崩壊の多くは、一つ一つは小さな変更の積み重ねから生まれます。「これくらいなら承認を取らなくてもいいだろう」という現場の判断が繰り返されることで、気づいたときには当初のスコープから大きく逸脱している、という事態が起きます。

影響が軽微な変更ほど承認フローを簡略化し、迅速に処理できるようにしておくことで、「面倒だから承認を飛ばす」というインセンティブ自体をなくしておくことが重要です。簡易承認ルートを用意しつつも、記録は必ず変更管理表に残すというルールを徹底します。

変更内容の記録には、変更管理表のテンプレートをnoteで配布しています。承認フローの設計とあわせて活用いただけます。

スコープ変更の承認フローは、変更管理表という記録ツールとは別に、誰が・何を基準に・どのタイミングで承認するのかを明確に設計する必要があります。承認権限の階層化、影響評価の必須化、承認前着手を防ぐルール作りが、記録だけでは防げないスコープ崩壊を防ぐための鍵になります。

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。