ストーリー
田
田中VPoE
DevExの評価方法とサーベイ設計を学んだ。ここからはPlatform Engineeringの設計原則だ。プラットフォームを作る際の「べし・べからず」を押さえておこう
あなた
原則というと、具体的にはどういうものですか？
あ
田
田中VPoE
「Thinnest Viable Platform（最も薄い実用的なプラットフォーム）」「Paved Road（舗装された道）」「Opt-in, Not Mandated（強制ではなく選択）」。プラットフォームは押し付けではなく、開発者が「使いたい」と思うものでなければならない
あなた
使わされるのではなく、使いたくなる。プロダクト設計の考え方ですね
あ
田
田中VPoE
そうだ。社内プラットフォームが失敗する最大の原因は「技術者が技術者のために作った、使いにくいツール」だ。プロダクトマネジメントの手法を適用して、ユーザー（開発者）中心に設計する
Platform Engineeringの7原則
原則一覧
| # | 原則 | 概要 |
|---|---|---|
| 1 | Thinnest Viable Platform | 最小限の機能から始め、フィードバックを受けて拡張する |
| 2 | Paved Road / Golden Path | 推奨パスを用意し、「正しいことが簡単なこと」を実現する |
| 3 | Opt-in, Not Mandated | 強制ではなく、価値で選ばれるプラットフォームを目指す |
| 4 | Self-Service First | 開発者がチケットなしで操作を完了できる |
| 5 | API-First | すべてのプラットフォーム機能をAPIとして提供する |
| 6 | Documentation as Code | ドキュメントをコードと同様にバージョン管理する |
| 7 | Measure and Iterate | メトリクスに基づいて継続的に改善する |
原則1: Thinnest Viable Platform（TVP）
TVP のアプローチ:
Phase 1（MVP）:
├── サービステンプレート（1種類）
├── CI/CDパイプライン自動生成
└── 基本的なモニタリング設定
Phase 2（拡張）:
├── テンプレートの追加（3-5種類）
├── セルフサービスDB作成
└── サービスカタログ
Phase 3（成熟）:
├── Internal Developer Portal
├── コスト可視化
└── セキュリティ自動チェック
アンチパターン:
× 最初から全機能を作り込む（2年間の開発期間）
× 使われない機能を大量に実装する
× フィードバックなしで機能追加する「最初の3ヶ月で100%を目指すな。3つの機能を完璧に仕上げろ。それが使われたら次の3つを作る」 — 田中VPoE
原則2: Golden Path
| 概念 | 説明 |
|---|---|
| Golden Path | プラットフォームが推奨する標準的な方法 |
| Off-Road | Golden Pathから外れた独自の方法 |
| ガードレール | Golden Pathを外れても安全が保たれる仕組み |
Golden Pathの例:
新規マイクロサービスの作成:
Golden Path（推奨）:
1. Backstageでテンプレートを選択
2. パラメータを入力（サービス名、チーム名等）
3. 自動生成（リポジトリ、CI/CD、モニタリング、Kubernetesマニフェスト）
4. 5分で開発開始
Off-Road（許可されているが非推奨）:
1. 手動でリポジトリ作成
2. CI/CDを手動設定
3. Kubernetesマニフェストを手書き
4. 2-3日で開発開始
差分: Golden Pathを使えば 5分 vs 2-3日原則3: Opt-in, Not Mandated
| アプローチ | 結果 |
|---|---|
| 強制（使え） | 初期は100%採用だが、不満が溜まりシャドーITが発生 |
| 放置（好きにしろ） | バラバラの手法が乱立し、メンテコスト増大 |
| 価値提供（使いたくなる） | 価値を認めた開発者から自然に採用が広がる |
採用の段階:
イノベーター（5%）:
プラットフォームチームと一緒に初期版を試す
アーリーアダプター（15%）:
成功事例を見て自主的に採用
アーリーマジョリティ（35%）:
周りのチームが使い始めて「自分たちも」と採用
レイトマジョリティ（35%）:
Golden Pathが事実上の標準になり採用
ラガード（10%）:
特殊な要件があり別のアプローチを継続（許容する）原則4-7: 実践的な適用
| 原則 | 実践 | アンチパターン |
|---|---|---|
| Self-Service First | Webポータル・CLI・APIで操作可能 | すべてチケット経由 |
| API-First | REST/gRPC APIを先に設計、UIは後から | UIだけ作ってAPIなし |
| Documentation as Code | ADR、API仕様書をリポジトリで管理 | Confluenceに書いて放置 |
| Measure and Iterate | 採用率、満足度を四半期測定 | 作って終わり、改善なし |
プラットフォームの成功と失敗
失敗パターン
| 失敗パターン | 原因 | 結果 |
|---|---|---|
| ビルド・アンド・プレイ | 開発者のフィードバックなしで構築 | 誰も使わないプラットフォーム |
| キッチンシンク | 全機能を最初から詰め込む | 複雑すぎて学習コストが高い |
| マンデート | 使用を強制する | 表面的な採用と内部の反発 |
| テック・ファースト | 技術選定から始める | ユーザーの課題を解決しない |
| メンテナンス放棄 | 構築後の改善投資なし | 陳腐化して使われなくなる |
成功パターン
| 成功パターン | 方法 | 効果 |
|---|---|---|
| ユーザーリサーチ先行 | サーベイとインタビューから開始 | 本当の課題を解決する |
| MVP + イテレーション | 最小限から始めて段階的に拡張 | 投資リスクの最小化 |
| エバンジェリズム | 成功事例を社内で共有 | 自然な採用拡大 |
| プロダクトマネジメント | ロードマップ、バックログ、リリースサイクル | 持続的な改善 |
まとめ
| ポイント | 内容 |
|---|---|
| 7原則 | TVP、Golden Path、Opt-in、Self-Service、API-First、Docs as Code、Measure |
| TVP | 最小限の機能から始め、フィードバックを受けて拡張する |
| Golden Path | 「正しいことが簡単なこと」を実現する推奨パス |
| 成功の鍵 | プロダクトマネジメントの手法を適用し、開発者中心に設計する |
チェックリスト
- Platform Engineeringの7原則を説明できる
- TVPのアプローチを理解した
- Golden PathとOff-Roadの違いを説明できる
- プラットフォームの成功・失敗パターンを理解した
次のステップへ
次は演習です。実際の組織シナリオを使って、開発者体験の現状分析を実施しましょう。
推定読了時間: 30分