今回は私がテクニカルサポートエンジニアを合計で8年強の間経験した中で感じたポイントやノウハウから、最速でテクニカルサポートから自分の求める回答を得る方法について記載していきたいと思います。 なるべく様々な場所で使えるような内容で記載します。
※個人の意見ですので、所属する会社とは関係ありません。
私のLinkedIn はこちら。もしよければ友達リクエストいただけると幸いです。
本稿でお伝えしたいこと
本稿では、問い合わせ時に自分がほしい回答を最速でテクニカルサポートから得るための考え方や流れについて記載していきます。
ITに携わる方は、仕事を遂行する中でテクニカルサポートに問い合わせを行ったことがあるのではないでしょうか。ベンダーに問い合わせることもあるでしょうし、システム屋さん（SIerさん）に問い合わせることもあると思います。
テクニカルサポートには大きく3種類（個人的な分類）の問い合わせが舞い込んできますので、今回は障害対応編としてユースケースを例にご説明していきます。
- 障害対応（故障して動かない、サービスの停止、業務に支障が出ている）
- Q&A（動作仕様の確認、手順の確認）
- 手順の確認（Q&Aと似ているが、やりたいことをする前に確認しておきたい等）
よくある問い合わせ例
- モニタ－が故障したから修理窓口に問い合わせる
- サーバーベンダーにサーバーの修理を依頼する
- ディスクの故障でOSが起動しなくなったので、サポートに問い合わせる
- OSに接続できないため、復旧方法についてサポートに問い合わせる
- データベースのパフォーマンスが高負荷であるためサポートに問い合わせる
例：OSに接続できないため、復旧方法についてサポートに問い合わせる
最速でテクニカルサポートから回答を得るには、やり取りの回数を最小にする必要があります。
メール、電話、チャット、いずれにしても最小回数を目指すことを意識することが重要です。
では、どのようにすると最小回数になるのか、ダメな例とイイ例から解説していきます。
ダメな問い合わせ例(107文字)
OSに接続できません。昨日までは使えていたのですが、今日の朝確認したところ接続できなくなっていました。
復旧方法と原因について教えてください。業務に支障が出ているため、急いでいます。
よろしくお願いします。
イイ問い合わせ例(230文字)
Microsot Azure 上の VMとして稼働中の Windows Server 2022 （VM名：ABC）にオフィスのPCからリモートデスクトップ接続できません。昨日の業務終了前 18:00 までは接続できていましたが、今朝9：00 に接続を試みたところ、エラーコードXXXX というメッセージが表示され、接続が出来ない状態です。
このサーバーは経費精算システムとして250名が利用中であり、業務に支障がでております。
復旧したいため、本日の午後14：00頃までに一時見解を頂けるでしょうか。
ここまでご覧頂いて、どう思われたでしょうか。
文字数にして、107文字と230文字 と約2倍の文字数でありながら、5倍、いや、10倍くらいの情報量がありそうではないでしょうか。
情報量の差で、問い合わせ回数が数倍変わります。
ココで意識して記載している事項はこちらです。
- どこで何が起こっているのかを正確に記載する
- 経緯を時系列の順に説明する
- 定量的な数字・時間を可能な限り記載する
- 何を達成したいのか明確に記載する
どこで何が起こっているのかを正確に記載する
ダメな例では「OSに接続できません」と記載されていましたが、イイ例では「Microsot Azure 上の VMとして稼働中の Windows Server 2022 （VM名：ABC）にオフィスのPCからリモートデスクトップ接続できません。」と記載されています。どこのVM（Azure上）、どこからの接続（オフィスのPC）、どの環境（VM名：ABC）ということが記載されています。
これだけの記載があるだけでも、サポートエンジニアは「この症状だから◯◯のログが必要だな」と推測することができます。
経緯を時系列の順に説明する
トラブルシューティングの観点で時系列は大変重要です。
いい例では、「業務終了前 18:00 までは接続できていましたが、今朝9：00 に接続を試みた」と記載されています。
この記載があると、サポートエンジニアは、膨大なログから日時を絞って早期に調査することができます。
具体的な数字・時間を可能な限り記載する
ダメな例では「業務に支障が出ている」とだけ記載されていますが、イイ例では「このサーバーは経費精算システムとして250名が利用中であり、業務に支障がでております。」と記載しています。
具体的な利用者数や利用目的がわかることで、ビジネスインパクトを推測することができます。
何を達成したいのか明確に記載する
ダメな例では「復旧方法と原因について教えてください。」と記載されています。
これ、皆様よく使ってしまっていないでしょうか！？
問題が発生中（現在進行系）のときに、先に原因について確認しようとする方が多くいます。
しかしそれは、最速で回答（対応策）を得ることから遠回りをしています。
場合によっては原因を先に知りたい場合もあるかもしれませんが、
障害対応において、最も優先すべきは 復旧 です。復旧後に 原因究明 するのです。
想像してみてください。火事が起こっている家を現場で見ながら、原因は何なのか…と考えるでしょうか。誰でも先に消火すると思います。ITの現場になると突然、復旧と原因究明が混ざってしまい、優先順位が曖昧になってしまい、最短ルートから遠のきます。
細かい話は生成AIや検索エンジンにお任せしたいとおもいますが、IT運用管理のベストプラクティスや業界標準のお話が出たときは、ITIL（Information Technology Infrastructure Library）が指標になることが多いですが、その中で、障害対応の原因究明と復旧は完全に別で管理することになっています。復旧を優先するのか、原因究明するのか、明確することが重要です。
いい例では、「復旧したい」と明確にかかれていますね。
まとめ
みなさまお忙しい中、問い合わせるのは非常に面倒なことだと思います。
面倒であるがゆえに、初回問い合わせの際にはテキトーに書いてしまうかもしれません。
（お気持ちすごくわかります）
一方で、それが理由でテクニカルサポートと何度も何度もやり取りが発生してしまい、
逆に時間がかかって貴重な時間を消費してしまうことになります。
何か問い合わせをする際には、どこでも使える考え方、意識ですので、少しでも実践いただけると幸いです。
補足)
このような内容はAWS様公式の問い合わせガイドラインが有名ですが、すこし具体例使ってご説明しました。
Tomoya@MS
Discussion