
「動きがおかしい」の切り分け|最初に聞く7つの質問リスト
「あの、システムの動きがおかしいんですけど」。
そう言われて、続きを待っていると「とりあえず見てもらえますか」で電話が切れる。手元に残ったのは、どの画面の、どの操作が、どうおかしいのか分からない一言だけです。
とりあえずログを開いてみる。エラーらしきものが並んでいるけれど、それが今回の話なのか、いつもの見慣れた行なのかも判断できない。調べ始めることはできるのに、どこを調べればいいかが決まらない。この状態がいちばん時間を吸い取ります。
結論:原因を推理する前に、事実を7つ集めます。軸は3つだけ——「どうなるはずだったか(期待)」「実際どうなったか(実際)」「いつから(変化点)」。この3つが埋まれば、残り4つは確認作業です。時間がなくて1つしか聞けないなら、「いつからですか」を選んでください。原因の候補がいちばん減ります。
質問リストを持つのは、相手を問い詰めるためではありません。相手が言葉にできていないことを、こちらから取りに行くためです。「動きがおかしい」としか言えないのは、説明が下手だからではなく、何を伝えれば伝わるのかを知らないだけなので。
何が起きているか:なぜ「動きがおかしい」だけで届くのか
まず、この一言が悪意でも手抜きでもないことを確認しておきます。理由はだいたい次の4つです。
- 報告する側は「システムの言葉」を持っていない。エラーメッセージ、画面名、操作手順。こちらが当たり前に使う言葉は、業務側の人にとっては日常語ではありません。「おかしい」は、語彙が足りないのではなく、共通の語彙がまだ作られていないだけです。
- 本人も何がおかしいか整理できていない。作業の途中で違和感に気づき、手を止めて連絡しています。まだ自分の中で言語化が終わっていない状態なので、出てくる言葉が短くなるのは自然なことです。
- 細かく言うと迷惑だと思っている。「忙しそうだから、要点だけ」と気を遣って、かえって情報が削られてしまう。遠慮が原因で情報が減るのは、けっこうよくあります。
- 前に詳しく伝えたら、そこは関係なかった経験がある。一度「それは今回関係ないです」と言われると、次から言わなくなります。これはこちら側の返し方が影響している部分です。
そして、こちらの側にも事情があります。「動きがおかしい」を受け取った時点で、可能性のある原因は数十個あります。データなのか、設定なのか、外部連携なのか、その人の端末なのか。この状態で調べ始めると、当たりを引くまで総当たりになります。
Googleの「Site Reliability Engineering」に、トラブルシューティングでよくある失敗として「症状の把握を飛ばして、思いついた原因から検証し始めること」が挙げられています。心当たりのある場所から見たくなるのは自然な反応ですが、症状が定まっていないと、当たりでも外れでも判断できないのが厄介なところです。
だから、最初にやることは調査ではなく、症状を確定させることになります。ここに使う10分は、あとで1時間を返してくれます。
質問の軸は3つだけ:期待・実際・いつから

7つの質問がありますが、覚えるのは3つで足ります。残りは、この3つを確かなものにするための補助です。
- 期待:本人は、どうなるはずだと思っていたか
- 実際:実際に、何が表示された・何が起きたか
- いつから:前は正常だったのか、いつから変わったのか
このうち、「いつから」がいちばん強い質問です。理由は単純で、変化点が分かると、そのタイミングに起きた変更だけを見ればよくなるからです。
「先週の火曜まではできていました」と分かれば、その週の変更管理台帳とリリース記録を見に行けます。「ずっとこうです」なら、そもそも不具合ではなく仕様かもしれません(→仕様書がないシステムの仕様を現状から起こす進め方)。同じ「おかしい」でも、この2つはまったく別の作業になります。
「期待」を聞く意味も、思ったより大きいです。報告の半分くらいは、システムではなく認識のずれだからです。「合計が合わない」の中身が「税抜と税込を比べていた」だったことは、どの現場にもあります。これは相手のミスではなく、画面がそう見えているという事実なので、そのまま画面表示の改善材料になります。
最初に聞く7つの質問
そのまま読み上げても使える形にしておきます。全部聞く必要はありません。上から順に、答えが出たところで止めて構いません。
① いつからそうなっていますか。前は正常でしたか
変化点を取りに行く質問です。「今朝からです」「先週くらいから」「ずっとです」。ざっくりで構いません。
答えが「分かりません」でも収穫はあります。そのときは「最後に正常だったのを覚えているのはいつですか」と言い換えると、思い出せることが多いです。人は「異常に気づいた時」より「普通にできていた時」のほうを覚えています。
② 何をしようとして、どうなりましたか
期待と実際をまとめて取る質問です。「〜しようとしたら、〜になった」という形で返ってきたら成功です。
返事が「押したら変になった」だけなら、操作を1つずつ分けて聞き直します。「画面を開いて、何を入力して、どのボタンを押しましたか」。手順に分けた瞬間、相手も思い出しやすくなります。
③ 画面に何か表示されましたか。可能ならその画面を送ってください
証拠を取る質問です。エラーメッセージの文言が1行あるだけで、調査の入口が決まります。スタックトレースまで出ていれば、さらに早くなります。
ここでのコツは、「エラーは出ましたか」と聞かないことです。業務側の人にとって「エラー」は赤い警告のことで、白い画面や真っ白なままの表示は「エラーではない」と判断されがちです。「画面に何か出ましたか。何も出なかったならそれも教えてください」と聞くと、正確な答えが返ります。
④ ほかの方でも同じことが起きていますか
範囲を確定する質問です。全員なのか、その人だけなのか。ここで調べる場所が大きく分かれます。
- 全員:サーバー側・データ側・設定側。まずログと監視を見ます
- 一部の人だけ:権限、担当部署、扱っているデータの違い
- その人だけ:端末、ブラウザ、キャッシュ、ネットワーク(→キャッシュが原因の「直したのに直らない」を切り分ける)
「他の人は試していません」なら、隣の席の人に同じ操作を1回試してもらうようお願いするだけで、範囲が半分に絞れます。
⑤ 毎回起きますか。それとも、たまにですか
再現性を取る質問です。毎回起きるなら、手元で再現できる可能性が高い。たまになら、タイミングや特定データが絡んでいる可能性が上がります(→再現しないバグの調査の進め方)。
「たまに」と言われたら、もう一歩だけ踏み込みます。「うまくいった時と、うまくいかなかった時で、何か違いはありましたか」。件数が多い時、月初、特定の取引先——本人は関係ないと思って言わなかったことに、答えが入っていることがあります。
⑥ どの画面・どのデータで起きましたか
場所を特定する質問です。画面名が通じないことも多いので、「メニューのどこから入る画面ですか」と聞くほうが早いです。
データが絡む不具合なら、具体的な1件を教えてもらいます。「受注番号でも、お客様名でも、1件だけ教えてください」。1件あれば、こちらでデータを直接確認できます。ここが埋まると、調査は一気に具体的になります。
⑦ いまその業務は止まっていますか。止まっているなら、どう回していますか
緊急度を測る質問です。そして、この記事でいちばん外してほしくない質問でもあります。
「動きがおかしい」の中には、いま業務が完全に止まっているものと、手作業でしのげているものが混ざっています。前者は改修ではなく障害対応の入口として扱い、第一報を出す判断が要ります。後者なら、落ち着いて調べる時間を確保できます。
「困っていますか」と聞かず、「いまどう回していますか」と聞くのがポイントです。人は遠慮して「大丈夫です」と答えがちですが、「いまは1件ずつ手で入力しています」という答えなら、実際の負担がそのまま見えます。
そのまま送れる確認メールの文面
電話で聞ききれなかったときや、相手が別拠点のときに使う形です。全部埋めてもらう前提にしないのがコツで、分かるところだけで返してもらいます。
ご連絡ありがとうございます。すぐ確認します。
調べる場所を絞りたいので、分かる範囲で教えてください。
埋まらない項目は「不明」で大丈夫です。
1. いつから:(例:今朝から/先週の火曜あたりから/ずっと)
2. 何をしたら:(例:受注一覧を開いて、検索ボタンを押した)
3. どうなった:(例:件数が0件になる/画面が真っ白のまま)
4. 画面表示:(メッセージがあれば文面、または画面の写真)
5. 他の方:(他の方でも起きる/その方だけ/未確認)
6. 頻度:(毎回/たまに)
7. いまの業務:(止まっている/手作業で対応中/急ぎではない)
写真は、画面全体が写っていれば十分です。
お手数ですが、よろしくお願いします。
「不明で大丈夫です」の一行を必ず入れてください。 これがないと、埋められない項目があるせいで返信そのものが止まります。返ってこない時間のほうが、空欄より痛いです。
なお、この形式が定着すると、次からは聞く前に書いてもらえるようになります。テンプレを渡すのは、こちらが楽をするためではなく、相手が伝えやすくなるためです。
具体例:実際のやりとりを1本たどってみる
ある日の午後、経理から内線が入ります。
「請求の画面、動きがおかしいんですけど」
ここで「どのへんがですか?」と返すと、たいてい「なんか、うまくいかなくて」で止まります。7つの質問から、①と②だけを使います。
「ありがとうございます、すぐ見ます。いつからそうなっていますか? それと、何をしようとしてどうなりましたか?」
返ってきたのは、こうでした。
「今日の午後からです。請求書のPDFを出そうとしたら、ボタンを押しても何も起きないんです」
これで、漠然とした「おかしい」が「今日の午後から、PDF出力ボタンが反応しない」に変わりました。ここまで30秒です。
続けて③④⑦を聞きます。
「画面に何か出ましたか。何も出なければ、それも教えてください」
→ 「何も出ません。押しても、しーんとしています」
「他の方でも同じですか」
→ 「隣の席でも試してもらったら、同じでした」
「いま業務は止まっていますか」
→ 「今日中に3件出せれば大丈夫です。夕方までは待てます」
この時点で、調べる場所は決まりました。 午後から・全員・画面にメッセージなし。端末側ではなくサーバー側の可能性が高く、緊急度は「今日中」。慌てて第一報を出す状況ではないことも分かりました。
サーバーのログを、午後の時間帯に絞って確認します(→大量ログからエラーを絞り込む)。PDF生成の処理が、一時ファイルの書き込みで失敗していました。原因は、ログの肥大でディスクの空きがなくなっていたことでした(→ディスク使用率100%を防ぐログローテーションと監視設定)。
不要なログを退避して復旧。質問に使ったのは合計2分、調査は20分でした。
もし質問を飛ばして、いきなりPDF出力のコードを読み始めていたら——おそらく、書き込み失敗という発想にたどり着くまでにかなりの時間がかかったはずです。「画面に何も出ない」「全員」「午後から」という3つの事実が、コードではなくサーバーの状態を見に行く根拠になりました。
そして最後に、経理の担当の方にこう伝えました。
「教えていただいた『今日の午後から』が決め手でした。ありがとうございます」
次からその方は、聞く前に「いつから」を書いて送ってくれるようになりました。 質問リストのいちばん良い副作用は、これかもしれません。
影響:質問リストを持つと何が変わるか
- 調べ始めるまでの時間が消える。どこから手を付けるか迷う時間が、7つの質問に置き換わります。迷いは減らせませんが、迷う対象を「調査方針」から「質問の順番」に移すことはできます。
- 総当たりの調査が減る。範囲(全員か個人か)と変化点(いつから)が決まるだけで、見る場所は大きく絞れます。
- 緊急度を取り違えなくなる。⑦を聞かずに全部を急ぎ扱いすると消耗します。逆に、止まっている業務を「あとで」にしてしまう事故も防げます。
- 仕様の相談と不具合を分けられる。「期待」を聞くと、実は仕様どおりだった、という話がその場で分かります。これは「相手の勘違い」ではなく、画面が伝えきれていないという情報です。
- 報告の質が上がっていく。テンプレを1回渡すと、次からは埋めて送られてくるようになります。こちらの手間が減るというより、相手の待ち時間が減ります。
- 記録がそのまま資産になる。7項目は、そのまま調査ログの見出しとして使えます。同じ問い合わせが再来したとき、過去の1件を引くだけで済みます。
数字でも見ておきます。問い合わせが週5件、うち3件が「動きがおかしい」型だとします。事実を集めずに調べ始めると、当たりを引くまでに平均30分かかったとして、週90分。質問に2分、調査20分に変わると、週66分。差は週24分、月に約1.6時間です。
派手な効果ではありません。ただ、この24分は「原因が分からないまま画面を見ている時間」なので、時間そのものより気持ちの消耗が大きい部類です。減る効果は、数字より体感のほうが先に来ます。
明日やること:紙1枚に7行だけ書く
準備は要りません。明日できる、いちばん小さな一歩はこれです。
- 付箋かメモ帳に、7つの質問を短く書く(「いつから/何をしたら/どうなった/画面/他の人/頻度/業務」の7語で十分です)。
- それを電話の見えるところに貼る。ディスプレイの端でも、机の隅でも構いません。
- 次に「動きがおかしい」と言われたら、上から2つだけ聞いてみる。全部聞かなくて大丈夫です。
- 聞いた内容を、そのまま7行のメモに残す。あとで調査ログに移せます。
- 相手が別拠点なら、上の確認メール文面をコピーして1回送ってみる。
1と2は、明日3分で終わります。 7つ全部を使いこなす必要はありません。「いつから」と「何をしたらどうなった」の2つだけでも、調べる場所はかなり絞れます。
いま抱えている調査中の案件にも、あとから聞いて構いません。「もう1点だけ確認させてください、いつからでしたか」は、途中でも普通に聞ける質問です。
「動きがおかしい」を受けたときのチェックリスト
コピーして、次の1件で当ててみてください。全部そろえる必要はありません。
まず外せない最低ラインはこの3つです。時間がなくても、ここだけは押さえます。
- 【最低ライン】「いつからそうなっていますか(前は正常でしたか)」を聞いたか
- 【最低ライン】「何をしようとして、どうなりましたか」を、操作の順に聞いたか
- 【最低ライン】「いま業務は止まっていますか/どう回していますか」で緊急度を確かめたか
次の項目は、余裕があるとき・より確実にしたいときに確認します。当てはまらなければ飛ばして大丈夫です。
- 「エラーは出ましたか」ではなく「画面に何か出ましたか。何も出なければそれも」と聞いたか
- 他の人でも起きるかを確認したか(未確認なら、隣の席で1回試してもらったか)
- 毎回か、たまにかを聞いたか
- 「たまに」なら、うまくいった時との違いを1つ聞いたか
- どの画面・どのデータかを、具体的な1件まで絞ったか
- 相手が「期待していた状態」を言葉にできているか(仕様どおりの可能性を先に潰したか)
- 変化点が分かったら、その時期の変更・リリース記録を先に見たか
- 調べ始める前に、原因の心当たりではなく症状を書き出したか
- 業務が止まっているなら、改修ではなく障害対応として扱ったか
- 聞いた7項目を、あとで引ける場所に残したか
- 相手に確認テンプレを渡すとき「不明で大丈夫です」を添えたか
- 教えてもらった情報のうち、決め手になったものを相手に伝え返したか
全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「いつから」さえ埋まっていれば、調べる場所はもう半分に減っています。
よければ、こちらも
質問で症状が固まったら、次は調査の手順に移ります。
- バグ報告から再現・原因特定までの最短ルート:症状が固まったあと、手元で再現させるまでの進め方です。
- 再現しないバグの調査の進め方|環境・タイミング依存を疑う:「たまに起きる」と言われたときの調べ方です。
- 曖昧な改修依頼の要件を引き出すヒアリングの型:不具合ではなく改修依頼が曖昧なときの聞き方です。
- 問い合わせ対応を「調査ログ」として残して資産にする方法:聞いた7項目を、次に効く形で残す方法です。
- 「サイトが重い」の切り分け手順:症状が「重い」だった場合の、調べる順番です。

「動きがおかしい」としか言われないのは、相手が不親切だからではありません。伝えるための言葉を、まだ一緒に作れていないだけです。
そして、その一言から調べ始めて、たいていちゃんと原因にたどり着いている。それは十分に難しい仕事を、毎回こなしているということだと思います。質問リストは、その難しさを少しだけ肩代わりしてくれる道具です。
明日は、7つ全部でなくて大丈夫です。「いつからですか」の一言だけ、次の電話で足してみましょう。それだけで、開くログの範囲は変わります。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。