問い合わせ対応でエンジニアが疲弊しないようにやったこと

これは何

こんにちは。CARTA HOLDINGSの事業部の1つである、fluctでエンジニアをしている宮前です。 弊社のDATA STRAPチームでは、ユーザーからの問い合わせ対応が逼迫し、エンジニアの開発効率が大幅に低下していました。そこで、この課題を解決するため、様々な施策を実施しました。 その結果、今は以前と比較してかなり開発に集中できる時間が増えました。

この記事ではやった施策でうまくいったこととうまくいかなかったことをまとめます。

前提として、問い合わせそのものが悪いわけではありません。むしろ、「こういった機能があれば良いのでは?」といった提案などは、プロダクトの改善につながる好機と捉えています。また、仕様の不明確さに関する質問もドキュメントの整備や仕組みの改善に役立ちます。問題は、適切にユーザーの要望をハンドリングできていないことです。このままでは、ユーザーとエンジニアの両者が不幸になってしまいます。

こうした問題意識のもと、ユーザーからの問い合わせを適切に管理し、エンジニアが開発に専念できる環境づくりに取り組みました。

背景

DATA STRAPとは

lp.data-strap.com

  • 社内で開発しているtoB(メディア運用会社)向けの工数削減ツール
  • 複数の広告事業者のレポートを集計して一元レポートとして媒体社に提供する
    • 現在200社ほどに導入して使ってもらっている
  • 社内でもコンサルティングツールとして活用されている

DATA STRAPは複雑な仕様やレポート取得に向けての設定が必要な部分があります。 そのため、ユーザー(媒体社やコンサルティングチーム)からエンジニアに対する問い合わせが後を絶たない状況でした。

従来は開発チームへの問い合わせをSlackのメンションで受けていました。しかし、問い合わせの数が多く、重要度や緊急性は文章を読み取らないと分からないため、エンジニアはコンテキストスイッチを強いられ続け、開発の進捗が芳しくない状態でした。

うまくいったこと

プロダクトの責任範囲を明確にして対応する問い合わせの境界を決める

  • これまではとりあえずチームにメンションされた内容は何でも答えていた
    • 本質的にはプロダクトに関係ないような問い合わせもあり疲弊していた
  • mtgを開いてDATA STRAPとして責任を持つ範囲を明確に定めた
    • これの範囲外の問い合わせは基本的に受けない

問い合わせをBacklogに一元化し、回答期限を設けた

  • Slackのメンションだけでは緊急度が分かりにくく、コンテキストスイッチが発生していた
  • Backlogにしてテンプレートで必要情報を事前に収集することで、無駄なコミュニケーションを削減できた
  • 回答期限を3営業日以内に設定し、即時対応の必要がなくなり、集中できる環境が整った
    • コンサルティングチームの方々に、問い合わせを根本的に減らすための開発を行う時間を作りたいので協力してほしい、ということを伝えて話し合い協力してもらった
      • ありがとうございます!
  • 緊急度の高いものについてはSlackでメンションしてもらう

毎週決まった時間で開発合宿を開催するようにした

  • 合宿といいつつオフィスの同じ会議室に集まって午後は丸っとそこで開発をするというもの
    • 設計などエンジニアみんなで話したいトピックなどがある場合は議論したりモブプロしたりする
      • ネタがない時は各々の開発を進める
  • 差し込みを排除することでフロー状態に入りやすくする
    • もともと金曜にやっていたが今は水曜、木曜の2日間連続でやっている
      • 金曜日にやると土日を跨ぐので、何やっていたか思い出すコンテキストスイッチが大きいので2日連続でやるようにした
  • オフライン環境のため、自然と会話が生まれやすくなる

うまくいかなかったこと

slackワークフローで問い合わせを管理するようにしようとした

  • Backlog起票にする前はSlackワークフローで問い合わせフォームを作っていた
  • フォームを埋めるだけで気軽に問い合わせしやすくなってしまったため問い合わせの量がむしろ増えてしまった
    • ビル・ゲイツ曰く「非効率的なオペレーションを自動化すると、さらに非効率になる」とのことでその通りという感じだった