ソフトウェアサポートエンジニアDaio net Eiji Kawakita

まずお断り• 過去現在の所属組織固有の話はしません• あくまでも共有可能な内容のみです• 個人的主観に基づいています• サポート専業じゃない人への参考になれば

自己紹介• 川北英治• japan.kissa.mountain の人 • 本業 ソフトウェアサポートエンジニア→某社ということでお願いします。• 趣味 トラブルシューティング• Facebook: woyadi28mamedeka• Twitter: @MAMEDEKA

アジェンダ• サポート• サポートと人生相談• クレーム• サポートエンジニア育成• サポートエンジニアの勉強会活用

自社サポートサービスの売り• カタログスペック

• 業務経験豊かなエンジニアの対応• 手厚いサポート• 迅速な対応で 24 時間 365 日対応

• 自分で説明できるか

なにを提供するかの基本情報• サポート契約• サポート規約• サービス仕様→正しく作成されて共有されていますか

サービス仕様• サポート契約、規約から抜粋• 提供するサービスおよびサポートについてどういう項目とレベルの物を提供するか• 何処迄が責任範囲か• サービス時間

サービス仕様項目• 前提条件 ( 契約、登録された人 )• 問い合わせ者の知識レベル• 責任範囲• サポートからの提供物• 連絡方法 ( 電話、メイル、チャット、 Web)• 問い合わせ完了条件

サポート時間• 対応時間

• 8x5 、 24x7• 初期応答時間

• 2 時間以内、 48 時間以内• 復旧リミット→通常お約束しないが契約依存

責任範囲外• ライセンス外の環境• サポート外環境 ( ヴァージョン等 )• 作り込み部分• 他社製品との組み合わせ• 改造した場合

一般、無料ユーザ対応範囲外• コンサルティング• 運用手順• 改造、作り込み部分• パフォーマンスチューニング • 他社製品との組み合わせの問題

製品範囲外• 環境の問題や他社製品に依存する問題• 使っていい業務

• 人体に影響• 発電所とかの重要設備での使用• 国の制限

サポート外の部分• SIer 対応• コンサルティング対応• 営業対応• 人生相談

→すべて追加でお金とれる所では ?切り分けが出来るならビジネスチャンスに出来る

問い合わせ開始• 契約確認• 状況把握• 要求把握• 切り分け• 対応記録

調査• 問題としている動作は何• 設定• ログ解析• 時系列• 状況を把握• 発生する条件、発生しない条件

問い合わせ終了• サービス仕様等で終了条件定義

• 既知事象であることをお伝えし対応策提供• 修正提供

• 正式対応モジュール、パッチ提供• 一時的対応モジュール提供

• ワークアラウンド提供

問い合わせ終了 ( 未解決 )

• 新規事象• 未解決• バグ対応受付• 改善要求受付• 合意出来ない場合

• 対応まで問い合わせを継続

事象再現しない場合• 実環境のみ発生する場合

• 次回発生時の取得情報すりあわせ• 影響度のすりあわせ

• 再現待ちで一旦クローズ• 政治的な意味での継続対応

サポート業務の特質• 問い合わせケースベース• 同時に数十件並列対応• カットオーバーやローンチは無い

対応記録• 入電日時• 連絡者• 問い合わせ内容• 担当者• つかった既知情報、リソース• 終了日時

対応記録の活用方法• 対応記録の検索• 既知事例の検索• 特記事項の共有 ( クレーマーとか )• 外部のリソースへの依頼先情報

対応記録目的• 過去の事例の記録• 特別な対応• 固有の対処手順• 負荷の計測• クレームの数と質→解析して今後使えるものになる

DevRel 的観点• サポートの対応をモニタ• ユーザとの直接的やりとり• 実際にユーザとの対応をしてみる• ニーズの汲み上げ• ユーザとの交渉

こんな問い合わせありますよね

• 動かない ( 以上 )• 何もしていないのに壊れた• 動かないけどなにをやったかわからない• 5年前に買ったものが Windows10 で動かない• うちの環境では機能がたりない

• こういう動きをしないのはおかしい• 根拠は無いけど、ここがおかしいはずだ• 技術屋だからわかるように説明できるはずだ• 絶対におたくの製品が悪い• なにがおかしいかわかるでしょ• そんなのしらない

• 使い方全部おしえろ• 自分は使わないけどユーザがつかう• 絶対におたくの製品が悪い• ツーとやってクリクリしたら動かなくなって、なんかわからない英語がでた

人生相談• 結局はお客様が解決する問題のヘルプ• お客様はその問題を解決したいのかわからない• 同僚、上司、お客への説明をどうするかが不安• 本来の問い合わせ先に聞けない状況• 本当に本当にそれ自分たちが解決する話 ?• 愚痴いいたいだけの場合もあり

サポートの立場• お客様と社内担当者との間で調整

• お客様側から見たらサービス提供側• 社内に向けてはお客様側

• 立場の帽子を適切に変える事が必要• スケープゴートになる覚悟

• 納得してもらう為にやむなく

サポート組織• サービスレベル

• 担当者によって違う対応をしない• お客様によって違う対応をしない

• 契約に従った対応• 無料ユーザ、有料ユーザ、上位契約

• サービス仕様の徹底• 「契約は契約だ」

サポートエンジニアの資質• タフである• スルー力がある• 自社製品以外との事象切り分けの能力• 時間と重要度の管理• 帽子を切り替え出来るか• エスパー、占い師、千里眼 ( 的な察する能力 ) も必要な場面も

クレーム• 正当なクレーム• 不当なクレーム

正当なクレーム• 製品不具合• 性能不足• 機能不足• 不適切販売

不当なクレーム• 製品範囲外機能• サポート外利用• コンサルティング対応• 有料ユーザ、上位契約ユーザ用サービス要求• チート対応、金銭要求• 社外秘開示要求

日本固有対応• 対処提案から実際の実施までの時間が長い• 他部署との調整• 日本の場合調整で数ヶ月から数年• 海外は提案された修正を即時本番環境へ対応→ DevOpt 的• ベンダでの事前テストの要求

日本固有の背景• 不具合の責任→ビジネスインパクト• 説明責任→技術者以外への説明• パッチ、 WA 等への影響の事前確認• 特別対応として有料サービスの無料対応要求

サポートはコストセンタ ?

• お金に直接結びつかない• コンサルティングへの領域侵害

• 丸投げする場合もある• サポート費用は製品価格に含まれる固定費

• 1年以上は追加費用• 問い合わせ毎に費用請求 ( パーコール契約 )

コスト• お客様のコスト• サポート組織のコスト• サービス提供者のコスト• SIer のコスト

コスト• コストをどれだけ最小化するか• 対応時間の短縮• お客のビジネスコストを最小化• 今後の拡張に反映• ビジネスインパクトの共有化

コスト対策• 対応の定型化

• 手順書、技術文書公開• 入電しないでユーザ側での自己解決

• オフショア、ニアショア

コストに対する成果物• ユーザの不満と要求のリサーチ• 入電傾向• 緊急対応等の傾向と対策

エンジニアの育成• サービスや製品の問題は組織の責任• 担当者個人の問題ではない事を理解する• すぐに経験者へ相談出来る体制• 責任者によるフォロー• 属人化しない

担当者疲弊対策• ストレス対策• 知識の共有化• 迅速な情報検索• 適切なツール• 壊れない為に負担を減らす

日々どう鍛錬するか• 場数を踏む• チームで事例共有• Wiki 等での知識共有• 過去ケースの蓄積と共有• 公開情報の作成• ロールプレイ

正確な情報収集• 情報収集ツールの提供

• 細かい情報を依頼するのではなく一括収集→後から依頼する場合の抵抗が大きい• 詳細の隠蔽• 手順のルーチン化、自動化• OS などの関連情報も収集

技術情報公開• 社外向け技術情報公開• 事例紹介と公開• 社内向け情報の蓄積• 社外に出さない情報の選定• 特定の人に集中させず属人化しない

組織作り• 個人、特定のチームで抱え込まない• 相談体制• 責任範囲の明確化• 対応、知識の標準化• 他部門との連携

サポートの利用方法• 適切な問い合わせ• クレームの入れかた• 逆にサポートはどうあるべきか

問い合わせ側の時に• リクエストされた状態のデータを提供• 標準環境での再現性• 回答は自分でも確認• 丸投げはしない。中継だけの人は有害

クレームの入れ方• 通常サービスで出来ない理由の明確化• 出来ない事によるロスの可視化• 感情的にならない• 別サービス乗り換え示唆は良し悪し

サポート部門側対応• 対応方針の共有と標準化• 試行錯誤するところを見せない• 情報収集は出来るだけ一回• 実際の生データをもとに対応する• ユーザ主観はあくまでも参考• 電話の聞き取りでは正確ではないのでメイルなど記録がのこるように

社外リソース• 勉強会

• サポート手法などの勉強会は少ない• 守秘義務により出席が難しい• 会社によってはやっている場合も

勉強会活用• 勉強会

• 発表に対する質疑応答• 自分だとどうするかのシミュレート• 発表中に質問事項の吟味• 受け答えの想定

質問の注意点• 相手が答えられる内容を質問する

• マサカリ禁止• 顧客のレベル把握、温度管理の実践

• Win-Win• 質問するのだから相手に有益な内容• 知識や手法の提案と共有

SNS 活用 (FB)

• 炎上させないように内容を吟味する• ニュースソース、ルートコーズ確認• 拡散希望は変質するので情報源確認• 共有関係も誰に共有するかを自覚する• FB 共有範囲は「友達の友達」がお勧め• 誰の友達かで傾向を確認し対応する• 議論をしましょう

まとめ• サポートのやること• サポート利用するときにやること• 日々の鍛錬への勉強会や SNS の利用• 相談出来る場が少ないので共有しましょう

自己紹介• 川北英治• japan.kissa.mountain の人 • 本業 ソフトウェアサポートエンジニア• 趣味 トラブルシューティング• Facebook: woyadi28mamedeka• Twitter: @MAMEDEKA