PR

 ようやく新しいパッケージ製品のリリースにこぎつけたが、エンドユーザーから「システムメッセージに誤字がある」「画面の出力値が文字切れしている」といった問い合わせやクレームが相次いだ。改修を続けているものの、なかなか問い合わせやクレームが減らない。リリースしてから半年がたつが、不具合改修に多くの時間を取られ、終わりが見えない――。

 パッケージ製品やクラウドサービスの開発で起こりがちな光景だ。製品やサービスのリリース後、不具合に場当たり的に対応してしまい、いつまでもクレームが収束しないといったものだ。問い合わせやクレームへの対応で、不具合改修、テスト、修正版のリリース予定の交渉に忙殺される日々がいつまでも続く。

 リリース後に指摘される不具合は機能に関するものだけではない。画面上の文言の誤字脱字のような、ユーザーインタフェース(UI)に関わる不具合も多い。UIの不具合は機能には影響しないが、軽視すると痛い目に遭う。エンドユーザーの目に付きやすく、ユーザーは「見ればすぐに分かるのになぜ直さないのか」と疑問を持つ。この疑問は「この製品は大丈夫か」という不安につながり、製品への信頼を低下させてクレームが止まらなくなる。

 こうした状態に陥るのは、不具合の分析が不足しているからだ。分析が不十分な現場の多くは、製品の品質状況や弱点を考慮せずにテストを実施している。そして、いつも同じようなテストを繰り返している。これだと、以前のテストで見つけられなかった不具合は、その先もずっと見逃し続けることになる。

 もちろん上流工程で不具合の混入を防ぐ方法も検討すべきだが、いったん埋め込まれてしまった不具合はテストと改修で対応するしかない。ここでは、リリース後に深刻なクレームにつながる不具合を減らす、不具合分析の方法とそれをテストに反映する方法について解説する。

3ステップでリリース後のテストと改修を効率化

 リリース後の不具合改修で問い合わせやクレームが止まらなくなる要因は大きく2つある。

 1つめはテストの優先順位の考慮不足だ。システム開発の中で実施するテストでは、機能に関わる不具合をつぶす方向に意識が傾く。時間、人員が限られていると、どうしてもUIの確認は後回しになりがちだ。リリース後の不具合対応でも同じようなテストを実施していると、エンドユーザーの目に付きやすいUIに関わる不具合を素通りさせてしまう。

 2つめは問い合わせやクレームの傾向を、開発部門の開発者やテスト担当者が把握できていないことだ。一般に、エンドユーザーからの問い合わせはコールセンターや営業部門が受ける。そして、営業部門などか取りまとめ、改修してほしい不具合を整理して開発部門に依頼する。こうした業務フローであるため、「UIに関する問い合わせが多数来ている」といった問い合わせの傾向が開発部門に伝わっていない場合が多い。

 2つの要因をそのままにしておくと、製品の品質のどの部分に問題があるのか、どの部分を優先して品質担保すべきかが見えない。こうした状態で不具合対応を続けると、冒頭のような不具合対応が収束しない状況に陥る。こうした課題に対する解決策として、筆者は次の3ステップの実施を推奨している。

STEP1 不具合の傾向を可視化する
STEP2 テスト観点とひも付ける
STEP3 結果を次のテスト方針に反映する

 STEP1ではエンドユーザーからの問い合わせ情報から不具合傾向の分析を行う。STEP2では不具合とテスト観点のマッピングを行う。STEP3では分析結果を次バージョンのテスト方針に反映して品質の改善を図る。以下、3つのステップを詳しく説明しよう。