テクニカルサポートのお仕事

https://speakerdeck.com/sugitk
https://www.linkedin.com/in/takashi-sugimura-8604a0185/

Transcript

1. テクニカルサポートのお仕事
   すぎむら @sugitk
   2023-05-15
   

   View Slide

2. はじめに
   ・OSSをベースとしたソフトウェアの製品サポートを４年半少々やっていました。　
   2018年8月〜2023
   年4月です。
   ・記憶が新しいうちにチーム内で実施した勉強会を振り返って、テクニカルサポートの仕事を少し紹介
   したいというのがこの資料の目的です。
   ・有償のサブスクリプション契約をいただいているお客さまに対してテクニカルサポートを提供していま
   した。OSSコミュニティでの活動についてはここでは触れません。
   ・テクニカルサポートは会社によっても位置付けや業務範囲がさまざまなものがあると思います。わた
   しがやっていた仕事はこうでしたということでご了解ください。
   ・略語はあらかじめここにまとめておきます。
   　- OSS : Open Source Software
   　- SLA : Service Level Agreement
   　- APAC : Asia-Pacific
   

   View Slide

3. 実績
   ・統計を取った時期が異なるのでわかりにくいですが、４年半少々でこの実績を積み上げてきました。
   - 1件以上コメントした問い合わせの数（オーナーを取ったものを含む）　
   2,937件 (2018-08 〜
   2023-04)
   - サポートケースへのコメント　
   4,836件 (2021-01 〜 2023-04)
   - ナレッジベースのドキュメントを執筆　
   168件 (2018-08 〜 2023-04)
   - 非公式ブログへの執筆　39件 (2018-08 〜 2023-04)
   - お客さまからのフィードバックの平均値　
   4.62 (5.0満点、2022-01 〜 2023-04)
   

   View Slide

4. いつも意識していたこと
   

   View Slide

5. お客さまはなぜ問い合わせをするのか？
   ・OSS 版を使うのではなくサブスクリプションを契約して製品版を導入しても、思うように使えないという
   ときに問い合わせをしてきます。その内容はさまざまです。
   　- 製品知識がない
   　- 設定が悪い
   　- 使い方が正しくない
   　- 期待する動作をしない
   　- まだ実装されていない
   　- など
   ・製品を動かすことが目的ではなく、製品を使ってビジネスを進めるために買っていただいています。
   担当製品は自動化の製品で、手でやるよりもこの製品を使ったほうが圧倒的に費用を削減できること
   が期待されています。
   ・テクニカルサポートへの問い合わせをすることで問題が解決すれば、悩む時間を減らして本来やりた
   いことに注力することができます。
   

   View Slide

6. テクニカルサポートが提供する価値
   ・テクニカルサポートはサーチエンジンではありません。
   ・作業の代行も行いません。運用の主体はあくまでもお客さま自身です。
   ・テクニカルサポートエンジニアはこのような価値を提供します。
   - 導入方法や利用方法について、製品の深い知識に基づいたアドバイスをします。
   - 問い合わせを受けた事象が不具合かどうかを確認して、必要なアクションをします。開発チーム
   に問題を報告したり、当面の回避策を提示します。再現できない場合には、お客さまの環境を
   実際に見せていただいて確認することがあります。
   - ドキュメントが不足している場合には、問い合わせを受けた事象に基づいてドキュメントを追加
   で記述することがあります。
   - OSS のプロジェクトに直接機能改善要望を出すよりは、テクニカルサポートからの要望として上
   げたほうが優先順位を高くして実装を検討してもらえることがあります。
   

   View Slide

7. 問い合わせを受けてから
   閉じるまで
   

   View Slide

8. 問い合わせを受け取ったとき
   ・カスタマーポータルからWebのフォームで問い合わせが起票されますと、申告された製品の情報に
   基づいて専任のチームのキューに入ります。
   ・キューの振り分けが正しくない場合には、適切なチームに転送します。契約があるお客さまかどうか
   も確認します。契約がないときは、原則として定型文でお断りします。
   ・担当するリージョンからの問い合わせであれば、オーナーを取ります。　
   APAC (およそ GMT+8〜
   11) の時間帯を担当していました。日本からの問い合わせは次第に増えて、退職する前には半分くら
   いはあったように思います。
   ・対応言語は原則として英語ですが、日本からの問い合わせは例外として日本語で対応していまし
   た。
   ・重大度(緊急度ではない)や契約によって、初期応答と継続応答の時間が
   SLAとして決められていま
   す。SLA を守れないと、悪いフィードバックを受けてしまうことがあります。
   ・土日当番もありました。平日よりも人数が少なく、重大度の高い問い合わせのみを対応していまし
   た。日曜が平日の国もあり、そのようなお客さまには平日と同様に対応しました。
   

   View Slide

9. 初期対応
   ・問い合わせの内容をできるだけ正確に捉えます。お客さまは必ずしも製品知識を十分に持っていないこと
   があります。困っていることを困っていない状況に持っていくことを目的とします。
   ・問い合わせの内容がサポート範囲なのかどうかを判断します。範囲外のものとしては例えばこのようなもの
   があります。
   　- 契約について → 営業
   　- コードの開発やテスト、作業代行 → プロフェッショナルサービス
   ・申告された重大度がSLAの定義に合わない場合、下げることを調整することがあります。問い合わせは全
   て急ぎなのは理解しますが、人力のリソースに制限があるからです。プロジェクトのスケジュールの都合で急
   いでいると言われることもよくありましたが、製品サポートとしては配慮することができません。本来急ぎで対
   応すべきお客さまへのリソースを圧迫するからです。
   ・問題の事象を理解するために、さまざまな情報収集をお願いしつつ、手元で再現環境を整えます。 OSや製
   品のバージョン、インストールされている構成を把握するところから始めます。
   

   View Slide

10. 問題解決に向けた対応
    ・情報収集して、事象を把握します。何を解決すべきなのかを、およそ３往復以内のやりとりで確定さ
    せます。
    ・問題を再現することができたら、状況によってアクションをします。
    　- 既知の問題で修正がある → アップグレードをお願いする
    　- 既知の問題だが修正されていない → 回避策があれば提示して、なければ修正が早く進む
    ように情報を開発チームに提供したりする
    　- 新しい問題 → 開発チームに問題として起票し、回避策も合わせて検討する
    ・再現できるかどうかが鍵で、再現できない問題は解決まで長期化する傾向にありました。
    ・難問はバックラインのエンジニアや開発チームと協力して進めます。コードを深く追わなければわから
    ないもの、大規模でパフォーマンスの問題があるもの、想定しない構成で使われていたもの、他社の
    製品との組み合わせで問題を生じていたもの、などがありました。
    

    View Slide

11. 問い合わせを閉じる
    ・問題が解決できたり回避策を受け入れてもらえたりなど、その問い合わせについて理解が得られたら閉じ
    ることになります。問い合わせのやりとりを進める中でさらに問題が増えてしまった場合には、別な問い合わ
    せを起票してもらいます。
    ・閉じるときには事務的に閉じて良いのですが、お互いに人間が仕事としてやっているということをきちんと意
    識して、気持ちよく終われるように心がけていました。お客さまは困っているから問い合わせして来ているわ
    けで、本来は困らなくても使えるようになっているほうが好ましいからです。
    ・ドキュメントを読んでもわからなかったから問い合わせをしてきているので、問題が解決できたらまとめのド
    キュメントを作成してナレッジベースとして参照できるようにすることもよくやっていました。製品ドキュメントへ
    の反映を進めることもありましたが、動きは遅くなるからです。
    ・好意的なフィードバックをもらうためには、その問い合わせを通して何か価値提供できたかどうか、それが伝
    わったかを意識していました。また問い合わせをすると助けてもらえる、サブスクリプションを買ってよかった
    と感じてもらえるようなファンになってくれるのが理想形でした。
    

    View Slide

12. 工夫したこと
    ・問い合わせの事象を高速に再現することをいつも心がけていました。自動化の製品を扱っているために自分でも
    検証環境の構築を自動化し、構成を把握したら同等の構成をすぐに作れるようにしていました。自分自身もユーザと
    して同じような問題に当たってしまうこともあり、自分をサポートするような動きをするのが役に立つこともよくありまし
    た。
    ・既存の事象であってもできるだけ再現することにして、新しい発見があるかどうか、いまだからその問題に当たるの
    かということを確認するようにしていました。 OS や製品のアップグレードのタイミングでたまたまその組み合わせで
    生じる問題があるからです。
    ・できるだけ早く、かつ具体的に返答するようにしていました。 SLAで8営業時間などと定義されていても、問い合わ
    せを並列にやっていたり、他のメンバーとの相談に応じたりしているとあっという間に時間はなくなります。早く返答し
    て手持ちの量を減らすことで、心理的な負荷も軽くなっていました。
    ・ただ既存のドキュメントや事例を紹介するというのではなく、実際に再現した結果をもとにして具体的なお客さまの
    環境ではどのような操作をしてほしいのかというところまで落とし込んだ回答をするようにしていました。
    ・以前法律の勉強をしていたことがあり、論文試験では法的三段論法として規範定立を必ずするわけですが、その
    考え方がテクニカルサポートの仕事でもとても役に立ちました。事実関係の把握、論点の抽出、条文のあてはめ、結
    論の導出です。
    

    View Slide

13. おわりに
    

    View Slide

14. これからもテクニカルサポートをやります
    ・教えたがりなこともあってブログも　
    1996年から書いていたりとドキュメントを書くのが好きなのです
    が、テクニカルサポートの仕事に出会って多くの経験をすることができました。
    ・英語力が乏しく世界中のお客さまを相手にするのは大変でしたが、技術力で補ってなんとか生き延
    びてきました。この資料で説明した元ネタはグローバルなチームメンバーへの勉強会でしたが、彼らに
    もそれなりの影響を与えることはできたのかなと思っています。
    ・ちょっと試して動かしてみるということと、実際に運用で大規模に使うということではかなり大きな開き
    があって、問い合わせを通して多くのことを学ぶことができました。開発チームや営業チームとも積極
    的に議論することで、具体的な使われ方に基づいた製品の改良にも関わることができて、やりがいは
    ありました。
    ・6月からはまた違った角度でテクニカルサポートの仕事をします。扱うものは変わりますが基本的な
    考え方はそんなに変わらないはずですので、引き続き頑張ります。
    

    View Slide

15. Thank you :)
    https://speakerdeck.com/sugitk
    https://www.linkedin.com/in/takashi-sugimura-8604a0185/
    

    View Slide