リリース直前で発覚した不具合にどう対応すべきか？

システム開発において不具合は避けて通ることができない課題です。
十分なテストをしたつもりであっても、不具合をゼロにするのは至難の業。
むしろ、不具合を発見した時にどのように対処すべきかを考えることの方が大切です。
もちろん、不具合はテスト中に発見することがベストなのですが、思わぬ時に見つかってしまうことも少なくありません。

リリース直前に不具合を発見した場合

リリース直前になって、不具合が見つかりました。
その時、どのような判断を下すのが正しいでしょうか？
不具合が発生したのだから、リリースを延期するのでしょうか？
あるいは、リリースの時間まで懸命に修正し、何としても間に合わせるのでしょうか？

もし、あなたがその判断を下す立場の場合、どのように考えますか？

まずは冷静に対応する

経験値によることもあるでしょうが、大抵はリリース直前で不具合があればまずは焦ってしまいます。

（リリースが遅れたらどうしよう・・・）
（上司に怒られる！・・・）
（お客さんに何て言おう・・・）

不安が先に立つのはもちろんです。しかし、そこは不安という感情を何とか消して冷静に考えることから始めるという思考に切り替えてください。冷静にそして、論理的に考えることができなければ、解決できる問題もできなくなってしまいます。

状況を理解する

もし、あなたがプロジェクトの管理者やリーダーだった場合、チームのメンバーから報告が上がってくることでしょう。
その時、ありがちなのは「○○機能で、更新をかけるとうまくいきません！」のような表現。
エンドユーザーでなくとも、経験が浅いプログラマーもこのような言い方をすることがあります。

しかし、これでは何も判断ができません。

「うまくいかない」というのが、具体的にどういう事なのか？
報告を受ける立場の人は、これを聞き出すこと、報告する側の人は具体的に説明をする必要があります。

　　エラーメッセージがでるのか？
　　フリーズするのか？
　　処理時間が通常時の倍かかるのか？
　　処理は正常終了するが更新されないのか？
　　表示が乱れるのか？

など色々なことが考えられます。
さらに、上記の例であったとしてもエラーメッセージがでるなら、どのようなメッセージが出るのか。どこに出るのかなどの情報も必要です。

まずは、どのような状況なのかを具体的に把握しなければなりません。

判断する

システム運用ポリシーが定められており、その手順に従うのであればその通りにします。
もし、特に決まったポリシーがない場合、どうするか判断しなければなりません。

どのような条件下で起こるのか

重要なのはどのような条件下で起こるのかです。

• 無条件で発生する。
• 一定条件の場合に発生する。
• 条件が分からない。

ということが、考えられます。

実際には、テストも行っているでしょうから、無条件で発生するパターンは少ないかもしれません。
しかし、開発時と本番時でのシステム環境の違いによって、起こることはあります。
本番環境と同一構成でステージング環境があるのは理想的ですが、コストもかかるため全てが理想的な環境にあることもないでしょう。

その条件が発生する頻度はどれくらいあるのか

次に、その条件はどのような頻度で起こりうるかを知る必要があります。
例えば、商品Aを更新する時に起こる。数量に100以上を入力すると起こるというものです。

調べてみると、商品Aの商品名は商品の中で最大であり、最大商品名の更新テストを実施しておらず発覚した。
数量が3桁以上の場合のテストを実施しておらず発覚した。
というようなケースがあり得ます。

分かってしまえば単純なことだったりするものですが、意外に見つからないものです。

もし、数量に100以上を入力すると起こるというものだとしましょう。
本番環境において、数量が100以上になるケースはどれくらいあるのでしょう？　（もちろん、本例の場合のみです）
調べてみると、数量は通常1であり、稀に3桁でも10。
3桁になることはほぼないということでした。
こういった調査は可能であれば本番データで同様のデータを調査し裏付けを取る。
業務（本システム）に詳しい人に確認する。
などの方法によって調査します。

必ずしも調査ができないこともあります。その場合、プロジェクトマネージャーの判断で、そのケースは年に1回あるかないか。ということを決断します。

もし、前述の例で過去データがあり、調査したところ3桁の数量は3年前に1回、5年前に1回あったきりだということが分かったとするならば、「この不具合が起こる可能性は低い」という判断のもとに、まずはリリースした後で修正する。という選択肢が生まれます。

どんな問題が引き起こさせるのか

その不具合が起こる可能性は極めて低いと分かった場合であっても、もし発生したらどんな問題が起こるのかは確認しなければなりません。
単にその機能がエラーになる、クラッシュするので済むのか、あるいはエラーになり、データを壊す、不整合データを作り出してしまう。
この問題の大きさもまた、リリースの判断材料となります。

確認する

判断を下した人が全権を持つならば不要ですが、そうではない場合、権限者である人に「このような判断のもと、リリースしても差し支えないと考える、ただし、このようなリスクはあるがよろしいか？」と、確認します。
前述の例にあげた3年に1回は、今日明日にも起こる可能性は否めません。
しかし、起こる問題は機能がエラーになるだけであり、データに影響を及ぼさない。
それであれば、リリースに踏み切るという判断はあるでしょう。
しかし、このシステムはBtoCであり、絶対にユーザにエラーを起こさせたくないという判断もあります。
リスクはゼロにはなりませんので、どこに重きを置くかで決断しなければなりません。

まとめ

リリース直前で不具合を発見したからといって、必ずしもリリース中止が正しい判断ではありません。
不具合の発生する条件、発生の頻度、引き起こす問題、そしてシステムの利用者などから、総合的に判断し、リリースの是非を決定することが大切です。