仕組み化によって、運用保守の属人化を防ぎつつ、問い合わせ対応を高速化した話
こんにちは！株式会社COMPASS 取締役の常盤です。COMPASSは「新しい学びの環境を創り出す」をミッションに掲げ、小中学生に対してAI型教材Qubena （キュビナ）を提供している会社です。
プロダクト開発に取り組むにあたり、新規機能の開発と運用保守のバランスに悩む会社も多いのではないでしょうか。COMPASSもそうした悩みを抱えていて、Qubenaを2016年に正式リリースしてから「もっと機能を追加したい！」と「ユーザーの困り事を解消しないと！」の狭間で揺れてきました。色々と試行錯誤していくなかで、今年に入って始めたプロダクトサクセスという仕組みがとてもバランス良く機能しているので、このnoteで紹介させてください。
プロダクトサクセスという仕組みの概要
COMPASSでは長らく新規開発チームと運用保守チームに別れた体制をとっていました。この分業は、新規開発の速度を高める効果があるのですが、情報の属人化やプロダクト開発の組織全体の一体感の欠如などの弊害を生んでいました。そこに誕生したのが、プロダクトサクセスという仕組みです。
このように、週替りで各チームより担当者が選出され、臨時のチームを編成します。そして、毎日15分のデイリーMTGを持ちながら、ユーザーへの問い合わせを素早く解決していきます。以下、そのメリットについて説明をしていきます。
問い合わせ対応がとにかく高速に！
全てのチームからメンバーを選出すると、どうしてもデイリーMTGの参加者が多くなってしまうのですが、その費用対効果は十分にあると感じます。例えば、ユーザーからバグの問い合わせがあった場合、まず最初に行うのは原因の切り分けです。
仮に「問いに対して正しく解答したはずなのに誤りと判定されてしまう」という問い合わせがあったとします。こうした問い合わせはICT教材を扱うCOMPASSでは頻繁に頂くものです。以下はそのサンプルです。 x+y=10 が正しい答えですが、yが1と認識されることによって不正解と判定されてしまっています。
この問い合わせに対して調査をする場合、様々な分岐が考えられます。まず第一にこの現象の再現性はどの程度あるのか？もし再現するのであれば、文字認識エンジンの認識補助機能は正しく動いているのか、もしくは文字認識エンジンに送信しているデータに誤りがあるのか？そもそもこのyの書き方が数学として許容範囲なのか...などです。
こうした原因の切り分けを1人の担当者がヒアリングをしながら進めていくと、ヒアリングの回答待ちなどでタイミングが噛み合わない時は、あっという間に数日経ってしまうことは珍しくありません。そもそもどのチームに問い合わせていいのかわからないことだってあります。それはユーザーを待たせてしまっているということであり、良い状態とは言えません。
それが全てのチームからメンバーを選出して一同に集まっていることによって、基本的にはその場その場で原因の切り分けが完結していきます。仮にその場で完結しない場合であっても、チーム内の適切な担当者へ漏れなく接続することができるため、不必要に調査が遅れるということもなくなります。また、この取り組みでのKPIとして、問い合わせチケットの起票からクローズまでに要した日数を計測し、見える化しています。まだまだ改善の余地はありますが、少しずつユーザーの皆様に対応の速さを褒めて頂けることも増えてきました。
情報の属人化を防げる
人によって詳しい領域とそうでない領域が存在するのは自然なことです。しかし「この領域は○○さんでなければわからない」という領域が増えれば増えるほど、組織内でボトルネックが生まれやすく、全体としてのスループットは低下する傾向にあります。プロダクトサクセスでは、週替りにメンバーを選出しますので、自然と情報の属人化を防ぐ効果が生まれます。
例えば、上述の例だと文字認識エンジン周りの知識が必要になりますが、自身がその領域を把握していなくても、一緒に原因の切り分けに参加しているだけで以下の理解が進みます。
・機能の概要
・詳細が仕様書のどこに記載されているか
・どういう要素によって想定外の挙動を引き起こすか
・社内で詳しい人は誰か
実際に改修が必要となった時に、コードレベルで対応ができる人が増えるほどの属人化の解消はプロダクトサクセスの取り組みだけでは難しいですが、組織全体の機動力の向上に寄与していると感じています。
プロダクトとビジネスの連携がスムーズに
デイリーMTGにはプロダクトオーナーとカスタマーサポートのメンバーも参加しています。この取り組みを通じて、プロダクトオーナーはどの機能にどのぐらい問い合わせが集まっているかを把握できますし、対応を進めるなかで求められている仕様変更や機能改善をすぐにプロダクトバックログへ反映できます。実際、ここからたくさんの開発アイテムが誕生し、リリースされていきました。
カスタマーサポートの担当者は、プロダクト開発のメンバーとの議論を経て、機能の意図や仕様上の制限、開発の優先順位など、様々な情報を得ることができます。こうした情報はユーザーへの返信内容の質を向上させる効果があると感じています。カスタマーサポートの対応はユーザーに対しての企業イメージそのものです。一次対応から的確にサポートを行うためにもプロダクトの理解は非常に重要です。
尚、プロダクトサクセスの議事は日々Slackに展開されます。自身が担当していない週であっても、問い合わせ対応がどのように動いているか把握できるようになっています。このような情報の透明性の高さはCOMPASSの文化の一つです。
終わりに
以上、仕組み化によって運用保守の属人化を防ぎつつ問い合わせ対応を高速化した話でした。COMPASSはユーザーと近い距離感でプロダクト開発をすることを大事にしています。まだまだ課題に感じることも多いですが、今回紹介したプロダクトサクセスはとても手応えを感じている取り組みの一つです。皆さんの何かしらの参考になれば幸いです！
また、COMPASSでは引き続き採用活動を積極的に行っています。応募意志が明確でなくとも、カジュアル面談からスタートすることも可能ですので、少しでもご興味があればご連絡を頂けると嬉しいです！
この記事が気に入ったらサポートをしてみませんか？