今回は変更管理ツールについてお話します。
ほとんどのソフトウェア開発組織では、ソフトウェアの変更管理について一定の仕組みをもっていることと思います。
コンピュータシステムであったり、紙の帳票による管理であったり、いろいろな形態が考えられます。
Automotive SPICEでは下記にようにプロセス成果が定義されています。
1) 変更管理戦略が策定され；
2) 変更の依頼が記録され、かつ識別され；
3) 他の変更依頼への依存及び関係が識別され；
4) 変更依頼の実装確認の基準が定義され；
5) 変更の依頼が分析され、優先順位付けされ、かつ資源要件が見積りされ；
6) 変更が、優先度及び資源の利用可能性に基づいて承認され；
7) 承認された変更が実装され、かつ終了まで追跡され；そして
8) 全ての変更依頼の状況が知られている。
これを帳票でのやりとりやツールなしで実現することはもちろん可能です。
SPICEは運用についての指定はありませんから、いろいろな方法が考えられるわけです。
しかし、ここで大事なのは如何に現場が使いやすいか、負荷がかからず効率的で有効なシステムかどうかです。
いくら要件をクリアしても現場が使ってくれない、使ってくれてもそれが逆に負荷になるようでは問題です。
帳票を書くのに手間がかかる、帳票がどこかで停滞している、変更全体がわかりづらい、関係者全員が把握しずらい。
など、紙の帳票には欠点が多く、効率的とは言えません。
現在変更管理システムにいいツールが出ていますのでこれを使わない手はないでしょう。
市販のツールも高機能ですが、オープンソフトのツールでも十分な機能を持っています。
Bugzilla、Mantis、影舞などいろいろな種類のソフトウェアが世の中にでていますので、自分たちの組織にあったものを採用するといいでしょう。
下記にその適用をざっと示します。
1) 変更管理戦略が策定され；
→品質システムにわれわれの戦略を定義しましょう。
こういうシステムを使う。こういう運用をするということが十分戦略になります。
2) 変更の依頼が記録され、かつ識別され；
→ツールに変更要求を記録します。これは固有のIDを持つことになりますが、通常ツールが勝手に割り振ります。
3) 他の変更依頼への依存及び関係が識別され；
→ツールに他の変更要求とリンクする機能がありますが、なければ関連するIDを記録します。
4) 変更依頼の実装確認の基準が定義され；
→通常CCB（変更管理委員会）や上長による実施判断があらかじめ決められます。
変更実施の可否を判断する人の権限の設定がツールにあるのが普通です。
5) 変更の依頼が分析され、優先順位付けされ、かつ資源要件が見積りされ；
→変更の分析をする人がアサインされ、その結果変更がどれくらいかかるか分析されます。
分析者は上級エンジニアなどが相当しますが、もちろんそういう役職でなくても可能です。
ようするに誰が分析するかをあらかじめ決めておいて、その人に任せます。
6) 変更が、優先度及び資源の利用可能性に基づいて承認され；
→分析の結果、その工数が妥当であれば実施が承認されます。
7) 承認された変更が実装され、かつ終了まで追跡され；そして
→変更を指示された人が分析結果に基づいた方法により、プログラムを変更します。
変更が完了すれば、その旨報告します。ツールのコメント欄などを使うことができます。
8) 全ての変更依頼の状況が知られている。
→変更管理ツールで変更要求を管理すると決めて、すべてこのツール上で管理すればOKです。
（アンダーグランドでプログラムを変更してはいけません）
これで、SPICEの要件はクリアできますが、後は如何に効率的で使いやすいシステムを構築するかになります。
変更管理のツールは項目フィールドやフローのカスタマイズが可能なものが多いのですが、なるべくシンプルにするのがいいでしょう。最初は必要最小限の項目フィールドや、フローで実施してみて、運用がうまくいったらいろいろ検討したほうがいいと思います。
なお、私の経験でプロセス改善でもっとも現場の受けがよかったのはこの変更管理であったことを付け加えておきます。
ほとんどのソフトウェア開発組織では、ソフトウェアの変更管理について一定の仕組みをもっていることと思います。
コンピュータシステムであったり、紙の帳票による管理であったり、いろいろな形態が考えられます。
Automotive SPICEでは下記にようにプロセス成果が定義されています。
1) 変更管理戦略が策定され；
2) 変更の依頼が記録され、かつ識別され；
3) 他の変更依頼への依存及び関係が識別され；
4) 変更依頼の実装確認の基準が定義され；
5) 変更の依頼が分析され、優先順位付けされ、かつ資源要件が見積りされ；
6) 変更が、優先度及び資源の利用可能性に基づいて承認され；
7) 承認された変更が実装され、かつ終了まで追跡され；そして
8) 全ての変更依頼の状況が知られている。
これを帳票でのやりとりやツールなしで実現することはもちろん可能です。
SPICEは運用についての指定はありませんから、いろいろな方法が考えられるわけです。
しかし、ここで大事なのは如何に現場が使いやすいか、負荷がかからず効率的で有効なシステムかどうかです。
いくら要件をクリアしても現場が使ってくれない、使ってくれてもそれが逆に負荷になるようでは問題です。
帳票を書くのに手間がかかる、帳票がどこかで停滞している、変更全体がわかりづらい、関係者全員が把握しずらい。
など、紙の帳票には欠点が多く、効率的とは言えません。
現在変更管理システムにいいツールが出ていますのでこれを使わない手はないでしょう。
市販のツールも高機能ですが、オープンソフトのツールでも十分な機能を持っています。
Bugzilla、Mantis、影舞などいろいろな種類のソフトウェアが世の中にでていますので、自分たちの組織にあったものを採用するといいでしょう。
下記にその適用をざっと示します。
1) 変更管理戦略が策定され；
→品質システムにわれわれの戦略を定義しましょう。
こういうシステムを使う。こういう運用をするということが十分戦略になります。
2) 変更の依頼が記録され、かつ識別され；
→ツールに変更要求を記録します。これは固有のIDを持つことになりますが、通常ツールが勝手に割り振ります。
3) 他の変更依頼への依存及び関係が識別され；
→ツールに他の変更要求とリンクする機能がありますが、なければ関連するIDを記録します。
4) 変更依頼の実装確認の基準が定義され；
→通常CCB（変更管理委員会）や上長による実施判断があらかじめ決められます。
変更実施の可否を判断する人の権限の設定がツールにあるのが普通です。
5) 変更の依頼が分析され、優先順位付けされ、かつ資源要件が見積りされ；
→変更の分析をする人がアサインされ、その結果変更がどれくらいかかるか分析されます。
分析者は上級エンジニアなどが相当しますが、もちろんそういう役職でなくても可能です。
ようするに誰が分析するかをあらかじめ決めておいて、その人に任せます。
6) 変更が、優先度及び資源の利用可能性に基づいて承認され；
→分析の結果、その工数が妥当であれば実施が承認されます。
7) 承認された変更が実装され、かつ終了まで追跡され；そして
→変更を指示された人が分析結果に基づいた方法により、プログラムを変更します。
変更が完了すれば、その旨報告します。ツールのコメント欄などを使うことができます。
8) 全ての変更依頼の状況が知られている。
→変更管理ツールで変更要求を管理すると決めて、すべてこのツール上で管理すればOKです。
（アンダーグランドでプログラムを変更してはいけません）
これで、SPICEの要件はクリアできますが、後は如何に効率的で使いやすいシステムを構築するかになります。
変更管理のツールは項目フィールドやフローのカスタマイズが可能なものが多いのですが、なるべくシンプルにするのがいいでしょう。最初は必要最小限の項目フィールドや、フローで実施してみて、運用がうまくいったらいろいろ検討したほうがいいと思います。
なお、私の経験でプロセス改善でもっとも現場の受けがよかったのはこの変更管理であったことを付け加えておきます。