連載第1回「ファイルバージョンの管理だけで十分ですか?」では、構成管理とは単なるファイルのバージョン管理ではなく、例えていうならプロジェクトを丸ごと保存することであり、その導入手順の概要をお伝えしました。第2回「プロジェクトの構成要素を探す手順」では、構成要素の見つけ方についてお話ししました。第3回は、それら構成要素の変更管理について解説したいと思います。
まず、変更管理について明確にしておく必要があります。皆さん、変更管理という言葉を聞くと、“何となく”想像することはできても、明確には定義できないのではないでしょうか?
システム開発における変更管理とは、
によって、常にすべての成果物間の整合性を確保・維持すること、です。
CMMIの構成管理に該当する説明には、詳細な記述がありますが、日常業務の範囲であれば、“最終的に”上記の認識で十分です。“最終的に”とは、「変更要求にはどんなものがあり、影響を把握するとはどういうことで、成果物間の整合性を確保・維持するためにはどうすればよいのか」といったことを理解したうえで、上記の認識を持てばよいという意味です。「なあんだ」と思うかもしれませんが、大事なのは、全体の構造を理解したうえで、上位概念を意識に留めておくということです。そうすれば、いつでも細部を思い出すことができます。
それでは、変更要求から見ていきましょう。
変更要求には、どのようなものがあるのでしょうか? システムには、大きく2つのフェイズがあります。新規に開発されている期間、つまりプロジェクトフェイズと運用フェイズです。運用フェイズにおいても、保守の一環としての開発プロジェクトがありますが、大きく分けた場合には、それらは保守フェイズの適用範囲です。ここで、システムライフサイクルとせずに、フェイズと呼んでいるのは、サイクルではなく、一方向のシステムライフの流れとしてとらえるためです。
(1) プロジェクトフェイズにおける変更要求
プロジェクトフェイズにおける変更要求には、いわゆる“仕様変更”に分類するものと、テストフェイズにおける障害対応の2つのタイプに分類されます。仕様変更は、さらに以下に分類されます。
◇ 要求変更
◇ 設計変更
→要求変更に起因するもの
→設計単独の見直し変更
→実装上の制限からの見直し変更
◇ 実装変更
→設計変更に起因するもの
→I/F設計に影響を与えない実装単独の見直し変更
→I/F設計に影響を与える見直し変更
(2) 運用フェイズにおける変更要求
運用フェイズにおける変更要求は、障害対応と保守開発の2つのタイプに分類されます。念のため保守開発の例を挙げておきますと、パフォーマンス改善や、操作性改善などのような、品質改善に分類するものや、利用ITの老朽化対応としてのハードウェア刷新、ミドルウェアのバージョンアップなどがあります。このフェイズにおける構成管理、変更管理についてはITILに詳しく載っていますので、そちらも参考にされるとよいでしょう。
ここまでの分類を図にしたものを下に示します(図1)。
変更管理では、このようにいろいろなタイプの変更要求が発生するたびにIDを付与し、一意に識別可能な状態でそのステータスを含めて管理していくことになります。
(3) 変更対応するのは誰か?
さて、このように変更要求はシステムのフェイズによって異なるタイプが発生するわけですが、対応する人もさまざまに異なります。プロジェクトフェイズにおいては、もともと変更対象となる個所の開発を担当している人が対応するのが一般的です。従って、設計やプログラムのどの個所をどのように変更すればよいかが非常に明確に判断できることが多いはずです。
ところが、プロジェクトフェイズのチームは、プロジェクト終了つまり、新規開発システムがリリースされると解散するのが普通です。100%自社で開発をしている情報システム部などもありますが、全体としては明らかに少数派でしょう。
従って、運用フェイズで発生する変更要求への対応は、もともとの変更対象となる個所の担当者とは異なることになります。元のプロジェクトメンバーを確保する場合でも、コスト面を考慮すると、ごく一部のメンバーによって本来の担当外の部分の面倒も見てもらうことになります。
現実には、運用フェイズにおける変更要求に対応する人は、変更個所のプログラムコードを読んで、影響範囲をプログラムから読み解きつつ対応する場合が非常に多いものです。その結果として、変更内容をリリースした途端に障害が発生することも頻繁に起きています。
このような状況を改善するには、プロジェクトフェイズから運用フェイズへ必要な情報を適切に引き継ぐことが必要です。では、必要な情報とは何でしょうか? それは、一言でいえば「構成要素とそれらの関係」です。この中には例えば、
などがあります(構成要素の詳細例は第2回の例を参照してください)。これらが適切に引き継がれないために、プログラムコードを読み解くしか対処方法がないわけです。1人2人で十分に把握可能なくらいの小さなシステムであればそれでも問題なく運用ができるでしょうが、皆さんのシステムはいかがですか?
それでは、もう少し細かく変更要求への対応について見ていきます。先に少し触れましたが、変更要求が生じたときは、その影響範囲を把握しなければいけません。その結果、対応によって得られるメリットと、対応に必要なコストとのバランスを見て、対応可否を判断します。
影響範囲は、要求変更なのか、設計単独変更なのか、実装単独変更なのかによって、大きく異なります。当然のことですが、プロジェクト終盤で、(要求などの)上流工程での成果物に影響がある変更ほど、後工程の成果物への変更も必要となるため、影響範囲は著しく大きくなります。
また、テストについてですが、できる限り自動でテストが実施できるような仕組みを築いている場合と、すべてを人手で実施する場合とでは、実施テストの件数は同じでも、再テストに必要となるコストは数十倍の違いが出てくることもあります。
要求間の依存関係が適切に管理されていないために、何か1つ変更を加えると、すべてのテストを再実行しなければいけないという脅迫観念に取りつかれているシステムもよく見かけます。図2は、典型的な要求変更に対する変更管理フローを示したものです。
図2では、インパクトの見積もりや、変更作業を、複数の関係者が同時に行っているように描きましたが、実際には関係者への情報の伝達と作業の実施は、適切な流れで行われるように制御されなければなりません。関連するすべての要求への変更が認識される前に、設計者が適切な設計変更を行うことはできませんし、設計と実装、テストの関係も同様です。
適用技術の検証が不十分な場合や、設計者が実装を熟知していない場合(残念ながら動かない設計というのは頻繁に見られる現象です)には、これとは逆の流れが発生することもあります。なお、誤解のないように付け加 えておきますと、私は、実装レベルの設計は実装者が行うべきだと考えています。
すこし話がそれましたが、変更管理において重要なことは、すべての作業担当者に必要な情報が正しく伝達されるようにします。システムやチームの規模が大きい場合には、何らかのツールの助けを借りる必要もあるでしょう。小さなチームであれば、メールの一斉通知でうまくいくこともあります。いずれにせよ、きちんとフローを定義し、チームメンバー全員がそれを守るようにしなければなりません。そうすることで、見かけの依存関係だけでなく、内容そのものの整合性、一貫性を保つことができるようになるのです。
さて、ここまでの内容をご覧になって、「要求管理と構成管理の変更管理は何が違うのだ?」と思われた方もいるかと思います。これらは、単純にスコープが違うということです。要求管理では、あくまで要求の依存関係や、変更を管理します。構成管理における変更管理は、いろんな要因によって生じる多様な構成要素への変更を管理します。そこでは、要求管理の一環として行われる活動も含まれるわけです。現実には、プロジェクトを成功させるために、バランスの取れた取り組みを行うことが重要なのであって、これらの間に明確な線を引くことは重要ではありません。
さて、今回は変更管理についてお伝えしました。あなたが変更管理を実施するに当たって検討しなければいけないことは整理できましたでしょうか?
今村智(いまむらさとし)
メインフレームでの証券取引所データリアルタイム配信システム開発を経験後、数々のオブジェクト指向での企業情報システム開発を経て、ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。個人Webサイト(http://www.human-process.com/)からの情報発信
も行っている。
Copyright © ITmedia, Inc. All Rights Reserved.