プラットフォームエンジニアリングとは？ 開発者のための社内基盤の考え方
要約
プラットフォームエンジニアリングとは、共通の開発基盤を専任チームが作り、運用する取り組みです。目的は待ち時間、チケット、覚えるべきツールを減らすことです。小規模な組織では不要な場合もあります。判断のシグナルと、最初の一歩も紹介します。
プラットフォームエンジニアリングとは、開発者が必要なものをセルフサービスで手に入れられるように、社内向けの基盤を作って運用する取り組みです。環境、パイプライン、サービスのひな形、ドキュメント、ガードレールがその対象になります。専任チームはこの基盤を一つの製品として扱い、社内の開発者を顧客とみなします。目指すのは、待ち時間、チケット、覚えるべきツールの数を減らすことです。
心当たりがあるはずです。新しいサービスを一つ作るだけで、リポジトリ、パイプライン、データベース、シークレット、ダッシュボード、オンコール当番が必要になります。それぞれが別のWikiページや、別の担当者とのSlackのやり取りの中に散らばっています。
なぜプラットフォームエンジニアリングが必要になったのか
「作った人が運用する」という考え方は、一つのチームが一つのサービスと数個のツールを持つ時代にはうまく機能しました。ツールチェーンが Kubernetes、Terraform、三つのCIシステム、シークレット管理、サービスメッシュ、監視基盤へと広がると、この考え方は回らなくなりました。すべての開発者が、いつの間にか一部インフラエンジニアを兼ねることになったのです。
そのコストは予算の一行としては見えてきません。見えるのは認知負荷です。どの Helm チャートが「正しい」のかを知るのに90分かかる開発者は、スキルが足りないのではありません。既定値（デフォルト）が用意されていないために遅くなっているのです。
プラットフォームエンジニアリングは、この状況への答えです。どのチームも同じスタックを一から組み立てるのではなく、専任チームが一度だけ組み立て、それを最も簡単な選択肢にして、健全な状態を保ちます。アナリストも同じ流れを指摘しています。Gartnerは、2026年までに大規模ソフトウェアエンジニアリング組織の80%がプラットフォームエンジニアリングのチームを持つと予測しており、2022年の45%から大きく伸びる見込みです。
プラットフォームチームは実際に何を作るのか
ベンダーの構成図は一度脇に置きましょう。多くの企業で、プラットフォームチームは次の四つを提供しています。
社内開発者プラットフォーム（IDP）: クラウドとCIの上にある、セルフサービスのツールとワークフローの集まりです。Backstage のようなポータル、ベンダーの製品、テンプレートとCLIを整えたリポジトリのどれでもかまいません。
ゴールデンパス: 「新しいAPIサービスを作る」「キューを追加する」といった、よくある作業のための推奨ルートです。
ガードレール: ポリシー、セキュリティスキャン、コストの上限を初期設定で適用します。安全な選択肢が、同時に一番楽な選択肢になるようにするためです。
ドキュメントと検索性: 「このサービスの持ち主は誰か、Runbookはどこか、何に依存しているか」に答えるカタログです。
新しい製品カテゴリは必要ありません。優れた基盤の多くは、cookiecutter のテンプレートと、誰かが最新に保ち続けたREADMEから始まっています。
ゴールデンパスとは何か、なぜ開発者は使わないのか
CNCFは、ゴールデンパスを「迅速なプロジェクト開発のための、よく統合されたコードと機能のテンプレート化された構成」と定義しています。Google Cloud は Spring Boot の例を使ってこの考え方を解説しています。平たく言えば、新しいサービスに初日からリポジトリ、パイプライン、ログ、デプロイ設定を与えるテンプレートです。
失敗のパターンも同じくらい単純です。誰も頼んでおらず、歩くチームと話さずに作られたパスは、利用率が一桁のまま放置されます。その間、プラットフォームチームは、開発者がなぜチケットを出し続けるのか首をかしげます。パスは回避策より短くなければなりません。そうでなければ、人は回避策を使います。
ゴールデンパスを生かし続けるルールは二つです。
囲い込まず、舗装する。 開発者はパスから外れてもかまいません。ただし、そこから外れて作ったものの保守は自分で引き受けます。
製品として持ち主をつける。 誰かがフィードバックを読み、利用状況を追い、誰も使っていないパスを削除します。
DevOpsの言い換えにすぎないのか
一部はそのとおりです。ただ、マーケティングの答えより正直な答えのほうが役に立ちます。DevOpsは文化です。開発と運用で責任を共有し、フィードバックのループを短くすることを指します。プラットフォームエンジニアリングは、繰り返される運用作業を製品に変えることで、その文化を大規模に続けられるようにする手段の一つです。
SREはまた別の分野です。SREは信頼性の目標を定め、計測し、それを守るためにいつリリースを止めるかを決めます。プラットフォームチームが舗装された道路を用意し、SREチームはその上でどれだけのリスクを負えるかを示す、という役割分担になります。
DevOps は文化と実践の集まりです。成果は共有された責任と自動化ですが、多くの場合、ただの肩書きとチケットキューに変わって失敗します。
SRE は信頼性の規律です。成果はSLO、エラーバジェット、インシデントプロセスですが、多くの場合、権限のないページング当番になって失敗します。
プラットフォームエンジニアリング は社内向けの製品チームです。成果はセルフサービスの基盤とゴールデンパスですが、多くの場合、誰も使わない基盤になって失敗します。
失敗パターンの部分は二度読む価値があります。依頼されたものを何でも作るチケット処理型のプラットフォームチームは、名前を変えた運用チームにすぎません。古いキューの問題を、そのまま引き継いでしまいます。
プラットフォームチームを置く価値があるのはいつか
エンジニアが30人未満で、サービスが一つか二つなら、置かないほうがよいでしょう。その規模では、よいテンプレートリポジトリと共有の Terraform モジュールで足ります。フルタイムのプラットフォームチームは、ただのオーバーヘッドです。10人のチームでは、数人が気づかないうちにプラットフォームの役割を担うことになりますが、それで問題ありません。
次のようなシグナルが繰り返し現れたら、投資の効果が出始めます。
新しいサービスが本番に出るまで数週間かかり、その大半が他の人を待つ時間になっている。
三つのチームが、同じデプロイの問題を三通りの方法で解決している。
新しいエンジニアのオンボーディングが、暗黙知の山と「あの人に聞いて」の連続になっている。
セキュリティとコンプライアンスのレビューが、チームごとに手作業で、最後にまとめて行われている。
Team Topologies が「最小限の実用的プラットフォーム（thinnest viable platform）」と呼ぶものが、最初の目標になります。一番大きな繰り返しの痛みを取り除くのに必要なだけを用意し、きちんと文書化し、それ以上は作らないものです。最初の一つは、チームをまたいで最も多くの時間を食っている作業から選びましょう。多くの場合、「新しいサービスを作る」か「プレビュー環境を取得する」です。
フィーチャーフラグは、各チームが個別に持つより共有サービスとして持つほうが安上がりになる機能の好例です。
全チームが呼び出せるフラグサービスなら、同じ監査証跡と同じクリーンアップのルールを持てます。各チームが中途半端なトグルの仕組みを一から作る手間も省けます。買うにせよ作るにせよ、それは各リポジトリの中ではなく、プラットフォームに置くべきものです。
プラットフォームとコードを読むことはどう関係するのか
構成図が認めている以上に関係があります。プラットフォームは、その周りにある知識と同じくらいしか使いやすくなりません。開発者が「サービスAはどうやってサービスBに認証しているのか」と聞くとき、答えはコード、設定、そして半年前から更新されていないかもしれないRunbookの中にあります。
ここでプラットフォームチームは、静かに時間を失っています。「Xはどこで設定されているのか」で始まるSlackの質問を受け取り、今週五回目になる同じ質問に、記憶を頼りにまた答えているのです。リポジトリが8万行を超えると、この状況がはっきり見えてきます。プラットフォームチームが、人間による検索インデックスになってしまうのです。
役に立つツールはいくつかあり、問題の別々の半分を解決します。Docs-as-code のツールは、文書の部分をソースの近くに保ちます。
コードを理解するアシスタントは、コードそのものについての質問に答えます。Sourcegraph のアシスタントは大規模なマルチリポジトリの組織を想定しており、エンタープライズ向けに見積もりベースで提供されています。そのため、15人のチームより、大きな環境を持つプラットフォームチームに向いています。
日常の作業でエディタの中で使うなら、汎用アシスタントが多くの場面をカバーします。ただし、与えた文脈しか知らないという制約は覚えておいてください。
私たちが真似したいパターンは次のとおりです。ゴールデンパスのテンプレート、オーナーのカタログ、コードの検索できるインデックスを同じ場所に置きます。そして新しいエンジニアが、人に聞く前にそこで質問できるようにします。効果も時間で測れます。これを導入した後、プラットフォームチームが受ける「この設定はどこか」という質問が週10件未満になれば、うまくいっています。
大きな城を作らずに始めるには、そして何が失敗するのか
失敗するプラットフォームの多くは、ツールから始めてしまいます。より良い順番は、人、パス、ツールの順です。
開発者十人にインタビューする。 マージ済みのPRから、動く機能が本番に届くまでのどこで時間を失っているかを聞きましょう。同じ三つの答えが返ってくるはずです。
パスを一つ選び、一か月で出す。 空のタイルが四十個並んだポータルより、「新しいサービス」のテンプレートを一つ、端から端まで動くようにするほうがずっと価値があります。
前後で計測する。 新しいサービスが最初にデプロイされるまでの時間と、新しく入った人が最初のPRをマージするまでの時間を追いましょう。満足度調査より、この二つの数字のほうが多くを教えてくれます。
ロードマップと変更履歴を公開する。 見せなければ、基盤の仕事は見えません。
削除する。 誰も使っていないパスやツールは廃止しましょう。人が信頼する小さな基盤は、人が迂回する大きな基盤に勝ります。
失敗パターンは繰り返し現れます。
ヘルプデスク型の基盤。 依頼はチケットで届き、チームが手作業で処理しています。それをセルフサービスと呼んでいるだけです。テストは簡単です。開発者は、よくある作業を誰とも話さずに終えられますか。
強制型の基盤。 基盤がまだ使い物にならないうちに、経営陣がすべてのチームに使うよう命じます。採用率の数字は良く見えても、満足度は崩れます。最初の六か月は、利用が自然に広がるのを待ってください。
何でも屋の基盤。 あらゆる依頼が機能になり、対象範囲が膨らみ、品質が落ちます。断るときは、文書で理由を添えて断りましょう。
早期に気づくための指標は、Slackの質問と文書化された回答の比率です。同じ質問が一か月に三回出てくるのに、文書もテンプレートも自動化もないなら、それが次のバックログの項目です。
月曜日に実際に何をするか
チーム全体で最も時間を食っている作業を一つ選び、退屈なものにしてしまいましょう。多くの企業にとって、それは新しいサービスの作成かテスト環境の取得です。パスを書き、人が見つけられる場所に置き、節約できた時間を数えてください。その後で、より大きなチームが必要かどうかを決めれば十分です。
プラットフォームエンジニアリングは、インストールするツールチェーンではありません。社内の開発者を顧客として扱うという決断です。その決断をした証拠は、新しく入った人の初日から最初のマージまでの距離が縮まることに表れます。