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

業務連絡

仕事のこととか

要望と実装の間に人生がある、という話

こんにちは、はてなの中川(id:riko)です。この記事は、はてなディレクターアドベントカレンダーの6日目となります。(昨日はid:onishi「編集チーフになってやったこと」でした。)

私はサポート部の部長で、はてなでは「ディレクター」という職種についたことはないのですが、開発チームで言えばディレクター的な立場ということなのでこの企画に参加しています。
advent.hatenablog.com

私が入社したのは2006年なのでもう10年になりますが、はてなという会社に入りたいと思ったきっかけとなったのは、実は、今はもう終了したサービス「はてなアイデア」でした。(それまでも、はてなダイアリーとかはてなアンテナは使ってましたが)

当時の私は、ある大規模UGCサービスのサポート担当者を経て同じ会社が運営するガラケー向けECサイトのディレクターをやっていたのですが、サポート時代もディレクター時代も、ユーザーさんからいただく要望を、どうやってエンジニアに伝えて実装してもらうかに悩んでいました。そこで、はてなという会社が、予測市場方式でユーザーからの要望の検討順位を決め、エンジニアが公開ミーティングを行なってその音声をポッドキャストで公開しているのを見た時「この会社はすごい!」と思ってしまったのですね。

いろいろあって、結局のところは、その画期的な仕組みを終わらせることになってしまったのは非常に残念でしたが、振り返ってみてもアイデアという手法自体は良いものだったと思います。しかし、企業として成長するにつれて、他社の関係することなど、どうしてもアイデアミーティングという公開の場で議論することができない情報も増えてしまいましたし、ユーザーさんも交えてワイワイガヤガヤと議論するスタイルでは運用できなくなったのも、やむを得なかったのかもしれません。

hatena.g.hatena.ne.jp

さて、アイデア終了後も引き続き「ユーザーさんのご要望や不具合へのご指摘を開発につなげる」ということについては、より良い方法を求めて、水面下で試行錯誤を続けてきました。今もまだ進行形ですが、こんな感じで改善してきています。

開発体制の改善

2010年に入ったぐらいから、それ以前に比べて不具合自体は確実に減りました。これは会社の成長に伴ってチーム開発にシフトしてきたことが大きいと思います。

技術面での努力についてはエンジニアがよくアウトプットしていますのでここでは割愛しますが、サポート側でも大規模なリリース前にはきちんと事前チェックができる体制を作りましたし、それだけではなく、さまざまな職種の人がそれぞれの目でチェックするようにもなりました。また、アイデア終了告知にもある通り、リリースの後、特に多くフィードバックをいただくタイミングでは、それに備えて受け入れ窓口を準備するなど、サービスがきちんと支えられるよう工夫を重ねています。まだまだご満足いただける域ではないかもしれませんが、今後も引き続き努力します。

サービス開発者との問題共有方法

現在は、開発者との共有ツールとして、はてなグループに加えてSlackとGHE(Github Enterprise)を活用しています。

日常的にはSlackで相談したり雑談しつつ、実際に依頼したり工数が発生するようなものはGHEのサポート用リポジトリにissueとして登録し、開発チームに流れるようにしています。かつてのアイデアミーティングでの議論がissueのコメント欄に置き換わったわけです。これで、サポート部から個々の問題の対応方針や実際の進捗を把握しやすくなりました。

現在、サポート窓口では、お問い合わせフォームから頂いたお問い合わせには可能な限り2営業日以内には返信するようにしています*1が、それと平行する形で、ご要望や不具合、改善点についてサービス開発者と相談し共有しています。

さらに、このような相談や共有がスムーズにできるよう組織面でも工夫をしています。

情報共有を促進する組織づくり

サポート部は、組織図ではサービス開発本部の直下に置かれています。

昨日 id:onishi がサービス開発のチーム構成について言及していましたが、サポート部は独立した部であるものの性格的には編集グループやデザイングループと同様「職能グループ」に近い位置づけとなり、サポート部に所属する社員は、それぞれに担当するサービスが決まっていて、サービス開発チームにもメンバーとして所属しています。

一般的なお問い合わせ対応は属人的になりすぎないように担当サービス以外も対応していますが、不具合や要望など、開発チームにつなげるべき案件については担当者が決まっていて、開発チームとサポート部とのハブになる仕組みです。私はサポート部の部長ですが、同時にサービスプラットフォームチームのメンバーでもあります。

よくある旧来型の組織では、サポート担当者→サポート部長→開発本部長→プロデューサー→開発チームのディレクター→開発チームのエンジニアという経路で情報が伝達されるところですが、このような体制にすることによって、軽い確認であればサポート側の担当者がチームメンバーであるエンジニアに直接聞けますし、それより重い意思決定を要する時もディレクターに直接相談ができるようにしています。

ですので、お問い合わせ対応と開発チームへの共有はリアルタイムで行われていて、共有した後、問題に対応ができるかどうか、いつできそうかも早い時期にわかります。そのため、お問い合わせに対して検討中のままお待たせするということも相当減りました。

はてなアイデア時代は、ここがボトルネックになっていて「対応ができないわけではないけれど、さまざまな事情から今すぐには難しい」というステータスの案件が数年動かない、ということもあったのですが、今はその状況を早い段階でご回答することができるため、結果的にはお待たせしなくなっているのではないかと思います。また、そのような保留ステータスの案件もチーム内では定期的に棚卸しがなされており、計画的に取り組めるようになりました。

さらに、この体制にはそれだけではないメリットもあることが運用してみてわかりました。

サポート部員が開発チームに所属して他にもよかったこと

開発チームとサポート部が分断されていると、サポート担当者の評価指標は「単位時間あたりの対応の量」「案件をクローズする前に何件やりとりがあったか」といった、お問い合わせだけで計測可能な要素に依存することになり、効率よく「処理」することだけを考えてしまいがちです。

そうなるとサポート部門は「圧縮すべきコストセンター」となってしまい、サポート担当者のモチベーションも上がらず、十分な待遇も得られません。そうなると良い人材は採用できず、サポート品質も下がるという悪いスパイラルが生じてしまいます。おそらく、そこに悩まれている方も多いのかなと思います。

しかし、サポート担当者がサービス開発チームにも所属することによって、単に対応効率だけではなく、担当するサービスのユーザー体験向上そのものを目指すことになります。そうなると目標や評価指標もその観点からのものとなり、結果的にコストだけではなく価値を生み出せる存在になれるのです。

具体的には、目標を立てる時には、担当するサービスのその期の計画から、自分がサポート担当者として何ができるかを洗い出し、それを完遂することを目標としてもらっています。例えば、機能追加やリニューアルが予定されているのであれば、その機能に関する過去のお問い合わせの中から改善すべき点を取りまとめたり、想定される問題点に対し問答集を作るといったことです。このような役割はサポート担当者だからこそできるものですし、リリースに貢献したという実績として評価されることになります。

また、メンバーのキャリアパスも、サポート部のマネージャーだけではなく、本人のスキルや指向によってはプランナーやディレクターという進路も開かれていますから、キャリア形成を前向きに考えやすくなるというメリットがあります。尚、サポート担当者からディレクターになった体験についてはid:AirReader *2がすでに書いていますので合わせてどうぞ。

airreader.hatenablog.com

サポート部は、幅広い知識とスキルが求められる職能集団でもあり、業務としては労働集約的な部分もあるので、教育のため、また、コスト管理のためにも、サポート部、サポートセンター、そういう組織はやはり必要ですが、労働集約的な観点で部分最適化してしまうと、最終的にユーザー体験の向上につながらなくなってしまう危険性があります。あくまでサービス全体でユーザー体験向上を目指した結果として、サポート担当者も早く的確にお問い合わせに回答できるようになるというのが理想形で、そこを目指した結果、こういう形に落ち着いたように思います。

むすび

はてなのようなUGCサービスにとってユーザー体験を向上させることはとても大事です。しかし、サポート担当者が対応速度や対応の量を闇雲に上げても、ユーザー体験の向上にはつながりません。本来、サービスを使う人にとって、問い合わせる必要がないのが一番快適なのであり、お問い合わせを受けている時点でマイナスだからです。

ユーザー体験を向上させるためには、単純に「お問い合わせを処理する」のではなく、お問い合わせに至ってしまった原因から改善を要する箇所を汲み取って、開発チームと共有することが大事ですが、得てしてそのパイプは詰まりがちです。スムーズに流すために、パイプを太く短くする、直結できるところは直結する、そういう工夫の一例として参考になれば幸いです。

ちなみに、はてなでは、2008年ごろからお問い合わせに対する回答メールのフッタに満足度アンケートを付けているのですが、当初は70%程度だった満足度が、今ではだいたい80%~90%を推移しています。前述した通り、お問い合わせへの反応だけでユーザー満足度を測ることはできないとは思いますが、一つの指標として結果は出せているのではないかと自負しています。引き続き、要望と実装の間でがんばっていく所存です。

また、はてなは、こういう感じで、単に与えられたポジションで業務を処理するのではなく、自分で組織レベルからの改善につなげていけるという意味でも面白さがある企業だと思います。職種問わず興味のある方はぜひご連絡ください!

hatenacorp.jp

明日は7日目で id:minemuracoffee さんです。よろしくお願いします!

*1:内容や状況により、それ以上おまたせしてしまうこともあります。申し訳ありません

*2:彼はサービスプラットフォームチームのディレクターですから、私は元部下の下で働いているということになります。さらに、彼は一時期サポート部のメンバーも兼務していましたので、上司が部下で部下が上司というおもしろ構造になっていました