読者です 読者をやめる 読者になる 読者になる

nekop's blog

OpenShift / JBoss / WildFly / Infinispanの中の人 http://twitter.com/nekop

テクニカルサポートというお仕事

tstalk Vol.1というテクニカルサポートのトークイベントに行ってきていろいろお話したり聞いたり考える機会になったので書き出しておくよ。いろいろなテクニカルサポートな人が集まっておもしろかった。ソフトウェア製品サポート、ハードウェア製品やそのファームのサポート、非サポート(興味がある、昔やっていた、サポートを利用するお客様の立場だけど、というような方々)、その他、みたいなごちゃまぜ編成。

ランダム箇条書きな感じで。

テクニカルサポートは楽しい

  • テクニカルサポートはケーキバイキングみたいなお仕事
    • 基本的に扱う内容はエンジニアであるお客様がつまずいた「技術的に難しいところだけ」おいしいとこどり食べ放題
    • 「サポート」を「エンジニアリング」する、多くの改善余地のある創造的な作業が多め
    • 例えばプログラマ関連だと、WebとDBとの橋渡しをするだけのコード書きや(デザインなどの創造的な作業ではない)単調なレイアウト修正などの作業はない
  • お客様と目的のベクトルがスタートラインから100%一致
    • 「特定の問題を解決する」というゴールが最初から共有されている仲間同士
    • お客様の期待にこたえたい
  • 解決するとすごい喜ばれる
    • いっぱい「ありがとうございました」がもらえるというモチベーション
  • 難しい問題をトラブルシュートできたときの爽快感
    • ビールがうまい
  • スキルがぐんぐん上がる

いろいろ残念なパターンも

  • 技術レベルのギャップ
    • サポートに問い合わせしてくる技術担当者の技術レベルが低すぎる場合
    • サポートに問い合わせしてくるお客様が子会社の実際のシステムの技術担当者じゃなく、親会社で人員管理中心の技術素人だったりして話が通じない
  • Man in the middle問題
    • 実際のシステム担当者 <-> 問い合わせしているお客様 <-> サポート担当者 という構造で間にはさまってる人のせいで速度低下やコミュニケーションロスや諸々いらない問題の発生
  • コミュニケーションスキルのギャップ
    • 日本語がうまく通じないお客様
    • 勝手にあさっての方向へ飛んでいくお客様
  • サポートを提供する中でサポート担当者に人的ミスがあった場合に善後策を求めてくるお客様の議論
    • 聞き間違い、言い間違い、書き間違い、理解の間違い、勘違い、その他もろもろ
    • リーズナブルな善後策はほぼ無いと言える
    • 人員倍増して全てをダブルチェックしろ、とかたまに無理なことを言い出すお客様が居るのでうまくかわす
    • 善後策がどうこう、ってしている間リソースが食われて結局問題の解決が長引いてお客様もまったく得しないパターンが多い
    • 上司っぽい人や営業などにそれっぽいメールなどを書いてもらって早めに収束させる
  • なぜか最初から敵意むきだし、非協力的、高圧的、興奮している、というようなお客様
    • サポートとしては迅速に問題を解決したいだけなのに
    • 回答の文面とかのアラ探しして難癖をつけたりすることに集中してくる、根拠なく疑ってかかってくる
    • 対策のひとつとして(本当は教えたい参考情報がいっぱいあるのだけど)なるべくお客様に提供する情報を絞る、安易に仮説や可能性の話をするのは厳禁
    • 淡々と確定した事実のみをベースに着実に進める
    • 意図的に回答まで時間を置いて、少し場を落ち着かせる
    • 他の対策として(やはり解決速度は遅くなりがちになるけど)サポート担当者を変えてみる
  • 不条理なお客様
    • 正当なサポート契約持っていないにもかかわらずキレ気味
    • 普通に考えてどうにもならないことをどうにかしろとしつこく迫ってくる
    • 契約外の要求をしてくる
    • 「回答はこういう形式にしろ」というように、お客様の会社の文化を押し付けてくる
    • 製品として用意されていないカスタムドキュメント作成などの「作業」を丸投げしようとする (サポートサービスは一般的に知識の提供の契約であって時間のかかる作業の代行を提供するサービスではない)
  • 学習しない
    • 同じことを何度も聞いてくる(質問担当者が違う場合もある)
    • 何度もサポートをご利用経験があり、何が必要なのかわかっているはずなのにログや設定ファイルを送ってくれず単純に「動きませんでした」
  • 日本人のフィードバック傾向
    • サポートで滞りなく問題が解決した場合、まったく問題のない場合に星5つ、星4つのフィードバックが欲しいのだけど、良い場合にはそもそもフィードバックをしてくれない
    • ちょっとでも悪い点があると星1つのフィードバックを送ってきてくれる
    • 「良いことに対するフィードバックをしない」文化をどうすればよいか
    • サポートWebシステムの各コメントに「いいね」ボタンを設置するのはどうか

サポート側が残念なパターン

  • 技術力がない
  • コミュニケーション力がない
    • 日本語通じない
  • 役に立たないテンプレ回答
  • たらいまわし
  • やたら待たせる
  • 「できません」「サポート外です」という回答で代案や次のアクションの提案なし
  • 技術的正論を振りかざすだけでお客様の立場や状況に理解がない

Red Hatどうよ

  • マッサージチェア、おやつ食べ放題、のみもの飲み放題あります
  • 大体社員に開発者が居るのでサポートエンジニアはわからなかったら単に開発者に聞けばいい
  • ログが必要だったり設定ファイルの受け渡しとかがあるのがほとんどなので電話はあまり使わない
    • 一般的なコールセンタ、のような雰囲気の仕事ではない
    • アーキテクチャや設計のアドバイスやぼんやりした質問は電話でも良い
  • サポートサービスはRed Hatのビジネスの根幹
    • ビジネスの中心をささえているというやりがいがある
    • サポートでお客様から頂いている対価からオープンソースソフトウェアの開発者などのお給料が支払われてさらに世界が成長するというエコシステム
  • 技術力みんなふつーにすごい高いです
    • 周りにLinuxカーネルとか深いレベルで理解してる人とかこういうときって何使えばいいんだっけ、みたいな質問にぱっと答えられる人がわんさかいるので便利

オープンソースであること

  • オープンソースは教育
    • ソースがない場合と比べ物にならないほど利用者のエンジニアリングスキルを最大化する
    • 「もっと知りたい」を阻害することは人類の進化の阻害
  • お客様がパッチを送ってくることがある
    • オープンソースであることのメリットを最大化するパターン
    • 素晴らしいお客様なのでサポートの回答でも参考情報とかできるだけ多めにインプットする
  • お客様にソースコードのURLを渡して「このメソッドのこのif文がバグです」と言える
    • 一方クローズドソースのサポートはサポート担当もソース見れなかったりするので五里霧中の空中戦が多め
    • クローズドソースのサポートは(特定製品のドキュメントの読み方、とかソースが無いという制限の中どう立ち回るか、みたいな変なスキルを除き)あまりエンジニアリングスキルが向上しなくてかわいそう
    • クローズドソースのサポートはブラックボックステストのスキルは向上するのでテストエンジニアへ転向というパスは現実的
  • オープンソース製品は「これ以上はうちでは調べることができません」という言い訳不可
    • 調査に必要な情報が取れないという場合を除き、調査不可、となることはない(必要なログが取得できない、再現しない、お客様の環境特有、msec単位のピンポイント情報が取れないと調査できない等)
    • SIerではこれが理由でオープンソースを採用することができない、というところも
  • ナチュラルに全Webがナレッジベース
    • ぐぐれば同じ問題の報告とか解決策とかいっぱい
  • オープンソースのサポートビジネスって儲かる?
    • 知識量がそのままサポートの質であり差別化の要素となる
    • 開発者、コントリビュータを雇っている、開発者の所属企業とパートナー関係にある、という以外の3rd partyサポートを独自展開しちゃったところは大抵ビジネスとしてはダメな感じ
    • 日本でも多くのSIerが手をつけてしまってジリ貧になってるパターンが散見
    • Red Hatはきわめて好調です

まだいっぱいトピックあったはずなので思い出したら追記します。

合わせて読みたい: 漢のコンピュータ道 - サポートエンジニアが経験から語る、論理的文章によるコミュニケーションのススメ