■プロジェクトマネジメントの応用 １２（ソフトウェア開発編）
◆バグ管理を徹底する
①バグはなぜ発生するのか？
ソフトウェア開発はバグを如何に収束させ安定な品質確保ができるかに掛かっている。つまり，ソフトウェア開発にバグは付きもので，完全なものを目指しても，人間の能力の限界を超えており，バグの無い完全な設計に時間を掛けすぎてトータル的な工数をオーバーするようではプロジェクトとして拙い。むしろ，設計した成果物に内在するバグをレビューやテストで上手く抽出する方がトータル品質・コスト共に優れることが多い。
バグはいろいろな要因で発生する。元々の顧客の要求仕様や企画仕様そのものが，設計を容易にした仕様になっているかと云えばそうではなく，顧客の使い勝手や使い方を中心に仕様化されているので，それらを設計仕様に変換，或いは機能分解するなど設計するレベルのドキュメントに仕上げる。ここでの変換が完全かと云えば必ずしもそうではなく，顧客要求の変換の間違い，或いは要求仕様の曖昧さが誤解を生み，設計仕様に変換されるリスクなどがある。
さらには，定められた機能仕様を基に詳細仕様へ落とし込む作業でも，理解不足からの仕様漏れ，変換ミス，或いは記述不十分など多くの人の手を経る作業に潜む欠陥が組み込まれてしまうリスクがある。詳細仕様からは仕様の詳細レベルにも依るが，プログラミング作業で，ここでも単純なミスはついて廻る。つまり，全体システムからプログラミング作業の到るところで欠陥が組み込まれるのである。
誰も欠陥を組み込もうとなど考えていない。完璧な設計を目指しているのだが，人間の能力，或いは多くの人の手を経ることによる欠陥はある程度発生するのは仕方がないことなのである。もちろん，メンバーのスキルの差に依ってバグの発生比率は大きく変わる。特に，オフショア開発などの場合，国内とちがって言葉の壁もあり，且つスキルもあまり高くないことからバグの発生率が上がることは間々あることである。
②バグ発生予測と実績を管理する
バグを管理するということの先ず第一は，バグの発生予測をすることである。つまり，開発プロセスのどこの工程でどれだけバグを摘出するかと云う予測をする。
未熟なプロセスである場合には，テスト工程でのバグ発生を予測するのであるが，最初はどのように予測するかも判らない。手始めは，以前のプロジェクトでバグがどれだけ出たか実績値を調べてみることである。このとき，以前のプロジェクトでは，単体テスト，結合テストなどが確実に行われていないことも多い。そうした場合には，システムテストで出たバグ率から，その２０％を単体テストで，３０％を結合テストで摘出するように計画してみる，などと，新しくプロセスを追加する効果を予測して計画に盛り込むことである。もちろん，感覚的割合なので必ずしも計画通りには行かないことが多いが，この実績値が次のプロジェクトの計画段階では活かされることになる。
習熟したプロセスがある場合には，同じようなプロジェクトでの開発プロセスの工程毎のバグ摘出率が予め判っているので，それらの比率に対して，どのような改善を加えるのでその効果を各工程へ反映して計画することになる。この計画した値に対して実績値を測定して比較する。実績値は計画通りになれば良いのだが，通常は差分が発生する。この差分がどうして生じたかを分析して，次のプロジェクトに活かす。こうして繰り返されることで，計画の精度が上がり，プロジェクトが計画通りに進むことができるようになる。
③バグの重要度を管理する
バグはその内容によって，重要度が違ってくる。影響度が大きく致命的な欠陥と，些細な欠陥とでは同じ１件のバグでもその重みが違うので，バグの重要度を付けて管理するのが実用的である。つまり，市場でも重要なバグと，重要で無いバグ（発生比率が殆ど無く，影響も小さいもの）では，顧客に対する影響度合いも違う。つまり，重要なバグを１件も出さないことが求められる。
そこで，システム評価又はその前の事前評価段階以降では，システムへの影響が明らかになるので，重要度が判ってくるので，バグの重み付けをした管理をするのが良い。例えば，発生度合いとその影響度合いから次のように決めるのも一つの方法である。
Ａランク：市場・顧客の通常の使い方で致命的なダメージを与える欠陥
Ｂランク：市場・顧客の通常の使い方では発生しないが，影響範囲が大きくダメージを与える欠陥
又は，市場・顧客の通常の使い方で発生するが，軽微な欠陥
Ｃランク：市場・顧客での通常の使い方では発生せず，軽微な欠陥
④バグはできるだけ早い段階で見つける
バグは設計の早い段階で見つけることが鉄則である。なぜなら，設計段階で組み込まれた欠陥は後工程までそのまま引きずってしまう。設計段階では些細な欠陥であっても後工程になればなるほど影響範囲が大きくなるリスクがある。また，欠陥の発見も後工程になるほど原因究明が難しくなる可能性も高い。
バグは発見すれば，必ずその対策が必要となり，その対策工数は少なければ少ないほど良いのは言うまでもない。実際，対策をしてみると判るが，システムが大きくなった段階でのバグは，その原因がどこにあるかを見極めるのが，なかなかたいへんである。そのミスが単純なコーディングミスであっても，そこに辿り着くまでに結構時間を要する。また，逆に原因は判っても，その対策することによる影響範囲が大きく，正しく修正することに時間を要し，また確実に修正できたかの検証にも時間を要するものもある。
つまり，大きな規模になってからのバグ対策は，単体テストや結合テスト段階での対策工数と比較して大きなものになる。過去の調査資料では，市場問題での対策工数は単体テストの工数の４０～１００倍であるとの報告もされている。
⑤バグの収束状況を把握する
バグが残っている状態で市場に出すことは，顧客に迷惑を掛けるだけでなく，その対策にも時間と費用が掛かるので，市場クレームになるようなバグ（上述のＡランクのバグ）は極力取り除かなければならない。そのためには，バグの除去がどこまで行ったかを示す信頼度成長曲線（バグの除去率を示す）を描くツールなどが準備されており，それらを利用して品質の安定度合いを確認することは必要なことである。
開発工程が安定し，習熟したものになると，計画時点でバグ収束予測曲線を描き，それに対して実績のバグ検出曲線がどのように描かれるかをトレースして，市場へ出荷してよいかどうかを判断するデータに使われることも行われている。
[Reported by H.Nishimura 2011.09.02]
Copyright (C)2011 Hitoshi Nishimura
