サグーワークス開発チーム PM の横道です。
サービスを運用していると利用者や運営メンバーから不満や改修依頼を受けることが少なからず発生してきます。一方で、開発からも運用を楽にするための提案をしているため、優先度をしっかりと判断して進めていく必要があります。そこでサグーワークスではどうやって要望を吸い上げて対応しているのかを紹介します。
要望の吸い上げる方法
1.定常的に発生する運営メンバーからの要望や依頼
業務を行っているとシステムに関する要望や質問が出てくるはずです。そうした内容を漏らさず対応するために要望を上げるときは下記の運用ルールに沿って運用しています。
要望の内容 | 依頼方法 | 補足 |
---|---|---|
簡単なデータ取得 / 変更 | Google フォーム | 「簡単」の目安は 30 分以内に終わる規模 |
質問 | Slack 相談チャンネル | |
開発要望 | Slack 相談チャンネル | |
システム不具合 | Slack 相談チャンネル | |
その他 | Slack 相談チャンネル | どれに該当するか判断がつかない場合も該当 |
※どれに該当するか運営メンバー側で判断します。
Googleフォームの場合
開発へ依頼する専用の Google フォームに投函してもらい、投函された内容は当日中に開発側で対応することにしています。急遽入った依頼で丸一日時間を使ってしまうことが無いように、投函されてから長くても 1 時間以内に収まる規模にしています。
サグーワークスチームでは週末に 1 週間の開発計画を立てるようにしていて、その際に依頼への対応分も見積もりに入れているため、対応する度に予定していた開発が遅れるということは起きないようにしています。
とはいえ、時間が掛かる依頼の中で「今日中にやってほしい」とお願いされることもあります。その場合は本当に本日中にやらなければいけない依頼か判断した上で、現在行っている開発が遅れる旨を伝えて合意を取った上で作業を進めていきます。
Slack 相談チャンネルの場合
Slack に専用の相談チャンネルがあるのでそこで以下の流れでやり取りを行います。
依頼したことが無い人は Google フォームで依頼するべきことか、Slackで相談するべきことか判断がつかないことがあります。その場合は Slack チャンネルで相談してもらい、必要に応じて Google フォームに促すことで次回から正しいフローで依頼してもらえるようにしています。サービスの質問に関しては web ディレクターが回答できることは回答してもらい、システムの詳しい仕様については開発が回答する形を取っています。 開発要望やシステム不具合の場合は「開発要望リスト(後述)」に記載して、相談者に要件リストに載せて判断をしていく旨を伝えます。
2.会議中や雑談から生まれる発想
会議の時や雑談の時にアイデアが突然降りてくるときがあります。そのアイデアも他の要望と同列にした上で対応する・しないを判断する必要があります。 しかしながら、全ての思い付きを開発要件として並べると時間がいくらあっても足りません。 そこで、 web ディレクターがその要望を聞いて開発要件として並べるべきかどうか判断し、開発したほうがいい要件を「開発要望リスト(後述)」に記載していきます。
開発から出た改善案は開発チーム内で要件として立てたほうがいいか議論した上で「開発要望リスト(後述)」に記載し、他の要望と同列に判断できるようにしています。
口頭で相談するという点以外は Slack で相談が来た時と同じフローになるようにしています。
開発要望の判断
上記で登場した「開発要望リスト」を元に web ディレクターと開発でミーティングを実施して判断しています。 ミーティングは毎日 10 分~ 30 分で実施し、 1 日で上がった要望の確認を行います。
〇開発要望シート
要望内容 | 期待効果 | 対応方法【ミーティング時に追記】 | 対応予定工数【ミーティング時に追記】 | 優先度【ミーティング時に追記】 |
---|---|---|---|---|
手動で行っている〇〇作業を自動化してほしい | 10 h/月の運用工数削減 | 運用のフロー確認・開発 | 30 h | 4 |
〇〇機能の絞り込み条件を追加してほしい | 2 h/月の運用工数削減 | 検索フォームの条件追加 | 4 h | 6 |
- 開発内容 :どういった要望なのか、何をしてほしいかを記載する
- 期待効果 :要望が達成された場合の期待効果を書く。(不具合時は対応しなかった場合も記載する)
- 対応方法 :ミーティングで開発内容を聞き、開発時に何を対応するか分かるように開発側で記載する。
- 対応予定工数:対応にどれくらいの工数が必要か見積もりを行う
- 優先度 :対応内容と見積もりから web ディレクターが優先度を決める
要望の内容が不明確な場合はどういった対応を行えばいいか分からない為、発案者と web ディレクターですり合わせを行ってから開発が内容を確認します。期待効果の記載が無い場合は開発の対応工数に比べ効果が余りでない可能性があることと、期待に添えることができるかがわからないので期待効果を記載するようにしています。
こうして優先度と対応内容が確定した要件は順に開発が対応していきます。 毎月どれくらいこの要望リストに時間を当てるか計画して、優先度の高い要望が多い場合は次月以降で「開発要望リスト」の要件に割り当てる時間を増やし対応していきます。
webディレクターを窓口にしている理由
数年前は運営メンバーから直接開発に改修依頼がいく仕組みになっていました。その場合、新しく入った依頼が対応されやすくなり、本当は優先するべき依頼がないがしろにされる事がありました。 さらに web ディレクターを通していなかったので、事業サイドはどういった機能が開発されたかも把握できていないという問題もありました。
全ての依頼に対して web ディレクターを通すことで、要望を横に並べて正しく判断して対応できる仕組みにしています。