テストという破壊的な作業の建設的なやり方：ソフトウェアテスト・エンジニアの本音（4）（2/3 ページ）

[大西建児，株式会社豆蔵]

組み込みソフトウェアとテスト（1）

松岡　そろそろ、Rexさんのコンサルのノウハウに絡んだ質問をさせてください。製造業のソフトウェア、いわゆる組み込みソフトウェアは、ここ1〜2年の間でも開発規模、体制ともにどんどん大きくなっています。数十キロ（ステップ）だった開発対象が数十メガになり、数名の体制が主流だったものが、数十〜数千名体制にまで膨れ上がっています。このように、わずかな期間でサイズが大きくなる環境において、品質を安定させるようにするには、どのようにすればよいのでしょうか？

Black　システムの規模というのは課題でしょうね。組み込みソフトウェアのアセスメントを実施したこともありますが、ある組織ではバグの数が2000〜2500ありました。コードベースのサイズから見るとバグの数は少ないと思われる方がいるかもしれませんが、テストマネージャの視点で見ると、バグの数よりも、その質に重きを置いてとらえることが重要になってきます。

松岡　もともとハードウェアの設計をやっていた人がソフトウェアの設計をすることがあります。ボードやチップの開発に従事するハードウェアのエンジニアがドライバやミドルウェアの開発に従事しなければならないケースが少なくなくありません。この場合、開発したコードの規模や複雑度、言語、例えばアセンブラに始まり、CやC++、Javaといったものに対するスキル不足に根差した問題によるリスクが、常に内在してしまいます。

　すると上流レベルの品質が悪くなり、単体レベルのテストの品質も悪くなるでしょう。品質を保証するのがいわゆる下流のテストフェイズではなく、品質保証レベルで何とかしろといわれるわけです。こういった状況において、どんなマネジメントをすれば効果的なのでしょうか？

Black　ハードウェアのエンジニアだった人がソフトウェアのエンジニアになると驚かされることがあります。どういうことかというと、ハードウェアのエンジニアだったときには、ちゃんとしたエンジニアリング手法にのっとったやり方を守っていたのに、ソフトウェアを作らせると、途端にいいかげんなやり方をするようになることがあるからです。

　ソフトウェア・エンジニアリング的なディシプリン［*3］を適用しなくなるのです。残念ながら、これに対するソリューションはありません。ハードウェアのエンジニアがソフトウェアを作り始めたときに、事故が起きてしまったことも考えたうえでもっとちゃんと設計しなさいといったことならあります。しかし事故が起きる前に分からせる方法というのは思い付きません。1回は痛い目に遭わないと分からないのが現実なのかもしれません。

---

［*3］　ディシプリン：規律や統制と訳される。プロフェッショナルとして職業に従事するためのルールや仕組みを意味する

---

組み込みソフトウェアとテスト（2）

秋山　松岡さんと同じく、私も組み込み分野にてソフトウェア開発を行っているのですが品質を確認するためにメトリクスをいくつか適用していますので、これについてお聞きかせください。これまでは1000行当たりのバグ数というメトリクスを取っていました。しかし、開発する規模が倍々になっていく中でこのメトリクスがうまく機能しなくなってきています。これに変わる組み込み系のメトリクスがあれば何か教えてください。

Black　何の目的でメトリクスを取るのでしょうか？ テストの十分性を見るためですか、それとも開発プロセスの方ですか。

秋山　開発工程を評価するためのメトリクスです。設計やプログラミングの改善が進んでいるかどうかのために測りたいと考えています。

Black　プロジェクトの改善活動のためですね。

秋山　そうです。行当たりの欠陥の密度は下がってきているのですが、その改善の速度以上に、1機種に搭載されるソフトウェアの規模が増加しているため、1機種当たりのバグ数で見ると改善がなかなか進んでいないようにみえてしまいます。ですから、お客さまにとっての満足度と1000行当たりのバグ数というメトリクスがリンクしなくなってしまったため、これに代わる適切なメトリクスを模索しています。

Black　私にとってもお客さま満足度は最終的な尺度になります。何メガステップのソフトウェアになったというのは、お客さまにとっては全く興味のない話です。われわれが何をやっても、お客さま満足度が上がっていなければ、結果として測っても意味などありません。99.8％までバグが除去されている製品の中に潜んでいるバグ数の絶対数をさらに減らすために、テストという手法だけで対応していると、いまのお話のように改善も頭打ちになってくるでしょう。ですから、もっと開発の上流フェイズで欠陥を除去するというアプローチを取らなくてはならないのです。つまり、テストの開始前にはすでにバグが少ないという状況を生み出す必要があるのです。

　最近、テストプロセスを評価してほしいという依頼がありました。評価してみたところプロセスはきちんとできていそうでした。欠陥防止策も取っていました。それにもかかわらず、システムテストでは何千個ものバグが発見されていたのです。さらに悪いことに終盤でバグを見つけ出すやり方を取っていたため、テストで2000のバグを発見できましたが、400ものバグを残したまま市場に製品が出荷されてしまいました。

　私はクライアントに対してこのようにいいました。「テストプロセス自体がひどいということはありません。問題はバグの修正を遅らせ過ぎていることです」。実はこのクライアント先のマネージャは、「テストチームが過剰にテストをやっているからバグが出るんだ」というようにテスター側を責めていたのです。このマネージャが正しければ、お客さま満足度は85〜90％になってもおかしくはないでしょう。

　現実はそうなってはおらず、お客さま満足度は75％という数字でした。この数字からいえることは、テスターが過剰にテストをしているということを数字で裏付けることはできなかったということです。バグの改修を後回しにし過ぎていることこそが、問題の根本原因だったのです。この事実を説明したところ、そのクライアントは次のようにいいました。「バグ改修のために出荷時期を遅らせるなど、できる道理がありません。

　ただでさえ出荷時期が遅いとお客さまからおしかりを受けているからです。出荷日はデッドラインですから、デッドラインは死守すべきでしょう」。これに対して私は「デッドラインを守って出荷するために、テストに時間をかけられないのであれば、2点やるべきことがある」と答えました。

　1つ目は「テスターによい質のものをリリースすること」ということです。レビューや単体テストをしっかりと行い、品質の高いものをテスターに引き渡すべきだからです。

　2つ目は「最後のフィーチャー（機能群）が完全に完成されるまでテスターが待つのではなく、前倒しでテストを行うこと」を推奨しました。テストの前半は機能レベルのテストであるため、それほどバグは出ません。すべての機能を組み合わせてテストすることから、開発フェイズの最後になって大量のバグが出てしまうからです。ただ待つのではなく、むしろテストを前倒しすることで品質を確保すべきですから、このように説明したわけです。