ストーリー
田
田中VPoE
「インフラを触る時間が長すぎる」「環境構築に何日もかかる」。開発者アンケートでこんな声が繰り返し上がっている。Month 5でクラウドネイティブ基盤を整えた。今月のテーマは「開発者プラットフォームの構築」だ
あなた
開発者プラットフォーム？Kubernetesの上に何かを作るということですか？
あ
田
田中VPoE
それだけじゃない。Platform Engineeringという考え方だ。開発者が「インフラのことを考えずに、ビジネスロジックに集中できる」環境を作る。インフラチームへの依頼チケットを切って数日待つのではなく、セルフサービスで数分で完了する世界だ
あなた
DevOpsの次のステップということですか？
あ
田
田中VPoE
DevOpsは「Dev と Ops の壁を壊す」ことを目指した。だが現実には「すべての開発者がKubernetesのYAMLを書く」ことになり、認知負荷が爆発した。Platform Engineeringは「適切な抽象化」を提供し、開発者の認知負荷を下げつつ、自律性を高める
Platform Engineeringとは何か
DevOpsの進化としてのPlatform Engineering
| 観点 | 従来のインフラ運用 | DevOps | Platform Engineering |
|---|---|---|---|
| インフラの利用 | チケットで依頼、数日待ち | 開発者が直接操作 | セルフサービスで数分 |
| 責任の所在 | インフラチーム | 全員（You Build It, You Run It） | プラットフォームチーム + 開発チーム |
| 開発者の認知負荷 | 低（インフラは他人事） | 高（全部知る必要がある） | 適切（必要な抽象化を提供） |
| スケーラビリティ | インフラチームがボトルネック | チームごとにバラバラ | 標準化された共通基盤 |
| ガバナンス | 中央集権的な承認フロー | チームの裁量に依存 | ガードレールによる自律的な統制 |
Platform Engineeringの3つの柱
Platform Engineering の 3 本柱:
1. Developer Experience（開発者体験）
├── 認知負荷の軽減
├── セルフサービス化
├── 高速なフィードバックループ
└── 直感的なインターフェース
2. Golden Path（推奨パス）
├── 標準化されたテンプレート
├── ベストプラクティスの組み込み
├── セキュリティ・コンプライアンスの自動適用
└── 「正しいことが簡単なこと」の実現
3. Platform as a Product（プロダクトとしてのプラットフォーム）
├── 開発者 = 顧客
├── 利用者フィードバックに基づく改善
├── 採用率・満足度のメトリクス
└── プロダクトマネジメントの適用なぜ今Platform Engineeringなのか
開発者の認知負荷問題
| 認知負荷の種類 | 説明 | 例 |
|---|---|---|
| 本質的な認知負荷 | ビジネスロジックの理解と実装 | ドメインモデル設計、アルゴリズム |
| 付随的な認知負荷 | ツールや環境の操作 | Kubernetes YAML、CI/CDパイプライン設定 |
| 無駄な認知負荷 | 不必要な複雑さへの対処 | 非標準的な手順、属人的な環境構築 |
「開発者が本質的な認知負荷に集中できる割合は、多くの組織で50%を下回っている。残り50%以上がYAMLの記述やチケット待ちに費やされている。これは経営課題だ」 — 田中VPoE
グローバルの動向
| 指標 | 数値 |
|---|---|
| Platform Engineeringを導入済みまたは計画中の企業（2025年推定） | 約70% |
| IDP（Internal Developer Portal）導入後の環境構築時間の削減率 | 平均80%以上 |
| プラットフォームチームを持つ企業の割合 | 約50% |
| 開発者の認知負荷が「高すぎる」と回答した割合 | 約60% |
| Platform Engineering市場の年成長率 | 約25% |
Month 6のロードマップ
| Step | テーマ | 得られる成果 |
|---|---|---|
| 1 | 開発者体験を可視化しよう | DevEx評価、開発者サーベイ、Platform Engineeringの基本原則 |
| 2 | セルフサービスプラットフォームを設計しよう | API駆動設計、Kubernetes抽象化、GitOps |
| 3 | Internal Developer Portalを構築しよう | Backstage、サービスカタログ、スキャフォールディング |
| 4 | Golden Pathとガードレールを整備しよう | テンプレート戦略、ガードレール、Compliance as Code |
| 5 | プラットフォームチームを運営しよう | チーム設計、採用メトリクス、プロダクト運営 |
| 6 | 開発者プラットフォームを完成させよう | 統合プラットフォーム導入計画書 |
「クラウドネイティブ基盤を整えた。次はその基盤を『開発者が使いたくなるプロダクト』に変える番だ。技術的に正しいだけでは使われない。使いやすくなければ意味がない」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| Platform Engineering | 開発者がセルフサービスでインフラを利用できる仕組みを構築するアプローチ |
| 認知負荷の軽減 | 適切な抽象化により、開発者がビジネスロジックに集中できる環境を作る |
| 3つの柱 | Developer Experience、Golden Path、Platform as a Product |
| Month 6の目標 | 開発者プラットフォームを構築し、全社の生産性を向上させる |
チェックリスト
- Platform Engineeringの基本概念を理解した
- DevOpsとPlatform Engineeringの違いを説明できる
- 開発者の認知負荷問題を理解した
- Month 6のロードマップを把握した
次のステップへ
次は「開発者体験（DevEx）の評価」を学びます。現状の開発者体験を定量的に測定するフレームワークを身につけましょう。
推定読了時間: 15分