BOOK Preview 新訳 ソフトウェアプロジェクトサバイバルガイド 第14章 構築 マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/08/30

Page1 Page2 Page3

ソフトウェア統合手順

　ソフトウェア構築に重要な役割を果たすのが、ソフトウェア統合手順である。これは、新しく開発されたコードをメインビルドに統合するための手順である。表14-1に、筆者が推奨する統合手順を紹介する。

表14-1 推奨する統合手順 1. 個別のコードを開発する。 2. コードの単体テストを行う。 3. 対話型のデバッガを使用して、コードのすべての行を1ステップずつ実行する。実行する範囲には、すべての例外処理とエラー処理も含む。 4. 自分の開発環境に移したメインビルドに、この暫定コードを統合する。 5. コードをテクニカルレビューに提出する。 6. コードをテスト担当者に非公式に引き渡し、テスト担当者がテストケースを準備する。 7. レビュアーがコードをレビューする。 8. レビューによって指摘された問題を修正する。 9. 修正結果を再びレビューする。 10. レビューに合格したコードをメインビルドに統合する。 11. コードが「完成」したことを宣言する。

完成してこそ「完成」

　表14-1に紹介した推奨統合手順を採用すると、プロジェクトの管理上重要なメリットが得られる。この手順に従えば、コードが「完成」したと公表した場合、実際に紛れもなく完成したことが保証されるのである。たとえば、「90%のモジュールが完成した」という進捗報告を読んだ場合、全モジュールのうちの90%は間違いなく完成しており、この90%については追加の作業が必要になったりしないという確信を持つことができる。

　コードの一部を未完成にしたまま次へ進む作業方法に慣れている開発者は、本書で紹介するアプローチを採用するときには、それまでの作業スタイルを変えなければならない。このような開発者は、プログラムの一部のコーディング中に、その部分が他の部分の機能に依存しているため単独では使用できないことに気付くと、依存している機能について仮のコードを作成しておいて、現在開発中の部分のコーディングを続ける。仮のコードには限界があるのが常であるから、開発者はこれを補うために、メインコードに補完用コードを追加する。慎重な開発者であればメモを作成しておいて、後で忘れずに仮のコードを修正し、仮のコードを使用するために必要だった補完用コードを削除する。

　補完用コードを作成しておいてから後でメインコードを改訂するという作業は、プロジェクト中に何回も必要になる。揚げ句の果てに開発者の手元には、「未決」リストの項目が膨大に累積されていくことになる。リストの説明には次のように書かれているだろう。「次の部分は仮に作成したコードなので、探し出して修正すること。また、仮のコードを補うためにメインコードに加えた部分もあるので、その部分も改訂すること。」このような開発アプローチでは、目に見える機能の多くがすばやく実装されていくが、後始末のためのフェーズが必要になる。そして、後始末のフェーズの作業量を予測することは、事実上不可能である。

　表14-1で概要を紹介した統合手順を採用するには自制心が必要であり、コードの一部が未完成のまま先へ進む開発アプローチに慣れ親しんできた開発者にとっては、かなりの努力を要する。しかし、1つのモジュールを完全に完成してから次のモジュールの開発に移るというプラクティスには、リスクを低減でき、進捗を明確に確認でき、コントロールがしやすいというメリットがある。つまり、実施する価値は十分にある。今までこの統合手順を使用したことがない開発者は、最初は非効率的と思うだろう。しかし、発生した欠陥をその発生直後に検出しないことによって生ずる非効率性の方が、はるかに大きい。本書で推奨する統合手順を実施すれば、こうした欠陥の大半は抑制できる。

他の開発者の作業のための安定した基盤の確保

　本書の統合手順では、プロジェクトの終期になるまで判明しにくい品質上の重大なリスクにも対応できる。コントロールが行き届かないプロジェクトでは、ソースコードの品質が保証される前にメインビルドに統合してしまう。欠陥がその場ですぐに明らかにならなければ、開発者はそのコードは完成したものとして次のコードの開発に進む。その結果、プロジェクトの終期になると低品質のコードが大量に統合された状態になり、問題が表面化し始める。個々のコードが高品質な標準を満たすことを要求されていなかったので、通常は1つの問題を修正すると新たに2、3個の問題が持ち上がる。この時点でプロジェクトは、Microsoftで「無限の欠陥」と呼ぶ状態に陥る。欠陥は、修正が追いつかないほどの速さで次々と現れてくる。そのまま手を打たなければ、無限の欠陥を持つソフトウェアとなることは間違いない。潜在的な品質問題がもたらすこのようなリスクは、これまでに何千とまでは言わないまでも何百というプロジェクトを中止に追い込んできた。この対応策となるソフトウェア統合手順は、プロジェクトの負担をわずかに増加させることと引き換えにプロジェクトのリスクを減少させるため、多くの組織が進んで採用している手段である。

デイリービルドとスモークテスト

　ソフトウェア統合手順と併せて、デイリービルドとスモークテストを行えば、相乗効果を生むことができる。これらの手順の概要を表14-2に紹介する。

表14-2 デイリービルドとスモークテストの手順［1］ 1. コード変更のマージ 開発者は、自分の開発環境にコピーしてあるソースファイルとマスターソースファイルを比較して、他の開発者によって加えられた最近の変更と、自分で追加する新しいコードまたは改訂したコードの間の相反箇所や矛盾点をチェックする。次に開発者は、自分のコードの変更箇所をマスターソースファイルとマージする。コードのマージには、多くの場合矛盾点などを検出する自動ソースコード管理ツールを使用する。 2. 自分の開発環境におけるビルドとテスト 開発者は、自分の開発環境でビルドとテストを行い、新しくコーディングした機能が期待どおりに動作することを確認する。 3. スモークテストの実施 開発者は、自分の開発環境に対して現状のスモークテストを実施し、新しいコードが原因となってビルドに異常が発生しないことを確認する。 4. チェックイン 開発者は、自分の開発環境でテストした新しいソースコードをマスターソースファイルに追加する。プロジェクトによっては、新しいソースコードをマスターソースファイルに追加できる時間を指定している場合がある。たとえば、新しいソースコードの追加を午前7時以降午後5時以前に限定して、それ以外の時間は禁止する、などである。 5. デイリービルドの作成 ビルドチーム（またはビルド担当者）は、マスターソースからソフトウェアの完全なビルドを作成する。 6. スモークテストの実施 ビルドチームはスモークテストを実施し、ビルドがテストに耐えられる程度に安定しているかどうかを評価する。 7. 問題を即座に修正 ビルドのテストを妨げるエラー、つまり、ビルドに異常を起こさせるようなエラーをビルドチームが発見した場合、異常を起こすコードを追加した開発者に対してその旨を通知し、その問題を即座に修正させる。ビルドのエラーの修正は、プロジェクトの他のいかなる作業にも優先する。 ［1］ この表で紹介した手順は、表14-1「推奨する統合手順」の手順11の後に続けて実施する。表14-1の手順が終了した時点で、開発者は自分のソースコードをチェックインする準備ができているはずである。これらの手順は、開発者が変更の必要なソースコードファイルをチェックアウトして、新しいファイルを作成したという前提に基づいている。

　デイリービルドとスモークテストの手順に従えば、プログラム全体を毎日ビルドする、つまり、プログラムのソースファイルのすべてを毎日コンパイルし、リンクして、実行可能なプログラムに統合することになる。次にそのソフトウェアに対して「スモークテスト」を実施する。スモークテストは、ソフトウェアが実行中に異常を起こさないことを確認するためのごく単純なテストである。スモークテストはもともと電気工学で使用するテストで、電気回路に電圧をかけたときに発火しないことを確認するためのテストである。

　デイリービルドとスモークテストを実施し、ビルドに異常が発生した場合、原因となるコードを作成した開発者を探し当て、異常の原因となったソースコードを必ず即座に修正させるという一連の作業を毎日行うには、ある程度の工数を覚悟する必要がある。小規模プロジェクトなら、品質保証担当者が本来の担当業務と合わせてデイリービルドを実施することが可能である。しかし大規模のプロジェクトでは、デイリービルドを実施するために専門の担当者が必要だろう。場合によっては複数の人間がグループで担当する必要があるかもしれない。

　スモークテストの内容は、ソフトウェアの開発の進捗に合わせて絶えず更新する必要がある。毎日実施するものなので、自動化しておく場合が多い。スモークテストですべてを網羅する必要はないが、ソフトウェアの機能の中の必要なものは網羅して、少なくともデイリービルドがテストに値するくらい安定しているかどうかを評価できるようにしなければならない。ソフトウェアがテストに値するほど安定していなければ、スモークテストで不合格とする。

　デイリービルドとスモークテストを実施することによって、プロジェクトが直面する最大のリスクの1つが防止できる。それは、別々のチームメンバーが独自に開発したコードを結合、つまり「統合」したときに、そのコードが正しく動作しないというリスクである。また、デイリービルドとスモークテストは低品質というリスクの対応策でもある。少なくともソフトウェア全体に対する最低限のテストを毎日実施することによって、品質の問題にプロジェクトが振り回されることを防止できる。プロジェクトチームはソフトウェアを確実に求められる品質まで引き上げ、その状態を維持する。品質低下の芽は早いうちに摘み取られ、対策に時間がかかる品質上の大問題が発生する余地はなくなる。

　デイリービルドを実施することによって、プロジェクトの進捗も容易に監視できるようになる。プロジェクトチームが毎日ソフトウェアをビルドするので、完成した機能と未完成の機能が一目瞭然であり、技術に詳しい人間もそうでない人間も、ソフトウェアを実行するだけで、どの程度完成に近づいているかを判断できる。

　デイリービルドとスモークテストを行う作業は、どのような規模のプロジェクトで実施しても成功してきたという実績がある。Microsoft Windows NT 3.0の巨大プロジェクトで500万行を超えるコードを作成した場合でも同じであった。大規模のプロジェクトでは、統合で問題が生じる可能性が非常に高いので、デイリービルドとスモークテストを実施することが特に重要である。

ステージ1 特有の考慮事項

　ステージ1の構築作業において、開発チームはシステムの骨組みを構築しなければならない。この骨組みは、その後に構築するシステムの機能を十分にサポートできるしっかりしたものでなければならない。この作業には、一般的にユーザーインターフェイスの外枠の作成が含まれる。この外枠にはメニューやツールバーなどをはじめとする部品を組み込んでおき、ソフトウェアの開発が進むにつれて、それらに各種の機能を持たせていくことになる。

　システムの骨組みを構築するには、ステージ1でインフラストラクチャの一部を開発する必要がある。一般的には、多くの機能を実装する前に、エラーハンドラ、文字列ハンドラ、メモリ管理などの基本的なツールを構築しておく。図14-1に示すように、システムの骨組みの構築では、一言で言うと、システムの「T」字型の部分の開発が必要となる。つまり、システム全体の幅を浅くカバーし、一部については深く掘り下げる。「T」字型というのは、ユーザーインターフェイスの1つ１つは完全には動作しないが、そのすべてがカバーされており、他の機能の基盤となるインフラストラクチャは、この時点ではまだ他の機能によって実際に呼び出されることはないが、完全に動作するようになっていることが必要である。

図14-1 ステージ1における「T」字型のシステムの骨組みの開発。幅にはシステム全体をカバーし、深さはステージ1の機能をサポートできる程度まで実装する。

拙速なインフラストラクチャ開発は避ける

　「T」字型の部分を構築したら、実際に目に見える機能を開発し始める。これが、プロジェクトの進捗を加速させるための最良の方法である。実際の機能のいくつかを実現する前に、インフラストラクチャをすべて開発しようとしてはならない。インフラストラクチャとは、プログラムを支えるのに必要な基盤、基本クラス、およびその他基礎レベルのコードを指す。

　目に見える機能を実装する前にインフラストラクチャを完全に開発することは、理にかなっているように思えるが、実際には、プログラムが動作することを実際に見て確かめる前にあまりにも多くの時間が必要となる。これではマネジャーや顧客、開発者などが不安になってしまう。インフラストラクチャの開発が、理論的に完全なフレームワークを作成するための研究活動になってしまい、結果的に多くの不要な機能を作成してしまうことが多い［注14-2］。したがって、プロジェクトチームが実装するインフラストラクチャは、現在のステージで実現する予定の機能をサポートするために必要な部分だけにとどめるべきである。このような方法をとれば、インフラストラクチャ開発が研究活動になってしまうことを防止でき、インフラストラクチャの問題点は、理論だけに基づいて開発している場合に比べてすばやく発見することができる。

注14-2 この問題の解決には「要求のトレーサビリティ表」が有効である。システムの各部分が必ず要求のどれかを満たすものでなければならないとすれば、開発者が不必要な機能をプログラムに組み込むことはできないだろう。仮に組み込んでしまったとしても、設計レビューで発見できるはずである。設計レビューで不必要な機能を発見した場合は、構築作業に進む前に削除しなければならない。

　

INDEX
	新訳 ソフトウェアプロジェクトサバイバルガイド
	1. 第14章 構築（1）
	2. 第14章 構築（2）
	3. 第14章 構築（3）

　

「BOOK Preview」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）