こんにちは。SmartHRの労務領域でプロダクトマネージャーをしている塚本です。
この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿します。ぜひご覧ください！
2023年下期に労務プロダクトとしての担当機能を再定義し、今期から運用を始めたので、その背景やどのように変えたのかを紹介します。 マルチプロダクトの会社で担当領域の棲み分けについて、課題をお持ちの方の参考になれば幸いです。
労務領域の再定義をしたかった理由
私は2019年に入社以降、労務領域の「基本機能」のプロダクトオーナーをしていました。 下の図の青線で囲った部分が「基本機能」の担当領域です。
この「基本機能」という分類が曲者で、プロダクトマネジメントをするうえではやりづらさを感じていました。そもそも機能が多岐にわたるうえ、近年ではタレントマネジメント領域のプロダクトも増え、「基本機能」としての中長期ゴールをどこに置けばよいのか？ということに頭を悩ませていました。
2021年にも機能が多岐にわたることに起因する課題感から開発体制を変更し、うまくワークするようになったことも多くありました。ただ、当時との差異として、タレントマネジメント領域のプロダクト強化がありました。
その変化がどういった影響を及ぼしたのかの一例を説明します。 「基本機能」の担当機能の1つに「従業員データベース」がありますが、これは労務管理においても、タレントマネジメントにおいても不可欠な、SmartHRプロダクトの土台となる重要な情報・機能です。
そうなると必然的に「基本機能」チームがやるべきこととして
- 労務領域でのプロダクト価値を増やすための開発
- タレントマネジメントのプロダクト価値を増やすための開発
が混在する状況がうまれます。 この2つは全体で考えるとどちらも重要ですが、ターゲットや提供したい価値は異なります。この2つを比較し、納得感のある優先度をつけることは容易ではありません。多くのステークホルダーとのコミュニケーションも必要になり、優先度決定までの時間もかかります。そして何より、開発チームにとっての「何を目指すのか」に曖昧さをもたらします。
つまり、マルチプロダクト開発を加速させるためにも、開発チームが何を達成すべきなのかを明確にしたかったのです。
担当領域再定義PJのはじまり
そのような思いを抱える中、CEOの芹澤さんとの1on1で「労務、タレントマネジメント、基盤の3つで組織構造と担当領域を揃えたほうがやりやすいと思うんですよね〜」と何気なく話したことをきっかけに、担当領域を再定義するプロジェクトが始まることになりました。
まずは、「基本機能」を担当するエンジニアマネージャーと、なぜやりたいのか、どういう状態を目指したいのかをすり合わせました。その後、従業員データベースに深く関わるPMとエンジニア、さらに基盤領域担当のPMとエンジニアにもPJメンバーとして加わってもらいました。そして、ゴールのすり合わせやタスクの洗い出し、進め方などについて議論を重ねました。
領域と職種が異なるメンバー間での議論は、普段の業務で得ている情報や職種による関心事の違い、私自身がうまく言語化しきれなかったことにより、最初はうまく目線合わせができませんでした。 諦めるわけにもいかないので、対話を重ね、同じゴールイメージを描くことができた結果、やるべきことの方向性も見え、以下の2つのテーマに分けて進行することにしました。
- 担当領域の再定義と組織変更
- 担当領域の再定義に伴うアーキテクチャの検討
なお、アーキテクチャの検討は主にエンジニアが進めてくれていたため、本記事ではふれません。（誰かが書いてくれることを期待）
担当領域の再定義と組織変更でやったこと
担当領域を再定義するにあたり、各機能のオーナーを明確にしました。各機能に対し、それぞれ「労務」と「基盤」どちらがオーナーかを決めるのです。
- 機能の洗い出し（結果、なんと43個でした..！！）
- 現状と理想状態について「労務」「基盤」を振り分ける
- はじめの一歩と中間地点での目標を決める
という流れで進めました。
対象機能がかなり多かったため、小さく始めて軌道修正しながら進めることを意識しました。理想の状態には1年くらいでもっていくことを目指しています。
※機能数の合算が43にならないのは、労務/基盤の両方をオーナーとしている機能があるため。
また、これを機に機能オーナーの役割を 「今と未来に対して責任をもつチーム」と定義し、機能とコードに対する責任の所在を明確にしました。これは決して責任の押し付け合いがしたいわけではありません。これだけ多くの機能に対し「基本機能」「基盤」に関わる70名近くの開発関係者がいる中で、一定の役割定義がないとコミュニケーションパスも複雑になりますし、品質担保も困難になるためです。
そして、機能オーナーが決まってからは、それを実現するために必要な体制やリソースを検討・決定していきました。
「開発チームが何を達成すべきなのかを明確にしたい」という最初の趣旨からは外れてしまいますが、よりスピード感をもった価値提供を目指すために、同じタイミングで「基本機能」チーム内も体制変更を行いました。 これまでは7チームでLeSSを運用してましたが、領域ごとにそれぞれ独立したLeSSチームとして運用することに決め、POも新たにそれぞれのLeSSチームにたてました。 また、労務全体をみるPOの役割も新設されました。
そして、いま〜これから
多くの方の協力により、無事に1月から「はじめの一歩」の状態で運用し始めることができました。とはいえ、想定外に負荷がかかってしまっているチームがあったりと、すべてが順調というわけではありません。今後は、ふりかえりをしつつ、常に最適解を模索しながら進行していく予定です。
そして、プロダクトの領域と組織構造が揃いつつあることで、私自身は動きやすくなったと感じています。今期から基本機能のPOは引き継ぎ、私は労務プロダクト全体のPOを担うことになり、労務領域としてのビジョンやゴールについて考え始めています。
開発チームの全員が、何を目指すのかをしっかり認識したうえで、顧客に価値を提供できる組織を目指し、引き続き取り組んでいきます。
プロダクトマネージャーを募集しています！
私たちはプロダクトマネージャーを募集しています！ SmartHRでは引き続きPMの採用に注力しています。PM職に関する情報をまとめた記事がありますので、ぜひご一読ください。カジュアル面談のリンクなどもこちらに掲載しております。
