HDE Advent Calendar 2015 どうも一年ぶりです。宮本です。
HDE Oneの運用サポート部門の担当役員をやっております。
皆さん見ました？
フィギュアスケート。
羽生結弦君、すごかったですね。
４＋３のトウループのコンビとか圧巻でした。前人未到の300点超えも頷けます。すっかり羽生くんの時代です。
ただ、個人的には、同じ羽生でも、羽生結弦君よりは、羽生善治さんの方が好きです。ええ、将棋の。あっちはハニュウ君で、こっちはハブさんです。羽生さん、今年もすでに４冠防衛。私、たまに羽生さんに似てるって言われます。寝ぐせがちな髪型とか、そのへんが。
さて、今年のアドベントカレンダーは、そんな羽生話を織り交ぜながら、「仕事」の話でいこうと思います。
この図何の図？
HDE Oneというサービスの、サポートフロントをやっているメンバーが日々見ている社内Wikiページがあるのですが、そこのトップにはこんな図が貼られています。
これは、トラブル対応の時、サポートのフロントはまず何を考えて対応するべきか？をイメージするために、私がパワポでささっと作ったレーダーチャートです。
作られたのはHDE Oneのサービスがスタートした５年前。ですが、実際はもっと歴史が深くて、さらにそれ以前10年以上やってきたオンプレミスのテクニカルサポートの経験の蓄積を元に生み出したもの。
15年以上の歴史があるものなので、それなりの重みのある図です（自画自賛）。
なぜ私がこんな図を書いたかというと、まぁ、サポートのフロントに携わることが多かったからですね。
Advent Calendarで社長の小椋が書いたように、元々HDEの経営陣は3人がフラットに役割分担しながらやってきていた会社です。ただ、それぞれ得意分野は違っていて、創業から過去19年の中でもっとも多い役割分担は、小椋が開発して、永留が売って、もしお客様の欲しいものと行き違いがあれば宮本が謝るというパターンです。時々入れ替わったり、新しいメンバーが誰かの代わりを担ったりもしますけど。でも、しんがりをやることが比較的多いのが私でした。陰ではこっそり、CAO すなわち Chief Apology Officerと名乗ったりもしています・・・まあ、うちの社員は誰も知らないと思いますが。
サポートのフロント対応にはそれなりの権限が必要
お陰様で、最近は私が直接サポートフロントの場に出て行くケースは随分減ってきています。
優秀なメンバーのおかげで、トラブルにならないような仕掛けが色々できてきたこともありますし、同時にサポートのフロント対応に関する権限移譲が随分できつつあるということでもあります。
フロント対応する、場合によっては謝る、というのは、会社を代表しての対応となるので、それなりの権限を持っていないとできないことです。
トラブルになると、お客様側も権限が上の人が出てくることが多いですしね。お詫びに訪問したら偉い人が出てきたり、メールのやりとりの途中で偉い人がCc:に入ってきたりします。
優秀なセールスがいくら粘っても引っ張り出せなかったお客様の偉い人とコンタクトするケースがあるわけで、そういう意味では役得ともいえます。その対応を任せられるかどうか、それなりの権限がないと対応すらできないわけです。
ちなみにここでいうサポートフロントとは、開発チームを除く、お客様対応を直接するサポートのメンバーを指します。技術的な解決を必要とするトラブルは、サポートフロントではなく、開発寄りのチームがバックを担いますから、そこを含めた対応はまた別のロジックと権限が必要になります。
今回はあくまで、開発チームとお客様の間の隙間を担う、サポートフロントのチームとしての姿勢に関する話となります。
で、この図には何が書いてあるか？
さて、図に戻りましょう。
トラブルが発生した時、どういう姿勢で望むべきか？ 私が考えるには、４つの指標があります。それは、
「(a) システム停止等、運用影響度合い」
「(b) お客様のイライラ度合い」
「(c) HDEへの不信感」
「(d) お客様の技術的納得度へのこだわり」
です。
そして、お客様がどういう状況かを踏まえて、対応の姿勢を決めます。
運用影響が大きく(a)、且つ、お客様がイライラしている(b) 場合は、「ひたすらスピード重視」です。フロント対応としてどのくらい素早く返事を返し、頻繁にコンタクトを取るということです。
イライラ(b)＋不信感(c) がある場合は、「相手の立場に立っていることが伝わるようにする」です。もしかすると、開発側からお客様の意に沿わない回答が出るかもしれませんが、そういう場合でも、サポートフロントとしてはあくまで、お客様に共感を示し、技術的にはそういう回答にならざるを得なくて申し訳ないという意向がちゃんと伝わるようにコミュニケーションをすることが大切です。
不信感(c) もあり、且つ、技術的な納得度のこだわりが強い(d) お客様の場合は「丁寧にしっかり回答する」です。素早いが間違っている回答や、端折って理解しがたい回答が出てしまうと、状況はどんどん悪化していきます。少し時間をかけてでも丁寧にしっかり回答する姿勢を取ります。
お客様の技術的な納得度へのこだわりが強く(d)、且つ、運用影響の大きい(a)場合は、「正確な分析を心がける」ことが大切です。原因がきっちり押さえられ、間違いが無く、合理的な対策がなされる必要があります。
複数重なっている場合はその分考慮が必要ですが、「どれも大切だから全部やれ」というのは必ずしも正しくありません。
お客様によってベストが少しずつ違うのです。これは相手の会社によって、ということでもありますが、もう少し厳密に言うと、「お客様のシステム担当者様によって」ということです。
将棋に例えると（やっと出てきた）、羽生さんだって相手に合わせて戦法を変えるわけで、今年の朝日杯の決勝では渡辺明二冠を相手にまさかの中飛車で挑んで勝ったりしているわけです。ええ、あの一局は驚きました。天を仰ぐ渡辺二冠、思わず「えーっ」と声を出して驚く解説の山崎隆之八段、騒ぐネット上の観覧者・・・まぁ、それはともかく。
やはり、サポートの場合も羽生さんと同じく、お客様のシステム担当者に合わせて対応の姿勢を考える必要があります。
BtoCのサポートメソッドとは違う
さてこのあたりは誤解を招きやすいので、少し突っ込んで説明をします。
「お客様のシステム担当者」にフォーカスをするということは、「担当者をどうなだめるか」、という表面的なことではありません。それはBtoC（個人向け）ビジネスの場合にありがちな考え方です。HDE Oneは法人向けのサービスなので、とにかく話を聞いて不満を解消してあげればいい、というものではないのです。
システムのトラブル対応には、幾つものステップが必要です。トラブルの状況を説明する、アナウンスを流す、報告を一旦ドキュメントにまとめる、HDE社内でのエスカレーションもあれば、お客様社内でのエスカレーションもあります。場合によっては一度システムを切り離すとか、あるいは、調査にかける人手を増やす、といったステップもありえます。
これら多数のステップをどう編んでいくか？
これを適当に場当たり的にやるとうまくいきません。
"トラブル対応にはストーリーメークが必要"というのはITの世界では常識ですが、そもそもストーリーメークとは何かというと、これら多数のステップをきちんと編んでいくことです。
ストーリーメーカーは一人ではない
そして、ここは非常に重要なポイントなのですが、ストーリーメークする人は一人ではない、ということです。
もちろん、我々サポート側の担当者は、解決までのストーリーメークをしていく意識を持たなければなりません。そして、もうひとり、「お客様側のシステム担当者」もまた、ストーリーメークのお手伝いをしてもらわなければならないのです。
我々サポート担当者側では、お客様社内の内部事情や社内文化は分かりません。トラブルが発生した時に、それをどのようにお客様の社内で展開し、対応するのが最適かの情報は、我々側では分からないのです。
同時に、お客様側では、問題がいつごろ解消しそうかとか、技術的な難易度、再発の可能性の有無等については分かりません。なので、お客様側のシステム担当者だけでもストーリーメークは完結しません。
どうやって、手と手をとりあってストーリーメークをしていくか
要は、少なくとも二人で、トラブルにどう対応していくかのストーリーメークをしていかなければならないのですが、では、どうすればそれがうまくいくでしょうか。
ここからはさらに深く踏み込んでいきます。
お客様の情報システム担当者の思考回路を考える必要があります。
お客様の情報システム担当者も、よっぽど新人でない限り、トラブル対応の経験があります。
そして、トラブル対応に際して、どのようにストーリーメークするかのセオリー・流儀を、それぞれが持っているのです。粒度はバラバラです。漠然としたものしか持ってない場合もありますし、人によっては、かなり具体的に、ストーリーの建て方が決まっている人も居ます。
ストーリーメークの仕方が異なるということは、ストーリーを組み立てるための材料を揃える順番が違うということです。 ある人は、相手が信頼できるかをまず確認しないと先に進んでもしょうがないと考えるかもしれません。ある人は、担当者が真剣にやってくれるかどうかは関係ない、技術的にどうなっているかを最初に押さえなければならないと考えます。また別のある人は、仮に問題解決が進んでいなかったとしても、とにかく現在の状態をアップデートしつづける環境づくりが第一だと考えます。無駄な情報を排除してとにかく明快な説明を望む人もいます。解決に向かって流れていることが確認できれば、時間がかかっても耐えられる人。正確じゃない情報がインプットされると、その後訂正されても、脳内のロールバックが難しい人。一旦感情を吐き出さないと冷静に脳が働かない人。事実より、主観的な信頼感、印象を重視する人もいます。
どれが良い悪いということではありません。お客様の思考回路がどういう順番で情報を揃えようとしているかを察すること。ストーリーを組み立てる材料として、その人が揃えたいであろう順番で、情報をインプットしてあげること。それが、コミュニケーションの第一歩です。 その上で、サポート担当者の持っているストーリーと、お客様の情報システム担当者が組み立てようとするストーリーをすりあわせて、一つの物語にするのです。
将棋の対戦も対戦するそれぞれが得意とする戦法（ストーリー）は違います。そして、二人のストーリーがぶつかりあって、歴史に残る名勝負が生まれます。
何度となく羽生さんと戦った谷川浩司永世名人はこんな言葉を残しています。
「羽生さんには随分と痛い目に遭いましたけど、彼のお陰で私も高めてもらった。名局は二人で作り上げていくものです」
それと同じように、システムのサポートとは、サポート担当者とお客様の情報システム担当者の二人が、それぞれストーリーを持ち寄って一つの物語を編むことである、というのが私のサポート観です。
そしてそのための、第一歩を踏む姿勢の取り方を直感的に表したのが、先のレーダーチャート図です。
たまに、
サポート担当者と、お客様の情報システム担当者のやりとりに、お客様の上司が割って入ってくることがあります。
そういう時は、仮に二人の物語がある程度組み上がっていても、一からやり直しになります。
なぜなら、持っているストーリーメークの流儀が違うから。その場合は、我々サポート担当者は、新しく出てきた上司に合わせて、先ほどの図を再度見なおし、新たな相手と新たな物語を紡ぎなおさなくてはなりません。
挑むべきサポートのシステム化／自動化について
サポートも、ある程度お客様が増加してくると、システム化をしていかなければなりません。無限にサポート担当者を増やすことはできませんので。しかし、システム化してしまうと、得てして、対応が一面的になり、不満をもつお客様が一気に増えがちです。
だからこそ、どういう場合にはどういう対応が必要か、というセオリーをある程度見極め、それをサポート自動化のシステムに組み込んで、サポート対応が一面的にならないようにすることが必要です。
HDE Oneもありがたいことにかなりお客様が多くなってきています。多くのお客様にどう満足していただけるか、そして、リーズナブルにご利用いただくには、いかに満足度を落とさずに効率化していけるかを考えなければならないフェーズに入ってきました。
これからの課題です。
もしここに興味のある方がいらっしゃいましたら、是非一緒に新しいサポートの体制を作り上げていきましょう。
ご連絡をお待ちしています。
というわけで、去年に引き続き、人材募集で幕を閉じさせていただきます。
お後がよろしいようで。
ありがとうございました。
