緊急時の呼び出し“オンコール”サポートの改善事例

前回、緊急時の呼び出し“オンコール”サポートを担当するチームの管理についてコラムを書いた。それに対して、読者から関心が寄せられ、成功モデルを実践したチームの実例を紹介してほしいという要望を受けた。そこで、チームのメンバー、責任者、そしてエンドユーザーのすべてが成功した例を紹介したいと思った。

そうしたなか、幸運にも Schwab Development の IT 担当マネージングディレクタ Mary Lavine 氏を探し出すことができた。彼女のチームでは、ほとんどがアプリケーションの開発に携わっているが、製品サポートを担当しているチームもある。

なかでも、CMS（コンテンツマネージメントシステム）のチームは、大変なサポートの重責を担っている。Lavine 氏は、経験豊富なシニアマネージャの Mei Wan 氏を紹介してくれた。Wan は CMS 分野に詳しく、チームが厄介な状況に陥りかけていることを知っていた。彼女のチームは、開発、ツール、システム管理、技術およびビジネスサポートを担当していた。四六時中電話を受けっぱなしで、息する暇もなかったという。

Wan 氏に、チームのメンバーで苦情を訴えに来た人がいなかったのか尋ねてみた。Wan 氏は「数を把握しきれないほどたくさんいた」「誰一人として幸せな人も、成功した人もいなかった」と答えた。

複数のチームのメンバーが彼女のところにやってきては同じメッセージを伝えた。「仕事があまりにも多すぎる。24時間体制で夜も週末も働いていて、それが日々同じペースで続く。顧客に納品しなければならない案件があるのに、われわれの仕事は予定よりもずっと遅れている」。それは、マネージャが変更を行わなければ、チームのメンバーを失うことを意味するメッセージだった。

「こうした訴えを聞いた後、この問題を解決して事態を改善するには6か月必要だと、私は Mary に伝えた」と Wan 氏は語った。Lavine 氏も Wan 氏も、開発者たちが危機一髪の状態で踏ん張っており、環境が改善されなければ彼らを失うことになるということで意見が一致していた。「彼女のチームを支援することに賛成した。もし、得意先から十分なサービスを受けていないという苦情があれば、われわれは確実に前進していること、そして時間稼ぎをするために大きな改善がなされていることを示すつもりだった」と Lavine 氏は語る。

またふたりには、どの開発者も、他の人と入れ替えることがほぼ不可能なほど、システムの知識を持っていることがわかっていた。「彼らはそれぞれ重要な中核技術を持っているため、誰かひとりでも失えば、事実上システムを失うことになると感じていた」と Lavine 氏は言う。「代わりの人を雇って訓練するのにかかる数か月の間、どれほどの仕事を失うことになるか分かっていたので、変更を行い対応する決断をするのは簡単なことだった。まして、そうこうする間の専門技術の穴埋めとして、チームのほかの人がさらに限界以上に頑張らなければならなくなることは、言うまでもなかった」。

Wan 氏は、サポートの状況が改善できたか反応を聞いたり、開発者それぞれの声に耳を傾ける時間を取るようにした。「彼らは何かしろと言われたら手際よく対応できる賢い人たちだ。私はより良いサポート手順を生み出すために彼らの考えを活用しただけ」と Wan 氏は言う。彼らの考えを聞き、小さな成功を見つけることで、彼らとの信頼を確立し、その結果問題を解決するための時間が増えたという。

サポート電話を分析してみると、大半の問題については解決に開発者が必要でないことがわかった。まず初めに Wan 氏が手がけたのは、これらのシステム管理サポートの任務を、もっと適任のグループに割り当てること、例えばサーバーの再起動は運用スタッフに任せるといった具合に。より重要だったのは、営業時間外の一段階目のサポートを、海を越えてインドで行うという決断をしたことだ。

しかし海外で行うには多くの課題があるため、Wan 氏はチームが完全に関わりを持てるよう特別な努力を払った。Wan 氏によると、「開発者たちは海外チームの選別に参加したがっていた。なぜなら、より質の高い人を集めれば、長い目で見た場合、サポート業務の軽減につながることが彼らにはわかっていたからだ」とのこと。開発者たちは自らインタビューを実施して新しいチームを訓練した。インドに出向いたこともあった。それから海外チーム全体をアメリカに呼んでトレーニングをさらに重ね、チームの同化を図った。

開発者は二段階目のサポートを行うのに、週代わりでローテーションを組んだ。彼らはすでに、オンコール任務に付いた週は10％給料を割り増しでもらっていた。また Wan 氏はもっと細かい点についてもいくつか変更した。「率直に言って、開発者をもっといたわりたかった」と Wan 氏は言う。より仕事と生活のバランスが取れるように、在宅勤務を可能にした。こうすれば、一晩中問題解決に取り組んだとしても、翌日出勤するために早く起きる心配をしなくてすむ。

サポート電話の悪いサイクルに巻き込まれ、あまりに多くの時間をサポートに注ぎ込んだ人がいた場合はどうなるのだろうか。「代休を与えたり、特別な場合は金銭報酬を与えることも可能だ」と Wan 氏は語った。

Lavine 氏が重要な点に同意を示した。「気をつけなければならないのは、大げさに報奨を作って状況を悪化させないことだ。このような悪いサイクルが数か月にわたって続くようなことがあれば、プロセスに問題があり、対応が必要ということになる。個々の問題に対してではなく、プロセスを改善できたことに対して報酬を与えたいと思うはずだ。理想的には、電話の数を減らし内容の重症度が軽くなるような妥当な検査、配備、そしてサポートのプロセスを奨励したい」。

またチームは、得意先からサポートを依頼した問題はすぐに解決されるとの信頼が得られるように、多くの時間をかけてサービス内容合意書を作り、サポートプロセスを明確にした。こうすることで、プロセスの迂回を避けることができる。というのは、得意先の人がプロセスに信頼を置かなければ、オンコール任務に付いている人付いていない人おかまいなしに、問題を解決できる専門家に連絡を取ろうとするからだ。

最後に、開発者にとって魅力のあるプロジェクトを増やした。「現在試験的に Ajax を使ったプロジェクトを進めており、これはチームの真の能力を活用できる本当にやりがいのあるプロジェクトだ」と Lavine 氏は言う。

つまり同社の場合、サポートの負担を軽減し、仕事場により融通を持たせ、よいプロセスを確立し、そしてスタッフのキャリアを高めるようなやりがいのあるプロジェクトを提供したのだ。勝利の方程式のように聞こえる。

Lavine 氏に、サポートの地獄に陥っていて状況を改善したいと願うマネージャが何から始めればよいのかを尋ねてみた。

Lavine 氏の提案は以下のとおりだ。まず経営上層部向けに、ビジョンを記した報告書を書くこと。「解決すべき問題は何か、そしてビジネスに与える影響を明確に示すこと。そしてどんな成果が期待できるのか、例えばよりよいサービス内容合意書を取り付けられるとか、退職者が減るとか、生産性が向上しコスト削減になるといったことについて話をする。上層部に内容を説明し、解決策を探求することは決して損にはならない。われわれの会社では、CMS の基盤を安定させ、上層部に行き着くことのなかった勤労意欲の問題に対応した」と Lavine 氏は言う。

次に、いかにより安定した環境を作り、退職者を減らし、質の高いアプリケーションを届けるかについて、具体的でレベルの高い実践的な計画を行うよう勧めている。「これらの事項をすべて、重要なポイントに絞って一ページ程度にまとめ、このような変更をしなかった場合ビジネスにどう影響を与えるのかを明確にすることだ」と Lavine 氏は言う。

最後に、ビジョンと計画を提示する前に、ビジネスパートナーと話をする時間を持つように勧めている。「得意先がすでに賛成した計画を持って IT の経営上層部のところにいけば、承認を受けられる可能性が増える」と Lavine 氏は言う。

現実的に、オンコールの地獄から自ら抜け出すための方法とは、こんなところだ。お分かりいただけただろうか。