主にこんな方向け
開発に問い合わせをすることがあるコンサルやサポートセンターの方向けの記事です。
問い合わせの際にどこがポイントになるのか
よくある開発への問い合わせの際に意図しない形で返答がされることはないでしょうか。
例えば、
・質問していることに質問で返されたり
・急いでいるのにデータを取得依頼されたり
・全く期限を守ってくれなかったり
・思っていたのとは違っていた返答が来たり
問い合わせる側が抑えるべきポイントをまとめます。
ここで記載するのはあくまで理想論です。
必ずこの通りになるとは限りませんが、もしかすると意識すると今よりもよくなるかもしれません。
初回の時点で提供可能な情報を伝える
たまにある 僕が考える最低な問い合わせ の一例
お客様環境でエラーが発生しました。
調査お願いします。
これは開発側からすると何が起こっているのかまったくもってわかりません。
そもそも調査するための情報が何もないのです。
一つ情報を足してみましょう
お客様環境で○○画面でエラーが発生しました。
調査お願いします。
これでどの画面で起きたかわかりました。
ただし、これでは全く十分ではありません。
問い合わせ文を書いてみましょう
××様の検証環境で
本日(2023/02/28)の10:05頃、△△ユーザーでログインした状態で
○○画面で「CSV出力」ボタンを押したところエラーが発生しました。
エラーが発生した際の画面キャプチャとログを取得しましたので、調査お願いします。
これぐらい書いてあると何がわかるでしょうか。
初回の時点で提供可能な情報を伝えることでできるようになること
- ××様の検証環境で発生したこと
- 2023/02/28 10:05頃に発生したこと
- △△というユーザーログインし操作をしていること
- ○○画面で「CSV出力」を押したタイミングで発生したこと
- キャプチャが取得できていること
- ログが取得できていること
5W1Hにある程度沿った情報が提供されていることで開発側としては調査を始めることができそうですね。
もちろんこれがすべてではないと思いますし、必要な情報があれば開発側からさらにデータの取得等の依頼をされることはあると思います。
ただし、この初動での情報がなければ上記のような情報の取得を依頼する必要がありますし、レスポンスタイムもかかり結果回答に時間がかかることになります。
いつまでに回答がもらえればいいかを伝える
上段で開発側にはある程度の情報が得られたので調査を始めます。
ただし、いつと指定されていないので開発は「検証環境で起きている問題だし、code freezeの後に見るか...」と思うかもしれません。
実は問い合わせている側には このエラーで検証のスケジュールがすでに押している という状況があったとします。
いつ期限なのか、それがどういった理由であるかを伝える
[事象]
××様の検証環境で
本日(2023/02/28)の10:05頃、△△ユーザーでログインした状態で
○○画面で「CSV出力」ボタンを押したところエラーが発生しました。
エラーが発生した際の画面キャプチャとログを取得しましたので、調査お願いします。
[期限]
現在、お客様の環境で検証を進めています。
このエラーが原因で次の検証に進めず、現状すでに一週間の遅れが出ています。
来週の朝の10時までに回答をいただけますでしょうか。
いつまでに回答がもらえればいいかを伝えることでできるようになること
これで開発はいつまでに調査をしなければいけないか把握することができます。
「来週の朝10時までに回答しないといけない」という状況になるので、タスクの優先順位を変更して優先で対応してくれる(かも)と思います。
何ができればゴールなのかを具体的に伝える
開発が調査した結果、エラーは不具合でした。なので開発は不具合でしたと答えます。
問い合わせた側としては当然こう思います「いや、そうじゃない」。
何をゴールとしているのかを伝える
[事象]
××様の検証環境で
本日(2023/02/28)の10:05頃、△△ユーザーでログインした状態で
○○画面で「CSV出力」ボタンを押したところエラーが発生しました。
エラーが発生した際の画面キャプチャとログを取得しましたので、調査お願いします。
[期限]
現在、お客様の環境で検証を進めています。
このエラーが原因で次の検証に進めず、現状すでに一週間の遅れが出ています。
来週の朝の10時までに回答をいただけますでしょうか。
[ゴール]
○○画面から、CSVを出力した結果と移行元のシステムから出力したCSVのデータに差異がないか比較をするために○○画面からCSVの取得したい。
○○画面で出すことができない場合、可能であれば何か代替の方法等ご提案いただけますと幸いです。
何ができればゴールなのかを具体的に伝えることでできること
調査の結果CSVの出力でエラーになることが不具合とわかりました。
よって、○○画面からのCSVの出力はできません。
ただしCSVの出力ロジックをたどり、ロジックでSQLを作成し、それをお客様の環境のDBに流します。
その結果は○○画面で取ったCSVと同じになると思います。
ということで「○○画面の「CSV」出力でのエラー」自体は解消できませんでしたが、本来果たすべきの目的である「移行元のシステムとのデータの比較」は実現できます。
まとめ
これはあくまでも理想論です。
でも上記の例であれば最初の問い合わせではもしかするとデータの取得で月曜日の朝10時を迎えていたかもしれない状態からかなりの改善が見られたのではないでしょうか。
上記の例では代替案があるケースを記載していますが、当然ないケースもあります。
しかし早い段階で次のアクションへの相談などに移れるので悪いことはないと思います。
少しの手間で、意図した回答をもらえるようにできるように工夫していきましょう。