目次を表示する

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

第7話 中規模成長期の選択 ── SREからPlatform Engineeringへの進化

場面

「専任のSREを採用できることになった。来月から2人入る」

エンジニアが100人を超えたあたりで、CTOがそう告げる。あなたはSREのリードを任された。さて、彼らに最初に何をやってもらうか。

選択肢は大きく2つある。

ひとつは「運用」。インシデント対応、SLO策定、オンコールローテーション、キャパシティプランニング。Google SRE本に書かれている古典的な領域だ。すぐに価値が出る。経営にも説明しやすい。

もうひとつは「プラットフォーム化」。Terraformモジュールを整え、デプロイの自動化を進め、開発者がセルフサービスでインフラを触れる体験を作る。長期的には開発生産性が跳ねるが、3ヶ月や半年では成果を見せづらい。

このジレンマは、第6話で見たスタートアップの「最小構成」を抜けた組織がほぼ全員ぶつかる壁だ。50人を超え、プロダクトが複数化し、マイクロサービス（あるいは「サービス分割の予兆」）が現れ始める頃に、SREが運用の便利屋として消費されるか、Platform Engineeringへ進化していくかの分岐が訪れる。

国内のSaaS各社は、この分岐をどう切り抜けたのか。本章では 10X・LayerX・カケハシ・freee・Visional の5社を縦に並べる。共通するのは「SREとして発足し、その後Platform Engineeringへとミッションを拡張した」という進化軌跡だ。第6話で扱ったCloudbaseやBitkeyのような「最初からPEを名乗らない最小構成」とは違い、彼らは規模の拡大とともに、組織を段階的に作り変えてきた。

この章を読み終えると、次の3つができるようになる。

  • SRE発足からPlatform化までの典型的な5パターンを、自社の現状に重ねて読み取れる
  • 「Platform SRE × Embedded SRE」のハイブリッド型がなぜ国内で定着しているかを説明できる
  • 「Backstageを入れるべきか」を、自社のコードベース構造から判断する材料を持てる

5社の進化軌跡を一枚の図にする

まず、各社がどのフェーズで何を立ち上げたかを並べてみよう。

timeline
    title 国内中規模SaaS のPE進化軌跡（5社）
    2018-2019 : LayerX バクラク事業開始
              : Mercari マイクロサービス移行（参考）
    2020      : 10X Stailerローンチ（GCP中心）
    2021      : カケハシ SRE現状報告（早期構築期）
              : Sansan Bill One SRE発足（参考）
    2022      : 10X SREチーム発足
              : Mercari DPE Camp 8チーム化（参考）
    2023      : LayerX バクラクDevOps「のびしろ」公開
              : Visional SODAフレームワーク発表
              : Sansan Platform Engineering Unit化（参考）
    2024      : freee SRE 4分割完成 / Platform Delivery改名
              : Visional ORE組織が定着
              : LayerX Platform Engineering部設立
    2025      : 10X Terraformモジュール化（Service Kit / Team Kit）が定着
              : カケハシ Platform SRE × Embedded SRE二層化
              : Visional BizReach SREプランニング改善公開
    2026      : カケハシ「強い現場と経営の視座を繋ぐ」ロードマップ

5社とも、SREチームの発足が2021〜2022年、Platform化への明示的な転換が2023〜2024年に集中している。第1話で見た「Platform Engineeringがディシプリンとして公式デビューしたのは2022年」という業界全体の動きが、国内SaaSにもほぼ同タイミングで波及していることが分かる。

10X：Terraformモジュール化で「ドメイン知識を隠す」

課題

10XのStailerは、小売チェーン（スーパー・ドラッグストア）向けのEC立ち上げプラットフォームだ。13以上のパートナー企業が、それぞれ独立したGCPプロジェクトを持つマルチテナント構成で動く。創業初期は開発者がインフラを片手間で管理していたが、パートナーが増えるにつれて限界が来た。

「2歩下がってでも信頼性で3歩進める」──そう判断して、2022年1月にSREチームが発足する。発足時点でやることは山ほどあった。Datadog移行、Kubernetesの再設計、インシデント対応の形式化、Terraformの整備、デプロイ高速化。

選択：「モジュール利用者は最低限のインターフェイスにのみ向き合えばよい」

3年経った2025年、10XのSREが到達した中核成果のひとつが Terraformモジュール化 だ。具体的には2種類のモジュール群を用意している。

  • Service Kit：個別マイクロサービスをデプロイするための単位。Cloud Run/GKE Workload・LB・Monitoring設定・IAM Bindingsをひとまとめにする
  • Team Kit：チームに対してGCPプロジェクトやIAMポリシー、Datadog権限などを一括で払い出す単位

設計思想は明快だ。モジュール利用者は最低限のインターフェイスにのみ向き合えばよい。Pub/SubのIAMをどう書くか、Cloud Runの起動引数の正解、Datadog APMの送信先──こうしたGCPやDatadogの「ドメイン知識」は、モジュールの内側に封じ込められている。利用側は数行の module 宣言で済む。

# ❌ モジュール化前：利用者が GCP の細部に向き合う
resource "google_cloud_run_v2_service" "my_service" {
  name     = "checkout-api"
  location = "asia-northeast1"

  template {
    containers {
      image = "..."
      # ... 数十行の細かい設定
    }
    scaling { min_instance_count = 1 }
    vpc_access {
      network_interfaces { ... }
    }
  }
  # IAM、モニタリング、アラートも別途数十行...
}

# ✅ Service Kit 利用後：利用者は「何を作りたいか」だけ書く
module "checkout_api" {
  source = "../../modules/service-kit"
  name   = "checkout-api"
  team   = "checkout"
  image  = var.image
  routes = ["/checkout"]
}

この設計は、第9話で扱う「Extraneous Cognitive Loadの削減」をTerraformレイヤーで実装した例と読める。GCP固有の知識（Intrinsic）はSREチームに集中させ、開発者にはチームのドメイン（Germane）に集中してもらう。

加えて、全IAM変更をTerraform PR経由にするポリシーが2025年時点で定着している。コンソールから直接権限を変える運用は廃止され、PAM（Privileged Access Manager）と組み合わせて、緊急時の昇格も監査ログに残る形になった。

その他の主な成果（10XのSRE現状報告 2025より）：

  • CUJ（Critical User Journey）→ SLOの紐付け。Slack上でエラーバジェット消費を可視化
  • アラートを actionable / non-actionable に分類してアラート疲れを削減
  • Spot VM移行で60〜91%のコスト削減、CircleCI→GitHub Actions統合

なぜその選択か

パートナー（小売）が増える事業構造上、共通インフラのモジュール化が「事業のスケーラビリティ」と直結する。1社追加するたびにIAMやLBの設定を手作業で書いていたら、10社目で破綻する。経営判断として「2歩下がってでも信頼性で3歩進める」を選んだのは、この事業構造から逆算した結論だった。

注目すべきは、10Xが Backstageを入れるより先にTerraformの抽象化に投資した ことだ。第10話で扱う「Building the Front End First」の逆を行く判断──ピカピカのPortalより、地味だが効くモジュール群を先に作った──と言える。

LayerX：「コンパウンドスタートアップ」の飛び込み型支援

課題

LayerXは「コンパウンドスタートアップ」を標榜し、バクラク（経費精算・請求書受領）、Ai Workforce（AIドキュメント処理）、暗号資産事業など、複数の事業体を並走させている。短期間で複数プロダクトをローンチする中で、共通基盤・インフラ・運用の技術的負債が蓄積し、サービス間依存関係の手動解決で運用負荷が増えていた。

選択：DevOps 4名 + Enabling、内製基盤「layerone」

バクラク事業部の Platform Engineering部 は、現時点で次の構成だ。

  • DevOpsグループ（4名）：内製インフラ基盤の運用と進化
  • Enablingチーム：プロダクトチームへの「飛び込み型」支援

技術スタックは、内製インフラ基盤 layerone（ECS Service + Jsonnet設定）を中心に、監視はDatadogで統一されている。CODEOWNER設定で権限が委譲され、各チームの自律性が担保される設計だ。

Backstage導入を検討中だが慎重な理由

注目すべきは、LayerXが Backstage導入を「検討中」のまま、本格採用に踏み切っていない ことだ。慎重な理由のひとつは、自社のコードベース構造（monorepo）との相性問題 にある。

Backstageは元々マイクロサービス（多数のリポジトリに分散したサービス群）の発見可能性を解決するために生まれた。一方、LayerXのバクラクは複数プロダクトを抱えつつもmonorepo寄りの構造を持つ。サービスカタログの粒度や、Software Templatesのリポジトリ生成モデルが、自社の運用に素直に乗らない。

この見極めは重要だ。第10話で扱う「Backstage導入で満足する」アンチパターンを回避するには、Backstageを入れる前に「自社のコードベース構造で本当に使えるか」を冷静に判断する必要がある。LayerXは、暫定対応として Design Docs / ADR をドキュメント基盤として運用し、IDP相当の機能（誰が・何を・なぜ作ったかの一覧化）をローテクに代替している。

なぜその選択か

「コンパウンドスタートアップ」モデルでは、新規プロダクトの立ち上げ速度が事業価値そのものだ。Enablingチームが飛び込み型で支援する設計は、新プロダクトが立ち上がった瞬間に必要になる「ECS設定・CI/CD・監視・アラート」をパッケージ化して持っていく前提で機能する。これは第9話で扱うTeam Topologiesの「Enabling team」のパターンに近い。

カケハシ：隔週30分の横断定例という「地味だが効く」施策

課題

医療DXのカケハシは、薬局向けの電子薬歴・薬局DXプロダクトを複数展開している。複数プロダクト化に伴い、Embedded SREとPlatform SREの責任分界が不明確になっていた。「Embeddedが個別プロダクトの可用性を見る」「Platformは全社共通基盤」という大枠は決まっていても、実務の境目──canary deploymentの設計はどちらの責任か、AWSの命名規則は誰が決めるか、セキュリティのChatOps化は誰が主導するか──で揉める場面が増えていた。

選択：Platform SRE × Embedded SREの二層構造 + 横断定例

カケハシは2025年に、SREを明示的に二層構造で整理した。

  • Platform SRE：横断的な共通基盤・標準化を担う
  • Embedded SRE：各プロダクトに配置。プロダクト最適の信頼性課題を担う

この構造自体は珍しくない。海外でもMercariや国内のSansanが採用している。注目すべきは、カケハシが 二層を機能させるための仕掛けとして導入した運用ルールだ。

隔週30分のSRE横断定例。Embedded SREが状況・課題を持ち寄る場として制度化されている。たった隔週30分。だが、これが地味に効く。

各プロダクトのEmbedded SREが孤立して同じ問題を別々に解決する状況を、横断定例が「共通言語化」していく。たとえば2025年に AWS命名規則の統一が実現したのは、横断定例で各プロダクトの命名がバラバラだと顕在化したことが起点だった。トップダウンで規則を押し付けるのではなく、Embedded SRE同士の対話から「これ揃えませんか」と合意していく。

加えて、RACI（責任分界）の明確化も2025年に進んだ。

責務Embedded SREPlatform / Enablingエンジニアリングマネージャー
プロダクト最適の信頼性A（責任）C（協議）I（情報）
共通基盤と標準化CAI
インシデント / セキュリティR（実行）RA

形式的な権限委譲より、「会で合意する」プロセスを先に走らせる。これが第5話で見た日本のSaaSの組織進化パターン──横断会・定例での合意形成──の典型だ。一気に組織変更せず、段階的に責任分界を合意していく民主的アプローチが、カケハシの選択の核心にある。

なぜその選択か

各プロダクトのSREが孤立すると、知識のサイロ化が起きる。第10話で扱う「Skill Concentration Trap」（スキル偏在）の入り口だ。横断定例は、その入り口を塞ぐ装置として機能している。

freee：SRE 4分割と「失敗からの転換」

課題

freeeは会計・人事労務SaaSとして数百人規模のエンジニア組織を持ち、複数プロダクトを展開している。マルチプロダクト化に伴う開発者基盤の整備需要が高まる一方で、**「大規模プロダクトでDORA導入を試みたが定着しなかった」**という公開事例（Findy Engineer Lab記事）を持つ。トップダウンで指標を入れただけでは、現場のチームが動かない、という典型的な失敗だ。

選択：SRE 4分割 + Platform Deliveryチーム + EC2セルフサービス

freeeは2024年時点でSREを4つのグループに分割している。

グループ役割
Platform基盤チーム
Enabling横断支援
Cloud Governanceクラウド統制
DBREデータベース信頼性

加えて、旧Developer eXperienceチームをPlatform Deliveryチームとして再定義し、内製デリバリープラットフォーム（GitHub Actions + ArgoCD + Kubernetes）を運用している。Jiraのインシデントデータと連携してFour Keysを計測し、特にMTTRの正確性に注力するメトリクス運用が特徴だ。

EC2開発環境のセルフサービス化も大きな成果だ。

  • AMI自動ビルド（GitHub Actions + Ansible + Packer）
  • 開発者がGitHub Actionsワークフローからインスタンスの起動・削除・スペック変更が可能
  • Instance Schedulerによる夜間自動停止でコスト最適化

開発者は「インフラ申請フォーム」を埋める代わりに、GitHub Actionsを叩く。これは第4話のadidasの「申請フォームを消す」と同じ思想だ。

スモールスタート戦略への転換

最も学ぶべきは、freeeが 「大規模プロダクトでのDORA導入失敗」から方針転換したことだ。

  • 過去：トップダウンで全社にDORAを展開→定着せず
  • 現在：小規模チームから検証→展開（トランクベース開発、ロールバック効率化など）

加えて、Platformチームは 「目標数値ではなく改善能力（capability）に焦点」 というドキュメントを整備し、メトリクスの誤用を防ぐガードレールにしている。

これは第10話で扱う「Tracking the Wrong Metrics」（誤ったメトリクス追跡）への解毒剤だ。「DORAの数字を上げる」ことを目標にすると、Goodhartの法則（「測定対象が目標になると、それは良い測定対象でなくなる」）が発動する。指標を改善することではなく、改善できる組織能力を作ることを目標にする ──この転換は、第8話で扱うPlatform-as-a-Productの発想と地続きだ。

なぜその選択か

数百人規模の組織で、トップダウンの統一が機能する余地は小さい。各プロダクトの自律性を奪わず、「データを見てチームが自律的に改善する」体験を作る。Platformチームの役割は、その体験をcapabilityとして提供することに集約される。

DORAの SPACEフレームワーク準拠の四半期サーベイで開発生産性を可視化し、「開発生産性2倍」を中長期目標に掲げる──これは指標を強制するのではなく、各チームが自分たちの状況を映す鏡を持つための仕組みだ。

Visional：プラットフォーム基盤推進室（ORE）と独自フレームワーク

課題

Visionalは、BizReach（転職）、HRMOS（HR SaaS）、CareerTrekなど複数プロダクトを運営する。複数プロダクト横断での信頼性・可用性の標準化、開発生産性の可視化（特にレガシーと近代化システムが混在する状況）、全社レベルでの「自分のチームが何ができているか」のアカウンタビリティ──これらが課題だった。

選択：ORE組織 + SODAフレームワーク

Visionalは プラットフォーム基盤推進室 = ORE（Organisational Reliability Engineering） という横断組織を持つ。ビジョンは “Make it Visible / No Ops More Code”。BizReach事業内のSRE Groupとは別レイヤーで、事業横断で動く。

開発生産性の可視化には独自の SODA（Software Outcome Delivery Architecture）フレームワーク を構築している。3つの指標領域を持つ。

領域内容
Quality & SpeedDORA / Four Keys
On-product 指標スコープ・時間・予算・デリバリー変化
Team conditionsエンゲージメント、個人能力、組織構成

単一のFour Keysだけでは「組織として説明できる開発生産性」にならない、という判断が背景にある。データ収集の現実──工数報告への抵抗が強かった──には、価値説明 + 2分入力 + 給与システム連携で乗り越えた、という具体的な工夫もある。

加えて、2025年には BizReach SREプランニング改善 をSRE Lounge #18で発表している。スクラムのプランニングに「Goodhartの法則を意識し、メトリクス単独最適化を避ける」運用を組み込んだ事例だ。

なぜその選択か

複数事業・複数年代のシステムが混在する組織では、「全社共通のひとつの指標」では現場が納得しない。事業ごとのコンテキストを保ったまま、横断で比較可能にする多次元の指標体系が必要だった。SODAは、その必要から逆算して設計されている。

これは第8話で扱うPlatform-as-a-Productの「プロダクトメトリクスを自分たちで定義する」発想に近い。Four Keysをそのまま借りるのではなく、自社の事業構造に合わせて指標体系を再構築する流れは、第5話で見たSansan（HEART）、SmartHR（RICE）と共通している。

5社を貫く共通パターン

5社を縦に並べると、いくつかの共通パターンが浮かび上がる。

パターン1：SRE発足 → ミッション拡張 → Platform化

freee、10X、Sansan（参考、第5話）、カケハシ。SREチームとして発足し、その後ミッションを「開発者が自律的に動ける環境を提供する」方向に拡張している。Platform Engineeringが独立した職種として最初から存在する例は、国内では少ない。

パターン2：Platform SRE × Embedded SRE のハイブリッド型

カケハシ、Sansan、Visional、freee（Platform / Enabling / Cloud Governance / DBRE 4分割）。横断的な基盤チームと、プロダクト常駐型チームを並走させて全体最適と局所最適を両立する構造が定着しつつある。

パターン3：開発生産性指標の独自フレームワーク化

freee（Four Keys + DORA SPACE）、Visional（SODA）、Sansan（HEART）、SmartHR（RICEスコア）。単なるFour Keys計測ではなく、自社の事業構造に合わせた指標体系を再構築する流れ。

パターン4：「Backstageは検討中／採用していない」が多数派

LayerXが検討中、Sansanが独自にOrbitを内製、他は明示的なBackstage採用言及が見当たらない。「Backstageを入れる」より「Design Docs / ADR / 内製ポータル」で代替する選択が多い。これは海外（Spotify・Zalando・HelloFresh・Pinterest）の傾向と対照的だ。

パターン5：横断会・定例による合意形成

カケハシの隔週SRE横断会、Sansan の Bill One 有志横断チーム、SmartHR の社内開発者コミュニティ。形式的な権限委譲より「会で合意する」プロセスが組織変革の主要手段になっている。トップダウンの組織変更ではなく、段階的な合意形成で責任分界を作っていくのが日本的な進化の特徴だ。

✅ 良い進化 / ❌ 悪い進化

5社の事例から、中規模成長期に陥りがちなパターンと、それを回避する選択を整理しておこう。

❌ 悪い進化：
   - 「専任SREを採用したから運用は彼らに任せる」
     → 開発チームから運用ノウハウが消える。SREが便利屋になり、
       Platform化の余裕を失う

   - 「Backstage を入れたら Platform Engineering をやっていることになる」
     → 自社のコードベース構造（monorepo か polyrepo か）を見ずに導入し、
       使われないPortalを生む（第10話アンチパターン4の伏線）

   - 「全社にDORAを展開して目標値を設定する」
     → トップダウン導入で定着しない。Goodhartの法則で数字遊びになる
       （freeeが過去に経験したパターン）

   - 「Embedded SRE と Platform SRE を組織図で分割すればOK」
     → 責任分界が形骸化し、両者が同じ問題を別々に解決する状況に

✅ 良い進化：
   - 「SREのcapabilityを Platform 経由で セルフサービス化する」
     → 10XのTerraformモジュール、freeeのEC2セルフサービス

   - 「自社のコードベース構造に合うかを見極めてからBackstageを判断する」
     → LayerX の慎重姿勢

   - 「小規模チームから検証→展開（スモールスタート戦略）」
     → freeeのDORA再導入、SmartHRの3フェーズアプローチ

   - 「横断定例で『共通言語化』してから組織を変える」
     → カケハシの隔週30分定例、AWS命名規則統一

次章へ

ここまで見てきた5社に共通するもうひとつの底流がある。それは「プラットフォームを内部プロダクトとして扱う」発想だ。

10Xの「モジュール利用者は最低限のインターフェイスにのみ向き合えばよい」という設計思想。LayerXのEnablingチームの「飛び込み型支援」。Sansanが標榜する「Platform as social product」（次章で詳述）。SmartHRのテクニカルプロダクトマネージャー。freeeのPlatform Deliveryチーム。

これらはすべて、プラットフォームチームを「ツールを束ねる便利屋」ではなく「内部の開発者を顧客に持つプロダクトチーム」として再定義する動きだ。第8話では、この Platform-as-a-Product という思想を正面から扱う。Spotify・Mercari・HelloFresh・SmartHR・Sansanの実装を比較しながら、「使ってもらえないプラットフォーム」を作らないための原則を整理していく。

中規模成長期の選択は、組織図の変更ではなく、プラットフォームに対する考え方の転換で決まる──これが本章の結論だ。

問い：あなたの組織のSRE（あるいはインフラ）チームは、今「運用の便利屋」として消費されているか、「開発者向けの内部プロダクトチーム」として動けているか。境目は、彼らが書いているのが「チケットの返信」か「Terraformモジュール」か、で見える。

参考文献