納期を守りながら高品質を実現するためにはどうすればいいのか。近道は存在しない。結局，要件定義フェーズや設計フェーズなどの上流工程から，綿密な品質点検と欠陥除去を行うことが欠かせない。そこでプロジェクト計画において，詳細な品質管理計画を立案する必要がある。

布川　薫／日本IBM

　企業情報システムの大規模化や複雑化に伴い，ソフトウエア品質の重要性はますます高まっている。とりわけ銀行のオンライン・システムなど公共性の高いシステムでは，品質向上は至上命題だ。

　では，そのためにプロジェクトマネジメントにおいて何を行うべきか。世の中には欠陥を未然に防いでくれる魔法のツールも，エラーを排除できる画期的な設計手法も存在しない。慎重かつ地道な，品質向上活動があるのみである。

　すなわちプロジェクトのスケジュール遅延とコスト超過を防止し，しかも高い品質を確保するには，自主検査やレビュー，テストなどの「欠陥除去工程（Defect Removal Processes）」，いわゆるバグつぶしを必要なときに適切に実施しなければならない。そのためにはプロジェクトの計画段階で，欠陥除去工程のスケジュールや方法，目的などをまとめた「品質管理計画」を策定しておく必要がある。

　今回はこの品質管理計画の考え方と，欠陥除去工程の具体的な手順について解説しよう。特にプロジェクトで非常に重要な開発工程において，「どのように品質を作り込んでいくか」を明らかにしていきたい。

品質は設計段階で作り込む

　システム開発における欠陥除去をテストだけに頼っていると，品質管理のコストは非常に高くついてしまう。多くの欠陥は，要件定義フェーズや設計フェーズといった上流工程で発生しており，その発見時期がテストなどの下流工程にずれ込めばずれ込むほど，修正に時間がかかるからである。

　事実，大規模なシステム開発における欠陥の45～80％は，要件定義や設計段階における問題に起因することが，全世界のIBMの経験から分かっている。テストによる欠陥除去はもちろん必須だが，プロジェクト全体から見れば重要度は低い。

　にもかかわらず，現実のプロジェクトではスケジュールの消化を急ぐあまりに，未決定事項を残したままコードを書き進めてしまうようなケースが多数見受けられる。しっかりと計画されたプロトタイピングのような場合はそれでいいが，そうでない場合，いきなりプログラミングやテストに入ってしまうのは，全くいただけない。開発に手戻りが発生し，結局はコスト超過やスケジュール遅延につながる。

　特に大規模プロジェクトになると，上流工程における欠陥を下流工程で除去するための作業に要するコストの方が，本来のプログラミングやテストにかかるコストよりも大きくなることが多い（図1）。ITエンジニアはこのことを，しっかり認識すべきだ。「品質は設計段階で作り込むもの」なのである。

図1●7000人月規模の実際のシステム開発での手戻りコスト
図1●7000人月規模の実際のシステム開発での手戻りコスト
この例では，開発コストの半分近くを欠陥除去コストが占めている。10年以上前の事例だが，現在もこの状況が改善されていないケースがある
[画像のクリックで拡大表示]

　例えば要件定義フェーズでは，未決定事項や要件間の矛盾，DFD（Data Flow Diagram）におけるデータの流れの不整合などを，しっかり検査しておく。あるいは外部設計フェーズでは，データベースのデッドロック対策が十分に考慮されているかどうかを検討しなくてはならない。要件定義フェーズや設計フェーズで未決定事項を残したまま，開発フェーズに入るのは致命的だ。このように設計フェーズなどの上流工程でなるべく欠陥を除去するのが欠陥除去の大原則である。

　しかし実はもう1つ重要なことがある。それはフェーズ完了時のレビューに頼らず，フェーズの立ち上がり時期やフェーズの途中で，品質に関する検査・点検をなるべく頻繁に行うことだ。あるフェーズの成果物が完成してからレビューを実施して欠陥を発見すると，その修正のための手戻りが発生する。

　これを避けるためには，成果物がある程度完成したら，そのたびに自主的に検査・点検を実施することが重要になる。それぞれのフェーズ内でも，早め早めに検査・点検を実施することが大切なのである。

　こう書くと「納期が決まっており，人員が限られている昨今のプロジェクトでは現実的でない」，「それができれば苦労はない」といった意見が出てくる場合が多い。ITエンジニアの1人として筆者は，そう言いたい気持ちは十分に理解できる。

　しかし現状に不満を言うだけで問題がなくなるなら，それこそ誰も苦労はしない。レビューを通じた品質向上はITエンジニアの責務であり，それを実現するためにあらゆる努力を払う必要があることも確かだ。それを果たして初めてユーザー企業から信頼されることを肝に銘じるべきである。

ウォークスルーで自発的に検査

　それではシステム開発における欠陥除去工程の手順を説明しよう。次ページの図2は，ウォーターフォール型開発工程での日本IBMの標準的な欠陥除去工程を示している。

図2●ウォーターフォール型開発における欠陥除去工程
図2●ウォーターフォール型開発における欠陥除去工程 [画像のクリックで拡大表示]

　図を見れば分かるように，要件定義フェーズや設計フェーズといったフェーズごとに，「ウォークスルー（Walkthrough）」や「インスペクション（Inspection）」，「公式レビュー」が組み込まれている。

　ウォークスルーとは，プロジェクト・メンバーが自主的に集まって机上シミュレーションの形で欠陥を発見していく作業のことだ。主に開発の上流工程で実施する。

　DFDやデータの正規化の結果，E-R（Entity-Relationship）図，データ・ディクショナリ，外部入出力仕様，データベース仕様，処理機能記述，モジュール構造，各種作業手順書などが，ウォークスルーにおける点検の対象となる。このウォークスルーを，フェーズの途中で頻繁に行うことで，成果物の品質を大幅に引き上げることができる。