各製品の資料を入手。
詳細はこちら →
「サポート」は製品開発？ 攻めのテクニカルサポートについて考える
こんにちは。CData Software Japan リードエンジニアの杉本です。
いきなりですが、皆さんは「サポート」ないし「カスタマーサポート」と聞くと、どのような仕事を思い浮かべるでしょうか？
おそらく殆どの人達が、コールセンターであったり、クレームの受付窓口、みたいなイメージが浮かぶのではないでしょうか。
今回お話する「テクニカルサポート」についても、何人かに話を聞いてみたのですが、なかなかイメージができない、カスタマーサポートと同様にネガティブなイメージがある、というコメントを貰いました。
そこにはおそらく「楽しい」や「やりがい」、もしくはエンジニアらしい「技術力」みたいなイメージを持てない人は多いのではないかなと思います。
しかしながら、「逆説のスタートアップ思考」という本でスタートアップにおける「サポート」の重要性・あり方をとてもうまく表現している一文がありました。
https://www.amazon.co.jp/dp/B06XTR4GFP/ref=cm_sw_r_tw_dp_x_snx6FbXQP7FZVwww.amazon.co.jp
「サポート」は製品開発だ
（中略）
カスタマーサポートと聞くと、リリースの後処理やクレーム処理のようなイメージを持たれている方も多いかもしれません。しかしスタートアップでは、決してそうではありません。
スタートアップにとってのカスタマーサポートとは、製品以外の体験を提供できる重要な活動です。つまり、より広い意味でのプロダクト体験をよくするための重要な一要素です。
むしろ製品そのものより、親身なサポートをすることが差別化要因になることもあります。サポートを強化することで、スタートアップは製品以上の体験を顧客に提供することができます。
さらに言えば、スタートアップにとってのサポートとは、「製品開発の一要素」という認識が必要です。なぜならサポートをうまく行うことで、製品の改良点が見つかるからです。
馬田隆明. 逆説のスタートアップ思考 (中公新書ラクレ) (Kindle の位置No.1609-1617). 中央公論新社. Kindle 版.
この記事のタイトルでも引用していますが、「サポート」は製品開発であるという、いきなり世間一般のイメージが覆るようなメッセージからこの文章は始まっています。
世間一般のイメージにあるサポートが「守り」であるとすると、上記引用から考えるサポートのイメージは「攻め」です。
製品以上の体験を顧客に提供し、他社との差別化要因として活用、さらには製品の改良にまでつなげます。
現在私の会社、CData Software Japanでも「テクニカルサポートエンジニア」という職種で募集をかけていて、それはいわゆる「カスタマーサポート」の部類に当てはまります。
しかしながら、この名前を冠する仕事の「世間一般イメージ」と私自身が行っている「仕事」との間には、この引用のように、どうやら大きなギャップが存在しているようです。
「せっかく面白い仕事なのにもったいない」そんな考えから、この記事では一ソフトウェア企業のテクニカルサポートエンジニアである私の普段の取り組み・仕事内容を元に、
「私が考える「サポートは製品開発」そして「攻めのテクニカルサポート」とは何か？」を考察し、そのギャップを埋めてみたいと思います。
テクニカルサポートの基本的なお仕事
とはいえ、「攻めのテクニカルサポート」の話に入る前に、業務的にベースとなっている「サポート」について押さえておきましょう。
皆さんが想像するように、テクニカルサポートは「カスタマーサポート」の一種なので、基本的にはお客さんからの問い合わせベースで動きます。
使い方がわからないとか、エラーが発生するとか、思ったように動作しない、みたいな問い合わせが主です。
ざっくりとしたフローを描くと、以下のような感じになります。
このフローをベースに、どのようにテクニカルサポートを展開していくかは、それぞれの会社の提供しているサービス・プロダクトによりますが、ソフトウェア・クラウドサービスを提供する会社であれば基本の流れは一緒だと思います。
ちなみに、私の会社「CData Software」で扱っている製品は、API連携のためのコンポーネントなので、関わるレイヤーの幅が縦にも横にも広いことが特徴です。
ツール側（BIやETLなど）、SQL、HTTP・TCP/IPなどの縦のレイヤー、そして各APIごとの特徴が出る横のレイヤーと幅広く関わります。
基本的な使い方はマニュアルやヘルプの箇所の参照だけで済みますが、エラーの切り分け・問題箇所の特定は一番重要になる仕事です。それがツール側からのSQLリクエストとのギャップなのか、SQLのパーサー部分なのか、HTTP・TCP/IPレイヤーなのか、それともAPI側へのリクエストの問題なのか、はたまた認証部分なのか。
知識を総動員させて、問題の特定に励みます。問題箇所が顧客の操作やネットワーク課題であれば、その回避策を案内しますし、製品に原因箇所が存在すれば、対応チケットを発行、修正を行い最新バージョンを顧客に提供します。
これがテクニカルサポートの基本的なお仕事です。
（ちなみにソースコードはテクニカルサポートメンバーもすべて見れますし、ローカルでのデバッグ・ビルドもできる状態になっています）
攻めのテクニカルサポートとは？
それでは「攻めのテクニカルサポート」とはなんでしょうか？ それは「どのようにサポートの効果をN倍化させるのか？」という考え方であると見ることができます。
そして、それは「Customer」「Market」「Product」の3つの観点から捉えることができるでしょう。
それぞれは密接に関連していますが、もう少し噛み砕いていくと以下のように表現することができます。
- 「顧客の質問に応える」だけではなく、「ニーズを開拓し製品のマーケティングに活用する」
- 「製品の問題や使い方をサポートする」だけではなく、「製品がサポートできるシナリオの幅を広くする」
- 「開発チームに修正をお願いする」だけではなく、「一緒にどのように修正するべきかを考える」
「顧客の質問に応える」だけではなく、「ニーズを開拓し製品のマーケティングに活用する」
まず最初にイメージをしっかりと持っておきたいのは、「顧客」が誰か？ という点です。
技術を生業とするテクニカルサポートといえど、コミュニケーションする先は「顧客」です。しかしながら、もう少しディティールを掘り下げると、この「顧客」は以下の3種類のレイヤーで存在していると考えることができます。
- 「潜在顧客」：自社の商品やサービスを知らない顧客。
- 「顕在・見込み顧客」：自社の商品やサービスを検討・トライアルなどを実施している顧客
- 「既存顧客」：すでに自社の商品やサービスを契約・利用している顧客
基本的にテクニカルサポートは「2」と「3」の顧客に対してサポートを提供しますが、もう少しビジネスに寄り添い、根本的に考えていくと「困っている人たちの課題を解決すること」と表現することができます。
上記内容に照らし合わせると「困っている人たち」とは誰でしょうか？
例えば、以前私の会社に「Office365（Microsoft365）の予定表をユーザー横断的に分析したいんだけど、どうしたらよいか？」という問い合わせがありました。
これが通常のサポートであれば、ヘルプを案内して
こんな風に実現できますよ、という案内を行い、問い合わせの解消、というのが通常のテクニカルサポートです。
しかしながら、ちょっと一歩引いて考えると、この「問い合わせ」つまりこういうことを実現したい、こういう課題を解消したいという「ニーズ」は、この顧客だけが持ち得るものではありません。
むしろ私達が今まで見えていなかった「ニーズの発見」がそこにはあります。
ここにニーズを感じた私は、その問い合わせをベースにしながら、コンテンツとしてBlog・動画・コミュニティに広げました。
このようにテクニカルサポートで日々来る問い合わせというのは、具現化されていないニーズの塊です。それを一つ一つの回答として済ませてしまうとその顧客だけしか幸せにすることができません。
もちろん、今後のテクニカルサポートのためのナレッジとしても活用できますが、こういったコンテンツによってニーズの掘り起こしや潜在的に課題を持っていた顧客層にリーチ（マーケティング）することが可能になります。
「製品の問題や使い方をサポートする」だけではなく、「製品がサポートできるシナリオの幅を広くする」
テクニカルサポートを提供しているということは、技術的な要素、他の開発者やサービスと連携したりすることができる製品を扱っていることが多いと思います。
エンジニアの皆さんが良く利用するAzure・AWS・GCPなんかもそうでしょう。
それらを活用する場合、それぞれのサービスやプロダクトは単一の存在として課題を解決するだけではなく、他のサービスやプロダクトと密接に関連しながら、顧客の課題を解決しています。このクラウド・SaaS・PaaS・IaaSの時代には特にそれらが顕著です。
APIを提供しているサービスであれば、そのAPIを活用しているサービスを増やすことは、その製品のエコシステムそしてそのサポートの範囲の拡充と考えることができます。
例えばSalesforceのAppExchangeやfreeeのアプリストアで公開されている連携はその典型でしょう。
逆もまた然りで、APIを活用しているサービスであれば、連携先のAPIを増やすことがサポート範囲の拡充に繋がります。
例えば、最近クラスメソッドさんが提供するCSA Data Uploaderという製品をSNSで見つけたことがありました。
これを自社の製品と組み合わせることで「より幅広い顧客に対して、Amazon S3やGoogle Cloud Storageへのデータ投入を効率化できるのではないか？」と思った私は早速トライアルを実施しました。
予想は見事に的中し、スムーズに連携を実現。連携記事まで作成してしまい、向こうの開発チームとも協業についてお話することができました。
ここでのポイントは特に自社製品の改良や変更を加えていない点です。また、今回は私が軸として動いた例になりますが、このような相談が顧客からリクエストされることもままあります。
このように、製品として現在公式にサポートされている内容だけでなく、そのサポートの範囲・シナリオを拡充させていく、と考えると、テクニカルサポートの仕事の幅というのは飛躍的に広がっていきます。
「開発チームに修正をお願いする」だけではなく、「一緒にどのように修正するべきかを考える」
テクニカルサポートをしていると、まず避けられないのは製品のバグ・エラー、意図しない挙動やニーズに応えられないといった「問題」との遭遇です。
単純な問題であれば、開発チームと共にスピーディに解消を図っていく必要がありますが、ここで一歩引いて考えたいことは、「問題」の遭遇というのは、潜在的なニーズであったり、他の顧客の「課題」でもあるという、最初に紹介した攻めのテクニカルサポートにも繋がるという点です。
特に既存の機能・仕様では対応していない課題へ対応するということは、慎重にその対応内容を見極めなければいけません。
製品トライアルを実施している顧客から「この機能が欲しい」「ここが思ってたのと違うから修正してほしい」という要望があったとしましょう。
それを新機能として追加もしくは変更することは可能ですが、それらを行った際、プロダクトの健全性として、またマーケット全体にとってどのような影響を与えるでしょうか？
「目の前の顧客」と合わせて「マーケット」＋「プロダクト」を見る必要があります。
修正する場合でも、直接その問題を解消する「プランA」だけではなく、プロダクトとしての健全性も維持しながら、この対応が他の顧客の課題も解消しうる修正なのか？ という判断を元に「プランB」を考えることができます。
プロダクトの健全性が維持できないのであれば、要求を受け入れないということも選択肢の一つです。
「そんなことはPMや開発チームが決めることだ」という声もあるかもしれません。しかしながら、「顧客のニーズ」を、「課題感」を、「マーケット」を肌で感じ、見ているのはテクニカルサポートチームです。
そういった、マーケット目線を持ちつつ、製品の修正対応を考え、開発チームと接していくことも、攻めのテクニカルサポートの一つであると見ることができます。
まとめ
ここまで話してきたように「攻めのテクニカルサポート」の中で重要なことは「サポートの効果をN倍化させる」ことです。目の前の顧客と共に、解決できる顧客の母数を増やすこと。サポート可能な範囲・マーケットを増やすことです。
そのために、この「Customer」「Market」「Product」それぞれの側面から、「どのように効果をN倍化させるのか？」と捉えてみました。
- 「顧客の質問に応える」だけではなく、「ニーズを開拓し製品のマーケティングに活用する」
- 「製品の問題や使い方をサポートする」だけではなく、「製品がサポートできるシナリオの幅を広くする」
- 「開発チームに修正をお願いする」だけではなく、「一緒にどのように修正するべきかを考える」
こうった点を考えながら、テクニカルサポートを行っているということがわかると、サポートという受け身なイメージの業務が変わらないでしょうか？ この記事で「サポート」に対する皆さんのイメージを少しでも覆せていたら、嬉しいです。
こんな感じで、CData Software Japan では日々のテクニカルサポートを提供しています。
絶賛新しいメンバーを募集中なので、興味が湧いた方はぜひお気軽に連絡してみてください！
参考
以下の記事もテクニカルサポートについて熱く語っています。是非テクニカルサポートエンジニアという仕事の参考にしてみてください。
