この記事は Microsoft Azure Tech Advent Calendar 2024 の 11 日目の記事 です。
こんにちは、アーキテクトのやまぱんです。
今回は私の経験をもとに、こうすればもっとテクニカルサポートがうまくつかえるんじゃないか？ っていう事を書きたいと思います。
テクニカルサポートが対応する問い合わせ、つまり SR (Support Request) は大きく、「障害発生系のトラブルシューティングケース」と「やりかた・使い方のHow to 系」のケースに大きく大別されます。
今回は主に後者の 「How to 系のケース」 にフォーカスしていきたいと思います。
またあくまで個人の意見ですので、その点ご了承ください。
モチベ
私はマイクロソフトでテクニカルサポートを 3 年弱、その後プロフェッショナルサービスとして 2 年ほど働いています。またマイクロソフト入社前には SIer として IT ベンダーに SR を上げる側の立場でした。
その経験のなかで How to 系のケースにおいては「SR、つまりテクニカルサポートをもっと活用することで解決できることもあるのになー」と思うことがよくあります。
今回はわたしなりに、How to ケースにおいてテクニカルサポートをうまく使う方法について、内部の事情も多少踏まえつつ書いてみたいと思います。
あくまで個人の意見です！
参考
まず最初にサポートリクエストに関する起票に関連する有益記事として以下があります。
- お問い合わせの発行方法について
日本マイクロソフトの公式サポートブログです
- （障害対応編）最速でテクニカルサポートから求める回答を得る方法
公式ブログではないですが、日本マイクロソフトのサポートエンジニアの方が書かれているブログです。
特にトラブルシューティング系の場合はこちらが参考になるかと思います。
急いでいる時こそ、必要十分な情報を記載しましょう！！
- 技術的なお問い合わせに関するガイドライン(AWS)
こちら AWS さんのページですが、非常によくできていて、AWS さんのテクニカルサポートに限らずほかのベンダーのテクニカルサポートにおいても参考となる部分が多いかと思います。
今回は上記の記事ような感じじゃなくてもう少し 個人的 Tips 的な要素、読み物要素も含めて書いていきたいと思います。
特に障害対応まわりは上に挙げたようなものをしっかり読んでいただければ SR の使い方としてバッチリかと思います。
テクニカルサポートにおける How to ケースの心得
まず、改めて明記することではないかもしれませんが、書いておきます。
- 基本的 に一問一答形式での QA 対応が基本となります、やりたいことが複数あっても、基本的には一問一答形式です。
- サポートエンジニアも人間で、あくまで対等なパートナーです。下請けや奴隷ではないです、たまに非常に上から目線でのコミュニケーションをされる方がいますが、大抵の場合は損してることが多いと思います
- サポートエンジニアは専門領域に関してはプロフェッショナルですが、その他の領域に関してはお客様(問合せ者)の方が詳しいことも往々にしてあります、歩み寄りのコミュニケーションを忘れずに
NG な例 と 改善点
では早速ですが NG な 例をいくつか挙げていきたいと思います。
スクリプト 丸投げ
まず、こちら非常によく見られます。
基本的にテクニカルサポートは個別の要件に合わせたスクリプトやプログラム (IaC やポリシーテンプレートなども含む) などの作成・およびレビューは受け付けません。
そういったものはテクニカルサポートでは対応していないので、別の有償サービス (プロフェッショナルサービスまたはコンサルティングサービス) にて対応できる可能性があります。(詳しくは営業担当にお問い合わせください)
ただ、そういった有償サービスは結構高額です。
ですが、うまく SR を使って解決することもできるパターンが結構あるかと思います。
場合によっては、SR にてサンプルスクリプトの準備があれば提供してくれることもありますが、必ずしもあるとは限りません。
「添付したスクリプトがうまく動かない！どうしたらよい？」みたいな丸投げはやめましょう、スクリプトレビューだと思って思われてしまうと不幸です、あくまで参考に添付するのはよいと思います。
スクリプトレビュー・作成だと思われて断られてしまうとお互いハッピーにならないと思います。
スクリプト 丸投げ - 改善ポイント
なんども言いますが、スクリプトの丸投げは NG です。お互いアンハッピーになります。
- まず、やりたいことを明確に、そして具体的に伝えましょう
- 作ったスクリプトが動かない場合は主観と客観を分けて伝えましょう
- 最低限のデバッグはして、どこで処理が止まってどういう Error Message がでているのかのログを取りましょう
- 「具体的に実装がわからない部分」や「エラーはいてる部分」がわかっている場合はそこにフォーカス、ブレイクダウンして具体的に質問を記載しましょう（原則、スクリプト内の不具合部分の特定はお客様の責任範疇になります）そこまで書けば一問一答形式となるのでサポートエンジニアも回答しやすいです。
- 関連するドキュメントを確認しましょう。まだドキュメントを確認していないのであれば、具体的にどういう事が書かれているドキュメントが欲しいのかを添えて「ドキュメントを確認したいので、関連するドキュメントを教えてください。」と記載しましょう
- また関連するドキュメントをよんで、その通りに実装しているのであれば、該当箇所をきちんと記載し問題点を具体的に記載しましょう
上記を参考にしていただければ、SR で初っ端から断れらることも少ないかと思います。
基本的にサポートエンジニアはお客様の困りごとを解決したいと思っているので❣❣
適切な製品分野を指定していない
テキトーに製品分野を指定して起票される方がいますが、これはお互いが不幸になります。
内部で適切なチームにルーティングをする仕組みがありますが、そのルーティング自体が結構なオーバーヘッドになっていたりします。サポートチームは製品カットで部署が細分化されており、比較的縦割りな一面があり、ルーティングにコストが結構かかってしまうケースもあります。
また、おおざっぱにしかお問い合わせが書かれていない場合はそのルーティング、つまりどの製品のことなのか？の特定にコストがかかります。結局、テキトーな製品分野で起票してしまうことで早期解決から遠ざかります。
適切な製品分野を指定していない - 改善ポイント
- なるべく、適切な製品分野を選択して明確に上げましょう、これにつきます
- 適切な製品分野がわからない場合：
とはいえ、適切な製品分野がわからない場合もあると思います、その際は以下に留意してみましょう
１.『なるべく具体的に、独自の言葉をつかわないで、MS Learn 公式の用語を用いて具体的に質問を記載』しましょう
２．参考の MS Learn の URL や 画面ショット、Error Message も添えて起票しましょう
そうすることで正しいサポート担当部署にルーティングする際にもスムーズ、かつ適切にルーティングされやすくなります。そういった情報がなく、かつ何が聞きたいのかもおおざっぱな場合はその製品の担当じゃないサポートエンジニアが初期対応 (時には電話でのヒアリング、およびほかのチームとの調整を担当製品じゃないのでなんとか頑張って) することになり、コミュニケーションのオーバーヘッドが発生し、かえってリードタイムがかかります。早く SR を起票したい気持ちも十分に理解できるのですが、早く起票したからと言って適切な情報が無いとかえって時間がかかります。
短納期を指定しているパターン
『至急、明日 AM 12:00 までにお願いします』
はい、これはとっても NG です。
サポートエンジニアはお客様専属のベンダーでもないですし、比較的慣れてるとは言え、急な対応をいつでも受けられるわけではありません。
各お問い合わせ、SR に優先度をつけて対応しています。
1人当たり 10～40 くらい、中にはそれ以上の SR を持っていることがほとんどです、そのなかで優先度をつけつつ日々対応をしています。
短納期を指定しているパターン - 改善ポイント
とはいえ、どうしても急いでることもあるかと思います。
その場合は以下の情報を書きましょう。
- ビジネスインパクト：何故急いでいるかの記載
これを必ず書きましょう、単に『急いでる』だけでは優先度をつけて対応することができません。最初のコミュニケーションでほぼ必ず聞かれることになります。余計なコミュニケーションコストを回避するためにも記載しましょう。具体的に『いつまでに解決しないとXXX(定量的な数字で示せるものがあればなおベターです)となってしまう』など - 目的：なにをするためにこのお問い合わせをあげているのか
これがあることで比較的早く代替案を提示することができること、またはより良い方法を提示できることがあります。 - 次回の連絡までに、最低限どんな情報がほしいのか
完全な回答はすぐに出せなくても、比較的すぐに代替案の提示などはできることがあります。
まとめ
Azureのサポートをもっと便利に使いこなすには、サポートリクエスト（SR）の作り方がポイント！基本は「一問一答」を意識して、質問を分かりやすく伝えることが大事です。
情報を整理して送るだけでも、対応が早くなるんです。また、サポートエンジニアさんたちは課題解決のパートナーです！
またスクリプト関連の SR の場合には、スクリプトをただ送るだけじゃなく、「何をしたいか」「どんなエラーが出ているか」を具体的に説明するのがコツ。そして、関連するドキュメントやリンクを添えると、よりスムーズに話が進みますよ。
急ぎのお願いをする時も、ただ「急いで！」ではなく、どうして急ぎなのかビジネスへの影響を具体的に伝えると、サポートエンジニアさんも優先度を理解しやすくなります。
サポートは上手に使えば本当に頼りになる存在ですし、頼りになりたいと思っています！
ちょっとした工夫でやり取りがスムーズになり、解決までの時間も短くなるはず。このポイントを意識して、もっとAzure を活用していきましょう！
あなたの課題が解決して、笑顔になりお互いがハッピーになるようなサポート体験となりますように！