欠陥を作らないための読書「ソフトウェアの欠陥予防」

「バグの無いソフトを作るためには、そもそもバグを発生させなければ良い」というのはid:rabbit2goの名言だけど、モグラ叩きの如くバグを潰していくだけの開発では、一向に品質は向上しない。そもそも、障害が発生するのは開発プロセスやエンジニアリングに何らかの問題を抱えているからであり、その根本原因を突き止めて直す必要がある。

「ソフトウェアの欠陥予防」はそんな欠陥予防にフォーカスした書籍だ。著者は、ソフトウェア品質に対する取り組みとして「検出、分析、予防」の3つがあるものの、この中では検出に重点が置かれすぎている現状を指摘している。

多くの開発チームは、結果を防ぐことの必要性を認識し、欠陥を防ぐためのさまざまなテクニックを試みています。しかしこのようなテクニックのほとんどは、欠陥検出（テスト）の改善に焦点を合わせたもので、欠陥の予測や予防に焦点を合わせてものではありません。

既存の様々な方法使ってソフトウェアの欠陥を取り除けば、確かにソフトウェアの品質は改善する。しかし、そこで終わってしまっては勿体ない。得られた情報を有効に使えば、改善策の方向性が見えてくるのだ。

しかし、ソフトウェアテストとその後のエラーレポートという副産物は、欠陥と欠陥のパターンに関する豊富な情報源です。これらを分析すれば、欠陥の根本原因の特定だけでなく、将来起こり得る類似の欠陥の除去あるいは低減方法を特定することができます。

次のステップは、その集まった欠陥情報を分析し、現在進んでいる開発にフィードバックしたり、開発プロセスの改善に繋げることだ。

欠陥分析テクニックの第1のゴールは、既に検出されている欠陥から学び、その学んだ内容を使うことによって、ソフトウェアの品質だけではなく、ソフトウェアを構築する人々の生産性をも改善することです。欠陥分析テクニックでは、既に終わった製品の開発時に集めたデータを適用することによって、進行中の個人およびプロセス改善と欠陥の予防を支援します。

さらに一歩進めば、欠陥発生前に手を打つことが出来るようになる。

欠陥予防テクニックの第1のゴールは、欠陥によって障害が引き起こされたりユーザーが混乱したりする「前」に、欠陥を見越して先手を打ち、予防することです。これは最良のアプローチです。なぜなら、発生しない欠陥は、捕まえたり、修正したり、サポートしたりする必要がないからです。

細かなテクニックはいろいろ有るので、それらを合理的な形で組み合わせて欠陥予防プロセスに持ち込むのがポイントだ。品質向上の掛け声だけでは、人は動かない。メトリクス測定やリスク分析を行い、シミュレーションを行って改善効果が見えるようになれば、組織や開発者（という抵抗勢力）も説得しやすいのではないだろうか。目の前の障害を直すのはもちろん大切な仕事だけど、その先を見据えた予防策はもっと重要だと思う。

ソフトウェアの欠陥予防 テストより確実な品質改善法