「障害を許さない」プロジェクトが破綻する理由（１）

障害を許さないプロジェクトは簡単に破綻します。

現場経験の長い方なら、これだけでも何となく同意して頂けるかもしれませんね。

逆に経験のない方や、マネジメントの経験（特にユーザー寄り）が長い方は「何を言ってるんだ」と思われるかもしれません。障害を出さないのが当たり前だろう、と。

なぜ「障害を許さない」プロジェクトが破綻するのか。これから何回かに分けてその理由を述べて行きたいと思います。

■「障害を許さない」プロジェクトの特徴

障害は本当に好ましくないものでしょうか。「障害なんか起こらない方がいいに決まってるじゃないか」と思われた方、少し待ってください。確かに本番運用に入って起こる障害は好ましくない。エンドユーザーさんにも迷惑を掛けますし、現場の体力もかかる。しかしプロジェクトの途中で起こる障害はどうでしょうか。「プロジェクトだって同じだ。障害なんか起こらないでスムースに行くのが一番」という声が聞こえてきそうですね。

でも、私に言わせれば「障害が起こらない」というのは「開発者が仕事をしていない」のと同義なのです。言い換えれば開発者が熱心に仕事をすればするほど、障害が発生するものです。障害が発生しないプロジェクトの方がよほど怖い。それはどこかで開発／テストのプロセスが機能不全に陥っている証拠です。

テストは潜在的な欠陥を発見するためのプロセスです。問題がないことを確認するプロセスではない。ソフトウェアには必ず欠陥があります。欠陥を発見し、修正するためにテストサイクルがあります。
障害が出ることを好ましく思わないプロジェクトではこれが逆転します。本来どんどん障害を出すべきテストフェーズが、障害が起きないことを確認する為のテストフェーズにすり代わってしまうのです。

その結果、障害を許さないプロジェクトでは障害への対応方法が全く違ってきます。

障害の発生を推奨するプロジェクトでは、障害を修正した後に速やかに次のテストケースに移ることができます。目的は次の潜在障害の検知です。潜在障害を検知するためにテストですから、テストをどんどん実施するのが望ましい。テストフェーズが上手く回っているプロジェクトで仕事をするのは気持ちのよいものです。障害がどんどん直り、品質が向上していることが体感できます。

ところが、障害を許さないプロジェクトでは発生した障害が望ましくないものとして捉えられます。障害は発生してはならない。あってはならないことが起こってしまった。今後二度とこのようなことを起こさないために、何をすべきなのか。そして執拗な原因追求が始まります。
つまり障害がほとんど不祥事として扱われる。そして単純ミス、思い込み、レビュー漏れが不祥事の原因と考えられてしまいます。
その結果、本来の目的であるはずの潜在バグの洗い出し作業が後回しになり、現状のプロセスや開発者に対する粗探しが始まります。
コミュニケーションをしっかり取っていればこの障害は発生しなかった。では会議の数を増やそう。一見筋が通っているようにも見えます。しかし、はっきり言って手遅れかつ時間のムダと言えましょう。会議を増やすよりもむしろ再テストを行ったりテストケースを増やすほうがバグが効率的に潰せるのは明らかです。
「障害＝不祥事」と捉えるプロジェクトではそのことに気がつかない。将来起こりうる障害を洗いだすことよりも、現状の粗探しに囚われてしまうのです。

繰り返しますが将来起こりうる障害を少なくするためには＝ソフトウェアの品質を上げるためにはどんどん障害を出して修正して行くべきです。いくら設計書を読み返しても、ソースコードをチェックしても、会議を増やしても、障害はなくなりません

もちろん会議を増やすことによって実際に別の問題が見つかることがあるかもしれません。でもテストケースを増やしたり、テストを行うほうがよほど効率がよい。テストケースの検討を通じて障害が発見されることはめずらしくありません。またテストを行えば少なくともそのテストは上手く行ったという結果が必ず残ります。
障害の発生を許さないプロジェクトでは、調査や机上検証を執拗に繰り返したり、安心したいがためだけに一時的な文書をベンダーに作成させがちです。しかしこれらは潜在障害を洗い出すためには極めて非効率です。このような作業にリソースをつぎ込んでしまうとプロジェクトが疲弊し、結局品質の向上が後回しになってしまうのです。

（続く）