第11章変更管理 ── 変更要求が来たとき、サイクルをどう回すか

変更要求が来たら

発注者から「送料無料の対象を、一部の商品に絞りたい」と言われたとします。すぐに成果物を開いて直したくなりますが、まだ直しません。変更要求も、ほかの論点と同じように【深める】で議論し、決めてから成果物に入れます。順番は次のとおりです。

1. 変更要求を、未決型ISSUEとして受ける。
2. 影響を調べる。
3. 決めて、ADRに残す。
4. 成果物に入れる（反映型ISSUE）。

直す前に決めるのは、変更がどこまで響くかを見てからでないと、変えるかどうかを決められないからです。変更の決定は業務に触れることが多いので、決めるのは発注者側の人になることが多いでしょう。

変更は、外から来るとは限りません。工程の途中で決めたことが、前に書いた成果物に及ぶこともあります。そのときも、同じ順番で回します。

影響を調べる

まず、変更がどこに響くかを調べます。使う道具は、これまでに出てきたものです。

影響を見るために、変更後の姿を試しに書いてみてもかまいません。これが分析用の試作です。試作に【広げる】でシナリオを歩かせると、既存の成果物のどこに触るのかが見えてきます。ただし、試作は成果物本体と分けておきます。本体に紛れ込むと、まだ決まっていないことが、決まったこととして読まれてしまいます。

こうして出てくるのは、影響の候補です。本当に影響があるかどうかは、人が1件ずつ決めます。影響を調べる範囲は広いので、候補もたくさん出ます。

影響が1本の業務フローに収まらず、もっと広い範囲へ及ぶこともあります。そのときは、その論点を上の単位の【深める】へ持ち込んで決めます。そこから先は、単位を広げるときの受け渡し（育て方サイクル総論で見たもの）と同じです。

決めて、ADRに残す

決まったら、ADRに残します。元のADRとの関係で、書き方が2通りあります。

• 元の決定を覆すとき：新しいADRを起票し、元のADRを置き換えます。
• 元の決定は生かしたまま、条件を足すとき：たとえば「送料無料の閾値は業務部門が切り替える」はそのままで、「対象商品を絞れる」を足す場合です。元のADRに追記せず、新しいADRを並べて起票します。新しいADRの「前提とする決定」に元のADRを書いておけば、2本の関係が辿れます。

元のADRに追記する形を認めると、いま有効な決定を知るのに、元の部分と追記した部分を読み合わせることになります。1つの決定は、1本のADRで読めるようにしておきます。

前提が変わったとき

決定の中身はどれも正しいのに、共通の前提が変わったせいで、何本ものADRが一度に古くなることがあります。たとえば「送料は注文単位で計算する」を前提にしたADRが何本もあるところへ、送料を明細単位で計算することになった場合です。

こういうときも、まとめて置き換える書き方は作りません。それを許すと、1つの決定を1本のADRで読むという単位が崩れ、置き換えの意味が2つになるからです。代わりに、前提そのものをADRにしておきます。

どのADRがどの前提に立っているかは、属性の「前提とする決定」に書きます。リンクの種類を新しく増やすわけではありません。前提のADRが置き換わると、それを前提にしていたADRは、成果物との整合の照合でAIなどが拾います。どれを置き換え、どれをそのまま残すかは、1件ずつ人が決めます。前提が変わっても正しいままの決定があるからです。

成果物に入れる

ADRができても、成果物はまだ古いままです。反映する作業を、反映型ISSUEに積みます。

決定がADRに残っていても、反映の作業を追っていなければ、決定は成果物に届きません。先行事例には、ADRに書いてあった負荷の問題が忘れられ、リリースの9か月後に障害として表に出た例があります。

いつ反映するか

反映は、決定の後ならいつでも構いません。節目でまとめて反映し、前の版は書き換えずに次の版で作り直すやり方もあります。