こんにちは。SmartHRでテクニカルプロダクトマネージャーをしている @h1kita とプロダクトエンジニアの @meganemura です。
SmartHRでは、今年（2023年）1月にプロダクト基盤チームを立ち上げました。 このチームは、SmartHRがマルチプロダクト戦略を実現し、ユーザー価値の向上と事業成長を続けていくために非常に重要な役割を持ちます。
この記事では、プロダクト基盤チームが組成された背景やミッション、取り組んでいることやその難しさについて紹介したいと思います。
プロダクト基盤チーム組成の背景。SmartHRの向かう先とマルチプロダクト戦略
「SmartHR = 労務系SaaSを提供している会社」というイメージを持っている方も多いのではないでしょうか。
もちろん間違いではありませんが、SmartHRは コーポレートミッション の “well-working” 実現に向け、祖業である労務領域だけでなく、タレントマネジメント領域のプロダクトも展開しています。
また、グループ会社による新規事業や外部ベンダーと連携したアプリケーションプラットフォームの構築も進んでいて、もう労務だけを扱う会社ではありません。
将来的には、「バックオフィスのあらゆる業務がSmartHRを中心に繋がっていくような世界」を目指して事業を拡大させており、そのような中で次の成長をつくっていくためのキーワードとしているのが「マルチプロダクト戦略」です。
SmartHRのマルチプロダクト戦略とは
SmartHRは労務やタレントマネジメントなど領域をまたいで、複数プロダクトを提供しています。提供しているプロダクトはSmartHRが提供しているものだけでも10個を超え、プラットフォーム上の他社製アプリを含めると30個以上存在しています。
今年3月に実施した「事業戦略発表会」でも、マルチプロダクト戦略を事業戦略のキーワードとしていくことを発表しています。
マルチプロダクトといっても、ただ単に複数のプロダクトをバラバラに提供するだけでは、ユーザーにとっても事業にとっても大きな価値は作れません。
プロダクト同士の連携や共通化、統一化によって、深いシナジーやシームレスな体験を作りだすことで、マルチプロダクトとして導入することの価値を作り出すことができます。
マルチプロダクト戦略を実現していくためには「データの連携」「プロセス、機能の連携」「管理の共通化」「統一されたUIや振る舞い」といった連携や共通化を作っていく必要があります。
それぞれ簡単に説明します。
- データの連携
- 各プロダクトに蓄積されたデータを統合し活用することで、単一プロダクトでは提供できない質の高いソリューションを提供する
- プロセス、機能の連携
- プロダクト間のプロセスや機能を高いレベルで連携させることで、業務や目的に合わせたシームレスなユーザー体験を提供する
- 管理の共通化
- 複数プロダクトで活用されるアカウントや部署などのマスターデータを共通管理することで、データのメンテナンスコスト削減やデータの更新性を担保する
- 統一されたUIや振る舞い
- デザインシステムによる統一されたUIや振る舞いをつくり、プロダクトごとの違いをなくすことで、ユーザーの迷いや学習コストを削減する
また、それによる事業価値としても以下のようなものを期待できます。
- 連携や共通化が、アップセルやクロスセルにつながる
- 複数領域のプロダクトを提供することで、多くのエントリーポイントが設けられる
- 連携や共通化による価値ある体験が競合優位性となる
これらを実現するためには、プロダクト同士が連携するための共通基盤を作っていくことが必要です。
プロダクト基盤の必要性とチームの組成
SmartHRでは、プロダクト同士が連携するための共通基盤を「プロダクト基盤」と呼んでいます。
プロダクト基盤に乗るアプリケーションは、基盤を通してデータや機能を連携します。
またそれだけでなく、プロダクト基盤は、そこに乗るアプリケーションの開発効率を高める役割も持ちます。
共通利用する機能を基盤化することで、各アプリケーションはログインや権限管理、課金管理といった機能を作る必要がなくなり、それぞれの領域の開発に集中できます。
そうすることで、新規プロダクトの高速な立ち上げや日々の開発効率の向上も期待できますし、プロダクト基盤を強化することで、全アプリケーションの機能を強化するというレバレッジの効いたプロダクト開発も可能になります。
これらの開発は、これまで全然やってこなかったわけではありません。
内部的には将来プラットフォーム化することを見込してアーキテクチャを設計してきており、社内のオプション機能はそのドッグフーディングも兼ねて本体のアプリケーションとは分離し、APIを利用する形で構築してきました。
しかし、領域を超えてプロダクトを提供して初めて学習できた課題や、ドッグフーディングによって学習できた課題も多くあり、課題は山積みです。
それらの課題を解決し、マルチプロダクト戦略の実現に向けて強いプロダクト基盤を作っていくため、そこに専門性と責任を持つチームとしてプロダクト基盤チームが組成されました。
プロダクト基盤チームのミッション
プロダクト基盤チームは現在、大きく以下2つのミッションを持って活動しています。
- ユーザーが複数プロダクトを導入することの価値を作る
- ユーザーが複数プロダクトを導入する際の課題を解決する
それぞれ簡単に説明します。
ユーザーが複数プロダクトを導入することの価値を作る
このミッションでは、ユーザーがSmartHR内で複数プロダクトをまとめて導入することが、ユーザーにとっての価値につながる状態を目指しています。つまり、複数社のプロダクトを組み合わせて使うより、すべてをSmartHRで揃えることの価値を作るということです。
例えば、
- プロダクト間のデータが連携できるので、領域横断した分析や検索ができるし、部門間の業務連携もスムーズになる
- 部署や役職といったマスターデータが連携されているので、組織変更時のメンテナンスが効率化される
- プロダクト間の機能が連携できているので、スムーズに業務を進められ、業務が効率化される
などです。
ユーザーが複数プロダクトを導入する際の課題を解決する
領域をまたぐプロダクトを一つのサービスとして導入する場合、部署や役職も様々なユーザーが利用することになり、それが導入の障壁となることがあります。
例えば、
- それぞれの担当者はどこまでのデータを見て良くて、どこまで操作できていいのかといった権限の柔軟性が求められます
- 横断したデータ活用がある場合には、その柔軟性はプロダクトを横断する形で求められます
- プロダクトごとに利用人数が異なる場合、課金体系の柔軟性も求められます
こうした社内ポリシーや契約に関する問題は導入を妨げる強い要因となる場合もあり、領域をまたぐマルチプロダクトにとっては解決しなければならない大きな課題です。
プロダクト基盤チームの実際の取り組みとその難しさ
ここからはミッション達成に向けた、実際の取り組みやその難しさについても紹介します。
プロダクト基盤チームの取り組み
ここでは、実際に取り組んでいることを2つ紹介します。
- 権限基盤
- プロダクトを横断したデータ集約API
それぞれ簡単に説明します。
権限基盤
SmartHRの権限は、プロダクトごとに細かい権限設定を可能にしたい、立ち上げスピードを早めたいなどの理由で、基本機能の権限とは別にプロダクトごとに設定できるように作られています。
しかし、プロダクトが増えるにつれて、分かれていることによる課題もでてきました。
- 権限設定が各プロダクトに分散していることで、今誰がどんな権限を持っているかが分かりにくい
- 権限変更時に操作する場所が増え、変更漏れや工数増加に繋がっている
- 複数領域を管理していることで、管理者であっても操作できないようにしたい、データを見られたくないものもある
また、基本機能の権限は労務領域のみを提供していたときに作られたもので、領域をまたぐことで顕在化してきた課題もあります。
そのため、複数プロダクトの権限を統合管理でき、かつ各社の運用に合わせて柔軟に設計できるような権限基盤の設計、構築を進めています。
プロダクトを横断したデータ集約API
SmartHRは以下のようなアーキテクチャになっていて、基本機能に蓄積された従業員データはAPIを通して各プロダクトで利用できる形となっていますが、基本機能以外のプロダクトのデータを他プロダクトからは活用できない状態になっています。
部署や役割を横断したシームレスな体験、より広いデータを活用した分析や閲覧、検索を実現するため、複数プロダクトを横断して統合的に従業員データを活用できるような集約APIの構築を進めています。
これは、SmartHRのマルチプロダクトとしての価値を高めるための、非常に重要な取り組みです。まずは、オプション機能の連携から進めていますが、将来的にはもっと広いデータ活用もできるようにしていきたいと考えています。
これらはそれぞれ、組織、アーキテクチャ、既存との整合性、マイグレーションなど様々な難しさが伴います。
プロダクト基盤をつくっていくことの難しさ
既存の基盤的機能を変化させる難しさ
社内で本体と呼んでいるリポジトリには、労務機能（入社手続きや電子申請など）と、基盤機能（権限、アカウント、通知、APIなど）の両方が含まれています。
この基盤機能をマルチプロダクトに適用できる形に変更していく上で考慮することがいくつかあります。
- 本体の労務機能と基盤機能はコード上に明確な境界が無く暗黙的に依存していて、互いの変更が意図せず影響を与えてしまうことがある
- 既に運用されているものに変更を加えるため、現状の挙動と整合性を保ちつつ改善する必要がある
- 基盤機能はプラットフォーム上の全てのプロダクトから依存されるため、インターフェースの安定と、高い可用性の維持が必要となる
マルチプロダクト向けに基盤機能を変更する上で大きな設計変更は避けられず、これらの考慮事項を押さえつつ変化させていくという点に難しさを感じています。
プロダクト基盤チームではこの課題に対しての初めの取り組みとして、既存の労務機能・基盤機能を含むモノリスを、明確なインタフェースを持つモジュールへと分解してモジュラーモノリスにするアプローチを取っています。
モジュラーモノリスの取り組みは、まだ始めたばかりではありますが、
- モジュールのサイズをどのように決定するか
- モジュール間をどのように連携させるか
- モジュールを越えて結合するライブラリをどうアップデートするか
などの、トレードオフを把握し決定する難しさが既に見えており、解決に向けて議論を重ねています。
データの統合方法と統合データ利用の難しさ
プロダクトごとに散在している従業員データを、横断して検索・閲覧するという統合利用の実現もまた、考慮すべき点があります。
- データを事前に集めるか、要求ごとに集めるかどうかという選択に関係するトレードオフ（検索性・応答性能・整合性）がある
- 各プロダクトは内部的に変更されたとしても、横断利用されるデータは他のプロダクトに向けて互換性を保つように設計する必要がある
- データを集めたり利用するプロダクトは各データを生成するプロダクトの知識を持ちすぎないようにデータを利用する必要がある
- 統合データのアクセス制御といったデータセキュリティの実現
横断的なデータ利用はそのプロダクトごとに求められる性質が異なっており、考慮点として挙げた点を踏まえて総合的に判断する点が難しいと感じます。
プロダクト基盤チームでは現在2種類のデータ統合利用に着手しており、特性からそれぞれ事前にデータを集めるものと、要求ごとにデータを集めるものとに分かれています。要求ごとにデータを集めるアプローチとして、GraphQL Federation を用いた実現の検証といった新たな技術の利用にも取り組んでいます。
統合利用はまだ始めたばかりで、ユースケースを整理しながら適切なアプローチを模索しているところです。
一緒にSmartHRのプロダクト基盤を作りませんか？
プロダクト基盤チームでは、一緒にSmartHRの成長を加速させてくれるテクニカルプロダクトマネージャー、プロダクトエンジニアを募集しています。
この半年間、現状の課題を調査したり、戦略実現に向けた新たな価値提供を模索してきましたが、やりたいこと、やるべきことがたくさんあり、今後チームもスケールさせていきたいと考えています。
すでに稼働している環境でプロダクト基盤を改善、構築していくのは、決して簡単なものではありませんが、今後のSmartHRの成長をつくるとても重要でやりがいのあるポジションです。
もしかしたら、ちょっとハードルが高そうと感じる方もいるかもしれませんが、僕たちもチームで議論し、学習しながら、手探りな状態で前に進めている部分もたくさんあります。
プロダクト基盤チームはまだ立ち上がったばかりですが、ぜひ一緒に議論しながら、最高の基盤とチームを作っていきましょう！
ご興味ある方は是非一度お話させてください。
テクニカルプロダクトマネージャー open.talentio.com
シニアウェブアプリケーションエンジニア（プロダクト基盤 バックエンド） open.talentio.com
