近年のSaaS業界では、マルチプロダクト戦略をとる企業が一層増えています。複数のプロダクトを展開することは大きなシナジーを生む一方で、プロダクト間のデータ連携は難易度の高い課題でもあります。
SmartHRにおいても、労務管理からタレントマネジメントへと領域を広げ成長を続ける中で、拡張性に耐えうるプロダクト間連携の仕組みをその都度構築し、磨き込んできました。給与計算、勤怠管理、年末調整など、それぞれ独立したプロダクトが連携し合うことで、単体では実現できない業務体験を提供することを目指しています。
そして、私が所属しているプロダクト基盤開発部の外部サービス連携基盤ユニットでは、こうしたマルチプロダクト戦略を技術面から支えるための共通基盤の開発を進めています。本記事の筆者である @ydah は、このプロジェクトにおいてFY2026上期にフィーチャーリードとして、KR1の達成に向けたアクションを牽引しています。
本記事では、マルチプロダクト戦略を技術面から支える「外部サービス連携基盤」について、その役割と設計思想、そして開発を通じて私たちがこれからどのような未来を描いているのかを紹介します。
マルチプロダクト戦略の核となる「連携」の必然性
人事労務の業務は、単独では完結しません。給与計算、勤怠管理、年末調整といった各業務は、それぞれが複雑に絡み合い、連鎖しています。
分かりやすい例が「給与計算」です。正確な給与を算出するためには、労働時間、残業時間、有給取得日数などの「勤怠情報」が不可欠です。つまり、給与計算と勤怠管理は実務上、切り離すことができない関係にあります。
この相互依存性は、人事労務のあらゆる領域に見られます。年末調整には従業員の基本情報が、社会保険手続きには給与データが、そしてタレントマネジメントには評価データが必要です。 これら複数のプロダクトがデータや機能を相互補完し、つながることで生まれる価値。単一の機能だけでは実現できない、シームレスな業務体験を提供する。これこそがマルチプロダクト戦略の真価です。 しかし、異なるデータ構造を持つプロダクト同士、あるいは外部のサービスとの「滑らかな連携」を技術的に実現することは容易ではありません。そのため、プロダクト間連携を支える共通基盤の必要性が高まっています。
プロダクトが増えるほど、「つながる」は難しくなる
マルチプロダクト初期において、連携機能の実装は「Point-to-Point（1対1）」のアプローチから始まるのが一般的です。給与計算システムが勤怠システムからAPIでデータを取得する、年末調整システムが従業員DBを参照する……。このように、必要に迫られたタイミングで、必要なパイプラインを個別に構築する方法です。
この方法はプロダクト数が少ないうちは最速の解ですが、事業がスケールし、プロダクト群が増えるにつれて、開発組織は3つの「見えない壁」に衝突することになります。
まず挙げられるのは、ボイラープレートの増大です。認証・認可、リトライ処理、エラーハンドリングなど、連携における「非機能要件」はどのプロダクトでも類似します。これらを各チームが個別に実装することは、車輪の再発明であるだけでなく、バグ修正や仕様変更のたびに全プロダクトへ横断的な改修を強いることになります。
もっとも深刻なのは組み合わせ爆発による拡張性の欠如です。プロダクト数が N になると、理論上の連携数は最大で N × (N-1) となります。
たとえばプロダクトが10個になれば、最大90通りの連携パスが発生します。この「メッシュ状の複雑な依存関係」を個別にメンテナンスし続けることは、運用コストの観点から見て事実上不可能です。
さらに、私たちが向き合うのは自社プロダクトだけではありません。顧客が利用する「他社SaaS」との連携もまた、避けて通れない課題です。外部サービスは、認証方式（OAuth 2.0、APIキー、Basic認証等）も、データ形式も千差万別です。「労働時間」 vs 「勤務時間」、「分単位」 vs 「時間単位」……。こうしたドメインごとの言葉や仕様の揺らぎ（インピーダンスミスマッチ）を、個々のプロダクト側で吸収しようとすれば、ビジネスロジックが「翻訳作業」で汚染されてしまいます。
解決策としての「外部サービス連携基盤」
これらの課題を一挙に解決するために構築したのが、共通の「外部サービス連携基盤」です。
各プロダクトが個別に連携機能を実装するのではなく、すべてのデータ連携をこの基盤に集約させるアーキテクチャへと舵を切りました。
flowchart TB
subgraph after["After: ハブ＆スポーク型 (基盤利用)"]
direction TB
Hub((連携基盤))
Q1[給与計算] <--> Hub
Q2[勤怠管理] <--> Hub
Q3[年末調整] <--> Hub
Q4[人事評価] <--> Hub
end
subgraph before["Before: メッシュ型 (個別実装)"]
direction LR
P1[給与計算] <--> P2[勤怠管理]
P1 <--> P3[年末調整]
P2 <--> P3
P1 <--> P4[人事評価]
P2 <--> P4
P3 <--> P4
end
classDef product fill:#e6fafa,stroke:#00c4cc,stroke-width:2px,color:#23221f
classDef hub fill:#00c4cc,stroke:#23221f,stroke-width:3px,color:#23221f
classDef meshProduct fill:#fff5e6,stroke:#ff9900,stroke-width:2px,color:#23221f
class P1,P2,P3,P4 meshProduct
class Q1,Q2,Q3,Q4 product
class Hub hub
style before fill:#fffaf0,stroke:#ff9900,stroke-width:2px,color:#23221f
style after fill:#f0ffff,stroke:#00c4cc,stroke-width:2px,color:#23221f
この「ハブ＆スポーク型」への移行は、開発効率と品質に劇的な変化をもたらしました。
各プロダクトが個別に繋がり合う「メッシュ型」では N × (N-1) の接続が必要でしたが、基盤を中心とした「ハブ＆スポーク型」に移行することで、接続数は N 通りにまで劇的に削減されます。各プロダクトはハブとのインターフェイスのみを意識すればよく、責務の分離が明確になります。また、連携先の仕様変更に振り回されることがなくなります。
また、基盤化のメリットは接続数だけではありません。セキュリティリスクの極小化も重要なテーマです。外部連携には認証情報（クレデンシャル）の管理が必須ですが、これらが各プロダクトに散在すると、セキュリティレベルの統一が困難になります。「プロダクトAは安全に暗号化されているが、プロダクトBは脆弱」といったリスクを排除し、連携基盤側でクレデンシャルを一元管理することで、強固なガバナンスを効かせることが可能になります。
加えて、開発工数の大幅な圧縮も可能です。OAuth認証フローの実装など、工数の大半を占める「定型処理」を基盤が肩代わりすることで、各プロダクトチームは本来の価値提供に集中できるようになります。さらに、連携設定のUIも基盤から提供すれば、SmartHRの利用者に対しても「SmartHR全体で統一された操作感」を提供することが可能になります。
外部サービス連携基盤の主な機能
基盤が提供する具体的な機能とアーキテクチャについて、掘り下げていきましょう。基盤は大きく分けて「データハンドリング」と「UIコンポーネント」という側面から、プロダクト間および外部サービスとの連携を支えています。
データハンドリング：柔軟なフィールドマッピングとデータ変換
異なるサービス間でデータを連携する際、最大の障壁となるのがデータ構造の違いです。基盤はこの問題を「Mapping」と「Connector」という2段階のレイヤーで解決しています。
あるサービスでは「労働時間」と呼ばれる項目が、別のサービスでは「勤務時間」と呼ばれる。こうした項目名の差異を吸収するのが「Mapping」のレイヤーです。SmartHRの利用者はGUI上で直感的に項目同士を紐づけることができます。 そして単純な項目名の紐付けだけでは解決できない「単位」や「形式」の違い（例：分単位 vs 時間単位）については、サービス固有のアダプター層である「Connector」レイヤーが吸収します。
flowchart LR
subgraph Source[連携元サービス]
D1[データ: 90分]
D2[項目名: 労働時間]
end
subgraph Platform[連携基盤]
direction TB
C[Connector] -- "単位変換 (/60)" --> N[正規化データ: 1.5h]
N -- "項目名変換" --> M[Mapping]
end
subgraph Dest[連携先プロダクト]
T1[データ: 1.5h]
T2[項目名: work_hours]
end
Source --> C
M --> Dest
classDef connector fill:#e6fafa,stroke:#00c4cc,stroke-width:2px,color:#23221f
classDef mapping fill:#e6fafa,stroke:#00c4cc,stroke-width:2px,color:#23221f
classDef data fill:#f5f5f5,stroke:#9d8ef8,stroke-width:2px,color:#23221f
classDef normalized fill:#eee5fd,stroke:#6e4ca6,stroke-width:2px,color:#23221f
class C connector
class M mapping
class N normalized
class D1,D2,T1,T2 data
style Source fill:#fff5e6,stroke:#ff9900,stroke-width:2px,color:#23221f
style Platform fill:#f0ffff,stroke:#00c4cc,stroke-width:2px,color:#23221f
style Dest fill:#f0ffff,stroke:#00c4cc,stroke-width:2px,color:#23221f
このように、変換ロジックを「Connector」に、紐付けの設定を「Mapping」のレイヤーに分離することで、柔軟性と保守性を両立させています。
UIコンポーネント：埋め込み可能な設定画面の提供
連携設定画面の実装コストを下げるため、基盤は各プロダクトに対して iframe で埋め込み可能なUIコンポーネントを提供しています。 これにより、各プロダクトチームは複雑なマッピングUIを一から実装する必要がありません。また、基盤側でUIを改善・アップデートすれば、すべてのプロダクトに即座に反映されるというメリットもあります。
そして、この埋め込みUIは単なる静的なiframeではなく、親画面と双方向に通信可能となっています。 親画面（プロダクト）と子画面（基盤が提供しているiframe）の通信には、ブラウザ標準の postMessage API2 を採用しています。
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e6fafa', 'primaryTextColor': '#23221f', 'primaryBorderColor': '#00c4cc', 'lineColor': '#00c4cc', 'secondaryColor': '#eee5fd', 'tertiaryColor': '#fff', 'actorBkg': '#e6fafa', 'actorTextColor': '#23221f', 'actorBorder': '#00c4cc', 'signalColor': '#23221f', 'signalTextColor': '#23221f', 'noteBkgColor': '#eee5fd', 'noteTextColor': '#23221f', 'noteBorderColor': '#8c5eee'}}}%%
sequenceDiagram
participant P as Product (親画面)
participant I as Platform UI (iframe)
P->>I: 初期化 (Token, Context)
I-->>P: ロード完了通知
Note over P, I: SmartHRの利用者がマッピング設定を変更
I->>P: 保存アクション (postMessage)
P->>P: トースト通知表示 / モーダル制御
ダイアログの開閉制御、通知の表示、画面遷移といったインタラクションは、メッセージングを通じてシームレスに連携され、SmartHRの利用者はiframeであることを意識せずに操作できます。
外部サービス連携基盤の設計思想
この連携基盤は、SmartHRの利用者が直接触れるプロダクトではなく、あくまで各プロダクトを裏側で支える「ミドルウェア」として設計されています。 この連携基盤を利用するプロダクトの開発者が向き合うのは給与計算や勤怠管理といった個別のプロダクトであり、基盤はその裏側で、黒衣のように連携処理を遂行します。 各プロダクトチームが本来のドメインや価値提供に集中できるよう、連携に伴う技術的な複雑さを基盤側に隠蔽すること。それがこの基盤の役割です。
共通基盤を作るうえでもっとも陥りやすい罠が、各プロダクトのドメインロジックを基盤側に取り込みすぎてしまうことです。 「Aプロダクトではこの例外処理が必要」「Bプロダクトではこの計算式が必要」といった個別の事情を基盤が引き受け始めると、システムは瞬く間に密な結合状態に陥ります。
そうなると、あるプロダクトの些細な変更が基盤を通じて他のプロダクトを壊す、という悪夢のような連鎖が生まれます。 だからこそ私たちは、「プロダクトは『何を』連携するかを決め、基盤は『どう』連携するかに責任を持つ」という境界線を引いています。 ビジネスロジックはプロダクト側に残し、基盤は純粋なデータ転送と変換のメカニズムに徹する。この規律を守ることが、基盤の健全性を保つ鍵だと考えています。
また、抽象化と具体化のバランスについても、私たちは現実的なアプローチをとっています。 最初から「あらゆる連携に対応できる完璧な汎用基盤」を作ろうとすると、実際のニーズから乖離した過剰設計になりがちです。
まずは目の前にある具体的な連携要件を確実に満たす実装から始め、2つ目、3つ目の連携事例が出てきた段階ではじめて共通項を見出し、抽象化していくようにしています。 未来の可能性よりも現在の実用性を優先し、運用実績の中からパターンを見出して育てていきます。この反復プロセスが、結果として最も拡張性の高い基盤を生み出す近道だと考えています。
現在地と今後の展開
2025年から数名のチームで本格始動した本プロジェクトですが、現在はファーストユーザーとなる連携機能のリリースに向け、最終調整のフェーズに入っています。 記念すべき最初のユースケースには、SmartHRのプロダクト間のデータ連携を選定しました。まずは第一歩としてSmartHR内のプロダクトで実績を作り、基盤としての足場を固める狙いです。
2026年は、この基盤の真価を社内に証明し、開発本部全体のプロセス変革へと繋げる「実証の年」と位置づけています。 単にプロダクト間の連携が動くだけでなく、基盤があることでどれほど開発が楽になるか、どれほどセキュアになるかという「描ける未来」を、実績をもって示していかなければなりません。
その先には、アライアンスパートナーとの連携をこの基盤で巻き取り、ビジネスの展開速度を加速させる未来が待っています。 また、OAuth 2.0やAPIキー、Basic認証といった多様な認証方式や、さまざまな外部サービスの認証先に対応した汎用的なクレデンシャル管理機能への拡張や、各プロダクトチームがより手軽に基盤を利用できるSDKの開発など、開発者体験を向上させるロードマップも描いています。
まだまだ始まったばかりのプロジェクトですが、マルチプロダクト戦略を技術面から支える基盤として、SmartHRの未来を形作る重要なピースになると確信しています。
おわりに
本記事では、私たちが取り組んでいるマルチプロダクト戦略の要となる「外部サービス連携基盤」について、その技術的背景と設計思想をご紹介しました。
事業が成長しプロダクトが増えれば、連携のニーズは必然的に高まります。 しかし、そこで場当たり的な個別実装を繰り返していては、重複コードやセキュリティリスク、そしてメンテナンスコストの増大という負債を抱え込むことになります。
私たちが構築している基盤は、そうした「連携の痛み」を解消し、SmartHRが次のフェーズへ進むための土台の提供を目指しています。 この記事を通じてマルチプロダクト戦略を技術面から支える外部サービス連携基盤の開発に関心を持っていただけたなら、ぜひ一緒に基盤を開発しませんか？
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ この記事を読んでいるあなたからのご連絡をお待ちしています。
