この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
どうも。データアナリティクス事業本部@大阪オフィスの玉井です。
私はDA事業本部のプロダクト営業部のテクニカルサポートチームというところに所属しています。テクニカルサポートチームは、 Tableau や Alteryx 、 CSA といった、データ分析に関する製品の技術サポート（一問一答形式）を行っています（弊社から製品を提供しているお客様が対象）。
で、私はそんなチームのリーダーを担当しているのですが、「そもそもリーダーってなにすればええんやろ…」っていう状態のままのんびり過ごしてきました。いよいよ流石にこのままではアカンと思い、「そういえばチームの基本方針とか行動指針とか使命的なものって何も決めてなかったな」って状況だったので、ちょっとチームの行動指針をちゃんと立てることにしました。
本エントリの前提
これは私の単なる思いつき
本記事に書いてることは私が自分で思いついたものでしかありません（一応チーム内では展開済、内容について合意済です）。自分で思いついたことを人目につくところにアウトプットすることで、自分の考えを整理しているだけです。例えば他のテクニカルサポートやカスタマーサポートに必ずしも適用できるものではありません。っていうかむしろ他にいい考え方があったら教えてほしいです。
テクニカルサポートチームの使命を考えてみる
我々が顧客に提供できる価値
テクニカルサポートチームは、お客様が抱えている問題・課題・疑問等を解決するのが主業務なので、それがそのまま提供できる価値と考えました。お客様から見ると「（自分たちが）抱えている課題が（弊社サポートのおかげで）解決されること」が価値ということです。
価値を高めるためには
「価値」が何なのか定義しましたが、その価値を高めていくにはどうすればいいのか…。価値を高めるためには、価値が向上させるための要素を特定して、その要素を高めていく必要があると考えました。
色々あると思いますが、ここでは「課題が解決するスピード」を、価値を高めるための要素としました。お客様にとっては、抱えている課題の解決は、早ければ早いほど嬉しいからです。
「回答の質」とかも考えることができますが、「その回答の質が良いかどうか」を（最終的に）判断するのはお客様です。こちらがめちゃくちゃ頑張って回答した内容でも満足いかないお客様もいれば、こちらがほとんど苦労せず回答した内容でも、お客様によってはとても助かる内容だった…ということも有り得ます。お客様に依存する要素（サポート提供側があまり介入できない要素）を追いかけるのは難しい（というか不毛）…と考えたので、こういった要素は省きました。
また、結局のところ「1秒でも早く解決する」ためには、「そのお客様にとって質の良い回答を迅速に届ける」必要があるので、回答内容を疎かにすることはないかな…と考えました。
つまり…
（現時点では）「お客様の問い合わせを解決するまでのスピードを短くする」ことを最優先事項として追いかける方針としました。
課題解決のスピードを早めるために
KPIの計測
うちのテクニカルサポートチームはZendeskを使用していますが、Zendeskは下記の方法でデータ分析することができますので、これらの方法で「課題解決のスピード」に関する指標（初回返答までの時間や、最終的に解決するまでに時間）を定期的にウォッチしています。
「スピードを上げるための」問い合わせに対する行動指針（対応方針）
上記で計測している指標（=課題解決までのスピード）を早めるためにはどうすればいいかを考える必要があります。
私は「問い合わせを何種類かにカテゴライズして、その種類毎に対応方針を定める」ということを考えました。「この問い合わせは○○だから、こういう風に対応することで早く解決できるYO」みたいな方針を作りたいということです。もちろん、完璧なカテゴライズなんてできませんし、結局は問い合わせ内容1つ1つで異なってはくるのですが、対応方針が全くない状態とある状態では、やはり対応スピードに差が出てくるのではないかと考えています。
では、問い合わせの種類をどうやって分けるのでしょうか。ここでやっとクネビンフレームワークが出てきます。
クネビンフレームワークとは
ぶっちゃけると、ググったら解説記事がいくらでも出てきます。
- 問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩
- クネビンフレームワーク Cynefin Framework – I & COMPANY / アイ＆カンパニー
- カネビン・フレームワークで問題解決策を見極める
- Cynefin framework - Wikipedia
一応ここでも簡単に説明すると、問題を4種類（プラス1種類）に分類するためのフレームワークです。問題と原因の因果関係に着目して分類するのが特徴です。
ITの現場だと、このフレームワークは、アジャイル開発の文脈でよく登場します。しかし、（私が調べた限り）テクニカルサポートやカスタマーサポートにこのフレームワークを使っている例は見つかりませんでした。だから、自分で考えるしかない！…ということで、実際にやってみます。
クネビンフレームワークで問い合わせの種類を4+1に分類してみる
Simple（単純）
どういう問題か
- 因果関係が明確
- 誰にでも分かる
- ベストプラクティスが使用できる
該当例
- Tableauで緯度経度情報を地図にプロットする方法がわからない
- Alteryxのライセンスアクティベーションの方法がわからない
対応方針
問題に対するベストプラクティスがわかっているため、ベストプラクティスをいかに早く顧客に届けるかを目指します。
- 予めた用意されている回答のテンプレートを送る
- 自分用のメモからコピペする
- Zendeskのマクロ機能を使用する
- ZendeskヘルプセンターにFAQを作成してそれを案内する
- 問い合わせ前に読んでもらえるのが理想
- 弊社ブログに既に存在する記事を案内する
Complicated（困難）
どういう問題か
- 因果関係が複雑
- 解があることはわかる
- 専門家が分析してグッドプラクティスを提供することができる
該当例
- Tableauでバーンダウンチャートを作ることはできるか
- Alteryxで、あるWebページをスクレイピングすることはできるか
対応方針
技術的な難易度はあれど解決できることはわかっているため、短期的にはナレッジ・人を頼ることによる解決を、長期的には自身のスキル向上による解決を目指します。
- 弊社ブログに技術エントリを投稿する（スキル向上）
- 詳しい人が残しているナレッジを確認する
- 社内資料
- インターネット上の情報
- …など
- 社内の詳しい人に聞く
Complex（複雑）
どういう問題か
- 因果関係が複雑
- 解があるかどうかわからない
- 分析や調査を繰り返し計画・実施して、解（プラクティス）を導き出す必要がある
該当例
- Tableauが急に止まった
- Alteryxで作ったワークフローがエラーで動かない
対応方針
課題の解決が可能かどうかは、実験・調査しないとわからないため、まずは顧客側で発生している問題のヒアリング・再現を行い、問題自体をComplicatedに落とす（移行する）ことを目指します。
- 問題が発生しているリソースの受領
- 問題が発生した状況
- ワークフロー
- データソース
- 製品ログ
- エラーメッセージ
- スクリーンショット
- …など
- 受領したリソースを用いて問題の再現を試み、Complicatedに落とせるかどうか判断する
リソースの受領については、（Zendeskの場合は）問い合わせフォームの時点で（ある程度は）初回の時点で入力させる等の設定を行うことができます（状況やエラーメッセージなど）。というか、逆に聞けることは先に聞いておかないと、後々お客様とのやり取りが増える=解決までの時間が伸びる=基本方針を満たせない…となってしまうので、問い合わせフォームまわりの設計は、実は大事なんだと思いました。
Chaotic（カオス）
どういう問題か
- Complex以上に因果関係がよくわからない
- 分析や調査の計画すら組めない
- 計画の前にまずは行動（対処）することが求められる
該当例
- 何を言っているのかわからない問い合わせ全般
- 何を解決したいのかわからない
- 何に困っているのかわからない
- …など
対応方針
顧客が抱えている課題自体がよくわからないため、根強くヒアリングを行い、問題種別をComplexに落とす（移行する）ことを目指します。
- 粘り強く会話を続ける
- 一人で悩まず、周りのメンバーに相談してみる
後者が特に重要だと考えます。サポート業務は1問い合わせに対して（基本的に）1人で対応するので、「チームで解決する」という視点が失われがちです。Chaoticは、向き合う領域が技術ではなく完全に「人」なので、調査や検証等では解決しません。お客様が本当に困っていること何なのか…それを聞き出すにはどうすればいいのか…こういったことは、1人で悩むより複数人でガッ！と相談したほうがはやく解決できることもあると思います。
Disorder（無秩序）
どういう問題か
- 問題分類（上記4つ）すら不可能なもの
該当例
- サポート対応範囲を逸脱しているもの
対応方針
サポート対応が不可なので、関連する別チームのメンバー（営業メンバー等）と連携して対応します。
上記を踏まえた上でのテクニカルサポートチームの行動指針
基本
- 「お客様の問い合わせを解決するまでのスピードを短くする」ことを意識する
- 上記を意識した上で、サポートエンジニアは以下を踏まえて業務にあたる
- 担当する問い合わせが上記4種類（プラス1）のどれなのかか判断する
- 種類に応じた対応方針に従って対応する
SimpleとComplicated
（基本的に）やること（回答してあげる内容）が既に明確なので、1秒でも早く回答を行うことを目指します。また、この2種類に該当する問い合わせを迅速に処理することで、ComplexとChaoticに対応するための時間を稼ぐことができます。
ComplexとChaotic
（基本的に）やること（回答してあげる内容）がわからない状態なので、1秒でも早く種別のレベルを1段階落とす（移行する）ことを目指します。この2種類に関しては、解決スピードは一旦捨て置き、じっくり取り組んでレベルを落とすことに注力します（SimpleとComplicatedを瞬殺した分、こちらに時間をかける）。
「1秒でも早く」と言いながら「解決スピードは一旦捨て置き」…と、言っていることが相反している気がしますが、この2種類の問い合わせはとにかく内容が複雑なので、じっくり腰を据えて取り組む必要があると考えます。複雑な問題に焦って対応しても、問題は解決しないまま時だけが過ぎていく一方なので、結局「最終的に問題が解決する」までの時間は遅くなっちゃいます。だから「じっくり腰を据えて取り組む」ほうが、かえって「問題のレベルを落とす」スピードは早くなり、その結果「1秒でも早く問題を解決できる」ようになると考えています。
リーダーができること
これまで書いてきたことは、実際に問い合わせに対応するサポートエンジニアに関する内容です。リーダーは何をすればいいでしょうか。
サポートエンジニアが上記の行動指針を貫けるようにサポートしてあげる…言い換えると、これらの行動指針の妨げになりそうな事項を片っ端から排除していくのがいいのかなと思いました。…具体的な例は思いつきませんが、サポートエンジニアから「○○という理由でこの問い合わせが解決できない or 解決に遅れが生じている」という声が上がったら、早急にそれに対応しないといけないでしょうし、こちらから能動的にそういった問題を確認していくのも重要ですね。こういうこと書くとリーダーのハードルが上がりそうで怖いですね。
おわりに
本エントリの執筆理由の90%くらいは自分のためのメモでしかないですが、残りの10％は「もしかしたらこれが役に立つ人がいるかも…？（別にいなくてもいいけど）」という事も含まれています。
書いてて思ったのですが、Deleloppers.IOってサポート業務にもすごく活用できているので、「万能なメディアだなあ…」と改めて感動しています。
4
