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

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

プラットフォームエンジニアリングは、開発者の生産性を向上させる内部開発者プラットフォーム (IDP) を構築・運用する実践である。書籍『チームトポロジー』(Matthew Skelton、Manuel Pais 著) が示す 4 つの基本チーム型 (ストリームアラインド / イネイブリング / 複雑サブシステム / プラットフォーム) のうち、プラットフォームチームが担う領域にあたる。プラットフォームチームの役目は、ビジネス価値の流れに沿って動くストリームアラインドチームが使うサービスを用意し、複雑さを引き受けて開発の速度を上げることにある。なお略称の IDP は Internal Developer Platform を指し、認証の IdP (Identity Provider) とは別物なので文脈で読み分ける。

なぜ必要か

DevOps の普及により各チームがインフラを自前で管理するようになったが、チームごとに CI/CD やインフラ構成がバラバラになり、認知負荷が増大した。プラットフォームエンジニアリングは、共通基盤を専門チームが構築・提供することで、開発者がビジネスロジックに集中できる環境を実現する。

問題	プラットフォームで解決
各チームが CI/CD を個別に構築	共通の CI/CD テンプレート
インフラの知識が必要	セルフサービスでデプロイ
設定ミスによる障害	ガードレール付きのテンプレート
オンボーディングが遅い	標準化された開発環境

プラットフォームの構成要素

構成要素は「開発者が案件ごとに書き直さなくて済むもの」を切り出したものになる。最初から全部を揃える必要はなく、CI/CD テンプレートとインフラの雛形の 2 つから始め、監視とセキュリティを後から重ねる順序が現実的である。

要素	説明	AWS での実装
CI/CD	共通のパイプライン	GitHub Actions テンプレート
IaC テンプレート	標準化されたインフラ	SAM テンプレート
監視基盤	ダッシュボード、アラート	CloudWatch
セキュリティ	ポリシー、スキャン	IAM, WAF
ドキュメント	使い方ガイド	内部 Wiki

DevOps との関係

プラットフォームエンジニアリングは DevOps を否定するものではなく、DevOps の「作った者が運用する」原則を組織規模で維持するための手段である。チーム数が増えると、同じインフラ課題を各チームが個別に解き直す重複が生じる。その重複部分だけを専門チームが引き受けるのが分担の考え方になる。

観点	DevOps	プラットフォームエンジニアリング
対象	各チームが自分で運用	専門チームがプラットフォームを提供
スケール	チームごとに異なる	組織全体で標準化
認知負荷	高い (全員がインフラを理解)	低い (プラットフォームが抽象化)

ゴールデンパス

ゴールデンパスは、迷わず選べる既定の道を 1 本用意する考え方である。唯一の道として強制しない点が要点で、外れた道を選ぶ自由は残したまま、既定の道を通ったときだけ監視やセキュリティ設定が最初から付いてくる状態を作る。

プラットフォームが提供する「推奨される道」:
  1. リポジトリテンプレートを使って新規プロジェクト作成
  2. SAM テンプレートでインフラを定義
  3. GitHub Actions で自動デプロイ
  4. CloudWatch ダッシュボードが自動生成
→ 開発者はビジネスロジックに集中

プラットフォームの原則

プラットフォームは内部顧客 (開発者) のニーズに応えるプロダクトとして扱う。開発者が自分でデプロイできるセルフサービスを提供し、制約を設けつつ自由度を確保するガードレールを設計する。使い方を明確に文書化し、利用の障壁を下げる。

よくある失敗

失敗の大半は技術ではなく需要の側で起きる。利用者である開発者に相談せずに作った基盤は使われず、使わせるために利用を義務化すると、プラットフォームチームが承認の窓口に変わって短縮したはずのリードタイムが元へ戻る。健全さの目安は、利用が任意のままで採用率が伸びているか、そして新しいサービスを本番へ出すまでの日数が縮んでいるかの 2 点である。逆にチームが 2〜3 個の段階で専任チームを置くと、利用者より提供側の工数が多い状態になりやすい。まずは既存チームの誰かがテンプレートを整備する形で始め、同じ要望が複数チームから重複して挙がるようになった時点で専任化を検討する。