プラットフォームエンジニアリング とは：DevOpsとの違い、いつ必要か

夜10時10分。新入社員がステージング環境の構築に丸2日を費やしている。Slackに同じTerraformエラーを2回貼り付けて、チケットを3枚切ったのに、4つのCIテンプレートのどれが本物なのかまだ判然としていない。その光景こそが「プラットフォームエンジニアリング とは」という問いへの完全な答えだ。それは内部に舗装道路をつくる仕事。誰もが一人でジャングルを切り抜ける必要がないように。そしてその道を、ユーザーを持つプロダクトとして扱うことだ。

実際のところ、プラットフォームチームは内部開発者プラットフォーム（IDP）を構築する。セルフサービスツール。他の開発者がサービスを作成し、デプロイし、何が動いているかを、人間を介さずに確認できる仕組みだ。このステップをスキップするとどうなるか。各チームがデプロイプロセスを再び発明する。知識は3人の頭の中にしか存在しない。

プラットフォームエンジニアリングをバズワードなしで理解する

最も要領よく定義できるのはplatformengineering.orgコミュニティのものだ。チームに、繰り返し起こる仕事の部分に対するセルフサービス機能を与えるプラットフォームを設計・構築すること。言葉を剥ぎ取ると、3つの動く部分が残る。

まず、内部開発者プラットフォーム。これは買うプロダクトではない。既存のツール（クラウドアカウント、Kubernetes、CI、シークレット管理、監視）の上に乗せる、テンプレート、パイプライン、API、ドキュメントの薄い層だ。複雑なエッジを隠す。

次に、プラットフォームチーム。小規模なエンジニアグループ。顧客は他のエンジニアたち。エンドユーザーのための機能ではなく、他の全員がスピード感を持ってデリバーできることが出力。

そして、プロダクトマインドセット。プラットフォームにはユーザーがいる。バックログがあり、導入率がある、オンコール制度がある。誰も使わなければ失敗。アーキテクチャがいかに優雅でも関係ない。

Gartnerは2026年までに大規模ソフトウェア工学組織の80%がプラットフォームチームを持つようになると予測した。2022年は45%だった。トレンド指標として捉えよ。約束ではない。同じ業界の知見では、そうしたチームの大部分が成果を示すのに苦労していると言う。この記事の残りがなぜ失敗するかに時間を費やす理由だ。

DevOpsとSRE。何が違うのか

短くいうと。DevOpsは文化。SREは信頼性の学問。プラットフォームエンジニアリングは両者をプロダクト化するチーム形態。

DevOpsは、開発者と運用が本番ソフトウェア運用の所有権を分かち合うべきだと言った。良い考え。15人の会社なら誰もが全てを見られるから機能する。300人の会社では、静かに「全スクワッドもKubernetesの専門家に」という話に変わる。誰も署名したことのない契約だ。

SREは信頼性ターゲットに焦点を当てる。エラーバジェット、インシデント対応、容量計画。プラットフォームチームも信頼性を気にするが、主なメトリックは異なる。開発者が「サービスのアイデアを持つ」から「本番環境でログとアラート付きで動いている」まで、どのくらい待つか。それが彼らの最重要指標。

プラットフォームエンジニアリングはDevOpsが残した認知負荷への答え。全ての開発者にツールチェーン全体を学べと要求する代わりに、サポートされたデフォルトを与える。専門知識はプラットフォームの内部に置く。3つ理由でやる価値がある。1つ理由でやらない方がいい。人数やサービスの数が十分大きいから重複がコストになってからだけ。そのしきい値を下で見る。

プラットフォームチームは実際に何をデリバーするのか

アーキテクチャ図を忘れよう。火曜日の普通の日のプラットフォームチームのバックログはこう見える。

サービステンプレート。1つのコマンド、またはポータル上のボタン1つで、リポジトリが生まれる。動くパイプライン。Dockerfile。ヘルスチェック。ログ設定。基本的ダッシュボード。開発者はビジネスロジックを変える。配管ではなく。

デプロイパス。mainにプッシュ。テスト実行。アーティファクト構築。環境を通じた昇格。毎回同じステップ。チーム固有のスノーフレーク化。なし。

オンデマンド環境。プルリクエストごとのプレビュー環境。自動破棄。これが開発者から感謝される機能。

シークレットとアクセス管理。短命の認証情報。1ヶ所で要求。監査証跡。退屈だが、セキュリティレビューで救う。

デフォルトの可観測性。テンプレートから作られたすべてのサービスはメトリック、ログ、トレースを配信。誰が配線しなくても。背後に通常はGrafanaのようなスタックが座る。フリーティアとオープンソースオプションは小さなチームに合う。

そのリストで欠けているものに注意。3ヶ月のロードマップ付きのカスタム構築ポータル。ポータルは最後に追加するもの。最初ではない。

ゴールデンパス。その他すべてを機能させる考え方

ゴールデンパスは、よくある仕事のサポートされた、意見的な方法。手動でするより速い。即興するより安全。そして決定的に、それはオプション。開発者は本当の理由がある時にパスを離れられる。責任はそれと共に来る。

Octopusのパッチワークとゴールデンパスについての記事に有用な違いがある。パッチワークは広く、よくメンテナンスされた表面。ゴールデンパスは与えられた仕事のための特定の推奨ルート。私の経験では、その違いは下のパイニング原則より重要度が低い。正しい方法を簡単な方法にすることで勝つ。他の方法を禁止することではない。

最小ゴールデンパスはこう見える。開発者が一度実行するスキャフォルドコマンド。

platform new service payments-api \\
  --template node-api \\
  --env preview,staging,prod \\
  --owner team-checkout

そのワンラインの背後に、リポジトリ、パイプライン、DNS、データベーススタブ、アラート、所有権レコードが座る。コマンドは簡単。難しい部分は6ヶ月を費やして「node-api」が何を意味するかについて合意する。Nodeのバージョン、ベースイメージ、クラウドプロバイダが変わるときそれを最新に保つ。

テスト済み。最適ではない。我々がそうする理由はここ。中程度のゴールデンパスが80%のチームに使われることは、完璧なものが10%に採用されることを上回る。なぜなら最初は全体を一度に改善するレバレッジを与えるから。

それが価値があるときと単なる気散らしのときの違い

ほとんどのブログ記事はこのセクションをスキップする。プラットフォームエンジニアリングは無料ではない。多くのチームにとって、それは間違った動きだ。

platformengineering.orgの概説は、組織が通常およそ20から30プラットフォームユーザーを超えると利益を得始めると示唆している。規則ではなく、おおよその下限として読もう。下では、共有README、良いCIテンプレート、気にかける1人が、形式的プラットフォームチームより多くを成し遂げる。

価値があるとき：

• 一握り以上のチーム。それぞれが独自のデプロイパイプラインを構築している。

• 新しい開発者は日ではなく週かかる、彼らの最初の変更をデプロイするまで。

• 同じインシデント型が繰り返される。各サービスが独自のアラートを配線したから。

• セキュリティか法令遵守が一貫性を求める。やさしく頼むだけでは達成できない。

スキップすべきとき：

• 5人の1チーム。スクリプトを書け。プラットフォームではなく。

• サービスが何に見えるかまだ知らない。早すぎるを標準化。間違った決定を凍結。

• 提案が「ポータルを構築」。痛みのポイントのリストなし。それが取り除く。

ソロビルダーと小さなサイドプロジェクトクルーにとって、正直な話はもっとシンプル。プラットフォームチームは不要。習慣だけが要。1つの反復可能なデプロイスクリプト。新しいプロジェクトのための1つのテンプレート。1つのダッシュボード。チェックする。それは1つのプラットフォーム。毎月1週末を節約する。

現実にエンジニアが組み合わせるツール

プラットフォームエンジニアリング用の単一プロダクトは存在しない。チームはスタックを組み立てる。ピースはいくつかのバケットに分かれる。

ポータルとカタログ用に、多くのチームはBackstageまたはホストされた代替を使う。サービスの検索可能なリスト。所有者とドキュメント。プロビジョニング用にTerraformまたはOpenTofu、プラスArgoCDまたはFluxなどのGitOpsツール。CI/CD用に既に持っているもの。共有テンプレートでラップ。

2つのバケットがより注意の価値がある。プラットフォームが信頼できると感じさせるかどうかを決める。

可観測性。開発者がそのサービスが何をしているか見えなければ、それをデプロイしたプラットフォームを信頼しない。Datadogはインフラ、APM、ログ全体で磨かれた単一ペインを与える。ホストあたりの価格でライセンス費用が膨らむ。Grafanaのオープンソーススタックは運用時間をコストする。少ないリソースが金銭か注意かで選ぶ。

ドキュメントと品質。良いドキュメントなしのプラットフォームはチケットキューの偽装。ドキュメント・アズ・コード・ツールはガイドをそれが説明するリポジトリの隣に保つ。CIのコード品質ゲートはテンプレートを正直に保つ。

これらのどれも必須ではない。プラットフォームチームがそこに時間を費やすレイヤーの例。デフォルトを選ぶ。テンプレートに配線。アップグレードパスを所有する。

間違ったものを構築せずに始める方法

ほとんどのプラットフォーム取り組みは同じパターンを共有する。大きく始める。月分構築してからシングルチームがそれを使う。ロードマップスライドのために最適化する。修正は地味だ。

1つの痛い、頻繁なタスク。「新しいサービスを作成」と「プレビュー環境を得る」は通常の候補。3人の開発者にインタビューして、彼らがそれをするのを見よ。ステップを数える。分を数える。

ほとんどの痛みを削除する最も薄いバージョンを構築。テンプレートリポと共有パイプラインファイルでカウント。友好的なチーム1つに与えて、彼らが使う間その隣に座る。破壊したものを直す。その後チーム2に提供。

2つの数を追跡。「新しいサービス」から「本番で動いている」までの時間。そして、どのくらいのチームがボランティアでパスを使うか。2番目の数がフラットなら、プラットフォームは委任。委任は腐る。

プロダクトチームのように人を配置。プラットフォームエンジニアはDevOpsの新しいタイトルではない。platformengineering.orgの資料はプラットフォームエンジニアはプロフェッショナル比較で約27%多く稼ぐと記す。市場はプロダクト・エンジニアリング混合を見ている。個別で、より難しい仕事として。

もう1つの理由はこれを今やる。最新の波紋は、プラットフォームのユーザーはもう人間だけではない。コードエージェントはプルリクエストを開く。テストを実行。環境を求める。クリーンなテンプレート、明確な権限、機械が読めるドキュメントを持つプラットフォームはエージェントが作業するための安全な場所。スノーフレークリポの山より。

短命の認証情報。プレビュー環境。一貫したパイプライン。これはエージェントミスを使い捨てブランチに含める方法。プラットフォームが人間のデプロイを自動化されたもの区別できなければ、他に何かを追加する前にそれを追加。

次に何を構築すべきか

30人の開発者チームを率いて、全スクワッドが独自のパイプラインを持っているなら、1つのゴールデンパスを持つ小さなプラットフォームチームはおそらくあなたの最高レバレッジ雇用。ソロ開発者で3つのサイドプロジェクト、今週末あなたの最良プロジェクトのパイプラインをテンプレートリポにコピーして、終わりとしよう。

いずれの場合も、次の計画セッションに持つ価値がある質問は具体的。あなたの開発者は何のシングルタスクを最も繰り返すか。そして、それを1コマンド仕事にするのに何が必要か。