目次を表示する

Platform Engineering 実践地図 ── 各社はどんな課題に、どう答えたか

第5話 ドメイン共通基盤からの逆走 ── 日本のSaaSの独自進化

場面

「Platform Engineering」を名乗る前から、すでにそれを始めていた会社がある。

第4話で見た Uber・adidas・Zalando は、いずれも「IDP（Internal Developer Platform）」を起点に語られる。Backstage を採用したか、内製したか、CNCF エコシステムで組み立てたか──軸は「開発者基盤レイヤをどう作るか」にあった。海外の Platform Engineering 言説は、おおむねこの軸の上で回っている。

だが、日本の SaaS の事例を一次情報ベースで横断すると、まったく違う進化が見えてくる。SmartHR、Money Forward、Sansan、freee──これらの会社が公開している記事は、Backstage や内製 IDP の話ではない。**「権限基盤」「事業者基盤」「認証基盤」「従業員データ基盤」**といった、ドメインの共通基盤の話が中心にある。

そして、これらは「プラットフォーム」と呼ばれていなかった。少なくとも 2024年以前は。

この章では、日本の SaaS が辿った二段階の進化──ドメイン共通基盤が先、開発者基盤が後──を、3社の事例から解剖する。なぜ日本でこのパターンになったのか、海外との対比でこそ見えてくる構造がある。

状況：海外と日本、Platform Engineering の起点が違う

3社の起点を並べる。

観点SmartHRMoney ForwardSansan
主要事業人事労務SaaS、40+プロダクト個人/法人金融SaaS群名刺管理、Bill One、Contract One他
共通基盤の起点プロダクト基盤チーム（2023〜）事業者基盤（2020年誕生）認証基盤の内製化（2024〜）
共通基盤の中身権限・課金・従業員データ・プロダクト連携認証・認可・テナント管理Auth0→内製認証、Orbit（GKE基盤）
Backstage 採用公開情報では未確認公開情報では未確認内製 Orbit
「Platform Engineering」呼称2024年以降に明示化「Platform and Reliability Engineering 部門」2024年に「Platform Engineering Unit」

ここで読み取りたいのは、3社とも、Platform Engineering を名乗るより先に、ドメインの共通基盤を立ち上げているという事実だ。

  • SmartHR の「権限基盤チーム」「課金基盤チーム」は、Backstage を入れる議論から始まったわけではない。マルチプロダクト戦略を実行するために、事業ロジックの共通化が先に必要だった。
  • Money Forward の「事業者基盤」は、創業初期から存在した単一メイン DB を「とんでもない単一障害点」と公式表現するほどの危機感から2020年に生まれた (マネーフォワードクラウドを支える事業者基盤 - Speaker Deck)。
  • Sansan の「認証基盤の内製化」も、Auth0 のコスト・拡張性の限界が起点であり、Bill One→Contract One→Sansan Data Intelligence の順で展開されている。

これは「Backstage を入れたい」という発想とは、まったく違う動機から始まっている。事業上の必然から共通基盤が生まれ、それが結果的に Platform Engineering 的な活動に化けていく。

選択：3社が辿った二段階進化

SmartHR：マルチプロダクト戦略の中で生まれた「プロダクト基盤」

SmartHR は2023年にプロダクト基盤チームを立ち上げ、2024年3月時点で4つのサブチームに分かれた (SmartHR Tech Blog, 2024-03)。

graph TD
    PB[プロダクト基盤チーム<br/>2023〜] --> KB[権限基盤チーム]
    PB --> PR[プロダクト連携チーム]
    PB --> CB[課金基盤チーム]
    PB --> ED[従業員データ基盤チーム]

    KB -.->|横断| App1[労務管理]
    PR -.->|横断| App2[タレント管理]
    CB -.->|横断| App3[ID管理]
    ED -.->|横断| App4[従業員ポータル]

各サブチームは「プロダクトエンジニア2名 + QA 1名（兼務）+ PM 1名」の小規模構成。注目したいのは、**テクニカルプロダクトマネージャー（TPM）**という役割が新設されている点だ (SmartHR Tech Blog, 2025-02)。

TPM は「内部の開発者を顧客とみなす」役割を担う。これは第8話で扱う Platform-as-a-Product の思想そのものだが、SmartHR ではその思想を**「IDP」ではなく「ドメインの共通基盤」に適用している**点が独自だ。海外の Platform-as-a-Product が「Backstage を社内顧客に売る」議論をしているとき、SmartHR は「権限・課金・従業員データを社内顧客に売る」議論をしている。

そして、3フェーズアプローチ：

  1. 小規模検証：導入プロダクトを絞る
  2. スケール準備：共通ライブラリ整備、社内開発者コミュニティ構築
  3. 標準化：新規プロダクト開発に組み込み

これは、過去にマルチプロダクト戦略を一気に展開しようとして失敗した経験から来ている。「大きく作りがち」になり、リリース時に状況が変わったり価値検証不足になる、という組織課題を、小さく検証してから広げるプロダクト開発の作法で解こうとしている (SmartHR Tech Blog, 2024-02)。

Money Forward：「とんでもない単一障害点」から始まった事業者基盤

Money Forward の「事業者基盤」は、3社のなかで最も早く（2020年）生まれた共通基盤だ。

公式登壇（Speaker Deck）が率直に語っているのは、**創業初期からの単一メイン DB が「とんでもない単一障害点」**だったという事実だ。個人向け家計簿から法人 SaaS（マネーフォワードクラウド）まで全プロダクトが、ひとつの DB に紐付いていた。これが事業継続のリスクと、マルチプロダクト・マルチ法人化への壁を同時に作っていた。

事業者基盤は、その壁を破るために生まれた。

  • 専用 DB を持つ認証・認可システム
  • ユーザー ID と企業テナントを紐付ける
  • SAML SSO、パスワードポリシー強制などエンタープライズ要件に対応

そして注目したいのが、Money Forward の組織構造だ。

graph LR
    PRE[Platform and Reliability<br/>Engineering 部門] --> SRE[グループ全体の<br/>SRE 支援]

    CS[Common Services 部門] --> BB[Business Base]
    CS --> CB[Contract Base]
    CS --> FB[File Base]

    GIT[Global IT 部門] --> GLOBAL[国際子会社含む<br/>全社IT戦略]

    BB -.認証・認可.-> All[マネーフォワードクラウド全体]
    CB -.契約管理.-> All
    FB -.ファイル管理.-> All

「Common Services」という呼称に注目したい。これは Platform でもなく、IDP でもなく、**「共通サービス」**だ。Business Base / Contract Base / File Base という命名も、開発者基盤というよりドメインのモジュール名に近い。

Money Forward は SRE 部門（Platform and Reliability Engineering）を別に持っているが、Common Services はそれとは別の系譜にある。「事業ドメインの共通化」と「信頼性・基盤運用」が別チームで並走しているのが、海外との大きな違いだ。海外なら、これらをまとめて「Platform Engineering」と呼ぶ会社が多いだろう。

Sansan：Platform Engineering Unit と Embedded SRE の二層構造

Sansan は、3社のなかで最も明示的に「Platform Engineering」を名乗っている (Speaker Deck, 2025-12)。それでも、起点は「ドメイン共通基盤」にあった。

公式登壇によれば、出発点は**「5つの新規事業を1人のインフラエンジニアが見る」**という状況だった。これは第6話で扱う「走り始めスタートアップの最小構成」とまったく同じ症状で、Sansan のような中規模 SaaS でも一度は通った道だ。

Sansan の組織解は二層構造で、これは日本の SaaS で繰り返し現れるパターンの代表例だ。

graph TD
    PE[Platform Engineering Unit<br/>横断的・全社最適] --> Orbit[Orbit<br/>GKE基盤・CI/CD<br/>Terraformモジュール]
    PE --> HEART[HEARTフレームワーク<br/>開発者体験計測]

    ESRE[Embedded SRE<br/>各プロダクト常駐] --> Bill[Bill One SRE]
    ESRE --> CO[Contract One SRE]
    ESRE --> SDI[Sansan Data<br/>Intelligence]

    Orbit -.セルフサービス基盤.-> ESRE
    ESRE -.教える文化.-> Devs[各プロダクトの開発者]

**Platform Engineering Unit が「全社最適化する側」、Embedded SRE が「教える側」**として明確に分離されている。SRE が代行するのではなく、開発者の自律を促す──これは SmartHR の「内部顧客を持つ」思想と通底する。

そして、Sansan の事例で特に興味深いのが認証基盤の内製化だ。Auth0 で運用していたが、コスト・拡張性の限界に直面し、Bill One → Contract One → Sansan Data Intelligence の順に内製プラットフォームへ移行した (Speaker Deck, 2024-07; Sansan Tech, 2026-02)。

ここで思い出したいのが、第4話の Uber Up だ。Uber は「商用 PaaS が要件を満たさない」から内製した。Sansan は「Auth0 のコスト・拡張性が限界」だから内製した。規模も業種も違うが、内製の動機は同じパターンを持っている。違いは、Sansan が認証という単一のドメインに絞って内製したことだ。Uber がフル内製の総合プラットフォームを作ったのに対し、Sansan は「ドメインごとの内製化」を選んだ。

そして Sansan が掲げる思想が “Platform as social product”。単なるツール束ねではなく、社内向けプロダクトとして扱う。RICE スコアと開発者フィードバックで改善優先度を決定する。TVP（Thinnest Viable Platform）から段階的に拡張する──このすべてが、第8話で扱う Platform-as-a-Product の系譜だ。

なぜ：日本でこのパターンになった理由

3社の事例を貫く「ドメイン基盤先行 → 開発者基盤後発」という進化は、偶然ではない。日本市場の構造的な要因が、4つ重なっている。

理由1：エンタープライズ顧客が早期に来る市場特性

日本の B2B SaaS は、起業後比較的早い段階でエンタープライズ顧客（大企業）の獲得を目指すことが多い。SmartHR、Money Forward、Sansan のいずれも、SAML SSO・監査ログ・複雑な権限制御を初期から要求される。これは、プロダクト機能の前に「認証・権限・課金」のドメイン基盤を共通化しないと、複数プロダクトの提供が成立しないことを意味する。

海外、特に SaaS 黎明期のアメリカでは、SMB（中小企業）から獲得して segment を拡大する戦略が一般的だ。エンタープライズ要件は後から付け足せる前提で、最初は「機能勝負」で動く。だから Backstage のような開発者基盤レイヤから議論が始まる。

日本は順序が違う。事業上の必然が、ドメイン基盤を先に要求する。

理由2：採用市場の制約が「自動化・セルフサービス化」を加速する

日本の SRE / Platform Engineer の採用難は深刻だ。「人を増やす」より「現有人員で支えられるよう自動化する」方向に強いインセンティブが働く。

10X の Terraform モジュール化（Service Kit / Team Kit、10X Product Blog, 2025-06）、freee の EC2 セルフサービス（GitHub Actions ワークフローからインスタンス起動・削除、freee Developers Hub）、Sansan の Embedded SRE による「教える文化」はその表れだ。

そして、この自動化の対象はドメインの共通基盤を含む。SmartHR の「共通ライブラリ整備・開発者コミュニティ構築」というフェーズ2は、開発者基盤の自動化と同時に、ドメイン基盤の自律利用も進めている。

理由3：「横断会・定例」による合意形成文化

カケハシの隔週 SRE 横断定例、Sansan Bill One の有志横断チーム、SmartHR の社内開発者コミュニティ──いずれも、形式的な権限委譲より「会で合意する」プロセスを組織変革の主要手段にしている (KAKEHASHI Tech Blog, 2025-12)。

これは日本の組織文化の影響だが、Platform Engineering の文脈ではドメイン基盤を運用する上で、特に重要な機能を果たす。権限基盤・課金基盤のような「事業ロジックに直結する基盤」は、各プロダクトチームの要件を聞かずには進化させられない。横断会はそのインターフェースとして機能している。

理由4：「派手な技術選定」より「地道な改善」を語る傾向

日本の公開事例を見ると、Backstage 等の派手な IDP より、「Terraform CI 2分高速化」「SLO に Slack 通知埋め込み」「アラート分類で疲労削減」といった地道な改善が中心だ。

これは技術が遅れているのではなく、事業ドメインの解像度が高いことの表れと読める。SmartHR の権限基盤、Money Forward の事業者基盤、Sansan の認証基盤は、いずれも事業の核心に深く食い込んでいる。Backstage のような汎用ツールでは置き換えられない。

選択を貫く7つの共通パターン

国内事例を横断すると、3社にとどまらない共通パターンが浮かぶ。

mindmap
  root((日本SaaSの<br/>Platform Engineering<br/>パターン))
    パターン1
      ドメイン共通基盤が先
      IDP/開発者基盤は後
    パターン2
      Platform SRE × Embedded SRE
      ハイブリッド型
    パターン3
      SRE→Platform Engineeringへの組織進化
    パターン4
      開発生産性可視化の独自フレームワーク化
        freee Four Keys+SPACE
        Visional SODA
        Sansan HEART
    パターン5
      Backstage採用は限定的
      Design Docs/ADR/独自ポータルで代替
    パターン6
      内部プロダクトとしてのPlatform思想
    パターン7
      コスト最適化がPlatform投資の正当化材料

パターン3：SRE → Platform Engineering への組織進化は、特に重要だ。freee（SRE 4グループ体制：Platform / Enabling / Cloud Governance / DBRE）、10X（2022年 SRE チーム発足→ Platform 的活動を内包）、カケハシ（Platform SRE × Embedded SRE）、Sansan（Platform Engineering Unit + Embedded SRE）──いずれも、最初から Platform Engineering を名乗っていない。SRE として出発し、ミッションを「開発者が自律的に動ける環境を提供する」方向に拡張している。

これが意味するのは、日本の Platform Engineering は SRE の延長線にあるということだ。海外、特に Spotify Backstage 系の言説は「SRE と Platform Engineering は別物」という前提で語られることが多い。日本では同じチームが両方を担い、徐々にミッションが拡張していく。

そしてパターン4：独自フレームワーク化も興味深い。

会社フレームワーク内訳
freeeFour Keys + DORA SPACEJira インシデントデータ連携、四半期サーベイ
VisionalSODAQuality & Speed、On-product 指標、Team conditions
SansanHEART開発者体験計測
SmartHRRICE スコアプロダクト基盤の改善優先度決定

これらはいずれも、「単なる Four Keys 計測では足りない」という認識から生まれている。自社の事業構造に合わせて指標体系を再構築する動きが、Platform Engineering の重要な活動として明示化されている。

なぜ「Platform Engineering」という名称の定着が遅れたのか

最後に、ひとつ事実を共有したい。

「Platform Engineering」という呼称が日本で本格的に使われ始めたのは、2024年以降だ。

LayerX（Platform Engineering 部）、Sansan（Platform Engineering Unit）、Visional（プラットフォーム基盤推進室）あたりが先行で、それ以前は SRE / DevOps / 基盤チーム / インフラチーム / 共通基盤チームといった呼称が主流だった。Platform Engineering Kaigi が初開催されたのは2024年だ。

これは「日本が遅れている」のではない。実体としてのプラットフォーム活動は、呼称が定着する前から存在していたことを示している。Money Forward の事業者基盤は2020年に生まれた。Sansan の Bill One SRE チームは2023年に紹介されている。SmartHR のプロダクト基盤チームは2023年立ち上げ。これらは「Platform Engineering」を知らなくても始まっていた。

逆に言えば、「Platform Engineering」という言葉に縛られると、日本の実態を見失う。ドメイン共通基盤は Platform Engineering の一部か、それとも別物か──そう問うことに意味はあまりない。事業上の必然で生まれたものを、後から「Platform Engineering」というラベルで括り直しているだけだ。

示唆：日本のSaaSで Platform Engineering を始めるときの問い

3社の事例から、自社判断のための問いが3つ抽出できる。

  1. 自社で先に必要なのは「ドメインの共通基盤」か「開発者基盤」か？

    • マルチプロダクト戦略を取り、エンタープライズ要件（SAML/SSO/監査）が来ているなら、ドメイン基盤が先。SmartHR・Money Forward 型。
    • 単一プロダクトでマイクロサービスが爆発しているなら、開発者基盤が先。Mercari の Single Front Door 型（第2話）。

  2. SRE チームから Platform Engineering へ拡張するか、別チームを立てるか？

    • 既存 SRE が成熟しているなら、ミッション拡張が現実的。freee・10X 型。
    • SRE がない段階で立ち上げるなら、Platform SRE × Embedded SRE の二層構造を最初から設計する。Sansan・カケハシ型。

  3. 独自フレームワーク化するか、Four Keys / DORA で十分か？

    • 単一プロダクトの初期段階なら Four Keys で十分。
    • マルチプロダクト・複数事業ラインなら、SODA や HEART のような独自フレームワーク化を検討する余地がある。

まとめ

観点海外（第4話で見た会社）日本（本章の3社）
起点IDP・開発者基盤ドメイン共通基盤
Platform Engineering 認知2018〜2020年頃から2024年以降に定着
組織モデルPlatform チーム単独Platform SRE × Embedded SRE 二層
中心ツールBackstage / 内製 PaaS認証基盤、権限基盤、課金基盤
メトリクスDORA / Four Keys独自フレームワーク（SODA, HEART）

日本の SaaS は、海外の Platform Engineering 議論を後追いしているわけではない。事業上の必然から、独自の進化を辿っている。ドメイン共通基盤が先、開発者基盤が後。Platform SRE × Embedded SRE のハイブリッド。SRE → Platform Engineering への組織進化。独自フレームワーク化──これらは全て、海外の事例にそのままは収まらないパターンだ。

そして、この章で見た3社の進化は、次の第6話・第7話への伏線になる。第6話では、走り始めスタートアップ（〜50人規模）の事例を扱う。SmartHR・Money Forward・Sansan も、かつてはそのフェーズを通った。「1人目 SRE」から「SRE チーム化」、そして「Platform Engineering Unit」へ。フェーズ移行の軌跡を、第6話・第7話で連続して追っていく。

問い：あなたの会社は「Platform Engineering」を立ち上げる前に、どんなドメインの共通基盤を持っているだろうか。それは事業上の必然から生まれたものか、それとも開発者基盤レイヤから先に作ろうとしているか。

参考文献

SmartHR

Money Forward

Sansan

freee / 10X / Visional / カケハシ