変更依頼管理ってなんぞや？

CRMっていうと、Customer Relationship Managementを連想する方がほとんどだと思いますが、こっちの世界（どこの世界だ？）では、Change Request Managementの3文字略語として用いることもあります（と書いておいてなんですが、私は個人的にはこの略語を使わない＆使いたくない派です）。

では、このChange Request Management（変更依頼管理）とは何かというと、

　　　不具合や仕様変更などの一連のライフサイクルを管理し、追跡しましょう

と、ここでは簡単にいってしまうことにします。

変更依頼っていうのは、不具合や仕様変更、機能拡張などのソフトウェアに関わるさまざまな“変更”の依頼の総称だと思っていただくといいかと思います。

じゃ、依頼（Request）ってなにさっ、っていうことになるのですが、これは、利害関係者（そのソフトウェアやシステムに関わる人々ですね。だからプロジェクトの内の人だけではなく、外の人もいることが多いですね）からもらった報告やお願い事です。依頼（Request）のポイントは、報告された時点では、これはまだ、実施するかどうか意思決定が下されていないということです。このあたりが要件（または、要求、英語だとRequirement）との大きな違いです。

依頼（Request）ってものは、報告されると、分析→意思決定→担当者の割り当て→作業実施→検証→承認→完了のようなライフサイクル（ワークフロー）を経てソフトウェアやシステムに組み込まれていくことになります。当然ですが、ナンセンスな依頼だったら却下したり、先送りにしたりする意思決定もありありなわけですね。

で、この依頼のライフサイクルを見ていただけると、これってひとつの役割で対応できるものではないことがわかります。言い換えるとたった一つの依頼であっても、完了するまでにはチーム全体を通して作業しないといけないことが見えるのではないでしょうか。

さまざまな役割がタイミング、タイミングで関わってくるとなると、これはもう何らかの管理手段なしでは取り扱いが困難になってくるのは容易に想像できることはないかと思います。

逆に、変更依頼管理を実践することで、意識や価値観の異なるチームメンバー（さまざまな役割）に対して、プロジェクトとしての共通の価値観や決定事項をもたせつつ、ワークフローにより流れに従って複数の厄介な“変更”に対応していくことができるといった、チーム内のコミュニケーションの改善や最適化につなげることができると言われています。実際に変更依頼管理のお手伝いをさせていただきますと、まず真っ先にでてくる定性的な効果がコミュニケーションの改善、最適化だったりします。

最後に、ソフトウェア構成管理との関連について。変更ってことはソフトウェアやシステムに何らかの手を入れることになるわけです。ってことはソフトウェアの構成が変わるってことですね。そうです！基本的には、ひとつでも変更依頼を対応したらソフトウェアやシステムは別のものに変わってしまっているんです。逆にソフトウェア構成管理をせずに、ここの変更依頼に対応するのも非常にタフな仕事になってしまいます。ひとつの変更依頼を対処するだけで構成がかわるわけですから、変更依頼の対応状況に応じて再現すべき構成（修正対象となる構成や変更後の構成など）も変化していくわけですから。ソフトウェア構成管理と変更依頼管理の関係をRUPではわかりやすいCCMキューブという立方体で表現しています。