← エピソード一覧に戻る Episode 175 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 速い feature team の裏にいる見えない加速装置
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発のプラットフォームチームを取り上げます。機能を作る feature team が主役に見えますが、実はその速さを支える見えない加速装置がないと、組織が増えるほど全員の足が重くなるんです。
ミカ
ミカです。プラットフォームチームって、インフラ担当の人たちをまとめて呼んでいるだけかと思っていました。でも今の話だと、単なる裏方じゃなくて、事業の成長速度そのものを左右する存在なんですね。
タカシ
その通りです。前回のアーキテクチャランウェイが『次の成長を止めない設計余力』なら、今回は『その余力を各チーム任せにせず共通基盤として誰が作るか』の話です。SaaS では、ここが弱いと新機能も品質も一緒に崩れます。
ミカ
なるほど。各チームがそれぞれ CI/CD や監視や権限設定を抱えていたら、人数が増えるほど同じ苦労を何度も繰り返すことになりますね。今日は、そのムダをどう経営判断で減らすかを知りたいです。
Chapter 2 原則 ― プラットフォームは社内向けプロダクトである
タカシ
Google Cloud は、platform engineering を、開発チームに Golden Paths を提供する internal developer platform の設計と運用だと整理しています。Golden Path は、よくある作業を自己完結で進められるテンプレートと自動化、いわば社内開発の最短ルートですね。
ミカ
最短ルート、分かりやすいです。つまり platform team の仕事は、みんなに『頑張って標準化してね』と言うことではなくて、標準に乗る方が圧倒的に楽な道を先に舗装しておくことなんですね。
タカシ
まさにそこです。Team Topologies も、内部プラットフォームの主目的は stream-aligned team の cognitive load を下げることだと述べています。Kubernetes や IAM の細部を毎回 feature team に背負わせない。そのために複雑さを platform 側へ引き取るんです。
ミカ
でも、それって中央集権が強すぎると逆に遅くなりませんか。何をするにも platform team の承認待ち、みたいな状態になると、結局ボトルネックが一つ増えるだけに見えます。
タカシ
重要なのは統制そのものではなく、社内開発者を顧客として扱うことです。Backstage も、中央チームは自分たちの platform を product として運営し、採用、サポート、テンプレート整備、利用データの計測まで担うべきだと明示しています。使われて初めて価値になるわけです。
Chapter 3 具体例 ― 使われる基盤は何が違うのか
ミカ
ここ、かなり経営っぽいですね。じゃあ実際に強い会社は、platform team をどう機能させているんでしょう。単なる理想論ではなく、数字や仕組みで見てみたいです。
タカシ
まず Spotify です。Spotify Engineering によると、頻繁に Backstage を使う開発者は、GitHub で 2.3 倍アクティブ、コード変更数は 2 倍、サイクルタイムは 17 パーセント短く、デプロイ頻度も 2 倍でした。入口を一つにまとめるだけで、ここまで差が出ています。
ミカ
2.3 倍はかなり大きいですね。『便利な社内ポータルができました』ではなくて、日々の開発行動そのものが変わっている。feature team が速く見える裏で、platform 側が迷子の時間を消しているわけですね。
タカシ
Dynatrace も象徴的です。Platform Engineering team は project initializer を発展させ、ownership、ドキュメント、CI/CD、依存関係、observability、security を Backstage に集約しました。事例では、この仕組みが 1000 人超のエンジニア効率改善につながったと紹介されています。
ミカ
しかも面白いのは、全部を固定しなかったことですよね。Dynatrace は標準の `config.yaml` を持ちながら、開発者が自分に必要な見え方へ調整できる余地も残していた。標準化と自由度の線引きが上手です。
タカシ
Trade Me の Thinnest Viable Platform も参考になります。彼らは TVP を production-ready application への golden path と位置づけ、標準ルートでは必須ガードレールを自動化しつつ、使わない自由も残しました。ただし外れるなら production-readiness checklist を自分で満たす必要があります。
ミカ
それ、すごく経営的ですね。禁止で縛るのではなく、標準ルートを一番早くて安い道にしておく。冒険したいチームはどうぞ、でも追加コストは見える化します、という設計に聞こえます。
タカシ
そして Google Cloud の調査では、900 超の組織のうち 55 パーセントがすでに platform engineering を採用し、その 90 パーセントが拡大予定でした。成熟した実践企業では、時間短縮を強く実感した割合が 71 パーセントで、未成熟企業の 28 パーセントを大きく上回っています。
Chapter 4 失敗パターン ― 使われない基盤は資産ではなく負債になる
ミカ
逆に、platform team を作ったのにうまくいかない会社は、どこでつまずくんでしょう。基盤投資って、一見すると正しそうなので、失敗が見えにくそうです。
タカシ
典型例は四つです。基盤を作ること自体が目的化する、標準化を強制しすぎて闇運用が増える、自己サービスがなく依頼窓口になる、そして内部顧客の声を聞かずに roadmap を決める。この四つですね。
ミカ
三つ目、耳が痛い会社は多そうです。portal はあるのに『環境作成は platform チームに Slack してください』だと、ただ受付係が増えただけですもんね。セルフサービスでない時点で、golden path じゃないと。
タカシ
その通りです。SaaS では、新規サービス作成、権限付与、監視設定、デプロイまでを、できるだけ申請なしで進められる形にして初めて投資効果が出ます。さらに platform team の KPI も稼働率ではなく、採用率、初回デプロイまでの日数、問い合わせ削減で見るべきです。
ミカ
なるほど。platform team が『社内のルール番人』で終わるか、『社内で一番使われるプロダクトチーム』になるかで、意味が全然違うんですね。前者だと嫌われ、後者だと頼られる。
Chapter 5 クロージング ― 標準化と自律性を両立させる
タカシ
今日のポイントは三つです。第一に、platform team の顧客は社内開発者であること。第二に、golden path は標準を押しつける仕組みではなく、最も速く安全な道を用意すること。第三に、効果は DevEx だけでなく、開発速度、信頼性、採用力に返ってくるという点です。
ミカ
明日からできることとしては、各 feature team が毎回つまずく作業を洗い出して、まず一つでも self-service 化してみるのが良さそうですね。『この基盤、本当に使われているか』を聞くところから始めたいです。
タカシ
いいですね。プラットフォームは大きく作るより、使われる最小単位から磨く方が成功しやすいです。次回は、その土台の上で個々の開発者がどれだけ理解しやすく、変更しやすく働けるか、SaaS 開発における開発者体験を見ていきましょう。
ミカ
プラットフォームチームは裏方というより、社内の売れ筋プロダクトを作るチームなんですね。皆さんの会社でも、標準ルートが本当に最短になっているか、ぜひ見直してみてください。それではまた次回。