こんにちは。SmartHR VP of Engineeringのmorizumiです。
2024年3月11日に「SmartHRがARR150億円を突破、前年比150％で成長」というリリースをSmartHRは出しているのですが、これはそんな急成長を支えているプロダクト横断基盤開発チームについての記事です。
SmartHRはスケールアップ企業を標榜しており、事業・プロダクトともに大規模でありながら急成長を続けるという新しいステージの挑戦を始めています。
プロダクト横断基盤チームは、スケールアップ企業であるSmartHRの今後の成長を支えるアプリケーションレイヤーのミドルウェアを開発しています。データの量・種類の多さ、権限に関する考慮、開発者体験、スケーラブルなアーキテクチャ、全社に関わる意思決定、などなど技術的にも事業的にも難易度が高く、それゆえに面白い領域になっています。
今回は、SmartHRが取り組んでいるプロダクト横断基盤開発について、現場のマネージャー / メンバーへのインタビューを通してその内情、難しいポイント、そして面白さをお伝えしていきます。
プロダクト横断基盤の全体像
まず、プロダクト横断基盤チームでエンジニアリングマネージャを務めるmeganemuraさんに、全体像をお伺いします。
meganemura
2017年にSmartHRに入社。基本機能の開発ののち、初めてのオプション機能立ち上げに開発者として参加。 2023年から複数プロダクトの連携・共通化やそれにまつわる課題解決を行うプロダクト横断基盤開発に従事。2024年からエンジニアリングマネージャ。
── まずは、プロダクト横断基盤の全体像を教えてください。SmartHRというプロダクトにおいて、プロダクト横断基盤はどのような役割を担うものですか？
プロダクト横断基盤は、「基盤」という言葉からよく連想される、アプリケーションを実行するインフラを提供するチームではありません。 複数のプロダクトが必要とする共通の基盤を提供するチームです。 マルチプロダクト戦略を推進する上で起こる変化に合わせて、SmartHRにおけるプロダクトの基盤を進化させる役割を担っています。
SmartHRのマルチプロダクト戦略は、複数のプロダクトを作って提供するだけのものではありません。複数のプロダクトで管理された従業員の情報やマスターデータを互いに連携し活用すること、また、機能同士の連携によって単体のプロダクトでは実現できない業務プロセスを実現すること。これらを通して、SmartHRで複数プロダクトを利用してもらうことの価値を生み出そうとしています。
例えば、新入社員に対して入社手続き時の情報入力依頼と同時に、別プロダクトを介して労働条件通知書を送付して合意締結を行う、といった連携ができるようになっています。こうした機能間連携を拡張していくことで、今までは別々の部署がそれぞれに実施していた業務がシームレスになり、より効率的に業務が実施可能になります。
これから多くのプロダクトを提供していく中で、各プロダクトが利用しやすい基盤を作り実際に利用してもらうことでマルチプロダクト戦略を推進していくことが、プロダクト横断基盤の役割だと捉えています。
── プロダクト横断基盤のチーム構成と働き方を教えてください
プロダクト横断基盤は、2023年1月にプロダクト基盤チームという1チームでスタートしましたが、2023年の途中で内部的に権限基盤・プロダクト連携・課金基盤の3チームに分割しました。そして2024年1月には新たに従業員データ基盤チームが組成されました。 つまり2024年3月時点では、権限基盤・プロダクト連携・課金基盤・従業員データ基盤の4チームからなります。 マルチプロダクトを推進する過程で、解決すべき課題が次々に明らかになり、それらに対応するためにチームが増加していっています。 各チームは、プロダクトエンジニア2名・QAエンジニア1名（兼務）・PM1名で構成されています。
プロジェクト管理や作業の進め方はチームに任されており、全てのチームがスクラム開発を採用しています。 また、ペアプロやモブプロといった同期での開発も多く実施されています。 これは基盤に限った話ではありませんが、チームメンバーの居住地はさまざまで、全てのミーティングをオンラインで行っています。
チーム全体の取り組みとして、週1回の全体会議と月1回の「集まる日」を設けています。 「集まる日」はランチをしたり同期で作業をするラフなイベントで、参加は任意です。雨天の場合は中止というルールがあります。
── チームが増加していっているのですね。年内にさらに増やす予定はありますか？
エンジニアだけの話をすると、現在4チームで9名のところを、16名増員して6チームで25名にしようと考えています。 基盤外からチームごと異動してくることも予定した人数となるため、既存チームへの増員や新しいチームの組成の新規採用数としては12名増やしたいと思っています。
── マネージャー目線で、プロダクト横断基盤に関わるおもしろさは何でしょうか？
1つのチームだけでは対応できない規模の課題解決や付加価値の提供に取り組めるところは、基盤特有の面白さだと感じます。
課題解決の例としては、既存の共通基盤の変更が挙げられます。 SmartHRでは「基本機能」と呼ばれるプロダクトを中心にして、そこと連携する大きな機能ごとのプロダクト群がつながった構成となっています。 中心にある基本機能は大きなモノリシックなシステムになっており、他のプロダクトから利用される共通機能の基盤を内包しています。例えば、アカウント管理、従業員や会社情報の管理、権限管理、通知などが該当します。
これらの共通機能への変更は、既に多くのお客様から利用されているプロダクト全体に影響を与えます。 共通機能への変更が価値を出すには、単に基盤を変更するだけではなく、各プロダクト側で適用してもらう必要があります。 しかし、各プロダクトがその変更に対して適用するタイミングはさまざまです。 そのため、機能的およびAPIの後方互換性を維持しながら、共通基盤を漸進的に変化させていく必要があります。 この点はまさにスケールアップ企業ならではの難しさであり、挑戦のしがいがあるものだと感じます。
また、マルチプロダクトとしての付加価値を生み出せることは、基盤チームで仕事をする際の大きな魅力です。 付加価値の一例としてプロダクト間のデータ連携があります。 昨年まで「基本機能」プロダクトと連携するプロダクト群のデータは各プロダクト内に閉じており、サイロ化していました。そこで、分断されたデータを他のプロダクトで利用可能にするために、プロダクト連携チームがリードして、各プロダクトチームの協力を得て、横断的なデータAPIの開発を進めました。 これにより、これまでアクセスできなかったデータが、共通化されたデータアクセス基盤を通じて他のプロダクトでも利用可能になりました。 SmartHRで従業員データプラットフォームと呼んでいるこの基盤により、プロダクト間で個別に連携する必要がなくなり、プロダクトの数が増えても迅速にデータ連携を実現できるようになりました。 その結果、「2024/01/22 人事評価機能のデータを従業員情報画面で参照できるようになりました」のような機能のリリースにつながっています。
このようにプロダクト間の連携機能は、新たに追加されるプロダクトが単独の価値を提供するだけでなく、既存プロダクトの機能を強化する効果に繋がっています。データ連携および業務プロセス連携といった連携は、各プロダクトの相乗効果を最大化させるものです。こうした連携の基盤を整備することは、マルチプロダクトを戦略的に提供をしていくSmartHRならではの面白い仕事だと思っています。
── どんな人がプロダクト横断基盤チームにマッチしますか？
SmartHRのその他のプロダクトチームとの違いとして、基盤という成果が短期的に見えづらい性質を持つものに取り組んでいることが挙げられます。そのため、基盤を利用するプロダクトが提供する価値だけでなく、1年先や3年先といった長期的な目標に向かって基盤を作り上げていくことにモチベーションを持って働ける人がマッチすると感じます。
権限基盤チーム
ここからは、各チームの代表者の方にお話を伺います。 まずは、権限基盤チームでチーフを務めるhachimitsuさんです。
hachimitsu
2021年に入社後、SmartHR基本機能の開発に関わり、2023年7月から権限基盤チームに移りました。今年に入ってから権限基盤チームのチーフをやっています。
── 権限基盤チームはどのような課題を解決しようとしていますか？
マルチプロダクトにわたった権限の適用課題を解決しようとしています。直近では、それぞれの担当者はどこまでのデータを見てよくて、どこまで操作できてよいのかといった権限の柔軟性の課題と向き合っています。
── 具体的にはどういった課題が生じているんですか？
SmartHR基本機能には「管理者」という強力な権限があるのですが、その権限を持ったユーザーは、マルチプロダクトを構成する他のプロダクトにおいても強力な権限を有するままになってしまう、という課題が発生していました。 例えば、特定のプロダクトでは「管理者」という強力な権限のままでよいが、他のプロダクトでは「閲覧者」といった弱い権限にしたい、という需要がマルチプロダクト環境では生じてくるんですよね。
そういった、単体のプロダクトとしては問題ないが複数のプロダクトを利用していただくとなった場合に生じてくる、横断的な課題に対応しています。
── 権限基盤を作っていく上で感じる難しさを教えてください
権限なので、何かが起きた時にリスクが大きいことと、影響範囲が広いところが難しいと感じています。 ドメインが権限ということもあり、バグが起きた場合に使えてはいけない機能が使えてしまったり、閲覧できてはいけないデータが閲覧できるようになってしまうなどリスクは大きいです。できるだけ小さく作ってこまめにリリースすることを心掛けていますが、基盤となる従業員データやアカウント権限は色々なところで使われているので、ある程度のリスクは常にあります。
── おもしろさはどういったところにありますか？
難しさで書いたことが逆におもしろさでもあります。QAと一緒にテスト戦略を考えたり、どうやってリスクを抑えるのかをチームと話し合って設計や開発を工夫している時が一番楽しいです。また、影響範囲が広いからこそ上手くいった時のインパクトも大きいので、モチベーションにもつながります。
最近の成果としては、「人事評価機能」に連携する従業員項目をSmartHR基本機能から制御できるようになりました」があります。これは、プロダクト毎に閲覧できる従業員項目に制限をつけられるようにすることで、柔軟な権限設定を可能としたものです。ユーザーには、これまで「見えすぎてしまう」がゆえに利用を広げられなかった機能を展開できるようにするという価値を届けられました。
── テストや設計・開発は、具体的にはどのように工夫しているんですか？
テストに関しては、イテレーティブ開発をしていたので開発中に次のことを気を付けるようにしていました。
- 新機能の場合、出ちゃいけない情報が出てしまう
- 既存機能の場合、今使っている機能が使えなくなる
開発を進めていく中でマニュアルテストのコストが高くなるおそれがあったので、基本的には自動テストで全て確認することにしていました。途中でリファクタリングを挟んでも自動テストを育ててきたので、リグレッションテストのコストを抑えられるというメリットを感じることができました。
設計・開発に関しては基本ペアプロで進めていたので、QAを含めた開発者全員が機能や実装周りの細かい仕様のキャッチアップができている状態でした。ユニット内のズレを抑えることができたので、気持ちよく安全に開発を進めることができました。複雑な機能だったので、これはかなり大きいメリットでした。
── どのような感じで複雑だったんですか？
すでに色々なレイヤーに権限制御の仕組みが実装されている中、そこに加えて新しいレイヤーの権限制御の仕組みを導入しようとしていたので複雑でした。既存の権限制御の仕様に影響が出ないように実装しながら、新しいレイヤーを追加することによって権限制御の仕組み全体が複雑になりすぎないように気をつけなきゃいけなかったので、設計が難しかったです。
── 権限基盤の今後の展望を教えてください
直近は、業務担当者が必要以上に従業員情報を参照できてしまうことで、領域をまたいだ機能の導入や運用の障壁となっている課題と向き合っています。 今後は各プロダクトに権限設定が分散していることで発生する課題や、社内の様々な担当者がより安心してプロダクトを利用できるような仕組みを検討していく予定です。
プロダクト連携チーム
続いては、プロダクト連携チームのyataさんです。
yata
2020年に入社後、SmartHR基本機能や従業員データプラットフォームの開発に関わり、2024年1月からプロダクト連携チームに移りました。 プロダクト連携チームではプロダクトエンジニアを担当しています。
── プロダクト連携チームではどのような課題を解決しようとしていますか？
各プロダクトに蓄積された従業員情報を他のプロダクトから活用したいという要望をかなえるべく、従業員データプラットフォームと題してプロダクト横断で従業員情報を取得できる仕組みを開発しています。
── 例えば、どのプロダクトがどのプロダクトのデータを活用するのでしょうか？
現状ですと、従業員サーベイ・人事評価・スキル管理などのプロダクトから、エンゲージメントスコア・最終評価記号・資格情報などの従業員情報が配置シミュレーションとキャリア台帳で活用されています。
── 従業員データプラットフォームを作っていく上で感じる難しさを教えてください
ガイドラインを作っていく動きに難しさを感じています。従業員データプラットフォームでは各ビジネスドメインにフォーカスしたプロダクトから従業員情報を集めるわけですが、表から見えるインターフェースでは、いち従業員情報として一貫したオブジェクトとして見える必要があります。例えば複数の近しい領域のプロダクトから同じ意味を持つデータだが項目の名前が若干異なる形で露出させるなど、全体から見たときにちぐはぐな形を避けるためガイドが必要になります。 今まさに仕組みを作りながら並行してガイドライン・定義の作成も進めているところで、率先して正解を作っていかなければいけないところに難しさを感じています。
── ガイドラインとは具体的にどのようなものかを、もう少し詳しく教えていただけますか？
ここでいうガイドラインとは、各プロダクトチームが従業員データプラットフォームを経由して従業員データを公開するにあたって、どのようにデータスキーマを設計すればよいかが書かれているドキュメントになります。開発者が迷いなく自身のプロダクトに溜まっている従業員データを公開するために必要な確認事項を、思想から実際の実装方法までモリモリ詰まったドキュメントを構想しています。
── 他にも難しさはありますか？
複数プロダクトから従業員情報を集約する上で関係するチームとのコミュニケーションパスの広がりを感じており、より良いコミュニケーションの方法がないかも模索しながら進めています。理想はきっと、データを活用するプロダクトと提供するプロダクトが直接コミュニケーションをとり完結する状態なんですが、まだまだ間を取り持つ立場であるわたしたちがガイドラインや理想の姿を出し切れておらず、従業員情報をどんなインターフェースで提供するかなどを一緒に考えさせてもらっています。
あとは、データ活用プロダクトもデータ提供プロダクトもどちらも欠かせないピースであり、横断して繋がっていることが価値であることを定量的に示せないか模索し始めていますが、まだまだとっかかりが掴めていません。
── おもしろさはどういったところにありますか？
難しいと思うポイントすべて、解決策を考えることはおもしろいです。 複数のプロダクトチームと関わることからプロダクト知識も横断して増えていき、従業員のオンボーディングからオフボーディングまでのどのフェーズ・プロセスでどのプロダクトが必要になっているのか、どの点で溜められたデータがどの違う点で活用されるかなどが見えてくるのも、ならではの面白さかなと思います。パズルのピースが埋まっていくイメージです。
── 従業員データプラットフォームの今後の展望を教えてください
弊社が取り組む領域では従業員情報が要であることは今後も不変であるとして、各プロダクトがそれぞれのビジネスドメインの不合理をシステムで解決する中で、自然に溜まっていく価値ある従業員情報をプロダクト横断に容易に活用できる状態にすることが従業員データプラットフォームの責務だと思います。まだまだ始まったばかりでできないことのほうが多いのですが、ミドルマンである連携チームを介することなくプロダクトチームが主導して従業員データプラットフォームに参加・利用できる状態にすることが喫緊で実現したいことであり、道のりはまだまだ長そうです。
課金基盤チーム
続いては、課金基盤チームでチーフを務める山本（ryp）さんです。
山本（ryp）
2021年に入社後、文書配付機能の開発に携わり、2024年1月から課金基盤チームに移りました。 チーフという立場で、プレイヤーとしてコードを書きつつチームのエンジニアのマネジメントも担当しています。
── 課金基盤チームではどのような課題を解決しようとしていますか？
課金基盤チームでは、契約や課金、契約による機能制御などの、ユーザとの契約管理やプロダクトとの連携周りを担っています。 その中で課題として向き合っているものは大きく2つあります。
1つ目は、組織としてマルチプロダクト戦略に舵を切ったことを背景に新規プロダクトの立ち上げやプロダクト間の連携が加速しており、従来の料金体系や関連システムではこの展開に対応することが難しくなってきていることです。
2つ目は、プロダクトの増加により、契約時の社内オペレーションが肥大化・複雑化しており、運用負荷とヒューマンエラーのリスクが増大していることです。
── 課金基盤を作っていく上で感じる難しさを教えてください
まず各基盤チームすべてに言えることですが、重大なインシデントに繋がるリスクが高い機能を担っているため品質担保には特に注意を払う必要があります。
将来も見据えた拡張性の高い課金基盤を構築しつつ、プロダクト展開のボトルネックとならないようスピードも求められる点は、難しさであり、やりがいですね。
課金基盤ならではで言うと、システム構成の複雑さも難しさの一つです。 課金基盤の責務は機能制御や料金の計上を適切に行うことですが、これは単一のシステム内で完結するものではありません。 従業員数の情報はSmartHR自身が保持している一方、契約しているプランの情報は外部の決済サービスで管理しているなど、多数のシステムが関係しています。 これら複数のシステムにまたがる情報の整合性を担保しつつ、課金基盤自体を進化させていくことが求められます。
また、課金処理はSmartHR社内の業務フローにも影響するため、技術以外のフロー全体の課題にも目を向けなければいけません。
── おもしろさはどういったところにありますか？
技術面では前述の難しさがそのまま面白さでもあります。
また、事業レベルでの意思決定に携わることができるので、プロダクト全体をよりマクロな視点から捉える力を養えることは魅力の一つです。 全体を見通す必要があるため課題解決の難易度も高いですが、チャレンジングな課題に向き合うこと自体が楽しいですね。
チームの成果がプロダクト間のシナジーを生む土壌となり、会社全体の売上に直結するという点で、1つのプロダクトを育てることとはまた別の面白さがあります。
── 課金基盤の今後の展望を教えてください
まずは、先に挙げた課題に取り組み、ソリューションを考え形にしていくことで、ユーザーに対して適切な料金体系で柔軟かつ迅速に機能提供ができる課金基盤を構築することが急務です。
社内におけるオペレーションの負荷削減と、ユーザーに適切な料金かつ最短でプロダクトの価値を提供することの両輪により、SmartHRのコーポレートミッションである「well-working」の実現を図っていきます。
課題や今後の展望について、より具体的に聞いてみたいという方はぜひカジュアル面談にお越しください！ お待ちしております！！
従業員データ基盤チーム
最後は、従業員データ基盤チームでチーフを務めるmiyashitaさんです。
miyashita
2020年に入社後、SmartHR基本機能・配置シミュレーション機能の開発に関わり、2024年1月から従業員データ基盤チームに移りました。 チームでは開発とマネジメントを担当しています。
── 従業員データ基盤チームではどのような課題を解決しようとしていますか？
従業員データ基盤チームでは、SmartHRを利用することで蓄積する従業員データベース（氏名や所属部署のような各プロダクト共通で利用する情報）を扱います。
SmartHRは労務管理のプロダクトから始まり、その後タレントマネジメントのプロダクトを拡充してきました。 これからマルチプロダクト戦略を進めていく中で、従業員データベースはさらに重要になるものと考えています。
従業員データ基盤チームでは、今後プロダクトが拡充しても、従業員情報をスムーズに蓄積・活用していけることを目指しています。
── 従業員データベースは、なぜさらに重要になるのでしょうか？
従業員情報は、主に労務管理機能で蓄積したデータを各プロダクトからも参照する形で活用しています。 今後プロダクトを拡充していくと、プロダクトの特性によって新たに追加したい従業員情報が出てきます。 例えば、人員配置を行うプロダクトで従業員の「等級情報」を利用したい、といったケースがあります。
様々な要望が挙がる中で、従業員データベースの対応がプロダクト開発のボトルネックにならないことが求められるため、さらに重要になると考えています。
── チームが立ち上がったばかりとのことですが、まず何から取り組まれているんですか？
チームが立ち上がる前から、タレントマネジメントのプロダクトから従業員情報の追加要望が挙がっていました。 そのため、まずは優先度の高い要望から対応して、他プロダクトのボトルネックになっていた状態の解消に取り組んでいます。
また現在抱えている課題として、アプリケーションの構造上、新しい従業員情報を追加したい場合に時間がかかってしまうという問題があります。 そのため、中長期的には新しい従業員情報をスムーズに追加できるように、データ構造のリファクタを含めた改善にも取り組んでいきたいと考えています。
── 従業員データ基盤を作っていく上で感じる難しさを教えてください
影響範囲が広いところだと思います。
従業員データベースは、既存プロダクトだけでなく今後開発する新規プロダクトも共通で利用します。 そのため、プロダクトの数だけ関係者がいることや、各プロダクトの要望を整理し優先度を付けて対応していく必要があります。
優先度付けを誤ってしまうと関係するプロダクトの開発に影響が出てしまうため、バランスを取りながら進めることが求められます。
── おもしろさはどういったところにありますか？
難しさで挙げた点と共通しますが、労務・タレントマネジメント・今後立ち上がる事業など全方位に目を向けた上で、汎用的に従業員情報を扱えるようにするために広い視点が求められることです。
また、従業員情報の追加は影響範囲が広い分、一つ一つの意思決定の影響が大きいことや、課題に挙げたようなアーキテクチャの改善にも目を向ける必要がある点もおもしろいところだと思います。
プロダクト横断基盤をつくるエンジニアを募集しています
事業・プロダクトともに大規模でありながら急成長を続ける、そんなスケールアップ企業であるSmartHRだからこその面白い経験ができると思っています。 紹介したプロダクト横断基盤をより進化させていくため、エンジニアを募集しています。 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
