サポートエンジニアってどんな仕事? ソフトウェアエンジニアから転職してみた

こんにちは、サポートエンジニアの山本 (@i05) です。

今日は、僕個人の体験を通してアトラシアンのサポートエンジニアがどういった職業なのかを紹介します。

#0 なぜこのブログを書いたのか

このブログを書いた理由は「サポートエンジニア (Support Engineer)」という職種があまり知られていないためです。僕自身も、アトラシアンへ参加するときにはよく分からず不安な部分が少なからずありました。

実際、転職のときも友人から考え直すよう、たしなめられたこともあったので今回はどんな仕事をしているか報告も兼ねて、サポートエンジニアの仕事を紹介してみます。

#1 入社の経緯

サポートエンジニアの紹介の前に自己紹介を兼ねて僕の入社経緯にもふれておきます。

転職以前はグリー株式会社でソフトウェアエンジニアをしていました。

転職時にアトラシアンに感じた魅力としてはおおきく2点あって、日本に限らず世界中で利用されている製品に携わることができる点と、B2Bをフィールドにしている会社で働けるという点です。

あと、大学院に通っているので、時間の拘束が厳しくないことも個人的に大きな条件でした。

ちなみに前職で働いていたころから JIRA や Confluence といった Atlassian 製品には馴染み、というか愛着がありました。

#2 日本のサポートについて

ここでは日本のサポートエンジニアの働き方を紹介します。

写真はアトラシアンの横浜オフィス。

#2-1 担当製品

アトラシアンのサポートエンジニアは通常、1つの製品を担当します。これは専門性を高めたほうが効率がいいためです。

しかし、例えば僕が普段担当しているのは Cloud 製品 (JIRA, Confluence, Bitbucket) および DevTools と呼ばれる Bitbucket Server, FeCru (FishEye and Crucible) です。

グローバルに比べ担当製品が多いですが、これは日本語でのサポートに絞っており総数が比較的少ないためかけもちをしています。日本のサポート件数は増加トレンドにあるため、今後はより担当範囲は狭まっていくでしょう。

ちなみに英語以外の言語でアトラシアンがサポートしているのは日本語だけです。

#2-2 何をしているの?

アトラシアンのサポートエンジニアの役割には大きく2つあります。

ユーザーから起票されたサポートリクエストにもとづき問題解決をすること
ユーザーが自力で問題解決できるリソースを提供すること (ドキュメントの日本語翻訳の提供, Knowledge Base と呼ばれるドキュメントの執筆, など)

詳しくは「技術サポート（日本語）の内容について」を参照してみてください。

#2-3 電話で話すことはありますか?

証跡を残すためチケット上でのやりとりをしており電話でのテクニカルサポートは原則ありません。

僕の場合は今まで1度、電話での連絡を受けたこともあります。

ちなみに、商習慣なのかシドニーオフィスではサポートエンジニアが BlueJeans などでユーザーとやりとりすることは多いそうです。

#2-4 ソフトウェアエンジニアとサポートエンジニアの大きな違い

決定的に違う点でいうと、ソフトウェアエンジニアはコンピュータを相手にしますが、サポートエンジニアは人間を相手にします。

むろん両者とも例外はありますが、主従でいうと覆ることはないと思います。コンピュータ相手だと、自分が制御できる範囲が大きく、再利用性を向上させることが容易ですが、人間だと勝手が違います。

サポートエンジニアの役割の後者「ユーザーが自力で問題解決できるリソースを提供すること」は情報の再利用性を向上させる取り組みですが、それでもコンピュータ相手ほどのレバレッジは効かせられないためチャレンジングな課題です。

正直なところ、エンジニアにこの点を伝えると魅力を感じなくなってしまうのではないかと心配なのですが、もしこの難しさや大変さを隠してしまうとフェアではないので書いておきました。

#3 アトラシアンについて

ここでは社風などを含めてアトラシアンで働く魅力を紹介します。

#3-1 一番の魅力は経験の幅

恥ずかしながら、前職のグリーにいたころに「エンタープライズ」と聞いても Oracle や IBM のロゴが頭をよぎるだけで、いまいちピンときていませんでした。

アトラシアンの製品は JIRA と Confluence を中心に、世界中の企業や政府機関に幅広く利用されています。特に、アメリカでは海軍からスタートアップまで幅広く受け入れられています。

そういう製品の利用ユーザーと日々触れ合うことで、どういった要件をユーザーが望むのかという世に公開されきれない実例にも触れられ、エンタープライズ領域についても今では徐々に理解が進んでいます。

また、グローバルに展開されている製品を日本へローカライズさせる過程も興味深いです。ドキュメントや製品の i18n の課題は当然として、地域ごとにマーケットの差異があります。例えばアトラシアン製品は日本での知名度は改善の余地が大きい一方で、グローバルは知名度の高い前提で方針が決まっていってしまうというギャップがあります。特にマーケティングチームはこのギャップに日々奮闘しています。

僕も日本チームの一員として、普段クラウド製品を担当している利を活かして国ごとのリソースの読み込み完了速度を比較した統計データをセールス担当へ共有するなど、小さなチームならではの連携もしています。

#3-2 気持ちのいいオープンさ

社内向けにも作業のチケットやドキュメンテーションを残す文化があります。

研修のときはもちろんのこと、この公開文化は日々の業務でも役立っています。どうしてその意思決定がされたのか、作業の進捗はどうなのかがすぐに分かるからです。最近の例だと、いま Atlassian Account というという製品横断の認証基盤が順次展開されているのですが、このロールアウトも各作業単位でチケットが公開されているので社内のチケットを探すとお問い合わせのユーザーが対象に入っているかどうかなども担当に聞くことなく簡単に確認できました。

"Open company, no bullshit" はアトラシアンの Value でもあります

ドキュメントを残す文化があると、その方法も洗練されていきます。

僕が驚いたのは、内容が陳腐化していないことを担保するため次回の書き換え時期とその担当者が明記されているドキュメントを発見したときです。スコープが明確なのは良いドキュメントの条件だといわれますが、個人的に長らく「ドキュメントには賞味期限があるべきだ」というぼんやりとした課題意識があったのでこのアイデアを見かけたときは興奮してしまいました。

#3-3 リーダー陣の風通し

入社当初、リーダー層がポストを兼務していることが少なく役割がうまく委譲されている印象を強く受けました。また、リーダー層であっても社歴数年のメンバーのほうがむしろ多数で、CXOレベルでも社外からの受け入れもあります。

#3-4 英語の苦労を楽しもう

サポートエンジニアの拠点はシドニー、クアラルンプール、アムステルダム、ポートランド、サンフランシスコ、など世界中に点在しており、日々密に連携して仕事をしています。

また、先述の通りローカルの言語でテクニカルサポートを提供しているのは日本だけです。

この状況から分かる通り、何かの情報をえるのにも、誰かに頼みごとをするのにも、英語は欠かせません。

公開されている例でいえば Atlassian JIRA (通称JAC) があります。問い合わせから発覚したバグや機能要望を起票することはサポートエンジニアの大切な仕事の1つなのですが jira.atlassian.com がその僕によるチケットの一覧です。

僕は留学経験もなくコミュニケーションに苦労することがありますが、英文への心理的抵抗が減ったり、読解速度があがったり、とっさのフレーズが蓄積されていったりと、日々進歩しています。

正確なレポートを書き上げるには論理的な文章を書くライティングスキルが必要になります。個人的に『THE ELEMENTS OF STYLE』という英語の正書法の本を読んでいます。これは英語圏の大学で学部生向けに最も採用されている教科書だそうで、おすすめされました。

とはいえ、そもそも第2言語同士でやりとりすることも考慮するとそんなに格調高い表現は必要ありません。細部を気にしすぎず前に進む。これは英語にかぎらず仕事へ向き合う姿勢としてグローバルの同僚からいい影響を受けられています。

#3-5 人間とコミュニケーションする技術

ソフトウェア工学の研究をしていれば、ソースコードは人間がコンピュータに寄り添うためのよくできた1手段だということが分かります。

それと同様に、サポートエンジニアがユーザーに寄り添うためにも多様な手段があります。上手にまとめきれないので普段気をつけていることを箇条書きにしてみます。

できる限り厳密に素早く、でもユーザーが希望している着地点を見計らって落とし所を模索する。
ユーザーからの質問は直接、本当にやりたいことを反映しているとも限らない。
ユーザーへの回答のほとんどすべては単なる僕自身の見解ではなく、必ず何らかの背景があるべき。それは製品のドキュメントであったり、サポートオファリングであったり、利用規約であったり、さまざま。
人間の理解には冗長性はつきものという点はあるものの、ただたんに長文で説明すればいいというわけではなく理解が容易になるよう要点をしぼって最小の労力で理解できるよう知恵をしぼる。

こういった諸要素を組み立ててやりとりするのは僕自身の性格にあっていると思います。このリストをながめて「おっ」と思った方は、サポートエンジニアに向いているかもしれません。

気になったひとは『テクニカルコミュニケーションへの招待』を読んでみてください。

#4 F&Q

ここではソフトウェアエンジニアのひとなら気になるだろうなと思われるポイントを紹介します。

#4-1 ソフトウェアエンジニアの経験はテクニカルサポートに活きますか?

はい、もちろん。僕が主に担当しているのが Cloud 製品と Bitbucket Server などの DevTools なのでその範囲での話となりますが、特に Web エンジニアや Service Reliability Engineering (SRE) に携わっているひとに向いていると思います。クライアントやアプリケーション層に特化して関わっている経験よりは、インフラ系も含めてアーキテクチャ全体を広く面倒を見ている経験が活きる環境です。

逆に、テクニカルサポートの経験もソフトウェア開発や運用をするときの発想を幅広くしてくれます。例えば "Something went wrong" とだけ表示するエラーページがどれほどユーザーを混乱させるか、企業の管理者はどういった要件の機能を好むのか、といった傾向を身をもって知ることができるからです。

#4-2 コードを書く時間って減りますか?

はい、僕は減りました。ざっくりとですがコーディング時間はおおよそ 2.3時間/日から 1.2時間/日にまで減りました。

※Wakatimeで計測した時間を転職日を境に平均をとっただけの概算です。転職日前後で日数の母数が異なる点に要留意。祝休日や業務外の時間も含んでいます。

赤線の 2016-06-15 が転職日。特に平日のコーディング時間が減っていることがみてとれます。

サポートエンジニアにも、こまごまとしたスクリプトを書く機会は少なからずありますが、設計・実装・テストなど大掛かりにプログラミングする業務はありません。

（それにしてもこうして算出してみると、そもそも転職前もコーディング時間が少なくて驚きました。休日や算入されていないエディタがあるとはいえ、実感としてはもっとコーディングしているつもりになっていました。でもよく考えてみると下調べをしたりコードを読んだりするような時間はフロー状態に入っていて生産的ではあるものの、コーディング時間には算入されていないので実感と乖離があっても妥当かもしれません。いや、それにしても少ないですが...）

#4-3 技術面の知識不足は感じますか?

はい、アトラシアンのサポートエンジニアをしていて自分の知識不足を感じる分野をあえてミドルウェアとして切り出してみると次の2点です。

Java: 自分にとってJavaは普段使いする言語でなかったのが大きいところ。言語仕様自体というよりは、歴史のある言語なのでエコシステムを含めて土地勘が足りていないなと思い当たることが多々あります。
Elasticsearch: アトラシアン製品のサーバ製品では Bitbucket にて利用されていますが、プライベートプロジェクトを含めて経験不足なので調査に時間がかかってしまいます。

前職時代、特に新卒入社当初などにはこういった知識不足に直面したときは帰宅後や週末に技術要素を触ってみていましたが、現在は大学院での研究に時間を割いているのでキャッチアップに時間が取れていないのが知識不足感の要因になっていると思います。