プロジェクトなら、変更要求の影響はそのプロジェクトの中で収まります。プログラムでは収まりません。

1つのプロジェクトで「画面の項目を1つ増やす」と決めただけで、別のプロジェクトのデータ連携が変わり、業務手順書が変わり、研修資料を作り直すことになる。こういうことが起きます。

■ 受け付けは断らない

変更要求が来たとき、その場で「できません」と答えたくなることがあります。ただ、これをやると次から要望が上がってこなくなります。上がってこない要望は、あとで別の形で噴き出します。

受け付けの段階では、判断しません。一覧に載せるだけです。

• 依頼者は誰か

• 何を変えたいか

• なぜ必要か（これが一番大事）

• いつまでに必要か

3つ目の「なぜ」を必ず聞いてください。理由が分かると、もっと軽い方法で同じ目的を果たせることがよくあります。「この項目が見たい」の裏に「月末の集計が手作業で大変」があるなら、画面を変えるより出力を1本追加するほうが早いかもしれません。

■ 影響は5つの方向に調べる

図の表の5つです。プログラムマネージャーが1人で判断せず、それぞれの担当者に聞きます。

順番にも意味があります。最初に他のプロジェクトを確認するのは、ここが一番見落とされ、かつ手戻りが大きいからです。

そして最後の業務手順・研修。システム側だけで検討していると、ここが完全に抜けます。「画面が1つ増えるだけ」でも、手順書の該当箇所を直し、研修資料を差し替え、すでに研修を受けた人に伝え直す作業が発生します。

■ 調べる時間を確保する

影響分析には数日かかります。この時間を「待たされている」と受け取られないよう、最初に伝えておきます。

「影響範囲を確認します。1週間後の定例で結果をお伝えします」

期限を先に言う。これだけで、催促のやり取りがなくなります。

■ 判断者を影響の大きさで分ける

この区分を最初に決めておかないと、すべてが運営委員会に上がり、月1回しか判断されない状態になります。逆に、何でも現場で決めていると、気づいたら全体の計画と合わなくなっています。

■ 断るときの伝え方

すべての変更を受け入れることはできません。断るときは、理由を影響の言葉で伝えます。

右側の形なら、依頼者も納得しやすく、場合によっては「では稼働後に」と自分から言ってくれます。

■ 見送った要望も残しておく

断った要望は、消さずに一覧に残します。「見送り（次期検討）」として記録しておく。

これには2つの効果があります。ひとつは、同じ要望が何度も出てきたときに気づけること。複数回出るなら、本当に必要なものかもしれません。

もうひとつは、次のプログラムや保守フェーズの企画材料になることです。断った要望のリストは、次にやるべきことのリストでもあります。

■ まとめ

変更要求は、受け付ける・影響を調べる・判断する・反映するの4段階で扱う。影響は他PJ・期日・予算・成果指標・業務手順の5方向に確認し、判断者は影響の大きさで分ける。

いま進めているプログラムで、変更要求の一覧があるか確かめてみてください。なければ、まず口頭で来ている依頼を書き出すところから始められます。