フレームワーク活用ガイドひとことで言うと#
開発チームが**インフラやツールチェーンを自力で使いこなせるセルフサービス基盤（Internal Developer Platform）**を構築し、「インフラチームに依頼して待つ」をなくして開発者の生産性を最大化する手法。
押さえておきたい用語#
- Internal Developer Platform（IDP）
- 開発者向けのセルフサービス基盤。サービスの作成・デプロイ・監視を開発者自身が行えるようにする仕組み。
- ゴールデンパス
- プラットフォームが提供する推奨される標準的な方法。強制ではなく、使うと便利で速い「舗装された道」。
- 開発者体験（Developer Experience）
- 開発者がツールやプロセスを使う際の使いやすさ・生産性・満足度の総合評価。
- サービスカタログ
- テンプレートから新しいサービスをワンクリックで作成できる仕組み。リポジトリ+CI/CD+監視が自動で揃う。
- 抽象化レベル
- インフラの詳細をどこまで隠蔽するかの度合い。隠しすぎると柔軟性がなく、見せすぎると複雑になる。
プラットフォームエンジニアリングの全体像#
こんな悩みに効く#
- 開発者がインフラの設定やデプロイの依頼に時間を取られている
- 「You build it, you run it」と言われても、開発者にインフラの知識がなくて回らない
- DevOpsを導入したが、結局各チームが独自にツールを構築してサイロ化している
基本の使い方#
開発者が日常的に感じている不満や非効率を調査する。
- アンケートやインタビューで「何に時間がかかっているか」を聞く
- 開発のリードタイムを計測し、ボトルネックを定量化する
- 「環境構築に2日」「デプロイに30分かかって手が離せない」等の具体的な課題
ポイント: プラットフォームの設計はユーザー（開発者）のニーズから始める。技術から始めない。
開発者向けのセルフサービス基盤を設計する。
- サービスカタログ: テンプレートから新しいサービスをワンクリックで作成
- CI/CDパイプライン: 標準化されたビルド・テスト・デプロイのフロー
- 環境管理: 開発・ステージング・本番環境のプロビジョニング
ポイント: 「抽象化のレベル」が重要。K8sのYAMLをそのまま見せるのではなく、適切に隠蔽する。
**推奨される標準的な方法（ゴールデンパス）**を用意する。
- 「新しいAPIサービスを作るならこのテンプレート」
- 「DBを追加するならこのセルフサービスポータル」
- 強制ではなく、使うと便利で速い「舗装された道」を提供する
ポイント: ゴールデンパスは強制ではない。でも使わない理由がないくらい便利にする。
Internal Developer Platformをプロダクトマネジメントの手法で運用する。
- 開発者からのフィードバックを継続的に収集する
- 利用率やNPS（推奨度）をメトリクスとして追跡する
- ロードマップを公開し、開発者と優先順位を議論する
ポイント: プラットフォームチームのユーザーは社内の開発者。プロダクトチームと同じ姿勢で向き合う。
具体例#
課題: 8つのプロダクトチーム（各5〜7名）が、それぞれ独自にCI/CD、インフラ構築、モニタリングを設定。新メンバーのオンボーディングに2週間、新サービスの立ち上げに1週間。
プラットフォーム構築:
- Backstageでサービスカタログとテンプレートを提供。「Go API」「React SPA」「Worker」のテンプレートから30分で一式が揃う
- ArgoCDでGitOpsベースのデプロイを標準化
- セルフサービスポータルでDB、キャッシュの追加をフォーム入力だけで実行可能に
結果: 新サービスの立ち上げ1週間→30分。新メンバーのオンボーディング2週間→3日。開発者のNPS: -10→+45。
状況: 各チームが自由に技術選定した結果、8チームで5種類のCI/CDツール、4種類のデプロイ方法、3種類のログ集約方式が乱立。異動のたびにゼロから学び直し。
ゴールデンパス提供:
- API開発: Go + Echo + OpenAPI → CI/CD → ECS Fargate の標準フロー
- フロントエンド: Next.js + TypeScript → CI/CD → CloudFront の標準フロー
- 各テンプレートにヘルスチェック、構造化ログ、メトリクス出力が組み込み済み
結果: 6ヶ月後に全チームの85%がゴールデンパスを採用。チーム間の異動時の立ち上がり期間が2週間から3日に。「強制しなくても、便利だから自然に使われる」状態を実現。
状況: プラットフォームチーム3名の人件費（年間2,400万円）に対して「コストセンターでは？」という疑問の声。
効果の定量化:
- 新サービス立ち上げ: 1週間→30分。年間20サービス作成で年間100人日の削減
- デプロイ待ち時間: 30分→5分。1日平均15回デプロイ × 50名 = 年間1,800時間の削減
- オンボーディング: 2週間→3日。年間15名の新規参画で年間165人日の削減
- エンジニア時給換算: 年間約8,000万円相当の生産性向上
要するに、プラットフォームチーム3名の投資に対してROI約3.3倍**。経営会議で承認され、チームの増員も決定。
やりがちな失敗パターン#
- 開発者のニーズを聞かずに作る — プラットフォームチームが「便利だと思うもの」を作っても、開発者が使わなければ意味がない。ユーザーリサーチから始めること
- 抽象化が不適切 — 隠蔽しすぎると柔軟性がなくなり、隠蔽しなさすぎると複雑で使えない。「通常は意識しなくていいが、必要なら深掘りできる」レベルを目指すこと
- 強制で普及させようとする — 「全チーム必須」と命じると反発を招く。まず1〜2チームで成功事例を作り、口コミで広げること
- プラットフォームの運用を怠る — 作って終わりにすると、プラットフォーム自体が技術的負債になる。プロダクトとして継続的に改善すること
まとめ#
プラットフォームエンジニアリングは「開発者がインフラを気にせず、プロダクト開発に集中できる環境」を作るための手法。セルフサービス基盤、ゴールデンパス、プロダクトとしての運用が三本柱。技術だけでなく、開発者のニーズに寄り添うプロダクトマインドが成功の鍵。