読者です 読者をやめる 読者になる 読者になる

構成管理ベストプラクティス 〜変更管理計画〜

PM

「構成管理」と言うと、主にバージョン管理の部分が協調されることが多いように思うのですが、変更管理も重要です。バージョンだけを管理していても、何の変更によりバージョンが修正されたのか、どのバージョンに対する変更なのかが分からないためです。


変更管理ツールは、以前はBTS(Bug Tracking System)と呼ばれることが多かったですが、最近はバグだけでなく、要件やTODOタスクなども管理できるようなITS(Issue Tracking System)と呼ばれるようなツールが多くなってきています。


ここでは、ITSを前提として話をします。なので、1つの変更要求は「Issue」と呼ぶこととします。

  1. 入力項目は集計/分析することを前提に決定する
    • Issueには、要件/バグ/タスク等の分類がありますが、入力項目は、各分類に対して、集計/分析したい内容に基づいて決定しておきます。最初は、Issueの内容と作業結果が分かれば十分だと思われるかもしれませんが、変更管理ツールを有効活用するためには、機能名や発生工程など、集計/分析に役立つ項目を含めておくべきです。
    • 変更管理ツールを選択する際は、入力項目をカスタマイズできるツールを選択すべきです。
  2. 入力項目が選択値の場合は選択基準を決めておく
    • 入力項目が選択値の場合(優先度や規模など)は、担当者によって、選択する基準がバラバラになりがちです。予め、簡単に選択基準の説明を示しておくと良いでしょう。
  3. いつでも集計/分析できる状態にしておく
    • Issueが頻繁に発生する場合は、何らかの問題が発生しており、是正処置が必要となる可能性が高いです。そのような状況に素早く気付き、効果的な是正策を立てられるようにするためには、Issueの内容をプロジェクト途中でも集計/分析できることが重要です。
    • ツール自体が集計機能をサポートしている場合もありますが、CSVなどでエクスポートしてExcelで集計するようにしておくのも有効です。
  4. バージョン管理との関連付けを行う
    • ツール自体で、自動でバージョン管理と変更管理が関連付くモノ(例:Subversion&Trac)もありますが、そうでない場合でも、変更の作業結果は、バージョン管理されている成果物と関連が分かるようにしておくべきです。変更作業終了時のコメントに、変更した成果物を示す程度でも良いでしょう。
  5. 変更のフローを決定しておく
    • Issueが常に正しく対応されるとは限りません。変更内容が不足していたり、曖昧だったりすると、担当者は作業ミスをする可能性があります。変更内容をレビューしたり、承認者を設けて作業結果をレビューしたりするようにしておくと良いでしょう。