上流工程のバグは、下流工程で増幅するプロジェクトはなぜ失敗するのか(13)

皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。

» 2008年12月15日 00時00分 公開
[落合和雄@IT]

上流工程ほどいいかげんな品質管理

 ソフトウェア開発でよくいわれることに、「上流工程のバグは、下流工程で増幅する」がある。要件定義や基本設計で間違いがあった場合、最終テストの段階でその間違いに気付き、プログラムを修正すると、相当大きな工数がかかってしまうということだ。この工数は、詳細設計よりも基本設計、基本設計よりも要件定義と、(バグの発生が)上流工程になればなるほど大きくなる。

 従って、理屈上は上流工程ほど品質チェックを厳重に行わなければならないはずだ。しかし、実態を見ると、上流工程になればなるほどチェックがいいかげんであることが非常に多い。

上流工程で確立していない品質基準

 この最大の原因は、上流工程における品質の測定方法が確立していない点にある。プログラミングが終わった後のデバッグやテストにおける品質の測定方法は、だいぶ定着してきている。一定のコーディング量に対してどのくらいのバグが見つかったかを測るバグの発生率や、テスト項目の設定度合いを見るテストカバレッジなどの指標が普及してきており、これらの基準を使って一定の品質を確保しようとする企業が増えてきている。

 これに対して、要件定義や設計に関する品質の測定方法は、あまり普及していない。これらの上流工程におけるチェックは、通常、レビューという形で行われるが、このレビューの品質管理基準が明確になっていない場合が多い。たいていの場合、「しっかりレビューしなくてはいけない」などの精神論で終わっている。このため、実際のレビューは、いろいろな理由でいいかげんになることが多い。代表的なものは、以下のようなものである。

  1. 自分の作業で手いっぱいで、他人の設計のレビューをしている時間がない
  2. 自分の担当外のところは、内容がよく分からない
  3. 基準がないので、どこまでチェックすればよいか分からない

 この状況を放置していては、上流工程の品質を一定に保つことができない。やはり、上流工程においても、しっかりとした品質管理基準を導入する必要がある。

品質管理基準の候補

 それでは、上流工程における品質管理基準として、どのような指標が考えられるだろうか。代表的な品質管理基準に、次のようなものがある。

(1)一定ページ当たりのレビュー時間
(2)一定ページ当たりのレビュー指摘件数
(3)仕様書の量

 (1)は、作成した仕様書などのページ数に応じて、一定量のレビュー時間を取る方法である。ただしこの方法では、真剣にレビューを行ったかを判断できない恐れがある。レビュー時間のほとんどを雑談に費やし、“時間だけ使った”という事態がないわけではない。

 (2)は、作成した仕様書などのページ数に応じて、一定の指摘件数が出るまでレビューをする方法である。この方法のデメリットは、設計品質が本当に良く、指摘件数が少ない場合に、余計な時間を使ってしまうことだ。逆に、品質が悪い場合は、一定の指摘件数が出た時点で、チェックをやめてしまい、まだある間違いを発見できない恐れがある。

 (3)は、仕様書の記述量を一定以上にすることで、品質を確保する方法である。これも一定の品質を確保するための1つの指標にはなるが、設計の記述の量と品質が必ずしも比例しないため、この指標だけでチェックを行うのは危険である。

 以上3つの指標はどれも単独では欠点があるが、これら3つを組み合わせることで、ある程度品質を確保することができる。もちろん、各レビュアーが高い意識でレビューすることも重要だが、その一方で、こうした客観的な指標も使用し、品質を高める工夫をすることが上流工程の品質確保のために重要である。

上流工程の品質確保から始まる品質改善

 とかく品質の確保は、最終テストをしっかりやればよいと考えられがちだ。だが、ここで上流工程のエラーが見つかったときの修復コストを考えると、結局は上流工程でレビューをきちんと行っておいた方が全体のコストは下がるといわれている。また、後から上流工程のエラーが見つかると、無理な手直しを行うことが多く、プログラム全体の品質低下につながる場合も多い。これらを考慮すると上流工程の品質確保にはもっと力を注ぐべきであり、そのための重要な手法が、上流工程の品質管理基準の設定である。

著者プロフィール

落合和雄

1953年生まれ。1977年東京大学卒業後、新日鉄情報通信システム(現新日鉄ソリューションズ)などを経て、現在経営コンサルタント、システムコンサルタント、税理士として活動中。経営計画立案、企業再建などの経営指導、プロジェクトマネジメント、システム監査などのIT関係を中心に、コンサルティング・講演・執筆など、幅広い活動を展開している。主な著書に、『ITエンジニアのための【法律】がわかる本』(翔泳社)、『実践ナビゲーション経営』(同友館)、『情報処理教科書システム監査技術者』(翔泳社)などがある。そのほか、PMI公式認定のネットラーニングのeラーニング講座「ITプロジェクト・マネジメント」「PMBOK第3版要説」の執筆・監修も手掛けている。



Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。