Platform Engineerに関して

Sat, 31 Jan 2026 22:50:42 GMT

要約

Platform Engineeringは、DevOpsの普及が生んだ認知負荷の問題への回答として登場した
自分の志向（責任分離をはっきりとしたアーキテクチャ、ミスを犯さない構造の事前設計、何しても良い最強の基盤を作りたい）はこの思想と重なる部分が大きい

Platform Engineeringとは何か

2009年頃から DevOps という考え方が広まりました。「You build it, you run it（作ったチームが動かせ）」という原則で、開発と運用の壁をなくすことでデプロイ頻度が上がり、障害対応も速くなりました。

「コード書きました、あとはよろしく」では優れたソフトウェアは生まれない　コンテナのスペシャリストが語る、運用性を損なう8つの実装例 | ログミーBusiness

You build it, you run it原トリ氏：（スライドの「You build it, you run it」を指して）この言葉、聞いたこと、見たことがある方がいるかもしれません。これは、2006年にACM（Associatio...

logmi.jp

DevOps の考えは、「運用性に優れたソフトウェアは重要である」という思想に基づいます。上記のサイトにおいて、運用性を損なう実装の例として

スケールアウトできない、しにくいアプリ実装
依存パッケージ解決を自動化出来ない
安全に停止できない
起動処理が長い
ビルド/パッケージング前に手作業が必要
設定値を実行時に外部から注入できない
ログをファイルにしか出力できない
Read レプリカを使えない

といったものが挙げられています。

これらの実装を避けるため、DevOps の原則を全チームに適用し続けた結果、別の問題が出てきました。各チームが CI/CD を個別に構築し、Dockerfile を管理し、Kubernetes のマニフェストを書く。チームごとにやり方が違う。再利用できない。新しいメンバーは膨大な社内ドキュメントを読まないと最初のデプロイができない、という状況です。

このような状況をソフトウェアエンジニアリングの世界では、「偶有的複雑さ（Accidental Complexity）」という言葉で表現することがあるようです。本質的に難しいわけではないのに、構造の問題で複雑になってしまっている。開発者がインフラ・セキュリティ・監視・デプロイを全て理解しながら機能開発もこなすのは、認知リソース的に無理があります。

Platform Engineering は、この問題への回答として生まれた考え方であり、その中心にある概念が Internal Developer Platform（IDP）です。

IDP とは、開発者が自分のアプリをデプロイ・運用するために使う、社内製の開発者向けプラットフォームのことで、GitHub や Vercel のような体験を社内で提供するものだと考えるとわかりやすいかもしれません。

IDP を設計するとき、「どこまで抽象化するか」が最も難しい問いになります。抽象化しすぎると柔軟性が失われる（Golden Cage と呼ばれます）。抽象化しなさすぎると認知負荷は減らない。このバランスを取るために生まれた概念が Golden Path です。Spotify が提唱したもので、「正しいやり方を、最も楽なやり方にする。ただし、それだけに強制はしない」という考え方を持っています。開発者は Golden Path から外れることもできるけれど、それに従えばセキュリティや監視やデプロイが自動的に整った状態でスタートできる。ルールではなく、舗装路（Paved Road）だということです。また Platform as a Product という視点も重要で、社内向けのツールであっても開発者体験と継続的な改善を考えることがこの職の特徴だと思います。

自分の志向との重なり

自分がこの領域に関心を持つ理由を整理すると、次のことが言えます。

システムの中での責任の分離と、ミスを犯しにくい構造を事前に設計しておくことに、一貫した関心があります。「動くものを作る」こと以上に「どういう構造にすればミスが起きにくいか」「どの層が何を保証するか」を考えることに面白さを感じています。

それをもっと具体的なイメージで言うと、「自分が最強のデプロイ基盤を作る。あとはその上で何でも作っていい」という状態を達成したい気持ちがあります。スケーリングや安全性の保証をプラットフォーム側に閉じ込め、その設計を自分が引き受ける。他のエンジニアが基盤を意識せずに動けるようになる状態です。そこには技術的な面白さと、ユーザー体験向上に直接関われることへの喜びの両方があります。

研究室サーバー上での PoC アプリの大量デプロイ基盤を構築した経験が、この志向を一番よく表していると思います。開発者には Dockerfile と entrypoint.sh だけを書いてもらい、Traefik によるルーティング・HTTPS・デプロイ手順・障害時の挙動はプラットフォーム側で担う設計にしました。「開発者が何をして良くて、何をしてはいけないか」の境界を設計することが、自分の作業の中心でした。

この志向は Platform Engineering の思想と重なる部分が大きいと感じています。

自分のやりたいこと

自分は、学術と産業の橋渡しをソフトウェアエンジニアリングの観点から取り組むことに興味があります。アーキテクチャ設計やエンジニアリングの観点から先進技術の標準化を主導すること、一人で完結した開発を行うのではなく、誰かと一緒により良い仕組みを作っていくことが、自分のやりたいことに近いと思っています。

Platform Engineer という職はその志向と重なる部分が大きいですが、唯一の答えというわけではありません。今は「この方向はありかもしれない」という位置づけで考えています。

近いうちに Clean Architecture を読んでみます。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

アーキテクチャのルールはどれも同じである! どんな種類のシステムでもソフトウェアアーキテクチャのルールは同じ。ソフトウェアアーキテクチャのルールとは、プログラムの構成要素をどのように組み立てるかのルールである。時代を超越した不変のルールたちを紹介する。

tatsu-zine.com

松本 侑真 — #career

Platform Engineerに関して

要約#

Platform Engineeringとは何か#

自分の志向との重なり#

自分のやりたいこと#

松本侑真 — #career

要約

Platform Engineeringとは何か

自分の志向との重なり

自分のやりたいこと