DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

システム開発の仕事をしていると、「仕様変更多発がプロジェクトの失敗を招いた！」なんて話を良く耳にします。この表現を使った場合、暗に「プロジェクト失敗の原因は、仕様を決める側にあり、システムを開発する側の責任ではない」というニュアンスが感じられます。

しかし、前回示したように「仕様変更のほとんどは設計不良である」ことが事実だとしたら、「設計品質の悪さがプロジェクトの失敗を招いた！」ということになります。。。

「品質」―――これまで、どれだけこの言葉に振り回されてきたことか！
今回は、この「品質」というものを、あらためて見つめなおしたいと思います。

【　カラオケ★バトルと品質？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
先日のゴールデンウイーク期間中に、久々にカラオケボックスに行く機会がありました。最近のカラオケは採点機能が充実しており、歌に自信のある人も無い人も、採点結果を見て一喜一憂して盛り上がります。この採点結果は、たまに歌自慢の人よりも、歌に自信が無い人の点数が高かったりするので、その意外性も楽しみのひとつです。

まあアマチュア同志がカラオケボックスでアルコールも入りながら楽しむ分には気楽なものです。プロの歌手たちがカラオケの採点を本気で競う、しかも、歌手本人の持ち歌で競うテレビ番組をたまに見かけます。さらに、ヴァイオリンやピアノなどの楽器の演奏による採点対決などもあり、なんとプロのクラシック奏者なども参加して、高度な演奏テクニックを披露しながらも、意外な採点結果が出たりして、実に面白いですよね。（※１）

音楽の即興性を重視したクラシック指揮者であるフルトヴェングラー好きの私としては、楽譜通りに正確に演奏することよりも、何か心に訴えかけるものがある演奏の方が好きであり、カラオケ★バトルで本人の採点が悪くてもまったく気になりません。むしろ、本当の意味での歌の良し悪しは、カラオケの採点システムなんかでは評価できるわけないと思っています。カラオケ★バトルに本人が登場することが当たり前になった今の世の中は、音楽の即興性が常識になったと解釈できるので、良い傾向だと感じています。（※２）

さて、だいぶ話が脱線したようですが、実はシステム開発における品質評価についても、カラオケ★バトルと同じことが言えると私は考えています。昨今では、システムの品質を定量的に評価することが当たり前になってきています。開発したシステムのテストを行った際のテストケース数やバグ摘出数がどれくらいかを目標値と比較して、品質の良し悪しを評価するのは、当たり前のことになってきました。

しかし、現実のプロジェクトにおいては、テストケース数やバグ摘出数が目標通りであっても、ユーザーテストで障害が多発したり、本番稼働後にシステムトラブルが発生するケースはいくらでも目にします。

つまり「カラオケの採点システムで高得点を得た歌が万人の心に響く歌であるとは限らない」のと同様に、「定量的な品質目標を達成したシステムが真に品質の良いシステムであるとは限らない」というのが私の長年の経験を通じて得られた答えです。

「定量的な品質目標を達成したシステムが、真に品質の良いシステムであるとは限らない！」

【　テストケース数とバグ摘出数による品質評価の考え方　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
そもそもテストケース数やバグの摘出数による品質評価とはどんなものでしょうか？

良くあるのは、単体テスト、結合テスト、システムテストのそれぞれの工程で、設定すべきテストケース数や摘出すべきバグ件数について目標値を設定し、その目標値と実績値を比較することで、品質を評価する方法です。

もちろん、開発するシステムによって、開発規模が違うので、ある一定の開発規模（たとえば、開発したプログラムのステップ数やＦＰ値）あたりの件数に割り戻して評価することになります。このある一定の開発規模で割り戻したテストケース数とバグ摘出数をテストケース密度、バグ密度などと呼びます。（※３）

図１では、機能別にテストケース密度とバグ密度を算出し、目標値と比較して評価しています。Ｂ機能やＣ機能のように、目標値との差異が出れば、それぞれなぜその差異が発生したかを調査することで、品質の弱点を発見し、弱点に対する対応を行うことで、より品質を高めることにつなげることができます。

しかし、Ａ機能のように目標値を達成していた場合は、この評価だけでは弱点を発見するヒントにはならないため、摘出されているバグの内容など、別角度の分析も必要になってきます。というか、Ｂ機能やＣ機能の場合も、本当にその差異の原因が品質の弱点なのかどうかはこの情報からだけでは判断できないので、別角度の分析も合わせて行う必要があります。

そもそもこの目標値というものは、たいていの場合、システム開発を行う組織の中で、過去のシステム開発プロジェクトではこれぐらいのテストケースを作成、バグを摘出してきたという統計情報をもとに設定されていることが多いと思います。つまり、過去のシステム開発ではだいたいこれぐらいのテストケース数を設定し、これぐらいのバグを摘出してきたので、今回のシステム開発においても同じぐらいの数値であれば、これまでと同じくらいの品質である可能性が高くなるという論理に基づいていることになります。（※４）

じゃあ、その過去のシステム開発がどれくらいの品質だったのか？過去の開発と比べて、今回の開発アプローチや開発体制はどうだったのか？などなど、プロジェクトの独自性に応じて、品質目標値と実績値の差異の原因が何によるのか、よくよく考えてみないと、そんなに単純に比較評価できるようなものではないことを認識する必要があるのです！

【　定量的品質評価の落とし穴　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
実は私が初めてこのテストケース密度やバグ密度による品質評価という考え方に触れたとき、ものすごく違和感を感じたものでした。それはかれこれ二十年以上前の、まだ大学を卒業して間もない社会人２年目ぐらいのプログラマーだったころだと思います。

それまでは、自分が作ったプログラムをテストしたり、レビューしてもらったりして、どんなバグが出ているから品質はこうだろうと定性的に考えるのが品質評価だと思いこんでいました。ところが、プロジェクト全体の品質評価結果の報告資料を見たときに、プログラムごとのテストケース密度とバグ密度の羅列の表が出てきて、なんでこんな数字で品質なんてデリケートなことが語れるんだろうと不思議に思ったものです。

それでも、テストケース密度とバグ密度による評価を行わないと、お客様に受け入れられない時代になってからは、この評価方法をもとにした品質レポートを二十年以上作り続けて、現在に至っております。そして、この定量評価を行うにあたって、つねづね頭の端にひっかかっていることがあります。もう、今では直接プログラムを作ることも無いだろうし、時効だと思うので思い切って告白します。。。

それは、自分が作るプログラムは、どうしてもバグ摘出の品質目標値に達しないという悩みでした。システムテストは自分の作ったプログラムだけの評価ではないのでまあ良いのですが、単体テスト、結合テストぐらいは、ほとんどバグらしいバグが無く、いつも「バグ摘出は少ないが品質に問題は無い」というレポートばかり書いていたのです。

当時はだいたい一本のプログラム全体をコーディングして、コンパイルエラーが無くなってから単体テストをスタート、バグ摘出数もそこからカウントするルールにしていたと思います。ところがコンパイルエラーを無くす段階までに、たいていのバグは発見して改修できていたので、単体テスト以降はほとんどバグが無い状態でした。

なので、最終的な品質レポートのことを考えて、単体テスト以降に少しはバグが残るように、あえてコーディング時点では雑に作ったりしたこともあります。さすがに意図的にバグを埋め込むことまではしませんでしたが、今考えるとそれに等しいナンセンスな行為だったと反省する限りです。そして、必ずテストケース密度は目標値を意識して、目標値を大幅に上回るようにテストケースを作成することにしていました。そうすれば、品質評価レポートには、いつでも「バグ摘出が少ないが十分なテストケースを設定して十分なテストを行っているため、品質に問題は無い」と書いておけばすむからです。

かくして、多少プログラミングが得意で、ずるがしこい担当者は、最初から品質目標値を狙ったさじ加減が出来てしまうので、ますますテストケース密度とバグ密度による品質評価の意義が信用できないものとなってしまいます。

これだけテストケース密度やバグ密度による定量的な品質評価の考え方が広まってしまうと、かつての自分がそうであったように、目標値を狙った実績値の操作が行われる可能性も高くなり、最終的な数字の評価だけでは、その辺の事実関係までとうてい把握することはできません。

そうした意味でも、テストケース密度とバグ密度による品質評価だけでは、真に品質の良いシステムかどうかの評価ができるはずもなく、もっと多面的な品質評価を行う必要があるという結論に達してしまうのです。。。

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　カラオケ★バトルについては、以下参照。
・「カラオケ★バトル」『フリー百科事典　ウィキペディア日本語版』
2015年5月19日 (火) 15:11 utc http://ja.wikipedia.org/wiki/カラオケ★バトル
・「THEカラオケ★バトル」『フリー百科事典　ウィキペディア日本語版』
2015年5月23日 (土) 13:26 utc http://ja.wikipedia.org/wiki/THEカラオケ★バトル

※２　フルトヴェンングラーに関しては、当ブログの以下の回も参照してください。
・【第６回】クラシックコンサート・プロジェクト
・【第７回】フルトヴェングラーのプロジェクトマネジメント

※３　独立行政法人 情報処理推進機構ソフトウェア・エンジニアリング・センター編(2006)「SEC BOOKSソフトウェア開発見積りガイドブック～IT ユーザとベンダにおける定量的見積りの実現～」より

ファンクションポイント法（以 下，FP法 と 略 す）と は，１９７９年 に Allan J.Albrechtが提唱したソフトウェア規模の計測手法です。FP法は，開発基盤に影響されないソフトウェア規模計測尺度を目指して開発され，データの入出力など，ユーザに見える機能に着目し，機能数とその重みにより，ソフトウェア規模を定量化します。

※４　組織としての定量的な品質目標値は、プロジェクト実績データの収集結果に基づいて設定されます。当ブログの以下の回も参照してください。
・【第４５回】ありのままのプロジェクト実績データ収集