platform-engineering

プラットフォームエンジニアリング

目的

セルフサービス型のインフラストラクチャを提供し、認知負荷を軽減し、ゴールデンパスと「プロダクトとしてのプラットフォーム」の考え方を通じて、開発者の生産性を高める内部開発者プラットフォーム（IDP）を構築します。

プラットフォームエンジニアリングは、従来のDevOpsから発展したもので、開発者を顧客として捉え、プロダクト品質の社内プラットフォームの構築に重点を置いています。この分野は、エンジニアが機能の開発ではなく、インフラストラクチャやツールに時間の30～40％を費やしているという、開発者の生産性の危機に対処します。

このスキルを使用する場面

以下の場合に、このスキルを使用します：

• 内部開発者プラットフォームの構築または改善
• 開発者ポータル（Backstage、Port、または商用IDP）の設計
• ゴールデンパスとソフトウェアテンプレートの導入
• プラットフォームエンジニアリングチームの立ち上げまたは再編
• 開発者エクスペリエンス（DevEx）の測定と改善
• IDPとインフラストラクチャ、CI/CD、オブザーバビリティ、またはセキュリティツールの統合
• エンジニアリング組織全体でのプラットフォーム導入の推進
• プラットフォームの成熟度評価と機能ギャップの特定

コアコンセプト

プロダクトとしてのプラットフォーム

顧客向けプロダクトと同じ厳密さで、社内プラットフォームを扱います：

プロダクトマネジメントのアプローチ：

• プラットフォームのビジョン、戦略、ロードマップを定義する
• 開発者という「顧客」と、その課題を特定する
• 導入指標、満足度調査、ビジネスへの影響を通じて成功を測定する
• フィードバックループと利用状況の分析に基づいて反復する
• 新機能とプラットフォームの信頼性およびサポートのバランスを取る

従来のDevOpsとの主な違い：

• DevOpsはデリバリーパイプラインに重点を置きますが、プラットフォームエンジニアリングは包括的な開発者エクスペリエンスを構築します
• プラットフォームチームはプロダクトチームとして活動します（プロダクトマネージャー、UXデザイナー、エンジニア）
• 成功はインフラストラクチャの指標だけでなく、開発者の生産性と満足度で測定します
• チケットキューではなく、セルフサービスを主要なインターフェースとします

内部開発者プラットフォーム（IDP）のアーキテクチャ

3層アーキテクチャ：

1. 開発者ポータル（フロントエンド）

• サービスカタログ：所有者、依存関係、健全性ステータスを含むサービスの一覧
• ソフトウェアテンプレート：ベストプラクティスを組み込んだプロジェクトのひな形
• ドキュメントハブ：一元管理され、検索可能で、バージョン管理されたドキュメント
• セルフサービスワークフロー：環境のプロビジョニング、デプロイ、アクセス要求

2. プラットフォームオーケストレーション（バックエンド）

• インフラストラクチャのプロビジョニング：マルチクラウドリソースの管理
• 環境管理：開発、ステージング、本番環境のライフサイクル
• デプロイの自動化：GitOpsベースの継続的デリバリー
• 構成管理：アプリケーションとインフラストラクチャの関心事の分離

3. 統合レイヤー（連携）

• CI/CD統合：パイプラインの可視化と実行
• オブザーバビリティ：メトリクス、ログ、トレースをポータルに表示
• セキュリティ：脆弱性スキャン、ポリシー適用、シークレット管理
• FinOps：コストの可視化、予算、最適化の推奨事項

詳しいアーキテクチャパターンとコンポーネントの内訳については、references/idp-architecture.mdを参照してください。

ゴールデンパスとひな形

ゴールデンパスの原則： ユースケースの80％に対応する、特定の方法を推奨するテンプレートを提供し、残りの20％には別の方法を選択できる余地を残します。

テンプレートの構成要素：

• リポジトリ構造とボイラープレートコード
• Infrastructure as Code（Kubernetesマニフェスト、Terraform）
• CI/CDパイプラインの構成
• オブザーバビリティの計測（メトリクス、ロギング、トレーシング）
• セキュリティ構成（RBAC、ネットワークポリシー、シークレット）
• ドキュメントテンプレート（README、ランブック、アーキテクチャ図）

制約の適用方法：

• セキュリティとコンプライアンスのためのPolicy-as-code適用（OPA、Kyverno）
• 過剰なプロビジョニングを防ぐリソース制限とクォータ
• 必須のヘルスチェックとオブザーバビリティの計測
• 承認済みのベースイメージと依存関係のスキャン

テンプレート設計のパターンと例については、references/golden-paths.mdを参照してください。

開発者エクスペリエンス（DevEx）の最適化

認知負荷の軽減：

• 必要な詳細を隠さずに、インフラストラクチャの複雑さを抽象化します
• 妥当なデフォルトを用意し、明確な上書き方法を提供します
• 段階的開示を活用します（一般的なケースはシンプルにし、高度なオプションも利用できるようにします）
• ツールを統合します（個別のツールを15個以上使う代わりに、単一の開発者ポータルを使用します）

主な指標：

DORA 指標：

• デプロイ頻度（コードが本番環境に到達する頻度）
• 変更のリードタイム（コミットから本番環境への反映までの時間）
• 平均復旧時間（インシデントの MTTR）
• 変更失敗率（インシデントを引き起こすデプロイの割合）

SPACE フレームワーク：

• 満足度：アンケートや NPS による開発者の満足度
• パフォーマンス：完了した作業の処理量と効率
• 活動：コードのコミット、PR、デプロイ（単純な件数ではなく、状況を考慮します）
• コミュニケーション：コラボレーションの質、発見しやすさ
• 効率性：中断を最小限に抑え、雑務を減らします

プラットフォーム固有の指標：

• プラットフォーム導入率（プラットフォームを利用しているチームの割合）
• セルフサービス率（プラットフォームチームへのチケットなしで完了した操作の割合）
• オンボーディング時間（新しい開発者が初めて本番環境にデプロイするまでの時間）
• テンプレートの利用状況（どのゴールデンパスが採用されているか）
• サポートチケットの件数と解決時間

プラットフォーム成熟度の評価

5段階の成熟度モデルを使用して、現在のプラットフォーム機能を評価します。

レベル 0：アドホック - 手動でのプロビジョニング、標準化なし レベル 1：基本的な自動化 - 一部の IaC と CI/CD、セルフサービスは限定的 レベル 2：整備されたパス - ゴールデンパステンプレート、初期段階のポータル、対応範囲は限定的 レベル 3：セルフサービスプラットフォーム - 包括的なポータル、セルフサービス率 80% 以上 レベル 4：プロダクト主導のプラットフォーム - データ駆動型、プロダクトチーム体制、FinOps の統合 レベル 5：AI 拡張プラットフォーム - AI によるトラブルシューティング支援、予測的な最適化

詳細な評価フレームワーク、ギャップ分析、改善ロードマップについては、references/maturity-model.md を参照してください。

意思決定フレームワーク

IDP の構築と購入の比較

オープンソース（Backstage）を選ぶ場合：

• 大規模な企業（エンジニアが 1000 人以上）
• 専任のプラットフォームチームを確保できる（エンジニアが 5～10 人）
• 高度なカスタマイズが必要
• オープンソースのエコシステムを優先する
• 長期的な投資（3 年以上の計画）

商用 IDP（Port、Humanitec、Cortex）を選ぶ場合：

• 中規模の組織（エンジニアが 100～1000 人）
• より短期間で価値を実現する必要がある（6～12 か月ではなく 3～6 か月）
• ベンダーサポート付きのマネージドソリューションを希望する
• プラットフォームエンジニアリングのリソースが限られている（エンジニアが 5 人未満）
• 標準的なユースケース（Web アプリ、マイクロサービス、CI/CD）

ハイブリッドアプローチを選ぶ場合：

• 柔軟性とスピードの両方を必要とする大規模な組織
• オーケストレーションバックエンドを必要とする複雑なインフラストラクチャ
• クラス最高のポータルとオーケストレーションコンポーネントを組み合わせたい
• 複数のシステムを統合できる（例：Backstage + Humanitec）

意思決定ツリー、選定基準、ROI 計算の全容については、references/decision-frameworks.md を参照してください。

ゴールデンパスの設計：柔軟性と標準化のバランス

制御の度合い：

高度な標準化（規制の厳しい業界）：

• 選択できるテクノロジーを制限し、テンプレートの使用を必須にする
• アドミッションコントローラー（OPA、Kyverno）を通じてポリシーを適用する
• 例外の適用には承認プロセスを必須とする

バランスの取れたアプローチ（多くの組織に推奨）：

• 推奨されるゴールデンパス（使いやすく、十分に文書化され、サポートされている）
• 代替手段はドキュメントを用意すれば利用可能
• 穏やかな適用（デフォルト設定と教育を利用し、厳しい制限は設けない）
• 逸脱する場合の明確な責任体制（「逸脱するなら、責任を持つ」）

高い柔軟性（イノベーションを重視する組織）：

• ゴールデンパスは要件ではなく提案として扱う
• ポリシーの適用は最小限にする（重要なセキュリティ対策のみ）
• 「構築した者が運用する」という責任体制

適切なバランスと適用戦略の選び方について詳しくは、references/decision-frameworks.md を参照してください。

プラットフォームチームの構成

集中型モデル：

• 組織全体にサービスを提供する単一のプラットフォームチーム（エンジニア5～20名）
• 適している組織：小規模から中規模の組織（エンジニア100～500名）

連邦型モデル：

• 中央チーム（エンジニア5～10名）＋各事業部門に配置されたエンジニア（各1～2名）
• 適している組織：大規模な組織（エンジニア500～2000名以上）、複数の事業部門がある組織

ハブ・アンド・スポーク型モデル：

• 中央の「ハブ」チーム（エンジニア3～5名）＋プラグインの開発に参加する「スポーク」チーム
• 適している組織：オープンソース文化が根付いている組織

チームの規模、役割、責任、ガバナンスモデルについては、references/decision-frameworks.md を参照してください。

ツールのおすすめ

開発者ポータル

Backstage（オープンソース、CNCF）

• 信頼スコア：78.7/100、コードスニペット8,876件
• ソフトウェアカタログ、スキャフォルダー、TechDocs、プラグインエコシステム
• おすすめの対象：プラットフォームチームを持つエンタープライズ

Port（商用）

• マネージドプラットフォーム、モダンなUI/UX、価値実現までの時間を短縮
• おすすめの対象：中規模の組織（エンジニア100～1000名）

Cortex（商用SaaS）

• エンタープライズIDP、コンプライアンスを重視、エンジニアリング標準の徹底
• おすすめの対象：規制対象業界

プラットフォームオーケストレーション

Crossplane（オープンソース、CNCF）

• 信頼スコア：67.4/100、マルチクラウド向けのユニバーサルコントロールプレーン
• Kubernetesネイティブの宣言型インフラストラクチャ
• おすすめの対象：マルチクラウドの抽象化

Humanitec（商用）

• プラットフォームオーケストレーターのバックエンド、環境とデプロイの管理
• おすすめの対象：複雑なインフラストラクチャ。ポータルを補完します

Terraform Cloud（商用）

• 成熟したIaCオーケストレーション、ワークスペース管理
• おすすめの対象：Terraformを多用する組織

GitOps継続的デリバリー

Argo CD（オープンソース、CNCF） - おすすめ

• 信頼スコア：91.8/100（最高）
• Kubernetes向けの宣言型GitOps、マルチクラスター管理
• 業界をリードするドキュメントとコミュニティ

Flux（オープンソース、CNCF）

• ツールキット方式、Kubernetesネイティブ
• 適している用途：GitOpsネイティブな運用

ツールの詳細な比較、統合パターン、選定基準については、references/tool-recommendations.md を参照してください。

実装ガイド

プラットフォームの立ち上げ

基盤フェーズ（1～3か月目）：

1. プラットフォームのビジョンを定義し、プラットフォームチーム（メンバー3～5名）を編成する
2. 開発者に聞き取りを行い、課題を特定する
3. 開発者ポータル（Backstageまたは商用製品）をセットアップする
4. 初期サービスカタログと最初のゴールデンパステンプレートを作成する

パイロットフェーズ（4～6か月目）：

1. 手厚いオンボーディングを行うパイロットチームを2～3チーム選定する
2. フィードバックに基づいて迅速に反復する
3. ゴールデンパステンプレートを3～5種類に拡充する
4. 主要なツール（CI/CD、モニタリング、シークレット）を統合する

拡大フェーズ（7～12か月目）：

1. エンジニアリングチームの20～50％に展開する
2. セルフサービスのドキュメントとトレーニングを整備する
3. プラットフォームのSLOとオンコールローテーションを確立する
4. 社内で普及を促進する（デモ、推進者プログラム）

成熟フェーズ（2年目以降）：

1. 組織全体で80％以上の導入を達成する
2. プラットフォームチームをプロダクトチームとして運営する
3. 指標とフィードバックを通じて継続的に改善する
4. AI支援機能、Policy as Codeの拡充

詳細な実装手順と立ち上げ用コードについては、references/implementation-backstage.md を参照してください。

ゴールデンパステンプレートの作成

テンプレート設計プロセス：

1. 最も一般的なユースケース（Webアプリ、API、データパイプライン）を特定する
2. 推奨する選択肢（言語、フレームワーク、デプロイパターン）を定義する
3. リポジトリ構成とインフラストラクチャマニフェストを作成する
4. セキュリティスキャンを組み込んだCI/CDパイプラインを設定する
5. オブザーバビリティを組み込み、使い方を文書化する
6. 広範囲に展開する前に、パイロットチームでテストする

テンプレートのカテゴリ：

• フルスタックWebアプリケーション（バックエンドAPI＋フロントエンド＋データベース）
• データパイプライン（オーケストレーションを伴うETL/ELT）
• 機械学習サービス（モデルサービング、モニタリング）
• イベント駆動型マイクロサービス（メッセージブローカーとの統合）
• スケジュールジョブ（cronジョブ、バッチ処理）

テンプレートの例、スキャフォールディングコード、カスタマイズパターンについては、references/golden-paths.md と examples/ ディレクトリを参照してください。

プラットフォームの導入を促進する

普及戦略：

• パイロットチームの成功事例を紹介します（社内ブログ記事、デモ）
• プラットフォームの機能に関するランチ＆ラーンを開催します
• 社内チャンピオンプログラムを実施します（パワーユーザーが同僚を支援）
• オフィスアワーやSlack/Teamsのサポートチャンネルを設けます

インセンティブの整合：

• プラットフォームを代替手段より使いやすくします（ゴールデンパスは「舗装された道」です）
• 開発者がすでに使っているワークフローに統合します
• すぐに価値を得られるようにします（オンボーディングの迅速化、可視性の向上）
• 早期導入者を称え、その成功事例を紹介します

導入指標、追跡用ダッシュボード、成功パターンについては、references/maturity-model.md を参照してください。

クイックリファレンス

プラットフォームエンジニアリングのチェックリスト

戦略とビジョン：

• プラットフォームのビジョンと憲章を文書化済み
• 明確な役割を定めたプラットフォームチームを編成済み
• インタビューを通じて開発者の課題を特定済み
• 成功指標を定義済み（DORA、SPACE、導入状況）

IDP の基盤：

• 開発者ポータルを導入済み（Backstage、Port、または商用製品）
• サービスカタログを整備済み（所有者、依存関係、健全性）
• 最初のゴールデンパステンプレートを作成し、検証済み
• すべてのエンジニアが利用できるドキュメントハブを用意済み

セルフサービス機能：

• 環境のプロビジョニング（開発、ステージング、本番）
• デプロイの自動化（Argo CD または Flux による GitOps）
• CI/CD との連携状況をポータルで確認可能
• サービスごとのオブザーバビリティダッシュボード

セキュリティとコンプライアンス：

• Policy-as-code による適用（OPA、Kyverno）
• シークレット管理を統合済み（Vault、クラウドプロバイダー）
• パイプラインに脆弱性スキャンを導入済み
• RBAC とアクセス制御を設定済み

運用とサポート：

• プラットフォームの SLO を定義し、監視中
• サポートチャンネルを整備済み（Slack、オフィスアワー）
• インシデント対応プレイブックを文書化済み
• フィードバックループと利用状況分析を導入済み

よくある落とし穴

最初から作り込みすぎる：

• 小さく始め（ゴールデンパス1つ、パイロットチーム）、反復します
• 「海を沸かす」症候群を避けます

開発者のフィードバックを無視する：

• 四半期ごとのアンケートだけでなく、継続的なフィードバックループを確立します

標準化しすぎる：

• 高度なユースケース向けに、明確な回避策を用意します

成功の測定が不十分：

• DORA 指標、満足度調査、セルフサービス率を追跡します

プラットフォームを IT プロジェクトとして扱う：

• プラットフォームエンジニアリングはインフラストラクチャのプロビジョニングではなく、プロダクト開発です
• プロダクトマネージャー、UX デザイナー、顧客重視の姿勢が必要です

他のスキルとの連携

関連スキル：

• kubernetes-operations：クラスター運用、名前空間管理、RBAC、ネットワークポリシー
• infrastructure-as-code：プラットフォームと連携したインフラストラクチャのプロビジョニングのための Terraform、Pulumi
• gitops-workflows：GitOps の原則、Argo CD / Flux の実装パターン
• building-ci-pipelines：プラットフォームテンプレートに統合する CI/CD パイプラインの設計
• security-hardening：ゴールデンパスを通じて適用するセキュリティのベストプラクティス
• secret-management：プラットフォームに統合するシークレット管理（Vault、クラウドプロバイダー）
• observability：開発者ポータルに統合する監視、ロギング、トレーシング

スキル横断ワークフロー：

プラットフォームのブートストラップ：

1. infrastructure-as-code を使用してプラットフォームのインフラストラクチャをプロビジョニングします
2. kubernetes-operations を使用してクラスターを設定します
3. プラットフォームのインフラストラクチャ上に開発者ポータル（Backstage）をデプロイします
4. gitops-workflows（Argo CD）を統合して継続的デリバリーを実現します
5. observability の統合（Prometheus、Grafana プラグイン）を追加します

ゴールデンパスの作成：

1. 一般的なユースケースに基づいてテンプレートを設計します
2. CI/CD 設定に building-ci-pipelines のパターンを使用します
3. security-hardening のベストプラクティス（SAST、コンテナースキャン）を適用します
4. secret-management（Vault、暗号化された設定）を統合します
5. observability の計装（メトリクス、ロギング、トレーシング）を追加します

ユースケースの例

ユースケース 1：E コマースプラットフォームチーム

コンテキスト： マイクロサービスアーキテクチャを採用する従業員 300 人の E コマース企業で、手動プロビジョニングがボトルネックになっています。

アプローチ： Backstage を導入し、3 つのゴールデンパスを作成して Argo CD と統合します。3 チームで試験導入し、6 か月かけて 20 チームに拡大します。

結果： オンボーディング期間が 2 日から 2 時間に短縮、デプロイ頻度が週 2 回から 1 日 10 回に増加、開発者 NPS が 35 ポイント向上しました。

ユースケース 2：金融サービスプラットフォーム

コンテキスト： 厳格なコンプライアンス要件、レガシーインフラ、ツールの分断を抱える従業員 1,500 人の銀行です。

アプローチ： Port（商用版）を採用し、高度に標準化されたゴールデンパス、OPA Gatekeeper、フェデレーションモデル、Terraform Cloud を導入します。

結果： コンプライアンス監査の準備期間が 3 週間から 3 日に短縮、インフラのドリフトに起因するインシデントが 90％減少し、サービスごとのコスト配賦が可能になりました。

ユースケース 3：スタートアップのプラットフォーム

コンテキスト： 急成長中で、開発者のオンボーディングを迅速化する必要がある従業員 50 人のスタートアップです。

アプローチ： 軽量な Backstage を導入（エンジニア 2 人）、2 つのゴールデンパス、GitHub Actions、PaaS インフラ（Fly.io）を活用し、ドキュメントに重点を置きます。

結果： 新しいエンジニアが 1 日で本番環境に到達（従来は 2 週間）、100％のセルフサービスを実現し、エンジニア 2 人で開発者 50 人をサポートしています。

コード例とテンプレート構成については、examples/ ディレクトリを参照してください。