調査データからは見えないもの

と、ここまで書いて筆者は、「本当にこんなに不具合を抑え込めているのだろうか?」と考えました。いろいろな所で筆者が見聞きする現場の状況を踏まえると、どうしても違和感を感じざるを得ないからです。

調査結果が示しているデータはあくまで「表面上、明らかとなった不具合数」にとどまっているように筆者には思われました。

例えば、開発側が「保守」という形で、一見すると不具合とはわからないように対応することは多々あるはずです。また、ユーザー側からすれば不具合だと思われるような場合でも、発注時や要求定義時に曖昧に開発側へ依頼した場合は発注側の問題となり、受注側の立場からすると不具合として扱えないことも少なくはないはずです。

このようなケースはおそらく、公式な調査データに載らないであろうことを考慮に入れれば、実感とは少々かけ離れているように感じたとしても不思議はない、と筆者自身は納得した訳です。あくまで公式見解としての不具合の数は少なく見える-そういうことなんだろうと個人的には結論づけました(単なる天の邪鬼だからかもしれませんが)。

果たして実際の現場では?

となると、「本当に不具合の数を含めて品質を満たすことができているシステム開発はどれくらいあるのだろう?」という素朴な疑問が出てきます。

この疑問を解く鍵は、きっと冒頭で述べたような開発上の「もどかしさ」にうまく対処できているかどうかにかかっているのではないかと筆者は考えました。

そこから考えを進めると、「もどかしさ」の要因は開発ライフサイクルのあらゆる場面に存在することが見えてきます。それこそ要求定義から基本設計、詳細設計、実装、テストに至るまで、どこの工程にでもあるのです。

           

システム開発の「もどかしさ」の原因

サービスインに間に合わせる

テストは特に他の開発工程のしわ寄せを受けてしまうため、テスト設計したテストをどこまで実施するかというトレードオフが必要となる

だから
もどかしい

システムの妥当性はどうか

何を根拠にテストすべきかが明確でないため、ドメイン知識があるかないかといった人依存のテストになりがちとなる

だから
もどかしい

システムの機能性をしっかりと検証する

機能性の根拠となる仕様がいつまでたっても定まらないため、テスト設計/実施のやり直しが増えるだけではなく、変更によるデグレードを誘発する

だから
もどかしい

執筆者プロフィール

大西建児 (Kenji Onishi)
株式会社豆蔵 シニアコンサルタント。国内電機メーカー、外資系通信機器ベンダーで培ったテストや品質保証などの経験を生かし、テスト手法や技術の普及、発展に取り組む。NPO法人ソフトウェアテスト技術振興協会(ASTER)副理事長。JaSST'08東京 共同実行委員長。著書に「ステップアップのためのソフトウェアテスト実践ガイド」(日経BP社)などがある。

『出典:システム開発ジャーナル Vol.1(2007年11月発刊)
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。