2023/02/28
自社サービス開発の機能拡張対象はどうやって決まるのか
目次
こんにちは。浜野です。
リモートワーク中心の働き方であっても子供の保育園の登園があり毎朝外出するのですが、立春を過ぎたあたりから暖かい日が増えてきて春が近づいていますね。
アトラスではエンジニアを通年で募集しているのですが、採用面接で「自社サービスの開発する機能はどうやって決めているのか」という質問をいただくことが何度かありました。受託開発ではプロジェクト開始時に仕様が決まっていて、その後の工程である「設計」と「実装」と「試験」を担当されるエンジニアの方が多いかと思います。自社サービスのプロダクト開発では、事業に必要と思われる機能とその仕様を自分たちで決めて開発していくことになります。また開発した機能が仕様通りかだけでなく、想定したユーザーにとって分かりやすく使いやすく課題を解決できるのかどうかも判断が必要になります。
今回は自社サービス開発の「設計・実装・試験」の前後で実施している「機能拡張対象の決定」と「機能評価」について紹介します。
機能拡張対象の決定
アトラスの自社サービス開発では、以下の流れで機能拡張対象を決定しています。
この記事では3つのパートに分けて説明します。
- 顧客要望や課題の収集
- 機能拡張候補の選定
- 機能拡張候補の優先順位決定
1. 顧客要望や課題の収集
SMOOSYとConfitはすでに一定のユーザーがいるサービスなので、導入を検討している学会様やご利用中の学会様から問い合わせをいただきます。その中から現状の業務課題やシステムへの要望に関するお問い合わせを顧客要望として管理します。
また問合せ以外にも導入を検討されている学会様との打合せで、現状困っていることやサービスの導入で解決したい課題をお聞きすることもありますし、導入後にしばらくご利用いただいてから打合せする場でも機能追加の要望や使いにくい点などをお聞きすることもあります。そうした打合せの場で出てくる要望や課題についても顧客要望に追加します。
顧客要望リストのイメージは過去のブログ記事「Notionでプロダクト管理すると情報共有のための手間が減って開発に集中できるようになった話」をご覧ください。
2. 機能拡張候補の選定
顧客要望の背景や課題の確認
週次で開催しているサポート確認会で、サポート担当と営業担当と事業責任者が顧客要望を確認します。顧客要望をいただいた担当者が学会様の状況や要望の背景を共有し、運用で対応できることがないか、システムの改修による対応が必要かを検討します。
言われた要望をそのまま受け入れるのではなく、以下のような背景を確認し、要望された機能が本当に課題を解決するのか、提示された課題が本当の課題なのか掘り下げていきます。
- その機能がなぜ必要になっているのか
- その作業は何のためにやっているのか
- どのくらいの頻度で発生するのか
- 機能がない現状はどうしているのか
SaaSの業務システムは利用者の共同プラットフォームですので、ごく一部のユーザーだけが使う特殊な機能に開発リソースを使うわけにはいきません。他学会様でも同じような要望がないかを照会して、複数の学会様から要望があり、機能がないと業務負担になると判断した場合は機能拡張候補のリストに登録します。
事業目標達成に向けた開発対象の検討
隔週で開催している事業定例会で、営業担当とサポート担当と開発担当の各責任者にCEOを加えたメンバーが顧客要望や過去の議事メモなどを参考にして、会社のビジョン実現や事業目標の達成に向けた開発対象を検討します。
こちらは隔週で毎回検討するのではなく、四半期などの節目に開発状況を確認し今後の開発対象を検討しますが、その時にどのようなKPIを重視するのかによって優先度が変わってきます。
- 既存ユーザーの継続率を上げるのか
- サービス単独の新規ユーザーを増やすのか
- アトラスのサービスを複数利用しているユーザーを増やすのか
決めた開発対象が中長期的な事業目標に向けて今すべき開発か、プロダクトビジョンの実現に貢献する開発かの整合性を確認して最終決定し、機能拡張候補のリストに登録します。
3. 機能拡張候補の優先順位決定
週次で開催している開発仕様検討会議で、事業に関係する営業担当とサポート担当と開発担当に加えて、CEOとCTOも同席して機能拡張候補の最終的な優先順位や対応方針を確認します。この場は関係者全員による多角的な視点での最終確認になります。
CTOはSMOOSYとConfitの開発を両方とも把握しているので、SMOOSYとConfitで同じような機能拡張候補や相互に影響する機能拡張候補を検討する場合にCPO的な立ち位置で意見をくれます。
事業目標の達成に向けた機能の開発は重要ですが、そちらばかり優先してしまうと顧客要望に対応できなくなってしまう可能性があります。ですので、事業目標の達成に向けた機能拡張候補（戦略的機能）と顧客要望の機能拡張候補（要望機能）を分けて管理して、それぞれを開発するチームに分けて対応するようにしています。優先順位はそれぞれのレーンで決めています。
顧客要望からの機能拡張候補は営業担当やサポート担当などユーザーに近い役割からの目線で判断する優先度とは別に、開発者がすぐに対応できそうなもの、開発予定の機能拡張と同時に対応できそうなものを考慮して、効率よく進められるようにしています。
最終決定した優先順位の高いものからZubeとGitHubにプロジェクトとして登録し、機能仕様を検討して開発に着手します。
機能評価
開発した機能は試験が終わったらすぐにリリースするのではなく、社内のメンバーで実際に使ってみて機能を評価します。なるべく多くの目線で評価すべく、開発仕様検討会議に参加するメンバー全員で確認します。各サポート担当は自分が担当している顧客の事情などを考慮して評価することで、より多くのユーザーに使っていただけるよう機能の精度を上げていきます。機能評価で気になった点はフィードバックシートに記載し、開発仕様検討会議で対応要否と対応方針を決めてエンジニアが追加で対応していきます。
開発に数ヶ月かかるような機能であれば、仕様検討時に把握していなかった顧客の要望が後から発覚することもあり、機能仕様の調整により対応可能であれば対応を検討することもあります。開発した機能を利用するファーストユーザーとその時期が決まっている場合はリリースのスケジュールを優先することもあるので、状況に応じてプロジェクトごとに判断します。
機能評価でフィードバックされた課題を対応して、いよいよリリースすることになります。とは言ってもリリース後に実際のユーザーが使って課題が見つかることもあり、その場合は冒頭で説明した顧客要望としてフィードバックいただき、次回の開発候補として対応していくことになります。
さいごに
ユーザーから集めた情報をもとに機能拡張対象を決めて開発し、開発した機能がリリースされた後にフィードバックをもらって次の開発候補の検討へと流れていく全体像をイメージしてもらえたしょうか。
事業に関わる全員がそれぞれの役割や視点から意見を出してサービスを進化させていくことが大事なので、アトラスでは意思決定のプロセスに多くの事業関係者が参加して議論しています。 当事者意識をもってユーザーの課題を解決するためにプロダクトを開発したいというエンジニアの方は一緒に働きましょう！
