問い合わせを受けて依頼される調査業務(以下、問い合わせ調査と呼びます)をしていて、「こういう情報があると調査が捗るな~」と思うことがあったので、記事として残しておきます。
問い合わせ元(ユーザー)→問い合わせ対応窓口→調査依頼元(開発・運用チームの窓口)→調査依頼先(開発・運用者、チーム)の流れを想定しています。
発生している事象・現状
発生している事象(主にバグ)です。
調査する人は問い合わせ元、問い合わせ対応窓口などとやりとりをしないため、それまでの経緯等を知らないことが多いです。
そのため、概要でいいのでどのような事象が発生して調査が必要になったのかを記載しましょう。
例:
発生事象:システム上でユーザーが見つからない
調査依頼内容
調査依頼内容(具体的に何を調べて欲しいのか)です。
調査依頼元の人の立場によっては、どこまで調査できるのかわからない場合もあるかと思います。
その場合も、調べてほしい情報を詳細に書いておけば、調査依頼先の人が調査可否を判断してくれるでしょう。
依頼内容が詳細でない場合、調査依頼元の人に対して認識に間違いがないか確認することになりますが、お互いの作業時間が奪われるので最初から詳細に書いておくのがいいと思います。
例:
調査依頼内容:
- 該当データ(詳細は判明している情報に記載)について、以下の点を調査してほしい
- 削除されているかどうか
- 削除日時(削除されている場合のみ)
- 削除したユーザー(削除されている場合のみ)
判明している情報
問い合わせ調査依頼時点で判明している、調査に有益な情報です。
調査における有益な情報とは、要するに「調査をする際に予め知っておきたい情報」のことです。
例えば、調査対象を特定できる、調査範囲を絞るための情報などが記載されていると、調査時の無駄な手間が省けます。
※情報の書き方によっては誤解を生んで余計に時間を消費するため、記載する情報は調査者に誤解を与えないように書くことを意識しましょう。
よくない例
判明している情報:
- 所属組織:~会社(システム上での登録名とは異なっている)
- 名前:~ (調査対象者ではなく、問い合わせ元ユーザーの名前を書いている)
- 作業日: 10月20日(時刻がわからないので、調査範囲が絞れない)
改善例:
判明している情報:
- 所属組織(~システム上の組織名): ~会社
- 問い合わせ元ユーザー名: ~
- 調査対象ユーザー名: ~
- 作業日時: 10月20日13時50分頃
関連する情報
問い合わせ調査に関連する情報です。
プロジェクト管理用のシステムを利用している場合、チケットのURLを記載しておくとこれまでの問い合わせの流れ(問い合わせ元→問い合わせ対応窓口→調査依頼の間)を確認できるので便利です。
例:
関連チケット:
- https://example.com/issues/1234
まとめ
以上の内容をまとめると、以下のようになります。
プロジェクトによって必要な情報・運用方法などは異なるので、自分のプロジェクトにあうように使い方を変えてください。
発生事象:
- システム上でユーザーが見つからない
調査依頼内容:
- 該当データ(詳細は判明している情報に記載)について、以下の点を調査してほしい
- 削除されているかどうか
- 削除日時(削除されている場合のみ)
- 削除したユーザー(削除されている場合のみ)
判明している情報:
- 所属組織(~システム上の組織名): ~会社
- 問い合わせ元ユーザー名: ~
- 調査対象ユーザー名: ~
- 作業日時: 10月20日13時50分頃
関連チケット:
- https://example.com/issues/1234