HotWiredで「「史上最悪のソフトウェアバグ」ワースト10を紹介」という面白い記事があったので紹介します。この記事を読んでそれぞれのバグについて何が原因であったか私なりに考えてみました。史上最大のバグ、というくらいだから原因も史上最大級に複雑なものなのかなと思って読んでみたのですが、私が読んだところでは、要求仕様バグ、設計バグ、単体試験不足、高負荷・競合試験不足、走行・運用試験不足、セキュリティ耐性試験不足、運用ドキュメントの整備不足など、ソフトウェアの開発工程の基本的な部分が十分に実施されていないことが原因のようでした。しかも、時代を経てもバグが除去できなかった理由にさほどの違いが見られず、過去に犯した過ちを繰り返してきた実態が垣間見えます。
このような状況を解消する方策としては、まず仕様・設計のレビュー、および試験、運用得手順書の作成まで手を抜いてはいけない、ということでしょう。そのためには、何をもってレビュー・試験が網羅したと言えるのかわかっている必要があります。次に、実際には開発にかけられる費用、日数が決まっているので網羅的にレビュー・試験をすることは不可能であることを認識した上で、項目の優先度を勘案し、優先度の高いものから項目消化をし、実施しなかった項目については、実施なくても良い理由、実施しないことによる影響を分析する必要があります。
これらのことは口で言うのは易しいのですが、実行に移すとなると非常に難しい作業です。しかし、これができるかどうかがソフトベンダ、システムインテグレータおよびその顧客にとって、今後の会社の命運を握っているといっても過言ではないでしょう。
また、上記の作業を抽象化して書くと、『課題に対し何をしなければならないか可能な限り網羅的に抽出し、そのうち実際に何をするか、実施しないことによる影響は何か分析する』、ということになります。これは何もソフトウェア開発の品質確保だけでなくマネージメントや経営についても適用できる考え方ではないかと考えます。この論を発展させると、システム障害をよく引き起こす企業はその経営やマネジメント手法にも問題を抱えていることが多いといえるのかもしれません。