本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Microsoftのサポートに10年以上質問し続けているエンジニアが明かす、サポートに聞く時のコツ！」を再編集したものです。
この記事はFIXER Advent Calendar 202312月6日の記事です。
こんにちは。FIXERの花野です。
「Microsoftのサポートに10年以上……」まで読んで、「おっ、サポートの中の人か」と思ってクリックした人、ごめんなさい。当方、サポートに聞く側です。
技術的に詰まった時、みなさんはどう解決していますか。公式ドキュメントを眺めたり手を動かしたり世の中の技術ブログを見たり。
私はサポートに問い合わせることが多いです。なぜならプロジェクトで使うためには（プロジェクトにもよりますが）「裏付け」が必要であり、公式ドキュメントや公式サポートの見解がその根拠となるためです。
こうしてずっとサポートに聞いていると、なんとなく自分なりのコツみたいなものが見えて来たので共有します。今回は私が一番お世話になっているAzureサポートをイメージして書いていますが、もちろん他の色々なサポートに聞く時も応用できると思います。
……なんて記事を執筆していると、つい10日ほど前にJapan Azure IaaS Core Support Blogさんで「お問い合わせの発行方法について」という記事が発行されました。なんでや。被るにしてもタイミングぴったりすぎやないか。気が合うなあ。
Japan Azure IaaS Core Support Blogさんの記事は全体が網羅されているので、まずはご一読いただくとして、私の記事ではその中でも「説明」欄を書く時と、その後のやりとりで気を付けている点を共有します。
問い合わせ発行時に気を付けること
合言葉：「言ってくれなきゃわかんないよ」
こちら座右の銘なのですが、当然ながらサポートの方は問い合わせ側の状況を知りません。
そのため、必要な回答を最短で得られるように、前提情報を漏れなくかつかつノイズなく共有することを心掛けています。
プロジェクトの状況や制約など
運用中の環境か、開発中の環境か、などを記載します。プロジェクトの事情でなんらかの制約がある場合、予め伝えておくことで欲しい回答にたどり着くスピードが速くなることが期待されます。
何をしようとしていて、何に困っているか
ポイントは、自分がどこまでやったのかを伝える点です。
たまにあるあるなのが「このURLを見てください」だけ返信が来て、「それはもう見た！」ってなるやつです。この無駄な一往復を削減するために、下記のように具体的に伝えるようにしています。
・XX（URL）を見たがXXの点についてよく分からない。もう少し詳しくXXする方法や注意点等知りたい。
・XXの環境でXXを実現したくて、XXを行った。しかし結果はXXだった。XXをする方法を知りたい。
・調査したところ、XXの状態になっていた。XXになっていた原因を知りたい。
技術的な情報を提供して欲しい場合は、その情報提供の前提となる情報を共有する必要があります。何を共有すべきかについては切り分けが必要なため、けっこう慣れが必要かもしれません。
個人的には資格試験の問題を作るような気分で文章を書いています。「あなたはfabrikamの管理者です。XXの環境でXXしたいのですがXXに困っています。XXをするにはどうしたらいいですか」といった感じです。これにより、回答に必要な前提条件の収取選択がしやすいような気がします。
何をゴールとするか
前段とも通じますが、何を達成できればこのサポートはクローズできるかを記載します。
・XXの情報を知りたい
・XXを実現する方法を知りたい
・XXを実現する方法が知りたいが、もしも無理ならYYを実現するなど、要件を達成する方法を知りたい、など
対象のリソース情報
一応、Azureの問い合わせではフォーム内にリソース情報を書く欄があるのですが、そこに書いてもその後のやりとりで対象リソースを聞かれることが度々あったので（なぜ？）、無駄な一往復を省くため、とりあえず対象リソースを本文中に書くようにしています。
また、関連リソースが複数ある場合も本文中に記載します。その際は、リソースの種類や用途ごとに分けたり、通信の流れ順に記載するなどして分かりやすいようにしておきます。
■Front Door - ＜リソースIDを記載＞ ■XX機能用 App Service - ＜リソースIDを記載＞ ■XX機能用 App Service - ＜リソースIDを記載＞
期限やその背景
プロジェクト的に何かしらの締切がある場合は、予め伝えておくことで、サポートの方も意識して動いてくださいます。期限までに回答を用意できない場合も、進捗状況を共有くださったりするため助かります。
・XXに打合せがあるので、できればXXまでに回答が欲しい
全体的なコツなど
問い合わせはなるべく早めに発行する
Microsoftのサポートに重大度Bで問い合わせた場合、契約や問い合わせ内容にもよりますが、体感的に回答は早くても一営業日、だいたいは数営業日程度かかることが多いような気がします。少し込み入った内容になると一週間以上かかる場合もあります。
また、通常は日本Microsoft内で処理されるようですが、内容によっては本国の開発部にエスカレーションされる場合もあります。こうなると、さらに回答に時間がかかります。
上記をふまえた上で、問い合わせは早めに発行しておくことをお勧めします。
一問一答
契約にもよりますが、基本的には一問一答をイメージして質問を組み立てるようにしています。これにより、自分の中で問題の切り分けがなされ、内容が整理されます。
もっとも、内容が関連する事項については、共通の前提情報を書いた上で、下記を教えてくださいと箇条書きで質問を複数書いてしまう場合もあります。あまりにもテーマから外れていない場合は、だいたいは対応いただけますし、別チケットの起票を案内されたらおとなしく従いましょう。
電話やTeamsを活用する
サポートの方とのやり取りにおいてはフォーム入力やメールのやり取りでじゅうぶんな場合も多々あるのですが、状況に応じて電話やTeamsを活用しています。私は下記のように使うことが多いです。
・前提条件やゴールなどを文章だけでは伝えきれない場合に、担当挨拶のメールが届いた後に電話して、伝えたい内容を共有する
・回答のメールが届いた後に電話して、メールの内容に関して満足するまで根掘り葉掘り質問する
・トラブルシュート時にTeams会議を開き、こちらが調査したことを画面共有しながら相談する
・回答に時間がかかっている場合に電話して、状況をうかがう
・うまくこちらの意図が伝わっておらず、方向がずれていそうな場合に電話して、軌道修正を行う
サポートの方にも、できることとできないことがある
サポートの方はいつも全力を尽くしてくださいますが、場合によっては欲しいものが返ってこない場合があります。
例えば、セキュリティーに関する詳細な仕様の質問やデータセンターの中身に関することなどは、セキュリティー上、教えてもらえないことが多いです。製品の仕様上、こちらが実現したい事柄が実現できないことが分かる場合もあります。
このような場合、できないことを言ってもしょうがないので、お願いできることを最大限お願いする感じで動いています。
みなさんもわざわざサポートを発行して調査するからには、何かしらプロジェクトで実現したいことがあるはずです。プロジェクトにおいて、何も情報がない上で「決めて」は無理ですが、サポートからの回答という情報があれば、それはそれで何かしらを決める判断材料になります。迷路の行き止まりを潰すイメージと言いますか。
ですので「XXする方法を教えて」に対して「できない」という回答が来た場合は、その背景を理解したり代替案を探ったりして、プロジェクト内で納得行くように進められる情報を集めるようにしています。
ゴールを見失わない
前段の項目を進めていると、内容が元々の質問から外れてきてしまう場合もあります。今聞いている内容が元の質問と地続きなのか、別途区切って問い合わせを発行した方がいいのかはこまめに見直して、状況を見失わないように気を付けています。
別の問い合わせを発行した方がいいのかどうか迷った場合は、サポートの方に相談するとよいかと思います。
ただ、何が知りたいか、何が分かったらゴールとできるかは、自分しか分からないので、そこは常に（必要に応じてプロジェクト内に相談しつつ）自分で決めた上で、はっきりとサポートの方に提示しておくのを心掛けています。
基本的にはサポートの方は親切な人が多い
主観ですが、サポートの方々は親切ですし、人の役に立ちたく、技術について伝えたい方が多いように感じます。
技術に詳しそうなサポートの方を見付けたら、電話で色々教えていただいたりして、大変お世話になっています。
また、分からない時は普通に「すみません、ここ、あまり詳しくないのですが」と正直に申告するようにしています。すると、なんと、うまくこちらにレベルを合わせて説明してくださるので、なんか分かったような気になります！ ただ、あまりにも分からなすぎるのもどうかと思うので、それぞれ自己研鑽は積むようにしましょう。暮らしの中に修行あり！
ゴールを達成できたらお礼と共に「クローズお願いします」と伝える
先方も仕事なので、こちらが「クローズお願いします」を伝え損ねた場合、何度か状況確認のメールが来て大変申し訳ない感じになります。うむやむに終わった問い合わせの担当者様が別の問い合わせでまた付いて（先方は気にしてないでしょうが）、こちらが気まずい気分になったりするのもあるあるなので、お互い気持ちよく「クローズ」で終わるようにしています。
アンケートに答える
「クローズお願いします」の合意の後、自動で送られてくるクローズメールの中に、アンケートへのリンクが入っています。日本人は性格的に（？）あまり満点をつけないらしいのですが、私は基本的に満点をつけるようにしています。
問い合わせ一覧を管理する
問い合わせのやり取りは全てメールに残っているのですが、時間が経つと意外と検索でも探し出せなかったり、下手したら存在自体を忘れていたりします。
そのため自分が発行した問い合わせを、発行日、番号、件名、クローズしたかのチェックで一覧管理しています。こうしておくと番号でメールを一発で検索できるので便利です（組織で管理するツールもあるのですが、それとは別に、あくまでも個人の記憶に紐付いたメモとして使っています）。
番外編：重大度Aの時
重大度Aの場合は、スピードが最優先となります。
そのため、まずは端的に「XXという事象が発生しました。運用中の環境のため、早急な解決をお願いします」など最低限の内容を書いてとりあえず問い合わせを発行するようにしています。
Microsoft内で問い合わせを受け付け後、内容確認や担当者の割り当て等が発生するため、担当者の方から連絡が来るまで30分～1時間程度のタイムラグが発生します。詳細はこの待ち時間中にまとめて、整い次第共有しています。
最後に
製品の情報や、細かい仕様や、極めてレア度が高くて下手したらどこにも公開されていない情報を提供してくださる最後の砦、サポートさん！ いつもお世話になっています。
この記事を読んだみなさんがサポートをよりよく活用できるようになると嬉しいです。
花野恵子／FIXER
うっかりものです。
