事業目標に繋がる開発ばかりではなかった──スペースマーケットがプロジェクト投資分析で見直した開発投資割合の捉え方
事業目標に繋がる開発ばかりではなかった──スペースマーケットがプロジェクト投資分析で見直した開発投資割合の捉え方
目次
目次を読み込み中...
新規機能の開発、既存機能の改善、品質保証、技術的負債の返済、問い合わせ対応──。
開発組織が向き合う施策は年々多様化し、限られたリソースの中で「どこにどれだけ投資すべきか」を判断することは、以前にも増して難しくなっています。プロダクトの成長フェーズによって最適な投資配分は変わる一方で、日々の開発運用の中では、それらを整理して捉えることが簡単ではありません。
AIの進化により、コード生成や調査作業の自動化が進み、「作る」工程そのものの効率は大きく向上しました。その結果、開発チームが生み出せるアウトプットの量とスピードは確実に高まっています。一方で、実装が進むほど、「この開発投資は事業のどこに効いているのか」「なぜ今この施策にリソースを割いているのか」といった問いに答えることの必要性も高まっています。
こうした状況の中、株式会社スペースマーケットはFindy Team+の「プロジェクト投資分析」機能とJiraを連携し、開発投資の構造を可視化する取り組みに着手しました。
同社はすでにデリバリー指標の改善を一定やり切り、「次のステージ」として、開発施策と事業のKGI・KPIをどう接続し、戦略に基づいたリソース配分や意思決定につなげていくかを見直すフェーズに入っています。
本記事では、スペースマーケットがどのような課題意識のもとで開発投資割合の可視化に取り組み、Jira運用の再設計を進めていったのか。その過程で得られた気づきや、意思決定の変化について紐解いていきます。
プロフィール
成原 聡一朗さん
エンジニアリングマネージャー
1988年、札幌市出身。23歳の時、WEBの世界に魅了され、独学でデザインなどを学習し、WEBデザイナーとしてキャリアをスタート。
受託制作会社で数年キャリアを積んだのち、WEBにおけるJavaScriptの可能性に魅了され、フロントエンドエンジニアに転向。
スペースマーケットに入社後、エンジニアリング領域でのマネージメントの面白さ、奥深さに気がつきエンジニアリングマネージャーへ。
開発は速いが、「どこに何を投資しているのか」が見えない
成原：開発チームとして日々さまざまな施策に取り組んでいましたが、その投資がどこにどれだけ向いているのかを、きちんと把握できていない状態が課題であると感じていました。
適切に人員をアサインできているのかも見えず、判断の前提となるデータが揃っていなかったと思います。
アドホックな対応や、KPIに直接紐づかないタスクも一定数ありました。それ自体が悪いわけではないのですが、それらが全体の中でどれくらいの割合を占めているのか、事業に対してどういう位置づけなのかを説明しようとすると、どうしても感覚的な話になってしまっていました。
デリバリーの観点では、これまで改善を積み重ねてきた実感があります。プルリクエスト（以降、PR）のリードタイムやデプロイ頻度など、いわゆる手前の指標については一定やりきった状態でした。
その上で「なぜこの機能を作っているのか」「この投資は事業のどこに効いているのか」といった、もう一段上の視点で議論できる状態を作りたかったのです。そのためには、まず自分たちが今どこに投資しているのかを、構造として把握する必要がありました。
KPIの進捗についても、数字としては見ているものの、それがどれだけの開発投資によって支えられているのかまでは見えていませんでした。結果として、選択と集中をしたいと思っても、その判断材料が不足している状態だったと思います。
Jiraだけでは限界だった投資構造の整理
成原：以前からJira上でもラベル運用は行っていましたが、それが体系立って整理されておらず、過去に使っていたものが残ったままになっていて、何のためのラベルなのか分からない状態になっていました。分類の軸として機能していないラベルが増え、投資の観点で使おうとすると、かえって混乱を招く状況だったと思います。
一時期は、いっそラベル運用自体をやめたほうがいいのでは、という話が出るほどでした。
そうした中でFindy Team+のプロジェクト投資分析機能を見て、Jiraのデータを前提にしながら投資構造を整理できそうだと感じました。ラベルの整理を行うことで、投資配分が可視化できる点は大きな魅力でした。
また、経営層やプロダクト側とのコミュニケーションを考えたときにも、数値で話ができる点は重要でした。これまでは「なんとなくこのあたりに工数を使っている」という説明になりがちでしたが、投資カテゴリ別に整理されたデータがあれば、議論の前提を揃えやすくなると感じました。
スクラム開発における施策管理──可視化前のJira運用
成原：スペースマーケットでは、Large Scale Scrum（LeSS）で開発を進めています。Growth Unitと品質を担うTrust Unitがあり、それぞれのUnit内に複数チームが所属しています。各Unitごとにバックログは分かれていて、同一Unit内のチームでプロダクトバックログアイテム（以降、PBI）を共有しています。PBIは「その単位でユーザーに価値を届けられるか」を意識して切るようにしています。
施策のアイデアはまず企画書としてまとめ、企画開発会議の中で進めるものを決めます。実施が決まった者は、企画内容をもとにPOがEPIC or PBIに変更させます。その後、エンジニアも含めて、どう分割するか、どのチームが担当するかを議論します。エピックはPBI単位に分解し、ストーリーポイントを付けたうえでリファインメントを行い、仕様の詳細を詰め、受け入れ条件を記載。合意できたものをサブタスクに落として進める流れです。
実際の作業管理はサブタスクが中心で、サブタスクが完了していくことで、最終的にPBIやエピックがクローズされます。開発プロセス自体は比較的整理されており、日々の運用で大きく困っている感覚はありませんでした。
一方で、可視化の観点では課題もありました。リファイントメント〜プランニングの中で要件定義と設計を行き来することが当たり前になっており、Jiraのステータス遷移だけを見ても、どこに時間がかかっているのかを素直に捉えにくい状態でした。
そのため、プロジェクト投資分析機能を使うにあたっては、まずこのJiraの運用、とくにラベルの扱い方を見直す必要があると感じていました。
Jira運用の再設計──オートメーションによるラベル運用の自動化
成原：実際にFindy Team+上で可視化を進めるにあたり、ラベルを一度棚卸しし、整理しました。
幸い、直近ではラベルをあまり活用できていなかったため、過去の運用に引きずられずに設計し直すことができたと思います。
ラベルの付け方については、エピック化されたタイミングで投資カテゴリに対応するラベルが自動で付与されるように、Jiraのオートメーションを設定しています。また、エピック配下のイシュー（ユーザーストーリーや一部のタスク）にも、エピックと同じラベルが自動的に引き継がれるようにしました。これによって、エピック階層全体で投資カテゴリが揃いやすくなっています。
ただ、運用負荷はそこまで高くありません。週に一度、15分ほどラベルの付き方を確認する程度で、継続できていますし、メンバーに新しい作業を強く求めるようなこともありません。
投資カテゴリをどう判断するかについては、企画書に書かれている目的や目標を基準にするようにしています。多くの施策は新規機能か既存機能の改善のどちらかに分類できるため、個人の感覚で判断が分かれることはあまりありません。
品質保証や信頼性に関わる取り組みについては、トラストチームが中心になって対応しています。問い合わせ対応やページ速度の改善など、エピックではなくタスク粒度から始まるものも多く、こちらはまだラベル運用を本格的に回せていない部分です。今後どう仕組み化していくかは、検討していく必要があると感じています。
全体としては、Jiraの運用を大きく変えることなく、最小限の調整で投資分析につなげられている感覚があります。
KPIを意識しているつもりだった──投資割合から見えたズレ
成原：実際にプロジェクト投資分析機能を使い始めて、まず感じたのは「思っていた以上に見えていなかった部分が多かった」ということでした。これまでも事業のKGIやKPIを意識して開発しているつもりではありましたが、投資配分として整理してみると、必ずしもそこにコミットできていないケースがあると分かりました。
エピック単位で見たときに、そもそもKPIに向いていないエピックが混ざっていることにも気づきましたね。
新規機能、既存機能の改善、品質保証といった投資カテゴリごとに見ていくことで、「どの領域にどれくらいリソースを使っているのか」が初めて一目で分かるようになりました。例えば、新規機能への投資割合が高い一方で、品質保証については別チームで対応している影響もあり、数字上は少なく見える構造になっていることがはっきりしました。
こうした結果は、チーム全体でも共有しています。Growth Unitグロースユニット全体の振り返りの場で数値を共有したり、スプリント単位の振り返りの中で「この期間の投資割合はどうだったか」を話すようにしています。
可視化された数字があることで、「選択と集中が本当にできているのか」「この投資バランスでよいのか」といった議論を、感覚ではなく事実をもとに進められるようになりました。まだ改善の途中ではありますが、議論の前提が揃ったこと自体が、大きな前進だと感じています。
投資分析を起点にした、これからの意思決定と組織づくり
成原：今後は、この投資分析の結果を「振り返りのためのデータ」にとどめず、意思決定に使っていきたいと考えています。特に、自分たちがやっている日々のタスクと、事業のKGIやKPIをどう結びつけていくかという点です。
目の前のタスクに取り組んでいると、その作業が事業のどこに効いているのかを見失いがちです。投資カテゴリとして整理されたデータがあれば、「この期間はどの領域に力を入れていたのか」「それは今の事業フェーズに合っていたのか」を振り返ることができます。そうした振り返りを通じて、次にどこへ投資するかをより意識的に決められるようにしたいと思っています。
今回の分析で実感したのは、自分たちが持っていた定性的な肌感と、実際に計測した数値の間には、思っている以上にズレがあるということでした。体感としては正しいと思っていた投資配分でも、数値で見てみると20〜30％ほど異なっている場面は決して珍しくありません。
そのブレを適切に運用することで、組織としてより良いリソース配分ができるようになります。
また、体制や採用などのリソースアサインの観点でも、活用できると感じています。投資配分と事業の状態を並べて見ることで、「人を増やすべきなのか」「やり方を変えるべきなのか」といった判断を、感覚ではなくデータをもとに議論できるようになるはずです。
経営層とのコミュニケーションにおいても、この可視化は大きな意味を持つと考えています。これまで人件費を含めた投資の話は抽象的になりがちでしたが、実際の投資配分を示しながら説明できれば、事業側が考えている予算感とのすり合わせもしやすくなると考えています。
今後一緒に働きたいエンジニア像とは？
成原：私たちエンジニアの存在意義は「プロダクトを通してユーザーに価値提供を行うこと」ですが、価値提供という言葉はあまりに抽象度が高いです。
なので、言われたものを思考停止で受け止めるのではなく、Why・Whatから自身で解釈し、エンジニアリングを通して価値提供を高速にできる組織を作っていきたいです。
自身の仕事に誇りを持ちながら、ユーザーへの価値提供を最優先事項として考え、動ける方。
そして、自身で閉じずに、チームで大きな未来を描くことにモチベーションを燃やせる方。
施策のWhy・Whatから自身で考え、ユーザーに価値提供を行えるダイナミズムに興味がある方には絶好の環境です！
https://findy-code.io/companies/668
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
https://jp.findy-team.io/
新規機能の開発、既存機能の改善、品質保証、技術的負債の返済、問い合わせ対応──。
開発組織が向き合う施策は年々多様化し、限られたリソースの中で「どこにどれだけ投資すべきか」を判断することは、以前にも増して難しくなっています。プロダクトの成長フェーズによって最適な投資配分は変わる一方で、日々の開発運用の中では、それらを整理して捉えることが簡単ではありません。
AIの進化により、コード生成や調査作業の自動化が進み、「作る」工程そのものの効率は大きく向上しました。その結果、開発チームが生み出せるアウトプットの量とスピードは確実に高まっています。一方で、実装が進むほど、「この開発投資は事業のどこに効いているのか」「なぜ今この施策にリソースを割いているのか」といった問いに答えることの必要性も高まっています。
こうした状況の中、株式会社スペースマーケットはFindy Team+の「プロジェクト投資分析」機能とJiraを連携し、開発投資の構造を可視化する取り組みに着手しました。
同社はすでにデリバリー指標の改善を一定やり切り、「次のステージ」として、開発施策と事業のKGI・KPIをどう接続し、戦略に基づいたリソース配分や意思決定につなげていくかを見直すフェーズに入っています。
本記事では、スペースマーケットがどのような課題意識のもとで開発投資割合の可視化に取り組み、Jira運用の再設計を進めていったのか。その過程で得られた気づきや、意思決定の変化について紐解いていきます。
プロフィール
成原 聡一朗さん
エンジニアリングマネージャー
1988年、札幌市出身。23歳の時、WEBの世界に魅了され、独学でデザインなどを学習し、WEBデザイナーとしてキャリアをスタート。
受託制作会社で数年キャリアを積んだのち、WEBにおけるJavaScriptの可能性に魅了され、フロントエンドエンジニアに転向。
スペースマーケットに入社後、エンジニアリング領域でのマネージメントの面白さ、奥深さに気がつきエンジニアリングマネージャーへ。
開発は速いが、「どこに何を投資しているのか」が見えない
成原：開発チームとして日々さまざまな施策に取り組んでいましたが、その投資がどこにどれだけ向いているのかを、きちんと把握できていない状態が課題であると感じていました。
適切に人員をアサインできているのかも見えず、判断の前提となるデータが揃っていなかったと思います。
アドホックな対応や、KPIに直接紐づかないタスクも一定数ありました。それ自体が悪いわけではないのですが、それらが全体の中でどれくらいの割合を占めているのか、事業に対してどういう位置づけなのかを説明しようとすると、どうしても感覚的な話になってしまっていました。
デリバリーの観点では、これまで改善を積み重ねてきた実感があります。プルリクエスト（以降、PR）のリードタイムやデプロイ頻度など、いわゆる手前の指標については一定やりきった状態でした。
その上で「なぜこの機能を作っているのか」「この投資は事業のどこに効いているのか」といった、もう一段上の視点で議論できる状態を作りたかったのです。そのためには、まず自分たちが今どこに投資しているのかを、構造として把握する必要がありました。
KPIの進捗についても、数字としては見ているものの、それがどれだけの開発投資によって支えられているのかまでは見えていませんでした。結果として、選択と集中をしたいと思っても、その判断材料が不足している状態だったと思います。
Jiraだけでは限界だった投資構造の整理
成原：以前からJira上でもラベル運用は行っていましたが、それが体系立って整理されておらず、過去に使っていたものが残ったままになっていて、何のためのラベルなのか分からない状態になっていました。分類の軸として機能していないラベルが増え、投資の観点で使おうとすると、かえって混乱を招く状況だったと思います。
一時期は、いっそラベル運用自体をやめたほうがいいのでは、という話が出るほどでした。
そうした中でFindy Team+のプロジェクト投資分析機能を見て、Jiraのデータを前提にしながら投資構造を整理できそうだと感じました。ラベルの整理を行うことで、投資配分が可視化できる点は大きな魅力でした。
また、経営層やプロダクト側とのコミュニケーションを考えたときにも、数値で話ができる点は重要でした。これまでは「なんとなくこのあたりに工数を使っている」という説明になりがちでしたが、投資カテゴリ別に整理されたデータがあれば、議論の前提を揃えやすくなると感じました。
スクラム開発における施策管理──可視化前のJira運用
成原：スペースマーケットでは、Large Scale Scrum（LeSS）で開発を進めています。Growth Unitと品質を担うTrust Unitがあり、それぞれのUnit内に複数チームが所属しています。各Unitごとにバックログは分かれていて、同一Unit内のチームでプロダクトバックログアイテム（以降、PBI）を共有しています。PBIは「その単位でユーザーに価値を届けられるか」を意識して切るようにしています。
施策のアイデアはまず企画書としてまとめ、企画開発会議の中で進めるものを決めます。実施が決まった者は、企画内容をもとにPOがEPIC or PBIに変更させます。その後、エンジニアも含めて、どう分割するか、どのチームが担当するかを議論します。エピックはPBI単位に分解し、ストーリーポイントを付けたうえでリファインメントを行い、仕様の詳細を詰め、受け入れ条件を記載。合意できたものをサブタスクに落として進める流れです。
実際の作業管理はサブタスクが中心で、サブタスクが完了していくことで、最終的にPBIやエピックがクローズされます。開発プロセス自体は比較的整理されており、日々の運用で大きく困っている感覚はありませんでした。
一方で、可視化の観点では課題もありました。リファイントメント〜プランニングの中で要件定義と設計を行き来することが当たり前になっており、Jiraのステータス遷移だけを見ても、どこに時間がかかっているのかを素直に捉えにくい状態でした。
そのため、プロジェクト投資分析機能を使うにあたっては、まずこのJiraの運用、とくにラベルの扱い方を見直す必要があると感じていました。
Jira運用の再設計──オートメーションによるラベル運用の自動化
成原：実際にFindy Team+上で可視化を進めるにあたり、ラベルを一度棚卸しし、整理しました。
幸い、直近ではラベルをあまり活用できていなかったため、過去の運用に引きずられずに設計し直すことができたと思います。
ラベルの付け方については、エピック化されたタイミングで投資カテゴリに対応するラベルが自動で付与されるように、Jiraのオートメーションを設定しています。また、エピック配下のイシュー（ユーザーストーリーや一部のタスク）にも、エピックと同じラベルが自動的に引き継がれるようにしました。これによって、エピック階層全体で投資カテゴリが揃いやすくなっています。
ただ、運用負荷はそこまで高くありません。週に一度、15分ほどラベルの付き方を確認する程度で、継続できていますし、メンバーに新しい作業を強く求めるようなこともありません。
投資カテゴリをどう判断するかについては、企画書に書かれている目的や目標を基準にするようにしています。多くの施策は新規機能か既存機能の改善のどちらかに分類できるため、個人の感覚で判断が分かれることはあまりありません。
品質保証や信頼性に関わる取り組みについては、トラストチームが中心になって対応しています。問い合わせ対応やページ速度の改善など、エピックではなくタスク粒度から始まるものも多く、こちらはまだラベル運用を本格的に回せていない部分です。今後どう仕組み化していくかは、検討していく必要があると感じています。
全体としては、Jiraの運用を大きく変えることなく、最小限の調整で投資分析につなげられている感覚があります。
KPIを意識しているつもりだった──投資割合から見えたズレ
成原：実際にプロジェクト投資分析機能を使い始めて、まず感じたのは「思っていた以上に見えていなかった部分が多かった」ということでした。これまでも事業のKGIやKPIを意識して開発しているつもりではありましたが、投資配分として整理してみると、必ずしもそこにコミットできていないケースがあると分かりました。
エピック単位で見たときに、そもそもKPIに向いていないエピックが混ざっていることにも気づきましたね。
新規機能、既存機能の改善、品質保証といった投資カテゴリごとに見ていくことで、「どの領域にどれくらいリソースを使っているのか」が初めて一目で分かるようになりました。例えば、新規機能への投資割合が高い一方で、品質保証については別チームで対応している影響もあり、数字上は少なく見える構造になっていることがはっきりしました。
こうした結果は、チーム全体でも共有しています。Growth Unitグロースユニット全体の振り返りの場で数値を共有したり、スプリント単位の振り返りの中で「この期間の投資割合はどうだったか」を話すようにしています。
可視化された数字があることで、「選択と集中が本当にできているのか」「この投資バランスでよいのか」といった議論を、感覚ではなく事実をもとに進められるようになりました。まだ改善の途中ではありますが、議論の前提が揃ったこと自体が、大きな前進だと感じています。
投資分析を起点にした、これからの意思決定と組織づくり
成原：今後は、この投資分析の結果を「振り返りのためのデータ」にとどめず、意思決定に使っていきたいと考えています。特に、自分たちがやっている日々のタスクと、事業のKGIやKPIをどう結びつけていくかという点です。
目の前のタスクに取り組んでいると、その作業が事業のどこに効いているのかを見失いがちです。投資カテゴリとして整理されたデータがあれば、「この期間はどの領域に力を入れていたのか」「それは今の事業フェーズに合っていたのか」を振り返ることができます。そうした振り返りを通じて、次にどこへ投資するかをより意識的に決められるようにしたいと思っています。
今回の分析で実感したのは、自分たちが持っていた定性的な肌感と、実際に計測した数値の間には、思っている以上にズレがあるということでした。体感としては正しいと思っていた投資配分でも、数値で見てみると20〜30％ほど異なっている場面は決して珍しくありません。
そのブレを適切に運用することで、組織としてより良いリソース配分ができるようになります。
また、体制や採用などのリソースアサインの観点でも、活用できると感じています。投資配分と事業の状態を並べて見ることで、「人を増やすべきなのか」「やり方を変えるべきなのか」といった判断を、感覚ではなくデータをもとに議論できるようになるはずです。
経営層とのコミュニケーションにおいても、この可視化は大きな意味を持つと考えています。これまで人件費を含めた投資の話は抽象的になりがちでしたが、実際の投資配分を示しながら説明できれば、事業側が考えている予算感とのすり合わせもしやすくなると考えています。
今後一緒に働きたいエンジニア像とは？
成原：私たちエンジニアの存在意義は「プロダクトを通してユーザーに価値提供を行うこと」ですが、価値提供という言葉はあまりに抽象度が高いです。
なので、言われたものを思考停止で受け止めるのではなく、Why・Whatから自身で解釈し、エンジニアリングを通して価値提供を高速にできる組織を作っていきたいです。
自身の仕事に誇りを持ちながら、ユーザーへの価値提供を最優先事項として考え、動ける方。
そして、自身で閉じずに、チームで大きな未来を描くことにモチベーションを燃やせる方。
施策のWhy・Whatから自身で考え、ユーザーに価値提供を行えるダイナミズムに興味がある方には絶好の環境です！
https://findy-code.io/companies/668
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
https://jp.findy-team.io/
事業目標に繋がる開発ばかりではなかった──スペースマーケットがプロジェクト投資分析で見直した開発投資割合の捉え方
新規機能の開発、既存機能の改善、品質保証、技術的負債の返済、問い合わせ対応──。
開発組織が向き合う施策は年々多様化し、限られたリソースの中で「どこにどれだけ投資すべきか」を判断することは、以前にも増して難しくなっています。プロダクトの成長フェーズによって最適な投資配分は変わる一方で、日々の開発運用の中では、それらを整理して捉えることが簡単ではありません。
AIの進化により、コード生成や調査作業の自動化が進み、「作る」工程そのものの効率は大きく向上しました。その結果、開発チームが生み出せるアウトプットの量とスピードは確実に高まっています。一方で、実装が進むほど、「この開発投資は事業のどこに効いているのか」「なぜ今この施策にリソースを割いているのか」といった問いに答えることの必要性も高まっています。
こうした状況の中、株式会社スペースマーケットはFindy Team+の「プロジェクト投資分析」機能とJiraを連携し、開発投資の構造を可視化する取り組みに着手しました。
同社はすでにデリバリー指標の改善を一定やり切り、「次のステージ」として、開発施策と事業のKGI・KPIをどう接続し、戦略に基づいたリソース配分や意思決定につなげていくかを見直すフェーズに入っています。
本記事では、スペースマーケットがどのような課題意識のもとで開発投資割合の可視化に取り組み、Jira運用の再設計を進めていったのか。その過程で得られた気づきや、意思決定の変化について紐解いていきます。
プロフィール
成原 聡一朗さん
エンジニアリングマネージャー
1988年、札幌市出身。23歳の時、WEBの世界に魅了され、独学でデザインなどを学習し、WEBデザイナーとしてキャリアをスタート。
受託制作会社で数年キャリアを積んだのち、WEBにおけるJavaScriptの可能性に魅了され、フロントエンドエンジニアに転向。
スペースマーケットに入社後、エンジニアリング領域でのマネージメントの面白さ、奥深さに気がつきエンジニアリングマネージャーへ。
開発は速いが、「どこに何を投資しているのか」が見えない
成原：開発チームとして日々さまざまな施策に取り組んでいましたが、その投資がどこにどれだけ向いているのかを、きちんと把握できていない状態が課題であると感じていました。
適切に人員をアサインできているのかも見えず、判断の前提となるデータが揃っていなかったと思います。
アドホックな対応や、KPIに直接紐づかないタスクも一定数ありました。それ自体が悪いわけではないのですが、それらが全体の中でどれくらいの割合を占めているのか、事業に対してどういう位置づけなのかを説明しようとすると、どうしても感覚的な話になってしまっていました。
デリバリーの観点では、これまで改善を積み重ねてきた実感があります。プルリクエスト（以降、PR）のリードタイムやデプロイ頻度など、いわゆる手前の指標については一定やりきった状態でした。
その上で「なぜこの機能を作っているのか」「この投資は事業のどこに効いているのか」といった、もう一段上の視点で議論できる状態を作りたかったのです。そのためには、まず自分たちが今どこに投資しているのかを、構造として把握する必要がありました。
KPIの進捗についても、数字としては見ているものの、それがどれだけの開発投資によって支えられているのかまでは見えていませんでした。結果として、選択と集中をしたいと思っても、その判断材料が不足している状態だったと思います。
Jiraだけでは限界だった投資構造の整理
成原：以前からJira上でもラベル運用は行っていましたが、それが体系立って整理されておらず、過去に使っていたものが残ったままになっていて、何のためのラベルなのか分からない状態になっていました。分類の軸として機能していないラベルが増え、投資の観点で使おうとすると、かえって混乱を招く状況だったと思います。
一時期は、いっそラベル運用自体をやめたほうがいいのでは、という話が出るほどでした。
そうした中でFindy Team+のプロジェクト投資分析機能を見て、Jiraのデータを前提にしながら投資構造を整理できそうだと感じました。ラベルの整理を行うことで、投資配分が可視化できる点は大きな魅力でした。
また、経営層やプロダクト側とのコミュニケーションを考えたときにも、数値で話ができる点は重要でした。これまでは「なんとなくこのあたりに工数を使っている」という説明になりがちでしたが、投資カテゴリ別に整理されたデータがあれば、議論の前提を揃えやすくなると感じました。
スクラム開発における施策管理──可視化前のJira運用
成原：スペースマーケットでは、Large Scale Scrum（LeSS）で開発を進めています。Growth Unitと品質を担うTrust Unitがあり、それぞれのUnit内に複数チームが所属しています。各Unitごとにバックログは分かれていて、同一Unit内のチームでプロダクトバックログアイテム（以降、PBI）を共有しています。PBIは「その単位でユーザーに価値を届けられるか」を意識して切るようにしています。
施策のアイデアはまず企画書としてまとめ、企画開発会議の中で進めるものを決めます。実施が決まった者は、企画内容をもとにPOがEPIC or PBIに変更させます。その後、エンジニアも含めて、どう分割するか、どのチームが担当するかを議論します。エピックはPBI単位に分解し、ストーリーポイントを付けたうえでリファインメントを行い、仕様の詳細を詰め、受け入れ条件を記載。合意できたものをサブタスクに落として進める流れです。
実際の作業管理はサブタスクが中心で、サブタスクが完了していくことで、最終的にPBIやエピックがクローズされます。開発プロセス自体は比較的整理されており、日々の運用で大きく困っている感覚はありませんでした。
一方で、可視化の観点では課題もありました。リファイントメント〜プランニングの中で要件定義と設計を行き来することが当たり前になっており、Jiraのステータス遷移だけを見ても、どこに時間がかかっているのかを素直に捉えにくい状態でした。
そのため、プロジェクト投資分析機能を使うにあたっては、まずこのJiraの運用、とくにラベルの扱い方を見直す必要があると感じていました。
Jira運用の再設計──オートメーションによるラベル運用の自動化
成原：実際にFindy Team+上で可視化を進めるにあたり、ラベルを一度棚卸しし、整理しました。
幸い、直近ではラベルをあまり活用できていなかったため、過去の運用に引きずられずに設計し直すことができたと思います。
ラベルの付け方については、エピック化されたタイミングで投資カテゴリに対応するラベルが自動で付与されるように、Jiraのオートメーションを設定しています。また、エピック配下のイシュー（ユーザーストーリーや一部のタスク）にも、エピックと同じラベルが自動的に引き継がれるようにしました。これによって、エピック階層全体で投資カテゴリが揃いやすくなっています。
ただ、運用負荷はそこまで高くありません。週に一度、15分ほどラベルの付き方を確認する程度で、継続できていますし、メンバーに新しい作業を強く求めるようなこともありません。
投資カテゴリをどう判断するかについては、企画書に書かれている目的や目標を基準にするようにしています。多くの施策は新規機能か既存機能の改善のどちらかに分類できるため、個人の感覚で判断が分かれることはあまりありません。
品質保証や信頼性に関わる取り組みについては、トラストチームが中心になって対応しています。問い合わせ対応やページ速度の改善など、エピックではなくタスク粒度から始まるものも多く、こちらはまだラベル運用を本格的に回せていない部分です。今後どう仕組み化していくかは、検討していく必要があると感じています。
全体としては、Jiraの運用を大きく変えることなく、最小限の調整で投資分析につなげられている感覚があります。
KPIを意識しているつもりだった──投資割合から見えたズレ
成原：実際にプロジェクト投資分析機能を使い始めて、まず感じたのは「思っていた以上に見えていなかった部分が多かった」ということでした。これまでも事業のKGIやKPIを意識して開発しているつもりではありましたが、投資配分として整理してみると、必ずしもそこにコミットできていないケースがあると分かりました。
エピック単位で見たときに、そもそもKPIに向いていないエピックが混ざっていることにも気づきましたね。
新規機能、既存機能の改善、品質保証といった投資カテゴリごとに見ていくことで、「どの領域にどれくらいリソースを使っているのか」が初めて一目で分かるようになりました。例えば、新規機能への投資割合が高い一方で、品質保証については別チームで対応している影響もあり、数字上は少なく見える構造になっていることがはっきりしました。
こうした結果は、チーム全体でも共有しています。Growth Unitグロースユニット全体の振り返りの場で数値を共有したり、スプリント単位の振り返りの中で「この期間の投資割合はどうだったか」を話すようにしています。
可視化された数字があることで、「選択と集中が本当にできているのか」「この投資バランスでよいのか」といった議論を、感覚ではなく事実をもとに進められるようになりました。まだ改善の途中ではありますが、議論の前提が揃ったこと自体が、大きな前進だと感じています。
投資分析を起点にした、これからの意思決定と組織づくり
成原：今後は、この投資分析の結果を「振り返りのためのデータ」にとどめず、意思決定に使っていきたいと考えています。特に、自分たちがやっている日々のタスクと、事業のKGIやKPIをどう結びつけていくかという点です。
目の前のタスクに取り組んでいると、その作業が事業のどこに効いているのかを見失いがちです。投資カテゴリとして整理されたデータがあれば、「この期間はどの領域に力を入れていたのか」「それは今の事業フェーズに合っていたのか」を振り返ることができます。そうした振り返りを通じて、次にどこへ投資するかをより意識的に決められるようにしたいと思っています。
今回の分析で実感したのは、自分たちが持っていた定性的な肌感と、実際に計測した数値の間には、思っている以上にズレがあるということでした。体感としては正しいと思っていた投資配分でも、数値で見てみると20〜30％ほど異なっている場面は決して珍しくありません。
そのブレを適切に運用することで、組織としてより良いリソース配分ができるようになります。
また、体制や採用などのリソースアサインの観点でも、活用できると感じています。投資配分と事業の状態を並べて見ることで、「人を増やすべきなのか」「やり方を変えるべきなのか」といった判断を、感覚ではなくデータをもとに議論できるようになるはずです。
経営層とのコミュニケーションにおいても、この可視化は大きな意味を持つと考えています。これまで人件費を含めた投資の話は抽象的になりがちでしたが、実際の投資配分を示しながら説明できれば、事業側が考えている予算感とのすり合わせもしやすくなると考えています。
今後一緒に働きたいエンジニア像とは？
成原：私たちエンジニアの存在意義は「プロダクトを通してユーザーに価値提供を行うこと」ですが、価値提供という言葉はあまりに抽象度が高いです。
なので、言われたものを思考停止で受け止めるのではなく、Why・Whatから自身で解釈し、エンジニアリングを通して価値提供を高速にできる組織を作っていきたいです。
自身の仕事に誇りを持ちながら、ユーザーへの価値提供を最優先事項として考え、動ける方。
そして、自身で閉じずに、チームで大きな未来を描くことにモチベーションを燃やせる方。
施策のWhy・Whatから自身で考え、ユーザーに価値提供を行えるダイナミズムに興味がある方には絶好の環境です！
https://findy-code.io/companies/668
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
https://jp.findy-team.io/
