変更が来る前提で計画をつくる
「変更が入らない前提で計画を立てる」のは、雨が降らない前提で出かけるようなものです。変更は必ず来ます。
問題は変更が来ることではなく、来たときの通り道が用意されていないことです。通り道がないと、変更は廡下や立ち話で決まり、誰も全体の影響を把握できなくなります。
■ 変更が「勝手に入る」とどうなるか
「ついでにこの項目も足しておいて」「この画面、こっちの並びのほうがいいよね」。1件ずつは小さな話です。ところが、次のことが起きます。
積み重なって工数を圧迫する。しかし記録がないので、遅れの理由を説明できない
テスト担当や運用側に伝わらず、テスト仕様書が古いままになる
誰がいつ決めたのか分からなくなり、後で「そんな話は聞いていない」になる
とくに遅れの理由を説明できなくなるのが痛いところです。「たくさん変更を受けたから」では、管理不足と見なされます。
■ 5つのステップを通す
① 受付
窓口を1人（PM）に決めて、決まった様式で受けます。様式に必要なのは4項目だけです。
誰が依頼しているか
何を変えたいか
なぜ必要か（業務上の理由）
いつまでに必要か
「なぜ」を書いてもらうのがポイントです。理由まで聞くと、別のもっと簡単な方法で解決できることがあります。
② 影響分析
開発側に、工数・納期・費用・他機能への影響を出してもらいます。回答期限を決めておきます（例：3営業日以内）。
ここで大事なのは、断る前に数字を出すことです。「できません」と先に言うと、非協力的だと受け取られます。数字を出せば、判断は依頼した側に返ります。
③ 判断
「やる／やらない／第2弾に回す」を決めます。誰が決めるかは、金額や日数の目安で先に分けておきます。
5人日以内かつ納期に影響なし → PMが判断してよい
それを超える → 決裁者に上げる
基準がないと、全件を上げることになって回らないか、PMが抱え込んで後で問題になるかのどちらかです。
④ 計画へ反映
承認されたら、工程表・見積・WBS・テスト仕様を更新します。ここを省くと、計画と実態がずれていきます。
「変更を受け入れた」という合意の記録も残します。決定事項ログに、日付・承認者・内容・理由を書きます。
⑤ 周知
影響を受ける全員に伝えます。忘れられやすいのは次の人たちです。
テスト担当（テストケースの修正が必要）
運用・保守の担当（手順書が変わる）
マニュアルや研修の担当
他システム側の担当（連携の仕様が変わる場合）
■ 変更の締切日を決めておく
いつまでも変更を受け付けていると、テストが始まりません。「◯月◯日以降の変更は、原則として第2弾に回します」と最初に合意しておきます。
締切を過ぎた依頼も、門前払いにはしません。受け付けたうえで、「今回はこの日以降なので第2弾ですが、緊急であれば影響を出します」と扱います。ルールはあるが、例外の判断もできる形にしておきます。
■ 却下した変更も記録する
「やらない」と決めた変更こそ、記録が要ります。理由とセットで残しておかないと、数か月後に同じ話が出てきます。
記録があれば、「6月に一度検討して、11月稼働を優先するために第2弾としました。前提が変わっていれば再検討します」と答えられます。
■ 立ち上げ期に伝えておく
このルールは、変更が来てから作るのでは遅いです。キックオフで、進め方のルールとして説明します。
変更依頼はこの様式で、私（PM）に出してください
3営業日以内に影響をお返しします
◯人日を超えるものは、部長に判断いただきます
◯月◯日以降の依頼は、原則として第2弾に回します
先に言っておけば、ルールを守ってもらうためのお願いではなく、最初からの約束として扱えます。
■ まとめ
変更管理は、変更を減らすための仕組みではありません。変更が来たときに、全員が影響を把握したうえで判断できるようにする仕組みです。
受付・影響分析・判断・反映・周知。この5つの通り道を最初に作っておけば、変更は脅威ではなく、普通の作業になります。