「磨き上げる」ことから始まる基盤開発 —— マルチプロダクト戦略を支える従業員データ基盤

はじめまして。今年の 1 月に SmartHR にプロダクトエンジニアとして入社した murakami です。

SmartHR では、プロダクト基盤開発本部の EDP（Employee Data Platform）ユニットに所属しています。「Employee Data Platform」という名の通り、プロダクト横断での従業員データ活用を支える「従業員データ基盤」を運用しているチームです。
入社して早 4 ヶ月。入社前の思惑通り、基盤を運用する上での難しさに向き合えていて、日々脳に汗をかいております。

入社してから実際に関わりはじめた従業員データ基盤は、すでにいくつものプロダクトで活用されていて「存在感のある基盤」という印象でした。従業員データ基盤のフェーズを「0 → 1」「1 → 10」「10 → 100」という表現に当てはめるのであれば、「10 → 100」に位置していて、"生み出し、育ててきたものを、より磨き上げていく" フェーズであると感じています。

今回の記事では、一定の成長を遂げている基盤をこれからどのように磨き上げていくのか、現在の状況を踏まえながら紹介します。

プロダクト基盤開発本部と EDP ユニット

まずは、私が所属するプロダクト基盤開発本部と EDP ユニットの紹介をします。

プロダクト基盤開発本部は、様々なプロダクトで必要になる共通機能を一貫して提供し、マルチプロダクト戦略を掲げる SmartHR において、プロダクト開発の生産性を高めてレバレッジを効かせる役割を担っています。
その役割の重要性を理解するには、共通基盤がない世界を想像してみるとわかりやすいです。

共通基盤がない世界線では、認証・認可、権限管理、プロダクト間のデータ連携といった共通課題に、プロダクトが各々対応していく状況になります。もちろん、開発が終わったらそれで終了ということはなく、パフォーマンス問題や機能拡張による複雑性の向上、運用負荷の増大などプロダクトの成長に応じて発生する問題にも抗い続ける運命も背負います。また、各プロダクトの体験や品質にバラツキが発生することも避けたいので、プロダクト間で入念にコミュニケーションをとる場も設けられるでしょう。
このような共通課題にコストを払い続けると、プロダクトが提供したい価値のデリバリーが鈍化することは想像に難くないと思います。

プロダクト基盤は、これらの課題を専門チームが一貫して担うことで、各プロダクトチームが価値創出に集中できる環境をつくります。
専門チームが一手に担うからこそ、高い品質を維持しつつ一貫した体験も提供できるようになりますし、プロダクト基盤を利用するプロダクトが増えれば増えるほど組織全体へのインパクトも大きくなります。まさにレバレッジが効く領域ですね。

EDP ユニットは、そんなプロダクト基盤において「従業員データ」の横断活用を担うチームです。
「従業員データ」とは、SmartHR の各プロダクトが管理している従業員に関するデータのことを指します。あるプロダクトは従業員の基本情報を、別のプロダクトは人事評価データを、さらに別のプロダクトはスキルや資格情報を、といった具合に役割やドメインに応じた従業員データをそれぞれ保持しています。
EDP は、このような各プロダクトが持っている従業員データを他のプロダクトでも活用できるようにする「従業員データ基盤」を提供しています。
基盤自体に各プロダクトのデータコピーを持つわけではなく、データの所在はあくまで各プロダクトにあり、基盤はそれらを横断的に参照できる仕組みを提供する、という構造になっています。

従業員データ基盤を支える技術

EDP が提供する従業員データ基盤を支える技術的な柱は大きく 2 つあります。

ひとつが、GraphQL Federation を活用した従業員データの提供。
GraphQL Federation は、複数のプロダクトが持つ GraphQL スキーマを統合して、あたかも 1 つのスキーマであるかのように振る舞う仕組みです。これによって、各プロダクトが持つ従業員データは 1 つの GraphQL エンドポイントから取得できるようになり、基盤を利用するプロダクトは「どのプロダクトに何のデータがあるか」を意識する必要がなく、1 つのクエリで複数のプロダクトからまとめてデータを取得できます。

---
title: GraphQL Federation による横断的な従業員データ取得
---
 graph TB
    Client["利用プロダクト"]
    subgraph EDP["従業員データ基盤（EDP）"]
        Gateway["GraphQL Federation"]
    end

    subgraph Products["データ提供プロダクト"]
        A["プロダクト A<br/>（基本情報）"]
        B["プロダクト B<br/>（人事評価）"]
        C["プロダクト C<br/>（スキル・資格）"]
    end

    Client -- "1 つのクエリで\nまとめて取得" --> Gateway
    Gateway -- "GraphQL" --> A
    Gateway -- "GraphQL" --> B
    Gateway -- "GraphQL" --> C

もうひとつが分散 SQL クエリエンジン Trino を活用した横断検索基盤です。
GraphQL Federation では「プロダクト A が保持している部署データとプロダクト B が保持している従業員のスキルデータを使って、営業部に所属していて SQL やデータ分析のスキルも持つ従業員を検索する」といったような、複数プロダクトが保持するデータを複合的に検索する用途には不向きです。
代わりに、その領域を担うのが Trino を活用した横断検索基盤になります。Trino は複数のデータベースを参照した検索クエリを、単一の SQL で実行することができます。これによりプロダクトをまたいだ柔軟な検索を実現しています。

これらを組み合わせて提供することで、プロダクト横断での従業員データ活用を支える基盤を実現しています。

内側から見た従業員データ基盤の印象

冒頭でも述べましたが、入社してからの従業員データ基盤は「存在感のある基盤」という印象でした。「0 → 1」「1 → 10」「10 → 100」のフェーズであれば、「10 → 100」に位置しています。
そのような印象を私に抱かせた背景にある事実をいくつか挙げてみます。

8 つのプロダクトが従業員データ基盤からデータを取得している
10 のプロダクトが従業員データ基盤を通じてデータを提供している
従業員データ基盤に関する社内 Slack チャンネルの人数が 170 人を超えている
プロダクトの関係者を集めた共有会が隔週で予定されている
データを提供する側と利用する側で GraphQL のスキーマ調整を進めるなどのセルフサービス的な動きも見られる
利用者からのフィードバックを受け、クライアントライブラリの開発が進められてプロダクトへの導入実績もある

社内の認知も獲得し、利用者含めた基盤を取り巻く体制も形成されていて、プロダクト横断で従業員データを活用するときの「標準的な手段」として確立していると感じました。
この基盤をゼロから生み出し、ここまで育て上げてきた人たちには、本当に大きなリスペクトがあります。

従業員データ基盤をさらに磨き上げていくために

「今の従業員データ基盤をさらに磨き上げていくために、何をどのように取り組んでいくべきだろうか」という問いに対して、入社してからよく想いを巡らせていました。

私が入社した頃には、基盤に対するプロダクト側からの要望は減少傾向にあるとのことで、実際、要望ベースの改修依頼はあまりなかったように思います。
これはプロダクトが使う基盤として一定の成熟と安定運用が実現できている一方で、自ら新しい価値を提案していくことがこれまで以上に求められてきている、ということでしょう。

基盤は使われてこそ価値が生まれる

では、具体的にどのように価値を提供していくべきでしょうか。

基盤は使われてこそ価値が生まれるものなので、「より多くのプロダクトに様々なシーンで活用してもらうために何をすべきか」を起点に考えます。

それにあたり、扱う従業員データの拡充を進める方向性は間違いではないと考えています。従業員データの拡充とは、取得できるデータ項目や検索できる項目を増やし、新しいユースケースを実現可能にすることを指しています。新しいユースケースが実現可能になることでこれまで基盤を利用していなかったプロダクトにも広く訴求できるようになります。
ただし、全プロダクトが持つすべての従業員データを提供し切ることが理想形かというと、そうではないです。
あまり使われないデータを提供しても意味は薄いですし、データを提供するプロダクトの保守コストも増えていきます。一度提供してしまうと後から剥がすのにもコストがかかります。利用者のニーズを置き去りにしたまま拡充させていった先には何も良いことはありません。
そのため、先に利用者の様々なニーズを集め、それらのニーズに応えていく過程で従業員データの項目や検索対象が増えていく。そのような構造にデザインしていくのが肝になるでしょう。

Platform Engineering Maturity Model を踏まえると何ができるか

また、基盤利用者を増やすにあたり、獲得すべきケイパビリティのヒントを得るため、CNCF（Cloud Native Computing Foundation）が公開している Platform Engineering Maturity Model にも照らしてみます。
このモデルは 5 つの評価軸と 4 つのレベルで構成されていて、プラットフォームエンジニアリングの成熟度を多角的に評価し、何を改善すべきかを整理するためのフレームワークです。

このモデルの評価軸のうち、Adoption（採用）に特に注目しました。Adoption は、プラットフォームの発見や使われ方、使う動機について言及しています。この評価軸のレベルを簡単に説明すると次のようになるかと思います。

Level 1. Provisional（暫定的）
- 利用は散発的で、噂や偶然の会話を通じてプラットフォームが発見される
Level 2. Operationalized（組織的）
- 組織的なルールやインセンティブなど、外発的な動機づけで利用が推進される
Level 3. Scalable（拡張可能）
- 利用者が価値を実感し、自発的に採用する。利用が自律的に持続する
Level 4. Optimizing（最適化）
- 利用者が単なるコンシューマーを超えて、プラットフォーム自体の改善にも貢献する

Level 2 と Level 3 の間に、こちらからの働きかけで利用を促す段階から、自発的に利用する段階への転換点があります。私の所感では、従業員データ基盤はちょうどこの転換点のあたりに位置しています。
すでに多くのプロダクトで利用されていて、セルフサービス的な動きも見られる一方で、「基盤の価値を実感した利用者が、自発的に新たなユースケースを見つけて使い始める」という点ではまだ伸びしろがあると感じます。

「これを使うと自分たちのプロダクトがもっとよくなる」と利用者自身が感じて、自ら手を伸ばしてくれる状態。そこに持っていくための土台づくりも、基盤を磨き上げていくための重要テーマになりそうです。

基盤の磨き上げに必要なアクション

ここまでの話から、基盤の磨き上げには次のようなアクションが必要だと考えました。

利用者のニーズを収集し、それに応えていく形で扱うデータの種類や検索の幅を広げていく
基盤を自発的に利用してもらうための土台をつくっていく

利用者が増えることでフィードバックが今まで以上に集まり、求められた機能やデータを提供することで、さらに利用者が増える。この好循環を絶えず回し続けることが真なる「磨き上げ」につながるのではないでしょうか。

一筋縄ではいかない従業員データの拡充

前述した通り、基盤が扱う従業員データを拡充することが重要な施策の一つになると考えましたが、それは思っていたよりも難しそうでした。
チームメンバーにこれまでの話を聞く中で見えてきたハードルをいくつか紹介します。

GraphQL スキーマとの相性

プロダクトが保持する従業員データは、GraphQL のスキーマに落とし込みやすいとは限りません。
プロダクトによっては、お客様ごとに任意の項目を追加できるカスタムフィールドなど、GraphQL スキーマとして表現するのが難しいデータを持っていることがあります。
そのようなデータを無理にスキーマに押し込むと歪みが生じ、破滅をもたらしかねないので、構造の見直しから協議していく必要があります。

データ提供プロダクトとの協調

新たなデータを従業員データ基盤で提供するには、そのデータを持つプロダクトチームの協力が不可欠です。
私たちのチームでデータ提供のための実装を行ったとしても、レビューや仕様のすり合わせは必要ですし、提供後の運用コストもプロダクトチームにのっかっていきます。
通常業務を一時的に止めてでも取り組むだけのリターンを示すのはもちろん、プロダクトチームにはプロダクトチームの優先すべき業務があるため、データ拡充のための諸々の調整を進めていく必要もあります。

横断検索基盤のインフラ

Trino による横断検索では、各プロダクトのデータベースに直接アクセスします。
プロダクトへの影響を可能な限り小さくするために Trino はリードレプリカに接続しますが、そもそもレプリカが存在しない場合は新たに構築し、接続するための設定を新たに追加する必要があります。
インフラ設定は私たちのチームでやるとしても、レプリカを新たに構築するのはコストもかかるので、検索基盤への追加が難しいケースもあります。

上記のようないくつかのハードルがある以上、要求を受けてから対応を始めるとリードタイムが長くなることがあります。かといって、未来に使うかも知れないデータ拡充を先んじて準備しておくのはコストに見合わない可能性があります。
結局のところ、利用者のニーズを先んじて収集すること、ニーズから裏打ちされた確度の高いデータ拡充を進めていくことが、どのみち必要になってくるというわけです。

現状の取り組み

ここまで、基盤をさらに磨き上げていくために何をしていくべきかについて述べてきました。最後に、それらを踏まえて現在どのような取り組みを進めているのかを紹介します。

「基盤を自発的に利用してもらうための土台づくり」という観点で、従業員データ基盤で何ができるかをお手軽に体験してもらうために AI エージェントからの基盤利用を進めています。
やることとしては、自然言語での問い合わせに対して精度の高い検索結果を返すためのワークフロー構築や、検索品質を高めるためのフィールドメタデータの整備、認証認可周りの対応あたりになります。これを実現することで、自然言語による従業員検索やデータ取得ができるようになるので、提供しているスキーマを細かく確認する必要はなく、従業員データを活用したユースケースのイメージを利用者に持ってもらいやすくなると考えています。

そして、この AI エージェントでの取り組みは、基盤ニーズ収集としても機能させたいと考えています。社内で従業員データを扱った業務をする人たちに実務でお試ししてもらい、そこで得られたフィードバックを、従業員データ項目や横断検索対象の拡充につなげていく。ここまで何度か言及している「利用者のニーズに裏打ちされたデータ拡充」を実践するための具体的な仕掛けです。