上記のような光景は、程度の差はあれ、多くの企業で見られる出来事です。これから新しい社内システムが始まるという大きく膨らんだ期待も、すっかりしぼんでしまいます。こうしたトラブルが最初の１〜２回程度ならまだしも、ことによっては何ヶ月も頻繁に発生して、システムに対する不信感を招いてしまうことも往々にしてあります。なかには、システム・ベンダーに対する不信感が高じて、損害賠償請求にまで発展するケースもあるほどです。

理想的な姿は、新システムが全く問題なく稼動し、新しい業務形態にスムーズに移行できることですが、残念ながらそういうケースは皆無であるといわざるを得ません。パッケージ・ソフトですら、そうです。

一般的には、新システムのバグが取り除かれ、品質が安定するまで１年はかかると見るのが適当でしょう。なぜなら、多くの適用業務は、日次、月次、四半期、年次というサイクルで管理されており、情報システムのインプット、アウトプットの機能もその周期にあわせて設計されているからです。日々のデータ処理のレベルで見つかるバグもあれば、一年間通して運用してみないと見つからないバグもあるわけです。ですから、システム導入にあたっては、まずは１年間は、このシステムのバグとの格闘であると心得ておくことが必要でしょう。

プログラムの品質問題の原因は何でしょうか？

理由は、ベンダーのプログラマーの開発能力の問題だけではありません。システム設計の段階で、すでに隠れた欠陥が内在する可能性があります。ユーザーの要求機能に対して、ベンダー側が十分理解していなかったり、業界では「当たり前」の常識になっている業務処理方法について、要求事項として明示されていなかったり、曖昧な表現であったことからくるベンダーの誤解というのも原因として考えられます。プログラムの品質問題は、実はこういうケースでの原因が最も多いのです。

また、システムの開発期間が短く、システムのテストが十分に行われずに納入されてしまうということも大きな原因です。ベンダー側は当初はなるべく余裕のあるスケジュールを組みますが、要件定義や設計段階でユーザーとの協議日数が長引くと、どうしても後半の工程に無理をせざるを得ません。多くのプログラマーを投入してプログラム開発の期間を短縮しようとしますが、えてして最後の工程であるテスト期間も短縮されてしまうケースが多いのです。

それでは、システム導入前に、ベンダー側で十分なテストを行えば問題は解決するかと言えば、必ずしもそうではありません。少しがっかりするか知れませんが、それが今日のシステム開発の現状です。なぜなら、膨大な量のプログラムを全て完璧にテストし、信頼性１００％を目指そうとすると、時間的にも、コスト的にも天文学的な量の資源投入が必要になるからです。
　　

ソフトウェアの品質とは、国際標準ＩＳＯ／ＩＥＣ９１２６の定義によると、「(1)機能性、(2)信頼性、(3)使用性、(4)効率性、(5)保守性、(6)移植性」の６つが挙げられています。（図表１参照）

この６つの特性をすべて満足するシステムを構築するのは、なかなか難しいと言わざるを得ません。現実には、これらの品質要件のうち、どれを優先するのかという考え方を採用することになるでしょう。

次に、プログラムの品質を測定するモノサシとして、「信頼性成長曲線」というグラフを紹介します。（図表２参照）

消化テストケース数 100 200 300 400 500 600 新規欠陥数 30 27 15 10 7 3 累積欠陥数 30 57 72 82 89 92 出所：「図解ソフトウェア開発のすべて」

これは、プログラムのテスト段階で、欠陥の発見件数を累積してグラフ化したものです。時間が経つにつれて、累積欠陥数の増加傾向がなだらかになっていく状態を示しています。通常は、この累積曲線が横に寝てきて、欠陥の発見が少なくなったときに、テスト終了となります。

プログラムは目で見て欠陥を検出できるものではありませんので、その品質については、「潜んでいると考えられる欠陥のうち、すでに検出されたものの割合」で間接的に証明するしかありません。それがこの「信頼性成長曲線」です。