IT業界じゃない人にとって「エラーが発生したとき画面に出ている内容を他人に伝える」は難しいことなのか - Togetter
https://togetter.com/li/1714921
このエントリーについてすこし自分でまとめておきたいと思い、増田に残すことにした。これは自分達で開発したプロダクト、サービスについての話なので「windowsが起動しなくなったんだけど」といった雑多な問い合わせを受けるITSM部などには当てはまらないと思う。
→ コメントで逆張りだと言われてしまったが、私の携わったプロジェクトでは実際にやっていた(半年かけてエラー出力処理を見直した)ことだ。
まず前提は利用者は困っている。
あなたが利用者のITリテラシーの低さに嘆く以上にシステムを使えないことに困っていることを理解しなくてはいけない。これは心構え。
無償のボランティアではないと思う。偉そうな態度をとりながら対価を受けることはできない。これも心構え。
自社内のサービスであろうと社内システムに予算を計上してることを忘れてはいけない。これも心構え。
日本語で提供しているシステムが突然「ERR:DB CONNECION ERROR 」等と言い出したら、利用者はまず「金を払ったシステムが作りかけか?」と疑う。もし動作ログと同じものを表示しているのなら欠陥だ。
システム全体が使えないのか、そのアカウントだけなのか、それによって利用者は対応を変える。「一時的にセッションが切断されました、再度ログインしてください」と「データベースの接続が失敗しました、システム管理者に利用してください」ではまったく異なる。エラーメッセージが表示される時点でそれをリカバリする業務が走ることを忘れてはならない。
ひとつ上の例と被る。利用者が自力でリカバリできればあなたへの問い合わせを減らすことができる。
利用者はシステムがどんなときに利用できないかを気にする。エラーメッセージはその検索キーになる。
やるべきことをやってないことを利用者の責任にしてはいけない。やっていなければ問合せ窓口が吸収するしかない。問合せ窓口が吸収できなければ開発者が吸収することになる。これは成果物の責任を持つということ。
今すぐ廃業すべきだろう。
エラーメッセージの文言まわりの実装なんて簡単だと思うだろ あの仕様にしたのが日本3位だ
エラーメッセージの実装は楽しいもんですよ。
逆張りおじさん、逆の方向性に極端になるから説得力なくなって無能な味方にしかならない とにかく否定することに一生懸命になっちゃって、とにかくいっぱいたくさん理由作っちゃう ...
なにを否定してるのか分からない。 開発者目線でいえばきちんとエラーを定義しようって話に落ち着く、エラーレベルを定義し、可能であれば番号も振り、利用者用のメッセージとト...
サポセンは客をクレーマー扱いしてる雰囲気を匂わせてマウンティングorサボりするからなあ 現実は理屈通りにいかないから元増田が書いてるような理屈は意味ないんだよ その情報を持...
開発者はサポートセンターをクレーマー扱いするのをやめましょう、という話です。