変更管理というのは、昔ながらのプロジェクトマネジメントで使われる変更を運用するための手法だ。昔ながらのプロジェクトの変更管理は典型的に、変更内容の詳細、プロジェクトへの影響、リスク、代替案などの属性を持った変更要求の詳細を書き込むことで成り立っている。その内容を何人もの承認を得る必要がある。昔ながらの変更管理は、アジャイルのやり方とは一線を画している。なぜならば、「計画に沿った上で変化に対応する」という原則に違反するからだ。変更の許諾要求が膨大な量の書類となっている場合、変化に対応していくことはとても難しい。リーンアジャイルスクラムグループ(リンク),で興味深い議論がなされていた。グループのメンバーが議論していたのは、スクラムにおいて変更がきちんとトラックできるような方法で変更を記録するということの必要性についてだった。
なぜチームは変更をトラックする必要があるのだろうか？
Ashish Pathak氏が挙げる理由の一つは(リンク)、プロダクトオーナーにプロダクトバックログに不要なものを追加するのを思いとどまらせるためだと言っている。これは巡り巡ってプロダクトオーナーを利することにもなる。件のグループでは、バックログに入っている項目が充分に考え抜かれたものでない場合、時として結果的に項目が頻繁に変更されてしまう傾向があることに同意している。Mary Poppendieck氏(リンク)は原則的に、ではあるが、バックログをきちんと運用するために、変化を抑制してしまうことは過程に問題があると言っている。しかしながら、彼女は一方でプロダクトバックログの頻繁な変更はしない方がいいということは同意している。彼女によると(リンク)、
どんなバックログであろうとも最初は、変更の必要がないだろう、と思えるような簡潔かつ高いレベルのものにするべきです。バックログに変更があったときは、それが変更を要求した人ではなく、バックログに問題が有ったのだと仮定してしまいましょう。変更要求が起きる場合は、たいていはバックログが長すぎるか詳細すぎることを意味しています。未来を予測することに多くの時間を割きすぎているのです。
また、彼女は以下ようにも述べている(リンク)。
もしこういったブレ（バックログの項目を入力してから製品が製造に入るまでにバックログの項目を変えること）を計測する場合、10%から15%のブレであれば問題有りません。しかし50%から200%のブレがある場合、バックログが変更されていくなかで、誰かが時間を大幅に無駄にしているということになります。何が確定していて、何がそうでないのかについて判断能力が無いと言わざるを得ません。大幅なブレが発生している場合、それはしばしば、進捗するように対処をしたり、不確かさに対応できるように組織化するのではなく、変更を抑制したり、不確かさから組織を分断するようなバックログになっているという合図なのです。
件のグループは、バックログのブレに基づいて分析をすることが、プロダクトオーナーが適切な項目を含んでいるバックログになるように微調整するための手助けになるということに同意している。この議論では、変更をトラックできるようにすることは、幾つかのシナリオを作る上でも手助けにもなると言っている。
では、チームはどのようにして変更をトラックすればよいだろうか？
件のグループの多くのメンバーは、変更はバックログに追加するべきだという論調になっている。Brian Bozzuto氏は、バックログの項目に、どのストーリに起因しているか特定できるような属性を持たせるようにすればよいと言っている(リンク)。この属性の値は、オリジナル、新規、変更などを取り得るようにする。
似たようなアイデアとして、Erik landes氏(リンク)は、リーンのかんばんのような手法で(リンク)変更要求を運用することを提案している。また、Chris Woodill氏は、アジャイルの変更管理プロセスを満たすような一般的な方法を提案している(リンク)。彼によると、ライトウェイトなプロセスを保持し、ムダをできるだけ除去することを主眼に置くべきだとしている。
彼が推奨している主なものを、以下に挙げる。
- バックログや変更のトラッカーに変更のログを取る
- できるだけ承認フローは排除する
- 変更管理フォームの書式は簡単なものにする（もし変更管理フォームが必要ならば）
- 関係者とオペレータは巻き込んだままにしておく
これまでに述べてきたように、幾つかの特定の場面では、変更のトラックが必要になることがある。変更のトラックをすると、プロダクトバックログのブレがいつの間にかムダを根絶する手助けをしてくれるようになるので、考えようによっては、プロダクトオーナーはより効率的に動けるようになる。まだまだ他にも変更をトラックする理由や方法もあるが、鍵となるのはプロセスをリーンに保つことであり、有益な情報が得られるまで詳細に踏み込むことにある。
原文はこちらです：http://www.infoq.com/news/2008/12/change-requests-in-scrum