無欠陥システムという聖杯

作者 Vikas Hazrati , 翻訳者 徳武 聡 投稿日 2011年2月27日

セクション

プロセス/プラクティス,

設計/アーキテクチャ,

デベロップメント

トピック

品質 ,

Agile in the Enterprise ,

ソフトウェアテスト ,

Agile ,

テスト

原文(投稿日：2011/02/22)へのリンク

無欠陥システムとは言えば聞こえはいいが、本当に実現可能なのか。それとも無理なのか。多くの組織が'無欠陥手法'を取り入れているが、本当に成果があがっているのか。

Jim Bird氏によると、100%完璧なシステムを作るのにかかるコストは膨大だ。チームが90%の欠陥を除去した段階で、残りの10%の欠陥を除去して得られるものはその作業に関わるコストと比べてはるかに少ない。氏はKen Beck氏とMartin Fowler氏の著書'XP エクストリーム・プログラミング実行計画'の下記を引用する。

しかし、多くのソフトウエアはバグをゼロにできません。欠陥はどんなものであれ、修正するのに時間と労力がかかります。このような労力と時間は機能を実装するための労力や時間から捻出されます。どうするか決めなければなりません。

同じように、Michael Dubakov氏は、無欠陥を目指す考え方を持つと、利点よりも多くの問題点を生み出すかもしれないと言う。氏曰く、望ましくない影響は、

• 複雑で汚くバグだらけではあるが、重要なコードに対して十分なリファクタリングをする勇気を持てなくなる。
• 重要な決定ができない。リスクは少ないが間違った決定をしてしまう。
• 責任逃れをするためにあらゆる手を尽くす。その結果、臆病で愚かな振る舞いをしてしまう。

氏は現実にはバグがあるシステムが稼働しているのは普通のことだと言う。チームはバグ修正をやめたり、避けたりしていいということではないが、いわゆる'最後のバグ'は幻だということを暗示している。

修正するバグは選択するべきだと氏は言う。チームは真っ先に、そのバグの頻度と重症度を検証してビジネスに与える大きさを見積もり、次に、'修正にかかるコスト'と'残りの機能に対するリスク'など技術的な要素を勘案してから修正に取りかかるべきだ。

バグを許さない方式で開発することは、バグ修正は常に正しい、良い行いだと仮定しています。しかし、バグを修正することは常に正しいことだとは限りません。バグ修正には常に新しい問題を埋め込んでしまう危険があるからです。

Joel Spolsky氏が言うには、無欠陥とは文字通り欠陥が無いということではない。バグがあるときはいつでも、新しいコードを書くよりもバグ修正を最優先にするという意味だ。

では欠陥を最小限にする最良の方法は何か。

Mark Windholtz氏はTDDの重要さを指摘する。

テストファーストでコーディングすることが無欠陥を達成するための基礎になります。テストファーストのコーディングでは自動単体テストを書いてから実際のコードを書き、テストしてコードを書くというサイクルを5分から10分くらい実施する必要があります。

同じようにMichael Dubakov氏はTDD、継続的統合、自動回帰テスト、そして根本原因分析と高い開発スキルを組み合わせて欠陥の数を少なくすることを勧めている。

Rolf Gotz氏は無欠陥システムを作るための10の原則を挙げている。その中に含まれているのは、

• 顧客と開発者は相思相愛であること。
• 要件の範囲が小さく簡単に見渡せること。少しづつ進められること。
• 初期段階では最も価値のある要求に注力する。
• 判定基準が最重要。
• 問題が優先(要求はその後)。
• 性能についての要求を優先。

欠陥が少ないシステムは実現できるが、無欠陥のシステムを作ろうと奮闘しても終わりがない。いつその努力を終わりにするのかが鍵だ。Jim Bird氏が言うように、

バグ修正をいつ終わらせるか。収穫逓減にたどり着いたか。もっと需要な仕事に取りかかるべきか。このようなことを理解するのは簡単ではありません。どのバグを修正し、どのバグを修正しないのか。今は修正できないのはどのバグで、修正すべきでないのはどれか。これを判断するのも難しいです。失敗することもあるでしょう。

• 次へ >