開発の優先順と最小構成の決め方
これは「GLOBIS Advent Calendar 2023」11日目の記事です
こんにちは！GLOPLAのPOの松尾です
今回はリリースから3年を経て落ち着いた、プロダクト開発の優先順と最小構成の決め方についてご紹介します
はじめに
社会人教育や経営大学院を営むGLOBISがどのように事業展開しているか、その中でGLOPLAの位置づけを図解しました
解説
📚 社会人教育や経営大学院の市場をグローバルに移したのが海外拠点
📚 学習コンテンツをデジタル化したのがGLOBIS学び放題
📚 学習コンテンツをデジタル化し市場をグローバルに移したのが Unlimited
📚 GLOBIS経営大学院の単位を取得できるデジタルサービスがナノ単科
💡 育成という領域で研修管理システムを提供しているのがGLOPLA
toBサービスはどれも決裁者が人事で、利用者が従業員という点は変わりませんが、次のような違いがあります
学習事業の収益モデルがフロー型なのに対して、GLOPLAはストック型
学習事業が質の高いコンテンツを提供しているのに対して、GLOPLAは育成の仕組みを安価に提供
国内市場を見ると社会人教育やEdTechがCAGR3~4%に対して、GLOPLAが属するHRTechはCAGR8～9%
GLOPLAは新規事業で、3年前は学習事業とは投資シナジーしかありませんでした、今では販売シナジーが進むなど徐々に連携がうまれています
プロダクト開発の優先順
現在GLOPLAはLeSSの概念を採用しています、POのわたしの他にAPOが2人、4つスクラムチームがあり、各チームでいつ何を開発するかはPOとAPOで相談しながら決めています
プロダクトに実装する機能や非機能は、顧客のペインとゲインのどちらかに作用します、POは次のことを意識しながら開発優先順を決めています
事業戦略に合致しているか
あると受注するか、ないと失注するか
あると継続するか、ないと解約するか
最小構成の規模感
GLOPLAは立上げ期ということもあり、4チームが同じリポジトリを触っています、POは次のことを加味しながらチームにタスクを割り振っていきます
チーム間のEpicの関連度合い
スプリントタスクの進捗具合
技術負債やBugなどの貯まり具合
GLOPLAではPOが開発優先順を検討するために、顧客の理解を深める場と、POが方針をBizに共有し顧客への価値提供に活かす場を設けています
プロダクト改善定例：CSからPOへの既存顧客からの開発要望
プロダクト進捗共有：POからBizへの開発ロードマップの進捗共有
プロダクト企画定例：POからCSへのバックログの進捗共有、1stスコープの認識合わせ
Sales顧客ニーズ共有会：SalesからPOへの受注前顧客からの開発要望
GLOPLAはPOとBizが直接コミュニケーションする機会を多く設けていますが、企業やプロダクトによってはPMMという役割を設けていることもあります
PMMはPOとBizの連携を円滑にし、プロダクトのマーケットインを効率的に進められるメリットがあります、GLOPLAは立ち上げ期という事業フェーズや組織の成長状態に合わないことから未だ採用していません
プロダクト開発の進め方
GLOPLAではリファインメントに入る前に、以下をDevとBizのチーム横断で進めています
POがイシューを設定する
POがビジネスフローを可視化する
Bizが顧客のファクトを収集する
POが顧客のペインを設定し解決手段を検討する
POが課題を解決する最小構成を設定する
最初に誰のどんなJobにアプローチするかというイシューを設定し、次にビジネスフローを可視化するのですが、顧客の業務の周辺まで視野を広げることで次のようなメリットが得られます
UIUX：社内で使われている業務システムやコミュニケーションツールは何か、など顧客の業務環境の解像度を上げることで、どんなUIUXが受容度が高いか、低いかを考えることができます
品質：前工程と後工程で誰がどんな業務をしているか、社内規則や業界団体で定義されている業務か、など業務背景の解像度を上げることで、品質のさじ加減を考えることができます
Bizは顧客から直接的に機能を求められますが、ビッグワードだったり、運用の実現可能性が低かったり、別のアプローチが有効だったりするので、社内にVoCを流す際は、解釈や推測を含めずファクトを共有するようお願いしています
POは、次のことを確認しながら最小構成を設定しています
他に代替手段があるか（今どうやっているか）
機能がないと業務が止まるか（今なぜそれをやっているか）
一連の業務が開始から終了まで滞りなく進むか（今それがなくなったらどうなるか）
プロダクト開発の注意点
プロダクト開発の手順は色々あります、GLOPLAでは過去に以下のようなフレームワークに取り組みました
ユーザーストーリーマッピング
サービスブループリント
イベントストーミング
デザインスプリント
いくつか試して分かったことがあります、それはフレームワークは手段なので正しくイシューを設定しないと、結果をミスリードしたり、サンクコストから手段が目的化してしまうということです
プロダクトの目的は顧客に素早く価値を届けることなので、新しいフレームワークを使ってみようという判断をした時も、どこまでチームのリソースを投資するか悩みました、今は以下の観点で開発を進めています
小さく出して顧客のフィードバック受けて変えればいい
不確実性の高い事業立上げ期ということもあり、フレームワークを使うことで正解を求めていたと思います、結果として時間をかけても社内に正解はないことの証明になりました
アジャイル開発なので短いサイクルを繰り返していますが、最初に作るものを決めて小分けに出していくのではなく、最小構成を決めてそれをリリースしていきます
小さく出すと次のような効果があります
プロダクト：顧客のフィードバックを受けながら機能の方向性を細かくチューニングすることで、最短で価値に近づくことができます
開発：作り過ぎという使われない機能への投資や、リリースできない期間が長引くことで不整合の発見が遅れたり修正箇所が増えるリスクを回避できます
顧客：画面上で実際に動かせることで、本当にやりたかったことが分かり易くなり、要望を適えてくれるプロダクトへのロイヤリティが高まります
顧客のフィードバックについては、今年からCSがVoCの重要度をポイント化したので、POが優先度を判断し易くなりました
さいごに
GLPOLAは新規事業なのでハードシングスが多い現場ですが、開発チームは今では3年前の3倍に拡大し、次々と障壁を打ち破り難所を乗り越えています
このチームの特徴を1つあげるとすると、「フィードバックを受け入れる」というところだと思います、SaaS事業はスピードが命ですが、チームは週次のレトロスペクティブやOKR振り返りなどを糧に成長しています
HRTech業界はバーティカルを極めるSaaSやホリゾンタルに拡張するSaaSなど、競争が激しい市場です、これからもチーム一丸となって勝てるプロダクトを作っていきたいと思います
GLOBISで一緒に働く仲間を募集しています！
GLOBISの開発組織では、一緒に働けるエンジニアを探しています！
まずは、カジュアル面談を通して、あなたに合う組織かどうか確かめてみませんか？