ソフトウェアシステムがより複雑になるにつれて - - マイクロサービス、Kubernetes、マルチクラウド、CI/CD パイプライン、オブザーバビリティスタック - - 開発者はインフラストラクチャにより多くの時間を費やし、プロダクトの構築に費やす時間が少なくなっています。Platform Engineering は、複雑さを抽象化し、開発者にセルフサービスツールを提供する内部プラットフォームを作成することで、この問題を解決します。
Gartner は、2027年までに**ソフトウェアエンジニアリング組織の80%**がプラットフォームチームを設立すると予測しています。このガイドでは、Platform Engineering とは何か、なぜ重要なのか、そして Internal Developer Platform をゼロから構築する方法を探ります。
Platform Engineering とは？
Platform Engineering は、ソフトウェアエンジニアリング組織にセルフサービス機能を提供するツールチェーンとワークフローを設計・構築する分野です。その成果物は Internal Developer Platform (IDP) - - 開発者とインフラストラクチャの間に位置する抽象化レイヤーです。
Platform Engineering vs DevOps
Platform Engineering は DevOps の代替ではありません - - 次の進化です。DevOps は「あなたが作り、あなたが運用する」と言いました。Platform Engineering は「構築と運用を楽にします」と言います。
| 側面 | DevOps | Platform Engineering |
|---|---|---|
| 焦点 | 文化とプラクティス | プロダクトとセルフサービス |
| アプローチ | 各チームがインフラを管理 | プラットフォームチームがインフラを抽象化 |
| 認知負荷 | 高い（各チームがすべてを学ぶ） | 低い（ゴールデンパスが提供される） |
| 成果物 | CI/CD パイプライン、IaC スクリプト | Internal Developer Platform |
| ユーザー | 全エンジニアリング | プラットフォームチームがエンジニアリングに奉仕 |
なぜ Platform Engineering が重要なのか
認知負荷の問題
典型的な現代の組織では、開発者は以下を理解する必要があります：
- Git ワークフローとブランチ戦略
- CI/CD パイプラインの設定
- コンテナのビルドとレジストリ管理
- Kubernetes マニフェストと Helm Charts
- クラウドプロバイダーサービス（AWS/GCP/Azure）
- ネットワーキング、DNS、TLS 証明書
- モニタリング、ロギング、アラート設定
- データベースのプロビジョニングとマイグレーション
- セキュリティポリシーとコンプライアンス
これは実際のプロダクトから注意をそらす膨大な認知負荷です。
ゴールデンパス
Platform Engineering はゴールデンパスの概念を導入します - - 一般的なタスクに対する意見を持った、十分にサポートされ、文書化されたパスです。ゴールデンパスは強制ではありません。開発者は逸脱できますが、プラットフォームは正しいことを簡単なことにします。
新しいマイクロサービス作成のゴールデンパスの例：
- 開発者がポータルで「新しいバックエンドサービス」を選択
- 言語/フレームワークを選択（Node.js、Go、Python）
- プラットフォームが自動作成：Git リポジトリ、CI/CD パイプライン、Kubernetes ネームスペース、モニタリングダッシュボード、アラートルール
- 開発者がリポジトリをクローンして、すぐにコーディングを開始
Internal Developer Platform の構築
レイヤー1：Developer Portal
ポータルは開発者のための単一のエントリポイントです。最も人気のあるオープンソースの選択肢は Backstage（Spotify が作成、現在は CNCF プロジェクト）です。
主要な機能：
- サービスカタログ：すべてのサービス、そのオーナー、ドキュメント、依存関係
- ソフトウェアテンプレート：ベストプラクティスが組み込まれた新しいサービスのスキャフォールディング
- 技術ドキュメント：コードとしてのドキュメント、レンダリングされ検索可能
- プラグインエコシステム：カスタム機能で拡張可能
# backstage/catalog-info.yaml apiVersion: backstage.io/v1alpha1 kind: Component metadata: name: user-service description: Manages user accounts and authentication annotations: github.com/project-slug: myorg/user-service backstage.io/techdocs-ref: dir:. spec: type: service lifecycle: production owner: team-auth system: identity-platform dependsOn: - resource:postgresql-main providesApis: - user-api
レイヤー2：インフラストラクチャの抽象化
開発者は Terraform や Kubernetes YAML を直接書くべきではありません。プラットフォームが抽象化を提供すべきです。
ツール：
- Crossplane：Kubernetes ネイティブのインフラストラクチャプロビジョニング
- Terraform モジュール：事前構築・テスト済みのインフラストラクチャモジュール
- Pulumi：実際のコードとしてのインフラストラクチャ（TypeScript、Python、Go）
# Example: Crossplane composition for a database apiVersion: database.example.com/v1 kind: PostgreSQLInstance metadata: name: user-db spec: size: small # Abstraction: small = 2 vCPU, 4GB RAM version: "16" backup: daily team: auth-team
RDS パラメータ、VPC サブネット、セキュリティグループ、バックアップポリシーを設定する代わりに、開発者は size: small と backup: daily を指定するだけです。プラットフォームが残りを処理します。
レイヤー3：CI/CD の標準化
各チームが独自のパイプラインを構築しなくて済むよう、CI/CD を標準化します。
# .github/workflows/platform-ci.yml # Teams just include the shared workflow name: Build and Deploy on: push: branches: [main] jobs: pipeline: uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2 with: language: node deploy-target: production secrets: inherit
主要なプラクティス：
- チームがインクルード（コピーではなく）する共有 CI/CD テンプレート
- 自動セキュリティスキャン（SAST、依存関係監査）
- 標準化されたデプロイメント戦略（カナリア、ブルー/グリーン）
- ヘルスチェック失敗時の自動ロールバック
レイヤー4：オブザーバビリティ
事前設定されたモニタリングにより、開発者はすぐに使えるダッシュボードとアラートを取得できます。
- メトリクス：Prometheus + Grafana、サービスごとの標準ダッシュボード
- ロギング：集中収集による構造化ロギング（Loki、ELK）
- トレーシング：OpenTelemetry による分散トレーシング
- アラート：合理的なデフォルトによる PagerDuty/Opsgenie 連携
成功の測定
プラットフォームが機能しているかどうかをどう判断しますか？以下のメトリクスを追跡しましょう：
DORA メトリクス
- デプロイ頻度：コードが本番環境に到達する頻度
- 変更のリードタイム：コミットから本番環境までの時間
- 変更失敗率：障害を引き起こすデプロイメントの割合
- 平均復旧時間：インシデント後にサービスを復旧するまでの時間
プラットフォーム固有のメトリクス
- 初回デプロイまでの時間：「新しいサービス」から最初の本番デプロイまでの所要時間
- 開発者満足度（NPS）：ユーザーに定期的にアンケート
- セルフサービス率：チケットなしで処理されるインフラリクエストの割合
- ゴールデンパス採用率：推奨パスに従うサービスの割合
よくある間違い
1. 早すぎる段階で作りすぎる
壮大なビジョンではなく、最大のペインポイントから始めましょう。デプロイメントが苦痛なら、そこから始めます。プロビジョニングに数週間かかるなら、そこから始めます。
2. プラットフォームをプロダクトとして扱わない
プラットフォームチームにはプロダクトマネージャー、ユーザーリサーチ、フィードバックループが必要です。開発者はあなたの顧客です - - 彼らのニーズを理解しましょう。
3. 引き付けるのではなく強制する
最良のプラットフォームは、開発者の生活を楽にするため自発的に採用されます。使用を強制しなければならないなら、プラットフォームが十分に良くないということです。
4. 開発者体験を無視する
UX がひどいプラットフォームは使われません。明確なドキュメント、役立つエラーメッセージ、迅速なフィードバックループに投資しましょう。
はじめに
最初の IDP を構築するための実践的なロードマップ：
最小限の実用的なプラットフォーム
- サービスカタログ（Backstage） - - 何が存在し、誰がオーナーかを把握
- 1つのサービステンプレート - - 最も一般的なサービスタイプのゴールデンパス
- 標準化された CI/CD - - チームがインクルードする共有パイプライン
- 基本的なドキュメント - - プラットフォームの使い方、ヘルプの入手先
この MVP は 2-3 名のエンジニアチームで 2-3 か月で構築できます。
まとめ
Platform Engineering は初日から完璧なプラットフォームを構築することではありません。開発者の認知負荷を段階的に軽減し、プロダクト構築に集中できるようにすることです。小さく始め、影響を測定し、開発者のフィードバックに基づいて反復しましょう。
Platform Engineering に投資する組織は、大きな競争優位性を持つことになります：より速いデリバリー、より幸せな開発者、そしてより信頼性の高いシステム。
リソース：
- Team Topologies - - プラットフォームチームを普及させた書籍
- Backstage - - Spotify のオープンソース開発者ポータル
- CNCF Platforms White Paper - - コミュニティによる定義とベストプラクティス
- platformengineering.org - - コミュニティ、イベント、リソース