背景
自分は開発のみ担当で、リリース後のシステムには関わらない生活を10年ほど送っていました。
今回初めてユーザー対応をすることになりました。
最初はよくわからず対応してましたが、半年ほどでだいぶ要領がつかめてきました。
今回は自分が心掛けていたことを紹介します。
想定する環境
・自分が部分的に修正、機能追加してるシステムへの問い合わせ
・問い合わせてくるのは同社の別部門
問い合わせ発生
ユーザー「xxxシステムで、xxxをすると〇〇〇になるんですけど、どうしてですか？」
大抵はこんな感じでかかってきます。
自分が心掛けていた調査手順はこんな感じです。
１：ユーザーの理想状態と、現状を把握する
２：ユーザーの勘違いを疑う
３：データを疑う
４：プログラムを疑う
ユーザーの理想状態と、現状を把握する
まずは「xxxをする」の部分を具体化します。
「xxxの画面で、xxxと入力して[決定]をクリックする」くらいに落とし込めればOKです。
入力内容は口頭だと正確に伝わらないので、ログを確認します。
（半角全角、スペース、アルファベットの綴りなどは伝達ミスが起こり得ます）
つぎに「理想状態」を具体化します。
「入力内容に関連したxxxリストが出てほしい」みたいな感じです。
ここまで聞いたら、調査に入ります。
ユーザーの勘違いを疑う
自分は長年開発したやってこなかったせいか（もしくは仕事できないせい）、初手で「プログラムにミスがあるのではないか」と考えてしまってました。
しかし、プログラムは基本的にテストをされた後にリリースされています。プログラムミスの可能性はかなり低いです。
システムの操作マニュアルを見て、想定された使い方なのか確認しましょう。
ユーザーが使い方を熟知していないケースは結構あります。
年に数回しか使われない機能の場合、ユーザーが正しい使い方を忘れている可能性もあります。
または新人が、現場のリーダーが休みで質問できず、システム部に問い合わせる場合もあります。
データを疑う
想定外のデータが入っていないか確認します。主には「全角スペース」「半角スペース」「改行」です。
僕が担当したシステムでは「ユーザーが入力したデータをチェックせずにDBへ入れる」というケースがあったため、想定外データが入るケースは多かったです。
プログラムを疑う
ここまで来たら、ようやくプログラムを見ていきます。
プログラムの見方は他の記事を参考にしてください（おい