※この記事は、Speee Advent Calendar15日目の記事です。
昨日の記事はこちら
こんにちは、イエウールのPdM（プロダクトマネージャー）の嶋です。
あと嶋稟太郎という名前で短歌をやっています。
突然ですが、
開発チームへの問い合わせが多すぎて困っていませんか？
プロダクト開発を続ける上で、改善要望や不具合調査のような「問い合わせ対応」は避けられないものです。しかし問い合わせ対応ばかりでは本来開発したいものが遅れてしまい事業の成長スピードも遅くなってしまいます。このトレードオフとどう向きあったか、最近１年の学びを書いていきます。
どんな人向け？
オペレーションが複雑なサービスや、複数の開発プロジェクトが並行するフェイズのプロダクトマネジメントに関わっている方に読んでいただきたいです。
一般的な話と弊社の体制①
「問い合わせ」に含まれるもの
問い合わせには障害対応の依頼のほか、営業がクライアントの要望を吸い上げてあげてくれたもの、マーケティング施策のためにちょっと開発して欲しい、といった社内外からの要望も「開発チームへの問い合わせ」としています。
このうち、障害対応のような緊急度が高いものは”やる”判断が簡単です。判断が難しいのは機能の改善要望のような「やった方が良さそうなもの」です。重要度と緊急度のマトリクスでいう左の象限にあたります。問い合わせを一つずつ「やるorやらない」の精査をするのは大変なので、ざっとPdM（私）が内容を見て重要度が高そうな順に対応するようにしていました。
一般的な話と弊社の体制②
エンジニア個人に調査や改修を直接依頼してしまうと、誰がどの問い合わせに対応しているか分からなくなったり、最適なメンバーのアサインができずに対応に時間がかかってしまう問題が起こります。
この問題に対して、DX事業部では４年ほど前から個人に問い合わせが行かないように仕組みで解決を図っていました。
具体的には、開発チームへの問い合わせ用のgoogleフォームを用意し、入力された内容や選択肢に合わせてslackの問い合わせ対応チャネルで適切な関係者に通知すると言うシンプルなものです。
この仕組みは社内にも浸透しており運用できていたのですが……
問題が起こった
問い合わせが多すぎる！！
改善の要望が上がることは健全な状態です。ただ、当時のイエウールは新規の開発プロジェクトが増えてきたタイミングで、各所から機能の改善要望が来るようになっていました。
問い合わせ対応はPdMと複数名のエンジニアでさばいていましたが、問い合わせの頻度が多すぎて他のプロジェクトの作業が中断されてしまい、重要度の高い開発に集中しにくい状態となりました。
考えたこと
エンジニアの負担を減らすぞ！！
どうした
まずは「重要度がよくわからない問い合わせ対応」を工数の大きさで分類して特徴を見ました。 ざっくりいうとこんな感じ。
- 大 問い合わせ対応の範疇を超えておりプロジェクト化すべきもの
- 中 依頼者の問い合わせに書かれた内容だけでは仕様が決められないもの
- 小 軽微な修正
このうち特に「中」の量が多く、大きな負担になっていたので、早く開発できるように詳細な要求を書く と決めました。要求を一度見ただけで理解できるようにドキュメントを整理して開発チームに依頼する、これでやりやすくなるはず！！
結果は…
エンジニアからめっちゃ不満が出る。
理由を聞くと
「細かく書かれた要求を淡々と開発するのは辛い。」
もう少し聞いてみると、
- どんな背景があってなんのための開発なのか知りたい
- もっといいやり方があるかもしれないが手段が限られている
つまり、ここでの問題は要求が細かいことではなくて、なぜこの問い合わせ対応を行うのか？ というwhyの対話ができていないことでした。
改めてwhyから考え直す
本当に知りたいのは、相手がなぜ問い合わせしているのか。
対応の優先度を決める前に、PdMから依頼者に問い合わせの目的（どんな課題を解決したいか）を聞くようにフローを変更しました。またエンジニアからも依頼者にwhyをヒアリングしやすいように要求のテンプレートを変更しました。
要求のテンプレートの例
### どんな成果に紐つくか - [ ] 事業成果 - メリット: ○○ユーザー向けの○○○ページでの流入を○○増加できる - [ ] 開発チームで必要な工数 - どの程度余計な時間がかかっているか: 1度の対応で10分程度 - 頻度はどの程度か: 月1回以上 - [ ] 開発チーム以外の工数 - どの程度余計な時間がかかっているか: 1度の対応で10分程度 - 頻度はどの程度か: 月1回以上 - [ ] セキュリティリスク - 発生しそうなリスクがあればかく ### 要求 ### 完了の定義 ### 改修の対象（プロダクト、機能、ページなど） ### 注意事項 ### 要求の補足
もうひとつ「問い合わせ対応の捉え方を変える」
そもそも問い合わせ対応する意味ってなんだろう？を考えました。
もちろん、インシデントにすぐに対応したりサービスの品質を保つためには欠かせません。ただそれだけでは不足を感じていて、組織や開発プロジェクトが大きくなるフェイズに合わせて考え方を変える時が良い来たと思って、問い合わせ対応へのスタンスを整理しました。
その時の開発チームに共有したことの抜粋がこちらです。
問い合わせ対応とは
- 事業成長の機会
- さまざまなコンテキストを持った依頼・相談が発生するからこそ、相互の背景を理解し合い、信頼関係を育む重要なチャンス。
- エンジニア以外のメンバーが「こんなこと実現できるのかなぁ」と悩まずに適切に相談できる組織の文化を作る。
- 依頼者が手段を狭く捉えて、目的から考える思考の妨げにならないようにしたい。
問い合わせ対応のスタンス
問い合わせを一次受けする人は、問い合わせ内容から各部署がどんな動きをしようとしているのか、それは事業戦略とどう接続するのか洞察しながら対応しよう！
- 依頼者をリスペクトしよう
- 成果のために考える範囲を広げようとする姿勢は善。
- 依頼者が細かい仕様を知らないのは当たり前。
- 即リアクションしよう！
- 案件の緊急度に応じて対応。
- PdMも問い合わせ内容を見てエンジニア対応が不要と判断したら自らボールを持つ。
- 緊急の依頼が来ることもあるので、見ている人がいるとすぐわかるようにスタンプを押そう。
- 次に対応する人がやりやすいようにしよう！
- 注意が必要な対応など、ドキュメントを残す。
結果は…
ただ優先度の順番を並べるだけではなく「やらない」判断がしやすくなった。
さらに、成果を増やせる改善案や仕様を開発チームから提案できるようになった。
これまではPdMの感覚的な優先度で対応順を並べていましたが、事業への影響を理解することで重要度がはっきりして やらなくて良いものを判断できるようになりました。 1件あたりの考える時間は増えましたが、やらないものを早く決めることで対応の総量をスリムにできました。開発チーム内でも成果を共通認識として対話することで、最適な手段を提案しやすくなりました。
あらためて過去の問い合わせ対応を振り返ってみると、開発に対するアウトカム（事業的な成果）が曖昧で、本当はすぐにやらなくて良いものがありました。問い合わせ対応のような一見細かいものでも、whyを中心に対話することで、より大きな課題に気付いたり、より良いアイディアを出せる機会になるのだと思います。
Whyから考えて意思決定しよう！
上に書いた体制や取り組みが完成形とは思っていません。最適な形は絶えず変化します。ただwhyから考える思考は、どんな状況でも欠かせないと思います。
私たちは考え続けます。🤔🤔🤔
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁
Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
