オーナーシップの持ちやすさを目指した、大規模プロダクト開発体制変更の裏側

こんにちは。「SmartHR基本機能」でプロダクトオーナーをしている塚本です。

この記事では「SmartHR基本機能」の開発体制変更の経緯とその後の状況、開発チームからの声を紹介しています。大規模プロダクトにおいて以下のようなモヤモヤを抱えている方の参考になると幸いです。

提供機能が多岐にわたるため
- すべてを把握するには認知負荷が高すぎる
- ゴールの設定難易度が高い
開発チームの思考が担当機能に閉じやすい

はじめに

SmartHRには、大きく分けて2種類のプロダクトがあります。ひとつはコア機能である「基本機能」で、もうひとつは基本機能にアドオンする形で使える「オプション機能」です。

この記事では、「基本機能」の開発体制について記載しています。

SmartHR「基本機能」の開発では大規模スクラム（LeSS）を採用しており、現在は6チームで構成されています。各開発チームにはPM、エンジニア、デザイナー、QA、UXライターが所属しており、総勢約50名の大所帯となっています。そして、昨年11月頃に6チームを2つのグループに分けるという体制変更を行ったので、経緯など含めてご紹介したいと思います。

補足: 各グループの担当領域

フロントシステムグループ
- 従業員と人事労務担当者が直接やりとりする領域（例: 申請機能）
人事DBグループ
- 正しい情報を蓄積・管理し、活用に備える領域（例: 履歴管理）

※ このグループ分けの軸は、機能ではなく提供価値としています。

感じていた課題

前提として、「基本機能」はかなり大きなプロダクトで、提供している機能も「申請機能」「給与明細」「従業員情報管理」「履歴管理」など多岐にわたり、すべてを詳細に把握することは認知負荷が非常に高いです。

昨年チームとやりとりをする中で、下記のような課題を感じることが増えてきました。

開発チームメンバーの目線が揃っていない
思考のスコープが担当する機能に限定されやすい

それぞれの課題感についてもう少し詳しく説明します。

まず「開発チームメンバーの目線が揃っていない」については、そもそもSmartHR「基本機能」としての目標を言語化できていなかったことと、人数が増えたことが相まって、そう感じることが増えたように思います。目標を言語化できていなかった要因の1つに、「基本機能」の提供価値が多岐にわたるために、フォーカスを絞った目標を設定しにくいということがありました。それでも人数が少ない間はなんとなく共通認識を持てていたように思いますが、徐々に人によって注力すべきと考えることが異なるなど、見えている景色が違ってきているような感覚がありました。目線が揃わないと成果を最大化できないことは想像に難くないですが、このままではまずいという危機感を感じていました。

次に「思考のスコープが担当する開発アイテムに限定されやすい」ですが、各開発チームが担当する開発アイテムは一貫性がないことも多く、中長期の視点が持ちづらいという状況がありました。例えば、給与明細の機能改善の次は権限管理機能の改善といった具合です。

どのように各チームの開発アイテムを決定していたかというと、ロードマップモム会で優先度について協議・決定したあとは、基本的には早く着手できるチームに割り当てるというやり方をしていました。プロダクト全体としては優先すべき開発をできていて一見効率よく見えるのですが、開発チームからするとコンテキストスイッチの負荷も大きく、プロダクト全体を点ではなく線や面で捉えることが難しかったように思います。

私たちのゴールは特定の機能の価値のみを最大化することではなく、顧客の人事労務に関する業務をプロダクトによって効率化することです。思考のスコープが限定されてしまうことは、価値あるプロダクトをつくるうえで大きな障害となると感じていました。

開発チームがもっとオーナーシップを持ちやすい体制へ

上記のような課題感から、開発チームの担当領域を狭めることでビジョンや目標を定めやすくすることと、担当領域の解像度をあげて顧客価値を最大化することを目的とし、冒頭で記載したとおり開発チームを2つのグループに分けることにしました。

担当領域の解像度があがることで、プロダクトへのオーナーシップを持ちやすくなり、誰もが中長期の視点を持ちながらアイデアを出し合い、顧客のニーズに応えるプロダクトを素早く提供できるような組織への成長を思い描いています。

担当グループの決め方についてですが、この体制変更は開発チームがオーナーシップを持つことを重視していたので、体制変更の背景や各領域の魅力や課題について共有後、組織開発のワークショップ手法の1つであるオープンスペーステクノロジーで対話の場を持ちながら進めました。

疑問や懸念などについて話し合いながら理解を深め、その後どちらのグループでやっていきたいかを各チームで意思表示してもらい、決定していきました。

その後の状況

グループを分けたあとはPMが中心となり、各グループでビジョンや目標の言語化を行いました。進行中の開発アイテムの都合により、まだ完全にグループ体制に移行できたとは言えない状況ですが、開発チームが自分たちがこれからどこに向かうのかという共通認識が持てるようになったことは、一歩前進ではないかと思います。

またロードマップを決めるプロセスにおいても、これまではPM/PMMが起案することがほとんどでしたが、今後は開発チームがオーナーシップを持って情報収集〜リリースまでを進めていけるように取り組んでいる最中です。

開発チームからの声

最後に、グループを分けたことに対する感想を開発チームに聞いてみたので、一部ご紹介します。

プロダクトエンジニア

これまでだと今後どういう機能を担当するかわからなかったので、自分達の作っているプロダクトが今後どうなりたいとか、どうしていきたいなどを考えられていなかった印象がありますが、グループ分けして、対象のスコープが絞られたので、そういった部分が考えやすくなり、開発アイテムに対する自分ごと化がより進みそうだなと感じています。

「人事DB」や「フロントシステム」のように、プロダクトの価値の方向をざっくり分類するような思考整理ができたことで、大きく多機能なひとかたまりを目の前にしていたときよりずっと「このプロダクトが成長していく（≒ユーザーへの提供価値が高まっていく）とはどういうことなのか」をクリアに考えやすくなりました。また、CSやSalesメンバーとの会話においても、個別の機能の局所最適化ではなく導入意図や活用目的といった土台にあたる抽象度のテーマをベースに課題を話し合えるようになってきたことがありがたいです。チーム全体で目標の目線を揃えられることで、より多角的な観点からあるべき姿の意見が出せたり工夫を凝らしていけるよう、開発プロセスも改善を進めていきたいところです。

UXライター

これまではそのフィーチャーで届けたい価値に閉じがちだった視点が、「人事DBとしてどういういう価値につながるんだろう？」のように、みんなの視座が上がっている雰囲気を感じています。

グループが分かれる前は、自分たちが開発中の機能に集中している傾向が強く、お客様の要望なども開発中の機能に特化して取得していました。この機能はあのチームが詳しいからあのチームが開発するのが良いかもといったように少し属人化している部分もあったと思います。グループが別れてからは開発中の機能だけでなく、グループ全体として何が課題なのか、どこへ進むべきなのかなどより大きな視点で考えやすくなり、開発するアイテムについても柔軟に考えられるようになり、その結果として属人化も解消していっていると感じています。

プロダクトデザイナー

これまでの基本機能のロードマップは、取り扱う範囲が広すぎて逆に見通しが立てづらい状況だったのに対して、テーマが絞られたことによって、それぞれのプロダクトビジョンを検討できるようになりました。「全体ではこっちに行くんだな」を意識して開発featureの位置付けをチームで話すシーンが生まれたことは、よい効果だと感じています。

この施策が成果として現れるのはもう少し先になりそうですが、開発チームの関心が担当機能から線や面で捉えた顧客価値へ、短期から中長期へと変化が見られ、オーナーシップを少しずつ持ち始めていることが感じられました。このような体制変更は決してひとりでできるものではなく、開発チームや関係者の理解や協力、納得感があってのことです。大所帯だからこそ大変なことももちろんありますが、一丸となった時に出せる成果は計り知れず、とても楽しみなものでもあります。良い方向に向かえるよう、引き続き課題と向き合い前進していきたいと思っています。