顧客の「使えない」は、バグとは限らない
目次
顧客から「この画面が使えない」という連絡が届いたとき、それが不具合なのか要望なのか、すぐに判断できますか。
サポートの担当者は、まず原因を調べます。設定の問題でなかったとき、その連絡を不具合として開発に渡すのか、要望として記録するのかで、そのあとの扱いは変わります。
この記事では、不具合と要望の分かれ目がどこにあるのか、迷ったときに誰がいつ決めるのかを整理します。要望管理の全体像は機能要望管理とは？収集・整理・優先順位付けの基本で扱っています。
- 顧客は不具合も要望も「使えない」という同じ言葉で伝えてくる
- 仕様との差だけで断定せず、要件と利用場面も確かめる
- 受付で迷ったら判定を保留し、開発・製品担当者が内容を確認する
顧客は、不具合も要望も同じ言葉で伝えてくる
顧客が製品の仕様を詳しく把握しているとは限りません。顧客にとっては、やりたい仕事が終わるかどうかが関心事です。
だから「エクスポートが使えない」という一言が、ボタンを押してもファイルが落ちてこない状態を指すこともあれば、ファイルは落ちてくるけれど必要な列が入っていない状態を指すこともあります。
前者では不具合が疑われますが、権限や利用環境の確認も必要です。後者も、必要な列を出す要件が漏れているのか、新たな利用目的への要望なのかで扱いが変わります。受け取る言葉が同じでも、必要な調査や対応は異なります。
仕様との違いに加え、要件と利用場面も確認する
まず、期待する動作と実際の動作を比べます。合意した要件や仕様を満たしていなければ、不具合として調べる手がかりになります。ただし、仕様書自体に誤りや抜けがある場合もあるため、「仕様どおり」だけで不具合ではないと断定はできません。
JSTQB Foundation Level シラバス V4.0の1.1節では、指定された要件を満たすか確かめる「検証」と、実際の利用環境で利用者のニーズを満たすか確かめる「妥当性確認」の両方を扱っています。
この2つは、不具合と要望を機械的に分けるための定義ではありません。要件や設計の問題が見つかる場合も、新しいニーズが分かる場合もあります。種別を確認したうえで、対応の優先順位は顧客への影響や緊急性、工数を踏まえて判断します。
仕様どおりでも、困りごとを閉じない
判定が割れるのは、製品が仕様どおりに動いているのに顧客が困っている場合です。表示に10秒かかる、1つの作業に5回のクリックが必要になる、ラベルの意味が伝わらない。性能や操作性の要件があれば不具合の可能性がありますし、要件が曖昧なら仕様を見直す必要もあります。
ここで「仕様どおりなので問題なし」と閉じてしまうと、顧客の困りごとは残ったままです。
同じシラバスの1.3節にある「欠陥ゼロ」の落とし穴も、要件に沿ったテストと修正だけでは、利用者が必要とする製品になるとは限らないと指摘しています。
仕様どおりという事実は、放置してよい理由になりません。種別が決まらなくても困りごとは記録し、開発・製品担当者と確認します。新たなニーズへの対応と判断した場合は、要望として検討します。
受け取った担当者は、その場で種別を決めなくてよい
迷ったときに起きるのは、判定が終わるまで案件が止まることです。サポートの担当者が考え込み、どちらとも言えないまま保留にします。
種別の判定を、受付の時点に置かないでください。受付では、顧客の言葉、期待した動作と実際の動作、再現手順、発生画面、業務への影響を確認できる範囲で記録します。判断に迷う場合は、開発・製品担当者が内容と要件を確認してから種別を決めます。障害やデータ損失など緊急性が高い連絡は、種別の確定を待たずに所定の窓口へ引き継ぎます。
受付時に記録する項目は機能要望の収集を一本化する方法で扱っていますが、そこに種別は入れていません。入口の項目が少ないほど、現場の担当者は記録を続けられます。
分けたあとに、要望だけが消えることがある
不具合として処理した案件でも、修正の対象とは別に操作上の困りごとが含まれている場合があります。修正票を閉じるときは、元の連絡に未対応の内容が残っていないか確認します。
修正そのものは正しい処理です。ただ、顧客が何度も同じ画面でつまずくなら、画面の作りも確認対象になります。不具合の修正票は閉じてよいですが、「この画面は迷いやすい」という要望のほうは、別に残しておく必要があります。
顧客が要望を言っているのに社内で止まる構造は顧客から要望が来ないのは、満足しているからとは限らないで扱っています。不具合として閉じることは、その止まり方の1つです。
よくある質問
不具合か要望かを、顧客にも伝えるべきですか？
伝えたほうがよいです。ただし、社内の呼び方をそのまま返す必要はありません。顧客が知りたいのは、直るのかどうかと、いつ直るのかです。不具合なら修正の見込みを、要望なら検討する予定があるかどうかを伝えてください。種別だけを返すと、顧客は答えをもらえなかったと受け取ります。
不具合と要望で、台帳は分けるべきですか？
開発側がすでに課題管理ツールを使っているなら、不具合はそちらに残して構いません。ただし、要望の台帳から元の連絡をたどれる状態にしてください。2つに分けること自体より、分けたあとに相互をたどれなくなることのほうが問題になります。
まとめ
顧客から届く「使えない」という言葉は、不具合と要望のどちらからも出てきます。仕様との違いは判断材料ですが、要件の漏れや利用場面も確認が必要です。
仕様を満たしていても、要件や設計の問題が残っている可能性があります。受付では困りごとと影響を記録し、迷った場合は開発・製品担当者と判定します。要望と判断した場合も、対応を検討する記録を残します。
集めた要望をどの軸で分類するかは機能要望をAIで分類する方法にまとめています。
