Recruit Tech Blog
サービス・プロダクトに関係者の要望を広く反映して差し込み案件を減らす方法
高橋圭太郎
この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2018 の投稿記事です。
こんにちは。スタディサプリENGLISHのプロダクトマネージャー（PM）の高橋です。
スタディサプリENGLISHはとても嬉しいことに急成長を続けています。
サービスが急成長すると、それに伴って関係者も急増、プロダクトへの要望も急増してくると思います。急な差し込み案件が発生することも多くなるのではないでしょうか？ しかし開発リソースには限りがあり、やれることは限られています。
皆さんはこのような状況のときにどのようにしていますか？
今回はスタディサプリENGLISHがこの課題を解決するために導入している「案件エントリー」という仕組みをご紹介します。
スタディサプリENGLISHの関係者
サービスメンバーの構成を記載します。実際はもっと多くの関係者がいますが、今回の内容には直接関係ないので省略しています。
- プロデューサー
事業責任者。案件の実施するかはこの人に判断して貰う必要がある。 - Biz
商品企画、事業開発、集客などを担当している人たち。数字を追いかける人たち。 - プロダクトマネージャー（PM）
プロダクトに関しての窓口役。プロダクトの全ての案件を開発チームと最初から最後まで寄り添って管理する人たち。Bizと一緒に数字も追う。開発チームに1名ずつ所属。 - 開発チーム
デザイナーやエンジニアなど実際にプロダクトを開発実装する人たち。いくつかのチームに分割されており、それぞれに各プラットフォームのエンジニアとデザイナーがいる。
抱えていた課題
まずはスタディサプリENGLISHがこれまで実際に抱えていた課題を説明します。
プロダクトへの要望を案件リストに載せる方法がわからない
当初のスタディサプリENGLISHの案件リストは、PM・プロデューサーだけで管理をしていました。そのため、直接開発に関わらない部署からの要望を正しく反映することが出来てない状況が続いていました。PM・プロデューサーを捕まえて直接会話した内容は反映出来ていることもありましたが、それはそれで非常に不健全ですよね…。
例えば、下記のような意見がプロダクトまで正常に届いていなかったということが過去に実際に起きていました。
- 集客の数値分析のために計測タグを新しく設置してほしい
- 顧客情報管理ツールの契約ステータスが見にくいからUIを改修してほしい
- などなど…
これらはユーザーに直接的に効果のあるものではありませんが、事業運営上は非常に重要なものであり、そういった要望の欠落が多く発生していました。
差し込み案件の発生
スタディサプリ ENGLISHの開発チームは、二週間の開発計画を立て、その計画に沿った開発を進めています1)スクラムの「スプリント」を取り入れたものです。。
しかし、上述の通り案件起案の方法がわからないため、期限がある案件が期限ギリギリまで表面化されていなかったり、突発的な作業依頼が直接エンジニアにいってしまったりと、いわゆる差し込み案件が往々にして発生していました。
そのため、開発サイクルを正常に回せていたとはお世辞にも言えない状態でした。
これらを解決するために実施したこと
プロダクトへの開発案件の起案から実施が確定している開発案件の優先順の調整するまでのフローを整備しました。
スタディサプリENGLISHではこのフローのことを「案件エントリー」と呼んでいます。
案件エントリーの目的は下記です。
- プロダクトに対して要望があったときに何をすればいいのか明確化する
- 案件の実施可否を適切な場で適切に判断する
- エンジニアが今後実施する案件を漏れなく優先順に一元管理する
ここからは案件エントリーの具体的な内容を説明していきます。
案件エントリーについて
案件エントリーは大きく3つのSTEPに分かれています。
- プロダクトへの要望を整理してJiraにチケット作成
- 案件をレビューして実施可否を判断する「案件レビュー会」の開催
- 実施確定した案件の優先順を既存案件と比較して再調整
スタディサプリENGLISHでは案件起案から開発まで、Jiraというアジャイル開発のためのプロジェクト管理ツールを使っています。
案件エントリーの対象になる案件は、エンジニア・デザイナーが関わる全ての案件としています。例えばアプリ内の文言を一部変更するなどの小規模案件も対象になります。
また、案件エントリーを通していない案件はいかなる場合も実施しないというルールにしています。少し厳しいですが、特例を認めてしまうととルールが複雑化するため、持続可能性を優先して出来るだけシンプルなものにしています。
※不具合やシステム障害などの緊急対応は別です。
下記は案件エントリーの全体図です。それではそれぞれのSTEPについて説明していきます。
STEP1.要望の整理とチケット作成
何を実現して欲しいのか整理するために、チケット作成の際に下記を記載してもらっています。
- 実現したい背景・目的
- 案件の概要
- 実現したときに見込める効果
これらは次STEPの案件レビュー会の場で使うための重要な要素となります。
それぞれの項目の粒度は各自に任せていますが、困ったり、悩んだりしたときはPMが相談役となってサポートしています。ルールを設けるからには「丸投げはせずに何でもサポートします！」という姿勢をPM陣は心がけています。
下記はチケット作成の実際の画面です。
STEP2.案件レビュー会の開催
案件レビュー会の目的は下記です。
- 起案された案件に対して多面的なレビューを実施して案件の精度を高める
- 実施可否の判断をする
案件レビュー会の必須参加者はプロデューサー・PMはもちろんですが、エンジニアマネジャーなど各領域のマネジャーには必須参加してもらっています。
完全にオープンな場になっているため、誰でも自由に参加できます。弊社ではリモートワークも導入しているため、リモートでの参加も可能です。ルールを設けると窮屈になりがちですが、風通しのよい状態は保つようにしています。
開催頻度は2週間に1度の定期開催となっているため、エントリーしたい案件があったときは一番近い開催日に参加します。2週間に1度の理由は、2週間の開発計画にタイミングを合わせているためです。
STEP3.案件の優先順の調整
実施確定はしているが開発未着手の案件リストと、案件レビュー会で実施確定した案件の優先度を比較して、案件の優先順を再調整していきます。
エントリーされた案件の中にはスケジュール決まっているものなども当然あります。そういった案件は余裕を持って実施するために優先順を上げて対応したりします。
また、既存案件より効果が高いものなどがエントリーされたら優先順を上げることもあります。
案件リストの順番を柔軟に変更できるように優先順の整理は案件レビュー会の度に実施しています。
この案件優先順の最終的な判断権はプロデューサーに持ってもらっています。
導入した結果と課題
以上がスタディサプリENGLISHが導入している「案件エントリー」というルールの全貌です。
導入した結果として、当初の目的は達成されていると感じています。
- プロダクトに対して要望があったときに何をすればいいのか明確化する
→様々な部署がJiraでチケット作成して、案件レビュー会に参加してくれています。 - 案件の実施可否を適切な場で適切に判断する
→チケットを作成して案件レビュー会に参加すれば、必ず実施となるような儀式的なものにはなってはいません。 - エンジニアが今後実施する案件を漏れなく優先順に一元管理する
→差し込み案件が圧倒的に減少しました。エンジニアに直接行くケースはほぼゼロになりました。
実際に2018年度上期だけで約200件の案件エントリーがありました。
最近は「案件エントリー」というワードがサービス全体を通して共通言語化されてきたように感じます。
とはいえ、下記のような課題が浮き彫り化されています。
- エントリーして実施確定となったもののなかなか実現できていない
- 実施可否の判断や優先順の判断の際に定量的な根拠が薄い
- 案件エントリーする人に偏りが出て来ている
まずは導入するというところを上期にやりきったので、今後はこの辺りの改善を実施して、ルールの精度を更に上げていきたいです。
最後までお読みいただき、ありがとうございました！
脚注
| ↑1 | スクラムの「スプリント」を取り入れたものです。 |
|---|