連載の目次へ

統計的なバグ件数を把握

 ではどうすればこうしたバグを未然に防げるか。正論としては,やはり上流工程でしっかりレビューをやるということになるだろう。設計時点でレビューを行い,テストのときに欠陥が見つかることがないようにする(図4)。


レビューで欠陥を除去する方が効果的
図4 レビューで欠陥を除去する方が効果的
基本的には欠陥は,レビューなど上流工程で検出し除去した方が効果的である。しかし,そうは分かってはいても,実際には現場では時間に迫られてレビューや単体テストを省略して次の工程に進んでしまうということがある。

 とはいえ,現実はそうもいかない。前述したが,携帯電話事業者も厳しい競争にさらされている。仕様はギリギリまで決まらない場合もある。これは何も日本だけの事情ではなく,世界中どこでも同じである。

この記事は,「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。詳細はこちら

 結局,仕様の揺れに対しては,現場が対応する必要があるのだが,現場としてはこれを待ってしまうことが多い。仕様が来たら,とりあえずレビューが甘くなる。いきなりコーディングに入ってしまう。携帯電話機はさまざまなアプリケーションから構成されるが,ある新規のアプリケーションだけが進捗が遅れていて,他のアプリケーションはもうテストの準備が整っているという局面がある。これはすごいプレッシャーになる。「早くしろ。お前のところが出来上がっていないから,統合テストができないじゃないか」と。すると,何が起きるか。「まあいいや。単体テストしてないが,つないでしまえ」となり,手戻りの爆発が起きるのだ。こういうことは,現場にはやらせてはいけない。上の人間がキッチリ見て,止める必要がある。

 さらにひどい例になると,まだ品質が安定していないのに,出荷時期が近づいてきたのでシステム・テストを始めてしまおうというのがある。これはやってはいけないことだが,開発現場と全体を見る人間とが同じ心構えでいないと,発生してしまう。私も,実際これで痛い目にあっている。

 こうした経験から,我々も統計的な品質管理手法を取り入れている。バグの品質予測曲線を用いて開発全体の状況を把握している。過去の経験を基に,バグの発生件数を予測し,それをどのくらいの期間で修正すべきかについても計画しておく。そこに実際の発生件数と修正を終えた処置件数を重ねてプロットしていく(図5(上))。この計画値と実績値が重なっていると,そのプロジェクトはかなり優秀ということになる。

 バグ曲線が予測と重なっていれば,収束しそうな頃合いも読める。この期間に,経験的に何カ月で最終のシステム・テスト工程が終わるのかが見える。数百万行を超えるソフトウエアなので,バグ曲線がそれほどギザギザになることはないが,それでも予測値と実績値が必ず重なるわけではない。例えば,バグ曲線が計画通りに収束しない場合がある。計画値ではそろそろ収束するころなのに,ずっとそれを超えて伸び続けてしまう場合がある(図5(下))。この要因は,非常に質の悪いモジュールがあることが一番多い。こういうものはすぐに手を打たないといけない。


バグ件数の品質予測曲線
図5 バグ件数の品質予測曲線
水色の線は,バグがどのくらい出るかという経験値から予測した計画値,黄色は実際にバグがどのくらい発生したかの実績値である。また紫色はバグが発生してからどのくらいの期間で修正すべきかという理論値,緑色は実際に修正が終わった処置済みのバグの件数である。優秀な場合は計画値と実績値が重なるが(上),実際のバグ件数が予測値より多いと計画通り収束しない(下)。

 もう1つ,よくある計画とのズレは,計画値よりも極端に急激に実績値が立ち上がる場合である。我々は今,計画値よりも極端に立ち上がりが急激な場合は,工程をいったん,前に戻すことにしている。そもそも単体テストがうまくいっていないからこうしたことが起きるわけで,システム・テストなど無駄なのでやめてしまえ,というわけだ。

 テストが佳境に入ってきたときに,次に何が起きるか。バグは検出されるものの,なかなか処置が終わらないという事態である。これにはリソース的な要因と技術的な要因の2つがある。リソース的な要因としては,そもそも人が足りないという状況。これは実際に,トップが開発現場に行って聞いてみないとつかめない。現場は必死なので「何とかしろ」と言うと「やります」といって徹夜してしまう。技術的な要因としては,新規モジュールやどこか根本的なソフトウエア,例えば,ミドルウエアの大物を入れ替えたときに,ずれることが多い。こうした統計は巨大なソフトウエアの場合,非常に有効で,我々も機種ごとに全部,こうした統計を取っている。(つづく