LESSON 40分

ストーリー

佐藤CTO
“自分でKubernetesのyamlを書きたい開発者”はいないよね?

佐藤CTOの問いに、あなたは苦笑いしました。

佐藤CTO
でも現実には、多くの組織で開発者がインフラの設定に時間を費やしている。アプリケーション開発者が本業に集中できる環境を作る — それがプラットフォームエンジニアリングの目的だ
あなた
DevOpsとは違うんですか?
佐藤CTO
DevOpsは”文化と責任の共有”、プラットフォームエンジニアリングは”開発者にセルフサービスのツールと基盤を提供する”。DevOpsの理念をプロダクト化したものと考えるといい

Internal Developer Platform(IDP)

IDPとは

項目内容
定義開発者がセルフサービスでアプリケーションの構築・デプロイ・運用を行える内部プラットフォーム
目的開発者の認知負荷を軽減し、生産性を向上させる
提供者プラットフォームチーム
利用者ストリームアラインドチームの開発者

IDPの構成要素

graph TD
    IDP["Internal Developer Platform"]

    IDP --> DP["Developer Portal
(Backstage等)"] DP --> DP1["サービスカタログ"] DP --> DP2["APIドキュメント"] DP --> DP3["テンプレート(Scaffolding)"] DP --> DP4["テックドキュメント"] IDP --> IA["Infrastructure Abstraction"] IA --> IA1["Kubernetes as a Service"] IA --> IA2["データベース Provisioning"] IA --> IA3["メッセージキュー Provisioning"] IA --> IA4["シークレット管理"] IDP --> CI["CI/CD Platform"] CI --> CI1["パイプラインテンプレート"] CI --> CI2["自動テスト基盤"] CI --> CI3["セキュリティスキャン"] CI --> CI4["デプロイ自動化"] IDP --> OB["Observability Platform"] OB --> OB1["ログ集約"] OB --> OB2["メトリクス収集"] OB --> OB3["分散トレーシング"] OB --> OB4["アラート管理"] IDP --> SC["Security & Compliance"] SC --> SC1["ID管理・認証基盤"] SC --> SC2["ポリシー自動適用"] SC --> SC3["監査ログ"] style IDP fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af style DP fill:#d1fae5,stroke:#059669,color:#065f46 style IA fill:#d1fae5,stroke:#059669,color:#065f46 style CI fill:#d1fae5,stroke:#059669,color:#065f46 style OB fill:#d1fae5,stroke:#059669,color:#065f46 style SC fill:#d1fae5,stroke:#059669,color:#065f46 style DP1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style DP2 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style DP3 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style DP4 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style IA1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style IA2 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style IA3 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style IA4 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style CI1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style CI2 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style CI3 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style CI4 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style OB1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style OB2 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style OB3 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style OB4 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style SC1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style SC2 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style SC3 fill:#f3f4f6,stroke:#9ca3af,color:#374151

セルフサービスの原則

5つのレベル

レベル内容
L1: ドキュメント手順書を提供「DBを作るにはこの手順を実行」
L2: テンプレート設定テンプレートを提供Terraform モジュール、Helm Chart
L3: CLI/APIコマンドで操作可能platform db create --type postgres
L4: UIポータルGUIで操作可能Backstage のフォーム入力
L5: 宣言的意図を宣言するだけI need a database → 自動プロビジョニング

「目指すべきはL3〜L4だ。L5は理想だが、現実にはまだ遠い組織が多い。**チケットを切ってプラットフォームチームに依頼する(L0)**の状態から、少しずつレベルを上げていく」 — 佐藤CTO


ゴールデンパス(Golden Path)

概念

ゴールデンパスとは、組織が推奨する「最も効率的で安全な開発パス」です。

golden_path_example:
  new_microservice:
    step1: "Backstageのテンプレートから新規サービスを作成"
    step2: "GitHubリポジトリが自動生成(CI/CD設定済み)"
    step3: "Kubernetes Namespace が自動プロビジョニング"
    step4: "監視ダッシュボードが自動作成"
    step5: "コードを書いてPushすればデプロイ完了"
    total_time: "30分で本番デプロイ可能な状態に"

  without_golden_path:
    step1: "インフラチームにチケットを起票"
    step2: "1週間待ってリポジトリ作成"
    step3: "CI/CD設定を手動で作成"
    step4: "インフラチームにK8s設定を依頼"
    step5: "監視設定を手動で追加"
    total_time: "2-3週間"

ゴールデンパスの原則

原則説明
推奨であり強制ではないパスを外れることも可能(ただし自己責任)
デフォルトが安全セキュリティ、監視がデフォルトで組み込まれている
段階的に拡張一度にすべてを作らず、需要の高いものから
フィードバック駆動利用チームの声を元に改善し続ける

Backstage(Spotifyの開発者ポータル)

概要

Backstage は Spotify が開発し、CNCFに寄贈した開発者ポータルフレームワークです。

backstage_features:
  software_catalog:
    description: "全サービス・ライブラリのカタログ"
    includes:
      - "オーナーチーム"
      - "依存関係"
      - "APIドキュメント"
      - "ヘルスステータス"

  software_templates:
    description: "新サービスのスキャフォールディング"
    includes:
      - "言語・フレームワーク選択"
      - "CI/CD自動設定"
      - "監視自動設定"
      - "セキュリティ設定"

  techdocs:
    description: "技術ドキュメントの統合管理"
    approach: "Docs as Code(Markdownから自動生成)"

  plugins:
    description: "200以上のプラグインで拡張可能"
    examples:
      - "Kubernetes プラグイン"
      - "GitHub Actions プラグイン"
      - "PagerDuty プラグイン"
      - "Cost Insights プラグイン"
Backstage導入のロードマップ
フェーズ期間内容
Phase 02週間Backstage環境構築、基本セットアップ
Phase 11ヶ月ソフトウェアカタログ(既存サービスの登録)
Phase 22ヶ月テンプレート作成(主要言語2-3種類)
Phase 33ヶ月TechDocs統合、プラグイン導入
Phase 4継続フィードバックベースの改善

プラットフォームをプロダクトとして扱う

プロダクトマネジメントの適用

graph TD
    PM["プロダクトマネジメント手法
顧客 = 社内の開発者"] PM --> UR["ユーザーリサーチ"] UR --> UR1["開発者へのインタビュー、サーベイ"] PM --> RM["ロードマップ"] RM --> RM1["四半期ごとの機能計画"] PM --> MT["メトリクス"] MT --> MT1["利用率、満足度、セルフサービス率"] PM --> DOC["ドキュメント"] DOC --> DOC1["Getting Started、APIリファレンス"] PM --> SP["サポート"] SP --> SP1["Slackチャンネル、オフィスアワー"] style PM fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af style UR fill:#d1fae5,stroke:#059669,color:#065f46 style RM fill:#d1fae5,stroke:#059669,color:#065f46 style MT fill:#d1fae5,stroke:#059669,color:#065f46 style DOC fill:#d1fae5,stroke:#059669,color:#065f46 style SP fill:#d1fae5,stroke:#059669,color:#065f46 style UR1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style RM1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style MT1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style DOC1 fill:#f3f4f6,stroke:#9ca3af,color:#374151 style SP1 fill:#f3f4f6,stroke:#9ca3af,color:#374151

成功指標

指標計算方法目標
セルフサービス率セルフサービスリクエスト / 全リクエスト> 80%
開発者満足度(NPS)四半期サーベイ> 50
新サービス立ち上げ時間テンプレート選択からデプロイまで< 1時間
チケット削減率プラットフォームチームへのチケット数の推移四半期で20%減

まとめ

ポイント内容
IDP開発者がセルフサービスで開発・デプロイ・運用できる基盤
ゴールデンパス推奨される効率的で安全な開発パス
BackstageSpotify発の開発者ポータルフレームワーク
プロダクト思考プラットフォームを内部プロダクトとして運営する

チェックリスト

  • IDPの構成要素を理解した
  • セルフサービスの5レベルを把握した
  • ゴールデンパスの概念と原則を理解した
  • プラットフォームのプロダクトマネジメントを理解した

次のステップへ

次は「デベロッパーエクスペリエンス(DX)」を学びます。プラットフォームの先にある、開発者体験全体を設計する方法を見ていきましょう。


推定読了時間: 40分