あらためて言いますけど「仕様かバグか」はどっちでもいいんです


とある自社プロダクト開発チームで、お問い合わせ対応(カスタマーサポート)を業務の一つとして担当してます。


3年ちょい続けてきて、最も多いやりとりが、

私「箇所Aと箇所Bの数値が違うってお問い合わせ来たんですが…」
エンジニア「あー、それ仕様です」

私「この画面真っ白なんですけど、大丈夫ですか?」
エンジニア「データが空だからですね。仕様です」


わかりますかね。「仕様です」のパワー。会話が終わるんですよね。
「仕様です(バグじゃないので弊社に非はありません)」だと思うのですが、そんなことお客様に関係ありませんよね、という話。

もちろん、初期段階では「仕様かバグか」は重要です。
ただ、バグではないけれど違和感がある、お客様が疑問を持ってしまった場合、「なぜ箇所Aと箇所Bの数値は違うのか」まで説明できる状態になければなりません。

それを「仕様です」発言はぶった切ってしまうんですね。


なぜ「仕様です」発言が生まれたか


これはフロント側(非エンジニア)にも責任があって、

今のチームでは昨年の夏ぐらいから
・日別のお問い合わせ件数の推移
・お問い合わせの種別
・バグによるお問い合わせの件数

をKPIとして追うようにしてしまっていたんですね。

この構造だと、
・「バグ」となった時点でなんとなく製作者を責める雰囲気になる
・ 結果、「仕様」であることを説明する方向に意識が向く
・「要件定義のときにはその仕様はなかった」とか不毛な会話が始まる
・ お客様にとって最善の状態は何か?という議論にならない
・ともすると隠蔽体質を作るトリガーになってしまう

なので「バグによるお問い合わせ件数」は、サービス全体の品質を測る指標としてキープしつつ、お問い合わせ対応の段階では議論の対象にしないことにしました。


お客様にとってどういう状態か?で緊急度わけをする

ではどうするか。
考えたのが、緊急度を下記の4レイヤーに分けること。

緊急度の高い順に、
1. 機能が正常に使えない
2. 納得感がない
3. 誤解してしまう
4. 追加要望、要求が出る

ツール側の仕様・限界ではなく、あくまで「お客様にとってどういう状況か」で考えるのがポイントです。
下記に具体例を挙げていきます。


1. 機能が正常に使えない
一般的にエンジニアの方に「バグ」だと確実に認識してもらえるのがこのレベルです。
例)画面が真っ白、データが溜まってない、ボタンが反応しない

2. 納得感がない
一概にバグとは言えないが、ターゲットユーザーの脳裏に「?」が浮かんでしまう可能性の高い状況です。
例)ローディングが10秒以上回っている、〇〇できそうなのにできない

3. 誤解を与える
機能は正常に使えるが、お客様が間違っていることに気づかなかったり、違った認識をしてしまう状況です。
例)対象が明示されていない、機能間でルールが違う

4. 追加要望、要求が出る
バグではないし、仕様(要件)にはなかったが、ターゲットユーザーが利用過程で感じた「ちょっとした不便」などです。
例)一括〇〇ができたらいいのに、前回の状態を保持してくれたらいいのに


このレイヤーわけだと、「バグか仕様か」という二項対立論から離れられるほかに、「エンジニアの仕事かどうか」に限らず議論できるので、
・誤っていた箇所をただちに修正
・わかりにくいラベリングを他の言葉に変更
・集計期間、対象範囲を明記
・小さな便利機能を新規追加
といったように柔軟な対応策が出やすい気がします。

また、カスタマーサポートとしても、問題がどこにあるか分かってないのに無責任に謝ってしまうといった事態を避けられます。


実際の運用について

とはいえ、正直このレイヤー構造をチームの全員が共通認識として持つのは難しいです。
(そもそも「お客様がどう思うか」をイメージできる人が少ない場合など)

うちのチームでは、お問い合わせを受けた時点でわたしが独断をもって判断し、
「ここって、昨日集計回ってるはずですよね?」
「確かに、〇〇した後にこの画面が表示されたら、なんか不安になりますよね…」
といったかんじで、お客様が言いそうな言葉を持って方向性を提起する形をとっています。

エンジニアの方からも「お客様的には…」といった発言が多く聞かれるようになった気が。


こんなかんじで、一口にカスタマーサポートといっても色々創意工夫してみたりしています。
情緒的と思われがちですが、意外にロジカルな作業という話も、またあらためて書きたい。


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

読んでくださりありがとうございます!

やさしい〜〜すき〜〜
4

niri

某Webサービスの UXデザイナー。毎日の学びを残す場所。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。