※当ブログではアフィリエイト広告を利用しています。
サポートエンジニアという職種をたまに見かけるけど、どんな仕事なの？
この記事を見に来てくれたあなたは、こんな疑問をお持ちではないでしょうか。
こんにちは、外資系 IT 企業の現役サポートエンジニアの fidn(@lancork) です。
この記事では以下のような方を対象に、サポートエンジニアの仕事についてご紹介します。
- サポートエンジニアの仕事内容について知りたい
- サポートエンジニアに興味がある
前職でのヘルプデスク経験をあわせると 10 年以上、サポートという仕事に携わっている実際の体験をもとにしています。
サポートエンジニアとは？こんなお仕事です
結論から言ってしまうと、サポートエンジニアとは以下のような仕事です。
- お客様からの問い合わせを受け付ける
- お客様の技術的な問題を解決に導く
たまに「ただのコールセンターじゃないの？」と思われる方もいますが、違います。
会社がある程度の規模になってくると、サービスや製品を作る人たちはそれに集中するほうが効率が良いです。
このためエンドユーザからの技術的なお問い合わせを受けたり、調査をメインで担当するのがサポートエンジニアです。
とはいえこれだけではザックリしすぎだと思いますので、さらに解説していきます。
筆者のサポートエンジニア歴について
サポートエンジニアのお仕事を詳しく解説する前に、自己紹介をさせてください。
2019 年 6 月の時点での、筆者のサポートエンジニアとしての職歴は以下のとおりです。
- 地方の中小 IT 企業でヘルプデスクを 7 年（システムエンジニアの一部）
- 東京の外資系 IT 企業でサポートエンジニアを 3 年
現在も東京の外資系 IT 企業で、自社で提供する製品・サービスについてのサポートを行っています。
サポートエンジニアに転職したきっかけや日本と外資系企業の違いについては、以下のブログ記事に詳細がありますのでご覧いただければと思います。
なお、この記事では私の体験をもとにサポートエンジニアの一般的な仕事について書いていますが、すべての会社には当てはまらない可能性もあります。
このためサポートエンジニアという仕事の一例としてお考えいただければと思います。
サポートエンジニアが問い合わせを問題解決に導く手順
お客様からの問い合わせの受け付け
まずはじめはお客様がサポート宛に問い合わせることによりスタートします。会社によりますが問い合わせは以下のような手段で行われます。
- メール
- チャット
- 電話
問い合わせの内容は以下のような仕組みで管理されます。これらの呼び方も会社によると思います。
- サポートチケット
- サポートケース
- サポートリクエスト
- インシデント管理システム
お問い合わせの内容は多岐にわたりますが、おおまかには以下のような種類があります。
- サービスを使う前の質問（ユースケース）
- すでにサービスを使っていて、使い方や仕様の質問
- サービスで起きた障害や不具合についての質問
パソコンを前にしている時間が長いものの、相手はお客様という人間になります。
調査に必要な情報や不明点のヒアリング
お問い合わせの内容だけで必ずしも調査に入れるとは限らず、情報が足りなかったり不明なことがある場合はお客様に聞きます（ヒアリング）。
たとえば以下のような項目をヒアリングすることが多いです。
- 障害の場合、はじめて起きたものか・いつから発生しているのか
- 問題が発生している環境について
- なにかエラーが出ていれば、エラーの内容
- お問い合わせに至った背景
場合によってはお客様にコマンドの結果やログの採取をお願いし、追加の情報を提供してもらうこともあります。
これらを聞くのはお客様の状況を把握するためというのもありますが、以下のような重要なポイントも把握する必要があるためです。
- なぜ困っているのかの理解のため
- 問い合わせの本質を理解するため
これはお問い合わせの内容にそのまま答えることが、必ずしも正解ではないときがあるためです。例えば以下のような場合です。
- 障害でビジネスが止まっている → 調査よりも復旧する手段を優先
- 質問された内容より、もっと良い方法がある → 別の方法を提示
- 問い合わせ内容そのものは実現できない → 代替案を提示
がんばって調べたものの、本当に実現したいのはそうじゃなかった・・となったら悲しいですからね。
お問い合わせに対する調査
必要な情報が得られたら、サポートエンジニア自身での調査に入っていきます。
これもお問い合わせの内容によって変わってきますが、調査の方法としては以下のようなものがあります。
- 自社サービスのドキュメント
- 社内のナレッジ
- 自分で似た環境を作って再現・検証
- GitHubなどでコードや Issue を調べる（オープンソースソフトウェアが関連する場合）
- 同僚やサービスを作っているチームに聞く
たとえば自社サービスの仕様に関するものならドキュメントを見てその内容で回答できる、ということも多いです。
しかし複雑なお問い合わせだと自分で環境を作ったり、場合によっては製品をつくっている別のチームとの連携も発生します。
別のチームとの連携の際にも、お客様がなぜ困っているのかを伝えることは重要なポイントです。
調査が終わったら回答→クローズ
調査が終わったらお客様に返信して、お問い合わせをクローズに導きます。
お問い合わせを受けたその日に解決できるものもあれば、長期間かかるものまであり、クローズまでにかかる期間は内容によって様々です。
サポートエンジニアについてよくありそうな質問
サポートエンジニアはコールセンターとは違うの？
サポートというと全員がヘッドセットを付けて、電話が鳴り響くいわゆるコールセンターのようなイメージがあるかもしれません。
しかし実際には電話での問い合わせはさほど多くなく、技術的な調査をしたりメールを書く時間のほうが長いです。（会社によって違うかもしれません）
また私の職場がそうですが、調査に集中するため電話を担当する時間帯が区切られている会社もあります。
サポートエンジニアはコードを書くの？
サポートエンジニアはソフトウェア開発エンジニアと違い、コードを書くことは仕事のメインではありません。
私の場合はシステムエンジニアだった前職と比べて、仕事中にコードを書く時間は減りました。
ただコードを全く書かないかというとそうでもなく、以下のように書く機会もあります。
- 検証や再現をするためにコードを書く
- 自分の仕事をラクにするためのスクリプトをつくる
- 社内で使うツールを作る
- 自社サービスの改善のためプルリクを送る（稀な例）
ごく一部ですが、OSSのコミッターをしながらサポートエンジニアをしている人もいます。
バリバリに開発ができる必要はありませんが、お問い合わせの内容を再現するためにある程度はコードもわかると良いといった感じです。
サポートエンジニアが向いている人
以下のような方はサポートエンジニアに向いていると思います。
- 情報を集めながら問題を切り分けて真相に迫っていくのが好き
- 問題を分析して解決するのが好き
仮説を立て、検証を繰り返し真相に迫っていく部分は探偵のようでもあります。
また「どこが痛いですか？いつからこうなったのですか？」とお客様に聞き、状況にあったお薬（対処法）を提示する姿は、僭越ながらお医者さんにも似たところがあるかもしれません。
サポートエンジニアが向いていない人
逆に以下のような方はサポートエンジニアには向いていません。
- コードをバリバリ書いて開発だけしたい
- サービスの運用そのものに携わりたい
ただキャリアとしてサポートを経験してからソフトウェア開発エンジニアになったり、サービスを運用するエンジニアになった例は私の身近にもあります。
おわりに
サポートエンジニアの仕事について最後にまとめます。
- お客様からの問い合わせを受け付ける
- お客様の技術的な問題について解決に導く
- コードを書くのはメインではないものの、たまにはある
近年ではサービス開発とサポートが分かれている会社も多く、多くの IT 企業がサポートエンジニアを募集しています。
この記事がサポートエンジニアに興味がある方に少しでも参考になればうれしいです。
