「受注検索で0件になります。見てもらえますか」
問い合わせがこの一文だけで届くことがあります。急いでログを開いても、誰が、いつ、どの条件で検索したのかが分からなければ、確認範囲は広がるばかりです。利用者へ聞き返し、返答を待ち、もう一度ログを探す。この往復で半日が過ぎることも珍しくありません。
問い合わせを受けた直後に集める情報を決めておくと、調査はかなり進めやすくなります。大切なのは長い報告書を最初から求めることではなく、ログと対象データをたどれる最小限の材料をそろえることです。
最初に確認するのは、利用者、発生時刻、画面・機能、操作、対象データ、表示内容、影響範囲の7項目です。情報が一つ欠けても、調査不能になるとは限りません。ただし、欠けたまま再起動や再実行をすると、原因を追う手掛かりを失うことがあります。
この記事では、受注検索で一部の利用者だけ0件になるケースを例に、問い合わせを調査可能な記録へ変える流れを扱います。SQLはOracleでも読み替えやすい形にしています。
問い合わせを受けた直後に確認する7つの情報
誰が困っているか
利用者ID、氏名、所属だけでなく、同じ操作をする別の利用者がいるかを確認します。受注検索で0件になる場合、利用者本人の操作ミスだけでなく、権限や所属コードによる絞り込みが影響しているかもしれません。
「営業一課の田中さん」と聞いたら、調査メモにはuser_id: tanaka01のように、システム上で検索できる識別子を残します。氏名だけでは、ログのLOGIN_IDや監査テーブルの更新者と結び付きません。
tomo利用者の連絡先だけを残し、ログにあるユーザーIDを確認しなかったため、同姓の別アカウントを追ってしまうことがあります。調査の入口では、表示名よりログに出るIDが役立ちます。
いつ発生したか
「さっき」「午前中」は、ログを探す条件としては広すぎます。少なくとも発生日時を分単位で聞き、分からなければ最後に正常だった時刻を取ります。
たとえば「7月31日10時12分ごろに検索した。10時05分には同じ条件で表示された」と分かれば、アプリケーションログ、DB監査ログ、ジョブ実行履歴を10時05分から10時12分へ絞れます。
問い合わせを受けた直後に再実行する前に、時刻を確認します 再実行でログが上書きされる、画面上のエラーが消える、対象データの状態が変わることがあるためです。
どの画面・機能で起きたか
「受注の画面」ではなく、メニュー名、画面名、URL、帳票名、バッチ名のいずれかを取ります。同じ受注を扱う画面でも、受注一覧、受注検索、出荷指示、請求対象抽出では、参照するテーブルや権限判定が違います。
画面名を利用者が分からないときは、スクリーンショットを一枚もらうのが早い方法です。ブラウザのアドレスや見出し、検索条件、エラー表示を同時に確認できます。個人情報や取引先情報が写る場合は、共有先を限定し、必要な箇所だけ隠してもらいます。
どの操作の直後に起きたか
検索ボタンを押した直後なのか、一覧を開き直したときなのか、CSV取込後なのかで、見るべき処理が変わります。操作手順は「受注検索を開く」だけで終わらせず、検索条件を含めます。
次のように、操作と条件を一続きで残すと再現しやすくなります。
1. 受注検索を開く
2. 受注日を 2026-07-31 に指定する
3. 営業担当を「自分」に指定する
4. 検索を押す
5. 件数が0件と表示される操作を聞く目的は、利用者の誤りを探すことではありません。 システムがどの条件で処理されたかを、担当者が同じ条件で確認できるようにするためです。
何のデータが対象か
受注番号、顧客コード、CSVファイル名、処理対象日など、データを一意に絞る値を集めます。今回の例なら、表示されるはずだった受注番号を一つ聞きます。
「A社の受注」という情報では、同じ日に複数件あるかもしれません。SO-20260731-0142のような受注番号が分かれば、検索条件とデータ実体を照合できます。個人情報を含む値をチケットへ貼る必要がある場合は、社内規定に沿ったマスキングとアクセス制御が前提です。
画面に何が表示されたか
エラーコード、メッセージ、0件表示、処理中のまま進まない状態を、そのまま残します。「エラーになった」という言い換えだけでは、警告表示とシステム例外を区別できません。
画面に表示された文言が短くても、ログ側の例外名と一致することがあります。スクリーンショットを依頼する際は、検索条件と結果件数が一緒に写る範囲を指定します。エラーだけを切り取ると、何を実行した結果なのかが分からなくなります。
どこまで影響しているか
本人だけか、同じ部署か、全利用者か。さらに、検索できないことで受注登録、出荷、請求などの後続業務が止まるかを確認します。
この情報は、原因調査とは別に優先度を決める材料です。全社で検索できないなら一次対応を急ぎます。一人だけで、回避手段があるなら、ログ保全と事実確認を優先できます。影響範囲が不明なまま「障害ではない」と判断しないことが重要です
情報不足の問い合わせを調査可能な形にする
聞き返しは一度で済む形にする
問い合わせへの返答を、質問一つずつに分けると往復が増えます。確認したい項目をまとめて、相手が答えやすい順に並べます。
確認のため、次の内容を教えてください。
- 発生した日時、または最後に正常だった日時
- 操作した画面名と、検索時に指定した条件
- 表示されるはずだった受注番号
- 画面に出たメッセージ、または検索結果が分かる画面
- 同じ操作をした他の方にも起きているか
可能であれば、画面を閉じたり検索をやり直したりする前にご連絡ください。依頼文は丁寧でも、長すぎると必要な情報が返ってきません。問い合わせ内容から分かっている項目は質問から外し、未知の項目だけを聞きます。
tomo「画面のスクリーンショットをください」だけでは、検索条件が見えないことがあります。結果一覧と条件欄が同じ画面にあるなら、その範囲を指定した方が調査に使えます。
申告、確認済み、推定を分けて残す
調査メモに「権限不備のため検索できない」と書くと、それが利用者の申告なのか、ログで確認した事実なのか分からなくなります。メモは少なくとも三つに分けます。
| 区分 | 記録例 | 扱い |
|---|---|---|
| 申告 | 田中さんは10:12ごろ、受注検索が0件と申告 | まだ事実と決めない |
| 確認済み | 10:12:14の検索ログで user_id=tanaka01、result_count=0 | ログやDBで裏付ける |
| 推定 | 営業担当の所属コードが未設定の可能性 | 次の確認事項として扱う |
この分け方があると、途中で担当交代しても、どこまで確認済みかが伝わります。推定は消さずに「推定」と書くことで、同じ確認を繰り返すことも減ります。
再起動・再実行の前に残すもの
再起動、再実行、データ修正は、復旧には役立っても原因調査の証跡を変えてしまう場合があります。最初に、画面、発生時刻、対象データ、アプリケーションログ、ジョブ実行履歴を確保します。
特に一時ファイルや短期間でローテーションするログは、後回しにしない方が安全です。復旧を急ぐ必要がある場合も、誰が何時にどの操作をしたかを時系列で残します。国土交通省の障害対応に関する資料でも、復旧前のログやデータの保全が必要で、復旧作業により証跡が失われる可能性が示されています。
受注検索の0件を例に初動調査を進める
問い合わせから見えてきた条件
保守対応では、「昨日まで見えていた受注が、今日だけ0件」という連絡が入りがちです。ここでは、営業担当者が受注検索を実行したところ、件数が0件になったケースを追います。
最初の連絡だけでは「検索できない」でしたが、聞き返して次の情報がそろいました。
| 項目 | 確認できた内容 |
|---|---|
| 利用者 | user_id: tanaka01、営業一課 |
| 発生時刻 | 2026-07-31 10:12ごろ |
| 画面 | 受注検索 |
| 操作 | 受注日を7月31日、営業担当を「自分」に指定 |
| 対象データ | 受注番号 SO-20260731-0142 |
| 表示内容 | エラーなし、検索結果0件 |
| 影響範囲 | 同じ部署の別ユーザーでは検索できる |
ここまで分かると、全件を返す検索SQLやDB停止を疑う前に、利用者と所属に関係する条件を優先できます。
アプリケーションログを時刻と利用者で絞る
検索ログに利用者ID、検索条件、結果件数を残している場合は、発生時刻の前後を確認します。
2026-07-31 10:12:14 INFO order-search
user_id=tanaka01 department_id=SALES-01
order_date=2026-07-31 result_count=0この一行だけで原因は決まりません。ただし、検索要求がアプリケーションへ届いていること、department_id=SALES-01が条件へ渡っていること、結果が0件だったことは確認できます。
ログがない場合は、Webサーバーのアクセスログ、画面の操作履歴、DBの監査ログの順に、時刻と利用者IDで追います。「ログがない」と結論づける前に、どの層に何のログがあるかを確認します。
SQLで対象受注と利用者の条件を照合する
対象の受注が存在するか、どの営業担当・所属で登録されているかを確認します。テーブル名と列名は、実システムに合わせて読み替えてください。
SELECT
o.order_no,
o.order_date,
o.sales_user_id,
u.department_id,
o.status
FROM
orders o
INNER JOIN users u
ON u.user_id = o.sales_user_id
WHERE
o.order_no = 'SO-20260731-0142';結果が次のようなら、受注そのものは存在し、営業担当の所属コードだけが利用者と一致していない可能性があります。
order_no | order_date | sales_user_id | department_id | status
SO-20260731-0142 | 2026-07-31 | suzuki02 | SALES-02 | OPENここで「データが別部署だから問題なし」とは決めません。担当変更の登録漏れなのか、利用者の検索条件に本来含めるべき受注なのか、仕様と業務上の事実を確認します。
本番DBで調査用SQLを実行するときは、更新SQLを混ぜません。検索条件を十分に絞ったSELECTから始め、取得結果に個人情報や取引先情報が含まれる場合は共有範囲を限定します。
調査メモを時系列で残す
最初の15分を記録する
調査メモは、後で清書するものではありません。問い合わせを受けたときから、時刻つきで短く残します。次の例では、申告、確認、依頼、推定が混ざらないようにしています。
10:18 申告受領
受注検索で0件。利用者は tanaka01。
10:22 確認済み
発生は10:12ごろ。対象受注は SO-20260731-0142。
他の営業担当者では同じ受注を検索できる。
10:27 確認済み
検索ログに tanaka01 の実行記録あり。result_count=0。
10:31 推定
受注の営業担当または所属コードが検索条件と一致しない可能性。
10:35 次の確認
受注の営業担当変更履歴と、検索画面の所属条件を確認する。この形式なら、10時31分の内容が確定事項ではないと一目で分かります。障害連絡の途中で状況が変わっても、古い推定を事実として伝える事故を防げます。
連絡文と調査メモを分ける
利用者へ返す文章には、調査中の仮説をそのまま書かない方がよい場面があります。「所属コードの登録ミスかもしれません」と先に伝えると、まだ確認していないのに原因が確定したように受け取られます。
利用者には「対象受注と検索条件を確認しています。確認でき次第、結果を連絡します」と伝えます。一方、調査メモには「所属コードの不一致を確認する」と残します。外向けの連絡と内部の作業メモは、目的が違います。
tomo調査メモに仮説を書いておくと、次にログを見る人が迷いません。外へ出す文章に仮説を混ぜないだけで、対応の説明はかなり落ち着きます。
対応後に残すべき結論
解決したら「直りました」だけで閉じず、原因、影響範囲、対応、再発時の確認先を残します。今回なら、営業担当変更時に所属コードが更新されず、検索条件から外れていたことが原因だった、といった形です。
原因が未確定のまま回避策だけを入れた場合も、その事実を残します。たとえば、受注の担当を一時的に修正して検索できるようにしたが、なぜ同期漏れが起きたかは調査継続中、という記録です。復旧と原因確定を同じ言葉で扱わないことが、後の再発調査に効きます
問い合わせを受ける側で整えておく運用
チャットやチケットの入力欄を先に用意する
毎回ゼロから聞き返さないために、問い合わせ用のテンプレートへ7項目を入れます。必須入力にしすぎると、緊急時に連絡しづらくなります。まずは、分かる範囲で記入してもらい、保守側が不足分を補う運用が現実的です。
【発生日時】
【利用者ID】
【画面・機能】
【操作と条件】
【対象データ】
【画面表示・エラー】
【影響範囲・業務への影響】この項目は、障害時だけでなく、帳票の数値差異やCSV取込エラーの問い合わせにも使えます。対象データがファイルならファイル名、画面なら受注番号のように、対象を特定する値だけ置き換えます。
ログの項目と保存期間を確認する
問い合わせのたびに「ログに利用者IDがない」「時刻が別タイムゾーンだった」と分かると、調査は遅れます。アプリケーションログに、処理日時、利用者ID、リクエストID、対象データID、処理結果を残せているかを確認します。
すべての入力値をログへ出す必要はありません。むしろ、パスワード、個人情報、トークンを出さない設計が必要です。調査に必要な識別子を決め、保存期間と閲覧権限を運用で確認します。ログは出ていればよいのではなく、問い合わせからたどれる形で残っているかが重要です。
調査完了の判断を共有する
調査が終わったと判断する基準も、チームでそろえておきます。少なくとも、次の三点を確認できれば、問い合わせを閉じる根拠になります。
| 確認すること | 今回の例 | 残すもの |
|---|---|---|
| 現象を説明できる | 所属条件により対象受注が検索から外れた | 原因と確認結果 |
| 利用者が業務を続けられる | 担当・所属の修正後に検索できた | 復旧確認の時刻 |
| 再発時に追える | 担当変更処理とログ確認箇所が分かる | 改修・運用の対応先 |
一人の利用者だけに起きた問い合わせでも、担当変更や権限更新の共通処理に原因があれば、同じ問題が他の利用者へ広がる可能性があります。修正する場合は、同じ条件を持つデータがほかにないか確認し、対象範囲と確認結果を残します。
問い合わせ調査の最初に必要なのは、完璧な原因分析ではありません。発生時刻、利用者、画面、操作、対象データ、画面表示、影響範囲をそろえ、事実と推定を分けて記録することです。これだけで、ログ確認、SQL調査、利用者への説明を同じ線で進められます。
