失敗プロジェクトのリカバリ方法

失敗した（工程が遅れた、品質が悪い）プロジェクトのリカバリを行うためには、以下の手順で行います。

失敗原因を見つけ出す

通常、失敗の原因は１つではないが、ほとんどの場合、機能仕様や構成仕様、開発体制、管理体制に原因がある。ここでは、開発体制や管理体制の問題以外、仕様の問題に焦点をあて説明する。

失敗原因は仕様だが、仕様書上は書いていなかったり、不明確だったりする。したがって、機能仕様書を単純に再レビューしても、なかなか失敗原因が見つからないものである。
（書いていない部分の指摘は難しい）・・・では、どうやって見つけるのか？

使ってみる

基本は、使ってみることだ。その製品を使う顧客になった気持ちで、客観的に使ってみよう。なんか、手番が自然じゃない（なんでこんな順番で処理させるの？）とか、なんでこんなもんを入れん（指定しない）といかんの？とか、ちょっと重い（レスポンスが悪い）とか。何か感じませんか？スーと理解できましたか。・・・気になったことをメモしてみましょう。直感でかまいません。

原因を分類してみる

さて、使ってみて大体、まずいところの見当がついたでしょうか？直感は働きましたか？次に、テスト結果を見てみます。テスト結果とは、テスト(CT/ST/PT)のバグと対応一覧です。このバグについてヒアリングをかけてください。ヒアリングの観点は、バグの作り込み工程と根本原因です。

根本原因は、担当者はほとんどのケースで誤解しているので、なぜ・なぜ５段階活用を利用します。根本原因は通常２つの側面、１つは作り込んだ原因ともう一つはテストで見つけられなかった原因をもちます。リカバリを行う場合、作り込んだ原因を徹底的に調べ、対策を打ちます。テストで見つからなかった原因についても、もれた原因をベースに、テスト項目を網羅性の観点で見直します。原因分析は、なぜ、こうなったのか、というのをとことん（根本まで）繰り返すのです。この時注意しないといけないのは、なぜ・なぜ　がループしてしまうことです。このループが発生した場合は、実は根本的な原因にたどり着いていないことを意味します。簡単そうにみえますが、とっても難しいことです。ただ、これをマスターすると品質は格段に上がります。
さて、原因をコンポーネント別や開発プロセス別にならべてみます。設計上の問題はみつかったでしょうか？機能設計やテーブル設計、コンポーネント設計の不良が発見できます

裏付けをとる

仕様書やソースプログラムをチェックしたり、テストすることで不良箇所が存在するかをチェックします。

短期的な対応方法

さて、不良箇所が見つかったところで、対応の方法です。

ポイントとしては、製品としての意味がなくならない範囲で以下ができないかを考えます。

不良箇所を隠す

不良箇所を呼ばないようにする。使わない。使う頻度を下げる。使うバリエーション、タイミングを固定化する。などがあります。ようするに、問題は残したまま、製品としてはうまく逃がす方法です。

使う自由度を下げたり、呼び出す回数を減らせば、障害の発生率は下がるわけです。呼ばなければ障害があっても障害が発生しません。

制限にする

マニュアル等の修正が困難なフェーズに入っていた場合は、制限にしてしまいます。制限にした場合の影響を考えます。制限にした場合は、一般的に制限解除に向けてのシナリオを練る必要があります。制限解除時期を影響を考えて明確にします。

修正する

通常PT工程まで行って、大きな設計障害の場合、修正はまず不可能とみたほうがよいでしょう。しかし、a,bの対応では製品としての意味がないのであれば、機能仕様・構成仕様の作り直しから再チャレンジします。当然、出荷も遅らせるか、一部の機能であれば、機能制限にして、制限解除時期を調整します。検査、販推への対策を取ります。