第6章 6.2 ← 6.0 進捗の追い方
変更管理は、変更を止める仕組みではありません
変更管理と聞くと、申請書と承認印を思い浮かべて気が重くなる方が多いと思います。ただ、目的は変更を止めることではありません。変更の代償を、決める人に見せることです。見せないまま受けると、代償は誰かの残業として静かに払われます。
この記事の要点
- リスクは未発生、課題は発生済み、変更は決めたことを変えること。3つは分けて扱います。
- 変更が通る道は5段階。受け付ける／影響を見る／決めてもらう／計画に入れる／残す。
- 実務でいちばん飛ばされるのは2番と5番です。どちらも一件あたり数分の作業です。
- 小さな変更に重い手続きを課すと、現場は手続きを避けて通ります。軽い変更は軽い道で。
- 課題の一行に必要なのは、内容・担当・期限・状態の4つだけです。
リスク・課題・変更を分ける
この3つは混ざりがちですが、打つ手がまったく違うので分けてください。
- リスクはまだ起きていないこと。打ち手は「起きにくくする」「起きても軽くする」。3.4で扱いました。
- 課題はすでに起きていること。打ち手は「解決する」しかありません。毎週見ます。
- 変更は、決めたことを変えること。打ち手は「代償を見せて、決めてもらう」です。
リスクが現実になったら課題に移します。課題への対処のために範囲や日程を変えるなら、それは変更です。この流れを一方向に保つと、一覧が整理されたままになります。
変更が通る道は、5段階です
2番——影響を見る——が、いちばん効きます
要望を受けたとき、その場で「入れます」と答えないでください。答えるべきは「見積もってから返します」です。半日でも構いません。
見るのは3つです。どれくらいの工数が増えるか。何の作業が後ろにずれるか。品質にどう影響するか。そして返し方は4.1で書いた形にします。
「入れられます。3人日ほどで、受入テストの開始が3日後ろにずれます。今回入れるか、次期にまわすか、どちらにしましょうか。」
この一文があるかないかで、まったく違います。ないと「それくらいなら」で20回受け、工数が1.5倍になり、しかも増えた記録がどこにもありません。3.1で書いたとおり、増えていることが見えれば、そこから先の追加は自然に減ります。
軽い変更には、軽い道を
変更管理でよくある失敗が、手続きを重くしすぎることです。すべての変更に申請書と3人の承認を求めると、現場は手続きを避けて通ります。そして避けて通った変更は、記録に残りません。管理を厳しくした結果、見えなくなるという逆転が起きます。
実務的には、大きさで分けてください。
- 影響が半日以内で、日程に効かないもの。担当者の判断で入れて、記録だけ残す。
- 数日ぶんの工数か、日程に効くもの。影響を見積もって、発注元の担当者に判断してもらう。
- 予算や納期そのものが動くもの。決裁者へ。稟議が必要ならそのルートで。
この3段階を最初に決めて共有しておくと、「これは誰に聞けばいいのか」で止まらなくなります。
課題の一行に必要なのは、4つだけ
課題管理表は、項目を増やすほど更新されなくなります。必要なのは次の4つです。
- 何が起きているか。一文で。「先方のデータに、想定外の文字コードが混在している」。
- 誰が持つか。ひとりの名前。解決する人でなくても、状況を答えられる人。
- いつまでに。解決の期限か、次に状況を確認する日。
- いまどうなっているか。未着手／対応中／解決済み。3つで足ります。
原因分析や影響範囲の欄は、書ける人が書けばよく、必須にしないでください。4つ埋まっていれば、その課題は動きます。10項目埋めないと登録できない仕組みだと、そもそも登録されません。
「他部署の回答待ち」も課題です
自分たちの作業の遅れだけを課題として登録し、外で止まっているものを登録しない現場が多くあります。これは損です。回答待ちを課題として置いておけば、それが自分の遅れではなく組織の遅れだと記録に残ります。置かなければ、最後には全部プロジェクトの遅れとして扱われます。2.3で書いた「待ちを外す」も、まず置くことから始まります。
週に一度、10分見れば足ります
課題の一覧は毎週見ます。ただし、全件の状況を説明する会議にしないでください。それをやると30分かかり、翌月には開かれなくなります。
見るのは3つだけです。期限を過ぎているものはどれか。今週動かなかったものはどれか。新しく増えたものはあるか。これなら10分で終わります。
そして「今週動かなかったもの」がいちばん重要な情報です。2週続けて動かない課題は、たいてい誰かが手を出せない状態にあります。そこがエスカレーションすべき場所です。
ABではこう見えます
AB Projectsでは、課題をタスクとして扱えます。担当・期日・状態が最初から備わっているので、別に課題管理表を作る必要がありません。ひとつの場所にあると、作業と課題を行き来せずに済みます。
変更の記録は、プロジェクトWikiに一行ずつ追記していく形が扱いやすくなります。「2月14日：移行範囲を3年分に限定（先方判断、工数▲5人日）」。この一覧が半年後に効きます。7.2のふりかえりで読み返す材料にもなります。
このページで使った言葉
- 課題
- すでに起きていて、対処しないと進まない事柄です。一行に必要なのは内容・担当・期限・状態の4つです。くわしく →
- リスク
- まだ起きていないが、起きると困ることです。現実になったら課題に移します。くわしく →
- 変更管理
- 決まっていたことを変えるときの手順です。変更を止めるのではなく、代償を決める人に見せる仕組みです。くわしく →
- 仕様変更
- 決まっていた内容を変えることの、日常会話での呼び方です。多くのスコープ争いの中心にある言葉です。くわしく →
- QCD
- 品質・コスト・納期の頭文字です。変更の影響を見るときの3つの観点になります。くわしく →
- エスカレーション
- 自分の権限で決められないことを、決められる人に上げることです。動かない課題は、ここへ回します。くわしく →