第3回 リリース後に見つかる問題点をつぶす：開発環境の整理術

今回はリリース間の変更管理に焦点を当てて、混乱した開発環境を収拾するノウハウを伝授する。一度の「リリース」ですべてがうまくいけば何の問題もないのだが、現実はそうではない。度重なる変更対応を手際よく整理するにはコツがいるのである。（アットマーク・アイティ編集局）

[田中友子（SourceForge 技術担当），VA Linux Systems Japan（株）]

問題：リリースで発生した不具合の原因を突き止められない／修正したはずの不具合が再発する／修正忘れが発生する

　ソフトウェアはいったんリリースしたらそれでおしまい、ということは少なく、次々と新しいバージョンをリリースします。ユーザーからの要望を反映したり、異なるチップやOSへ対応させたり、不具合を修正したり……。この過程でも、いろいろな問題が作り込まれる危険性があります。

　例えば、不具合Aの報告を受けたときに、こんなのはすぐに直せるからといってすぐ修正を行い、作業内容や不具合現象を記録に残さなかったとします。すると、この修正が別の不具合Bを引き起こしたときに原因解明に時間がかかります。不具合Aの存在を知らない人が不具合Bを修正すると不具合Aが再発するかもしれません。

　また、リリースを複数リリースに分岐しなければならなくなった場合、さらに複雑になります。あるリリースで見つかった問題が別のリリースで再現するかどうか、必要なリリースすべてに正しく修正を行ったか把握しなければなりません。必要以上に不具合対応状況の把握に時間を浪費したり、対応し忘れたりします。

　この結果、保守ばかりに無駄な工数が発生し、次リリースが延期され、その挙げ句、不具合が再発し最悪ユーザーの信用をなくすことにつながります。

　問題の発生を最小限にとどめ、かつ問題が発生したとき工数の浪費を防ぐためには、リリース後のソフトウェアに対する変更を的確に管理する必要があります。

◎ ポイント

［A 変更手順を見直す］

• A-1 変更要求内容を記録する
• A-2 対応を検討する
• A-3 対応する
• A-4 検証する

［B 派生・分岐の管理方法を見直す］

• B-1 派生・分岐の行い方
• B-2 派生・分岐後の変更管理

整理術的解決方法

［A 変更手順を見直す］

　リリース後、そのリリースに対する変更要求は、不具合の報告であろうと機能の追加要求であろうと、内部報告であろうと外部報告であろうと、種類を問わず、1つ1つ変更要求として管理します。そのうえで各変更要求に対する処理は次のA-1からA-4にのっとって行うように徹底します。

図1 リリースの変更要求は種類を問わず、個別の変更要求として管理する

［A-1］ 変更要求内容を記録する

　記録をするときに大切なのは、変更要求の対象となっているリリースを明確にすることです。例えばユーザーから不具合の報告があった場合はそのユーザーが利用しているリリースのバージョン番号を記録します。当然ながらリリースのバージョン番号とそのリリースを構成するファイル群は一意に特定できるようになっていなければなりません。

　リリースのバージョン番号以外にも要求の対応に必要な情報はあります。利用環境、条件、不具合なら再現手順など。内容を記録するときに必要な項目が漏れないよう記録フォーム（紙でも、表計算ツールでも）を用意するのはもちろんのこと、フォーム入力形式を定義するのも有用です。

［A-2］ 対応の検討

　記録された変更要求に対し、対応方法・対応順序を検討し決定します。広範囲のユーザーに対する満足度を上げることができるような変更の要求や、製品のコンセプトを深めるような変更の要求を、より効果の高いものから順に取り込んでいくことで、上手に製品を成長させていくことができます。

　具体的には、例えば以下のような点に基づいて、各変更要求に客観的な5段階程度の優先度を付けていくのがいいでしょう。

◆ 回避策・別手段の有無

◆ ユーザーへの有効性・実害の有無

◆ 競合製品のとの比較

◆ 流行

◆ 実現性（コスト・スケジュールなど）

　そして、高い優先度のものから、担当者を割り当てます。優先度が決まった経緯、すなわち、優先度が高い／低い理由、優先度を最終的に決定した人、日時を記録として残しておくと、後々実際の対応方法を検討するとき役に立つでしょう。計画的に対応していくために、その対応先となるリリースのバージョン番号を決める必要もあります。

［A-3］ 対応する

　割り当てられた各変更要求に対し、担当者が対応を行っていきます。後から、どの変更要求に対して実際にどのような変更が行われたかを確認できるように、実際に行った変更の内容を記録します。

　各種仕様書に影響する変更であれば、仕様書の変更内容と変更要求との対応付けを明確にします。その変更要求に基づいて変更したソースコードは、ファイル名と変更個所とが、各変更要求別に分かるようにします。例えば、バージョン管理ツールを使っていれば、変更要求は1つ1つ順に処理し、1つの変更要求に対応したところでソースコードやその他関連ファイルのチェックインを行います。そして変更されたファイル名とその新しいバージョン番号を、変更要求の詳細として記録しておくという具合です。

　また、現在対応中の変更要求については、いつでも状態を把握できるようにしておく必要があります。変更要求を1つずつ別々の用紙に記載し、対応の段階で、それぞれを担当者に配る、という方法も世の中にはありますが、これは状態を把握するという視点からはあまり効率のいい方法とはいえません。誰が担当しているか、状態がどうなっているかを把握するには、開発者に1件1件問い合わせなければならなくなるからです。

［A-4］ 検証する

　対応が終わった変更要求について、正しく対応が行われているかを次の2点から検証します。変更が正しい手続きにのっとって行われていることと、変更内容に誤りがないことです。

　まず、変更要求として登録されていること「のみ」が変更されていることを確認します。簡単に修正できるようなことが見つかったりすると、何かの変更に便乗して修正してしまいがちですが、これは正しい手続きにのっとった変更とはいえません。このような変更が、行われていないことを確認します。

　それとは別に、変更要求に対する対応が、変更要求の内容を満たしていることを検証します。担当者が正しく対処したつもりでいても、変更要求のとらえ間違いで別の対応をしてしまっている可能性もあります。また、対応方法自体が適切でなく、別の問題を引き起こしてしまっている可能性もあります。ソースコードのみが変更されていて、文書の変更が忘れられているかもしれません。

　変更要求に対して正しい対応が行われたかを確認して、この変更要求に対する処理の流れというものは終了します。変更要求の管理方法を検討するときにはこのような検証を効率よく行える方法であるかということも考慮に入れなければなりません。

　ここまでは変更要求に対する処理そのものを確認しましたが、次に、変更した要素の分岐後の管理方法について簡単に解説します。

［B 派生・分岐の管理方法を見直す］

　ソフトウェアを分岐させるということは、それだけ管理対象が丸ごと増えるということです。例えば、パラメータなどを追加したり、共通部分を別モジュールにするなど、できるだけ避けたり、規模を小さくしたりすることを検討してから行う方がいいでしょう。分岐せざるを得ない場合は次のようなことに気を付けます。

［B-1］ 派生・分岐の行い方を考える

　ある特定のリリースを基に、別の開発をすることになったとき、そのリリースをコピーし始点とします。ここでファイル群だけをコピーしてしまうと、いままでの開発の履歴・変更の経緯がすべて無駄になってしまいます。コピー元となるリリースについて、それを構成する文書・変更要求・ファイル群を明確にし、かつ、コピー先ではどこからコピーされてきたか、後から必ず確認できるようにします。

［B-2］ 派生・分岐後の変更管理を行う

　あるリリースAから分岐A1と分岐A2が派生したとします。このとき分岐A1で報告された不具合は分岐A1の変更要求として管理します。この後、分岐元であるリリースAでの再現性、分岐A2における再現性を確認し、分岐A2でもし再現する不具合であれば、分岐A2の変更要求として新たに登録します。これによって、分岐先での不具合の修正漏れを防ぐことが可能になります。

　ただ、分岐A1と分岐A2でそれぞれ0から原因を調査していたのでは、時間が倍かかってしまいます。分岐A1の変更要求と分岐A2の変更要求で関連性があるものについては、その関連性を明記するなどの作業重複を回避する工夫が必要です。

図2 派生・分岐後の変更管理

　第2回「チーム開発の落とし穴を埋める」、ソフトウェア構成管理ツールに関する説明を書きましたが、ソフトウェア構成管理ツールには、それぞれ、この分岐の管理、分岐で行われた変更の管理やほかの分岐への反映を効率よく行う仕組みが存在します。開発しているソフトウェアの性質・分岐の方法を念頭に置いたうえで、このような仕組みを導入・活用するのもよいでしょう。

---

　以上、今回はリリース間の変更管理に焦点を当てて、整理方法を検討しました。整理方法を決めて実行するのは、軌道に乗るまでは、面倒で手間が掛かります。しかしながら、軌道に乗ってしまえば、問題の発生・原因究明・対応すべてにおける時間を短縮させることが可能になります。この記事が変更管理の検討のきっかけになれば幸いです。

著者プロフィール

田中友子

　VA Linux Systems Japan (株)、SourceForge 技術担当。米国製構成管理ツールやコラボレーションウェアの日本語化作業およびテクニカルサポートに従事。

「開発環境の整理術」バックナンバー

• 第4回（最終回）担当者で情報を共有し、引き継ぐノウハウ
• 第3回 リリース後に見つかる問題点をつぶす
• 第2回 チーム開発の落とし穴を埋める
• 第1回 要求仕様に関係する落とし穴