変更管理は検事の立証作業に似ている

ITILの変更管理プロセスは、まるで検事が事件を立証していく作業に似ている。
そのデジャブから考えたことを書く。

【元ネタ】
ITILの変更管理

【1】どのプロジェクトでも、納品後の検証が最もプレッシャーがかかる。
検収で上がった不具合は、決められた期限で、デグレしないように確実に修正していかなければならない。
課題として管理し、症状を把握し、原因を調査して、対策を立てて、PG/テスターにアサインし、最後にPLが確認する。
このプロセスをいかに早く回すか、が鍵。

システム全体の機能とお客様の業務の整合性を考えて、設計していく作業をしていると、まるで自分が検事になったかのような気分になる。

というのも、お客様から上がってきた要望や不具合の指摘に対し、設計書や要求定義書、過去メールを引っ張り出して、本来の要求は何なのか、を突き詰めていく作業だから。

だから、過去はこんな仕様だったから仕様変更ですね、とか、これはバグではなく元々の仕様が間違っていましたね、というふうに、元々の要求を探っていく。
そして、以前お客様はこんなメールを書きましたね、とか、こんな要求を言ってましたが矛盾してますね、と、本来の要求を追い詰めていく。

この作業はまるで、検事が、現場の証拠や犯人の行動から事実を論理的に組み立てて、犯人を追い詰めていく作業に似ている。

要求を論理的に追い詰めた後の証拠があると、お客様も無理難題は吹っかけられなくなる。
そして、開発者へも、仕様と要求の本来の意図を確実に説明することができる。

【2】Redmineでプロジェクト管理全般のタスクを管理し始めて、バグ管理だけでなく、仕様変更、プロジェクトの立ち上げ時のスケジュール作成、サーバー環境の構築、顧客からの問合せ調査など、SW開発全般のタスクにも使えることが分かってきた。
Redmineは構成管理の強力なインフラだ。

Redmineでは、チケットに全ての作業履歴が残る。
更に、チケット同士の相互リンク、チケットとSVNリビジョンの相互リンクとしても残る。
又、SVNリポジトリにあるWordやExcelの仕様書、ビルドスクリプトも同様に、SVNリビジョンとチケットが相互リンクできる。
このインフラのおかげで、バージョン履歴から要件やソース修正理由を追跡しやすくなった。

この構成管理のインフラのおかげで、3年前にパッチを当てた修正理由を簡単に探し出すことができる。
すると、設計者やPLは、顧客の要求と過去の修正理由からシステムの変更仕様を設計して、仕様に矛盾がないか、他の機能に影響が無いか、など、仕様の整合性や一貫性を更に突き詰めることができる。

この作業は、丁度、法廷に集められた証拠から一つのストーリーを組み立てる検事の作業に似ている。
Redmineはこの作業の生産性をアップしてくれる。

これが、Redmineが構成管理のインフラになる利点だ。
そして、最近のSW構成管理は、ソースのバージョン管理や、常時統合のようなビルド管理だけでなく、変更管理のプロセスも含むようになりつつある。
だからこそ、昨今のSW構成管理の難易度は数年前と比べて格段に上がっているように思う。