プラットフォームエンジニア
プラットフォームエンジニアが作るのは社内向けのプロダクトで、その利用者は組織自身のエンジニアです。成果物は、サービスを作り、届け、観測し、運用するためのセルフサービスの仕組みであり、その上を通る十分に支えられた経路が、組織の基準を毎回組み直すことなく運びます。この職種は採用されるかどうかで成否が決まるため、インフラの問題であると同時にプロダクトの問題でもあります。本ガイドでは、役割の範囲、組織がこの投資に見合う規模になる時期、そして候補者の評価の仕方を扱います。
プラットフォームエンジニアは何をする職種ですか
プラットフォームエンジニアは、社内開発者プラットフォームを構築し運用する職種です。それは、組織のエンジニアがサービスを作り、デプロイし、必要なインフラを得て、動いているものを観測し、運用するためのセルフサービスの窓口であり、下層のコンポーネントを自分で理解したり組み立てたりする必要をなくします。そのプラットフォーム上の十分に支えられた経路は、セキュリティ、信頼性、コストに関する組織の要件を既定で満たします。この役割はインフラを、意図的に設計された窓口の背後に抽象化すべきものとして扱い、他のあらゆるプロダクトと同じ基準——それを作った相手が実際に使うことを選ぶかどうか——で評価されます。
中心にある考え方は「舗装された道」です。よくある作業に対して、十分に支えられた一つのやり方を用意し、他の選択肢より容易にし、しかも組織の要件を満たした状態で届けます。チームはその道を外れる自由を保ち、外れた分の責任を引き受けます。それがプラットフォームと強制の違いです。プラットフォームは正しい経路を便利な経路にし、強制は誤った経路を禁止し、たいていどこにも記録されない手の込んだ迂回を生みます。
経済的な論拠は注意力についてです。各プロダクトチームがそれぞれ独立に、クラスタのネットワーク、証明書の更新、ログの保持、アラートの経路、プロバイダーの権限を考えると、プロダクトに向けられたはずの注意が消費され、しかも他のどのチームとも少しずつ違う答えに行き着きます。プラットフォームが作る価値を持つのは、同じインフラの判断が繰り返し、しかも一貫せずに下されるようになってからです。それ以前は、単一のユースケースの上に置いた抽象にすぎず、防いだ重複より維持費のほうが高くつきます。
隣接する職種と最も違うのは、断ることのできる利用者がいる点です。誰も使わない社内プラットフォームは部分的な成功ではありません。チームが代わりに作った個別の仕組みの隣に置かれた、保守負担そのものです。この点が、通常のインフラ作業には伴わないプロダクトとしての義務をもたらします。利用者の必要を理解すること、ドキュメント、サポート、バージョニング、移行経路を伴う廃止、そしてそもそも使われているかを測ることです。
この能力が必要になる場面
プラットフォームエンジニアリングは早く始めすぎるのが容易で、その場合は一つのユースケースの上に凝った抽象ができあがります。以下は、投資が回収され始めるのが通例の条件です。
複数のチームが同じ問題を別々のやり方で解いている
各サービスに固有のデプロイ方法、固有のログの慣習、固有のアラート、そしてセキュリティ要件の固有の解釈があります。どれも間違いではなく、すべてが少しずつ違い、基本を学び直さずにチーム間を移れる人はいません。本当の代償は重複した労力ではなく、何かを改善するにはすべての場所で変更が必要になることです。
インフラを得られるかどうかが特定の人に依存している
新しいデータベース、キュー、環境、認証情報一式を得るには、忙しい誰かに頼む必要があります。デリバリーはその人の予定に律速され、組織は可用性の問題を、遅さの問題として経験しています。
基準が既定値ではなく文書として存在している
シークレット、保持期間、暗号化、アラートをサービスがどう扱うべきかが書き残されており、遵守は記憶とレビューの問題になっています。文書化された基準の守られ方はばらつきます。チームが既に通っている経路に組み込まれた基準は、構造として守られます。
新しいサービスの立ち上げに、差別化されない作業が数週間かかる
プロダクトのコードを一行も書く前に、誰かがリポジトリ、パイプライン、ランタイム、シークレット、監視、アラートの経路、アクセス権を組み立てます。それが煩わしいため、分離したほうが良い設計である場面でもチームはサービスの新設を避け、アーキテクチャは静かに立ち上げコストによって形づくられます。
インフラ部門が待ち行列になっている
依頼が処理より速く届き、主要な成果物はバックログで、部門はスループットで測られています。依頼が生じる理由をなくす時間は誰にもなく、どれほど効率よくさばいても行列は伸びます。これは人手が足りない兆候ではなく、仕事の形を変える必要があるという合図です。
共有の仕組みが元を取れるだけのチーム数がある
プラットフォームは固定費を持ち、便益は使うチーム数に比例します。組織ごとに異なるものの、確かに存在する境目があります。それ以下では、よく手入れされたテンプレートと共有モジュールのライブラリのほうが役に立ち、それ以上ではプラットフォームの不在が、あらゆる場所で一貫性の欠如として現れます。
中核となる能力
プラットフォームをプロダクトとして扱う
利用者が誰で、それ以前は何をしていて、そのどの問題を実際に解いているのかを把握します。この役割はプロダクトとしての通常の義務を伴います。利用者調査、ドキュメント、サポート、練られたロードマップ、そして成果物の量ではなく採用状況を誠実に測ることです。
ゴールデンパスとサービステンプレート
何もない状態から、動いていて観測でき、適切に守られたサービスまでの、支えられた経路を用意します。雛形、パイプライン、ランタイム設定、テレメトリ、アラートの経路が一緒に届き、チームが手を加えたあとも保守可能であり続けることです。
セルフサービスのプロビジョニング
データベース、キュー、環境、DNSレコード、権限を、宣言された要求として出せば、プラットフォームが強制する制限の範囲内で自動的に満たされるようにします。成功とは、依頼が速くなったことではなく、誰にも頼まなくてよくなったことです。
抽象の設計
何を隠し、何を見せ、どこに逃げ道を置くかを決めます。隠しすぎれば、要件が少し変わった途端にチームは行き場を失います。隠さなすぎれば、手数の増えたドキュメントができあがります。この境界の見極めが、この職種の知的な中核です。
マルチテナンシーと分離
共有インフラ上で多くのチームのワークロードを動かしつつ、一つが他を劣化させないようにします。リソース制限、名前空間とネットワークの境界、クォータの方針、そして行儀の悪いテナントに対してプラットフォームが何を保証するのかについての明確な立場です。
既定で備わる可観測性
舗装された道に計装を同梱し、各チームが自前で作らなくてもトレース、構造化ログ、有用なメトリクスが存在するようにします。監視がプロジェクトになる組織と、どのサービスも不調になった瞬間に調べられる組織の差はここにあります。
コードとしてのポリシーとガードレール
要件を自動化された制御——アドミッションポリシー、イメージの来歴の規則、ネットワーク制限、実行時の検知——として表現し、準拠した構成が既定になり、そこから外れれば見えるようにします。何かを拒むガードレールは、代わりに何をすべきかを示さなければなりません。さもなければチームは迂回します。
ワークロードのアイデンティティとシークレット
すべてのワークロードに検証可能なアイデンティティを与え、それに基づいて短命な認証情報を発行し、アプリケーションが長期の鍵を持ち歩かないようにします。配布、ローテーション、失効はプラットフォームの性質になり、各チームが別々に実装するものではなくなります。
プラットフォーム自体の信頼性
プラットフォームはその上に築かれたすべての依存先であるため、自身の可用性目標とエラーバジェットは、個々のサービスのそれより重要になります。障害の起き方には特に注意が要ります。障害時に閉じる方向へ倒れるプラットフォームは、インシデントの最中に組織のデプロイを止めてしまいます。それはまさにデプロイが必要な瞬間です。
インターフェースの進化と廃止
チームが依存するものにバージョンを与え、古いインターフェースは移行経路、十分な予告、そして可能であれば自動変換を伴って引退させます。まずい廃止は、プラットフォームが依って立つ信頼を失う最短の道であり、信頼は仕組みより立て直しが難しいのです。
技術エコシステム
プラットフォームエンジニアリングで一般的に用いられる技術を以下に示します。これは職種として実践されている領域の全体像の説明であり、特定のエンジニアが扱う技術についての主張ではありません。プラットフォームは買うものではなく組み上げるものですから、より有用な問いは、何を作り、何を採用し、何に手を出さないでおくかをどう決めるかです。
ランタイムとオーケストレーション
- Kubernetes
- Nomad
- ECS
- Cloud Run
- Knative
開発者ポータルとインターフェース
- Backstage
- Port
- Cortex
- Humanitec
- Internal CLIs
コントロールプレーンとプロビジョニング
- Crossplane
- Kubernetes operators
- Kubebuilder
- Terraform modules
- Pulumi
構成とテンプレーティング
- Helm
- Kustomize
- CUE
- Jsonnet
- Cookiecutter
ポリシーとワークロードのセキュリティ
- Open Policy Agent
- Kyverno
- Falco
- cert-manager
- External Secrets Operator
- SPIFFE
テレメトリ
- OpenTelemetry Collector
- Prometheus Operator
- Grafana
- Tempo
- Pyroscope
プラットフォーム部品の実装言語
- Go
- Python
- TypeScript
- Rust
- Shell
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- プロダクト
- 事業の優先順位
- ロードマップ
- アーキテクチャ
- スプリントの優先順位
- エンジニアリング標準
- 日々の技術的な協働
Talent.ID handles
- 雇用関係
- 給与支払い
- 従業員福利厚生
- タレント管理
- 継続的な従業員関係
採用時に見るべき点
プラットフォームエンジニアリングという呼び名は、それが指す仕事より新しいため、いまでは幅広い職務を覆っており、中には従来のインフラ作業に名前を付け替えただけのものもあります。本物のプラットフォームエンジニアを分けるのは、社内の利用者に向いた姿勢と、アーキテクチャと同じくらい自然に採用状況を語れることです。
社内の利用者に向いた姿勢
直近に関わったプラットフォームを誰が使っていたか、そしてその人たちの必要をどうやって知ったかを尋ねてください。これをきちんと行ってきたエンジニアは、具体的なチーム、具体的な不満、そして具体的に外した点を挙げます。そうでない人はアーキテクチャを説明し、必要は自明だったと前提します。
- 作ったが社内チームに使われなかった機能と、その理由を語れる
- プロダクトチームがプラットフォームを使う場に同席した経験がある
- プラットフォームの利用者を、受け手ではなく他の選択肢を持つ人として語る
- 自分のプラットフォームのどの部分が最も不満を集めたかを知っている
抽象についての判断力
社内の抽象はいずれ、想定していなかった要件に出会います。そのとき何が起きるかを尋ねてください。答えから、逃げ道を意図的に設計しているのか、締め切りを抱えたチームとの押し問答の最中にその必要に気づくのかが分かります。
- 抽象の外へ出ることを禁じるのではなく、支えられた出口を用意する
- 意図して隠さないことにしたものを説明できる
- 維持費に見合っていなかった抽象を取り除いた経験がある
強制によらない採用
通達で押しつけられたプラットフォームは、反感と回避策を蓄積します。本当に楽だから選ばれたプラットフォームは、利用者を蓄積します。自分たちが作ったものへの移行に、どうやってチームを納得させたかを尋ねてください。良い回答は、代替を禁じるのではなく移行を安くします。
- 採用状況を測っており、伸びたとだけでなく、どれだけだったかを言える
- チームの作業の一部を肩代わりして移行の費用を下げた
- 本当に採用されたプラットフォームと、使うよう指示されただけのものを区別する
プラットフォームを本番システムとして運用すること
プラットフォームは他のすべての基盤であり、そのために求められる水準が変わります。自分たちのプラットフォームが使えないとき組織に何が起きるか、そして開いた方向へ倒れるほうが安全な場面のために設計してきたかを尋ねてください。
- プラットフォーム自体の可用性目標を明示的に持っている
- どの障害ならチームがなおデプロイできるべきかを検討している
- 障害をプロダクトチームに流すのではなく、プラットフォーム自身のオンコールを持つ
- プラットフォームのインシデントと、そこから生まれた変更を語れる
障害物にならないガードレール
自動化されたポリシーは、基準を既定値に変える仕組みであると同時に、プラットフォームが嫌われる最短の道でもあります。チームがそれまでできていたことを止める制御をどう導入し、反対意見にどう対処したかを尋ねてください。
- 強制する前に、報告のみのモードでポリシーを導入した
- 拒否のメッセージに、代わりに何をすべきかを書く
- 非公式ではなく記録される例外プロセスを持っている
開発者体験の測定
プラットフォームが役に立っていると、どうやって分かったかを尋ねてください。優れた候補者は観測可能な何か——空のリポジトリから動くサービスまでの時間、チームがサポートを求める頻度——を挙げ、その測定が捉えられなかったものについても率直です。
- プラットフォームの産出量ではなく、開発者の体験に結びついた指標を使う
- 定量的なシグナルと、影響を受ける人との対話を組み合わせる
- 数字の上では改善したが実態は変わらなかったものを挙げられる
自分が作ったものを廃止すること
社内のインターフェースは積み上がり、何も引退させない組織は、これまで出したすべてのバージョンを保守し続けます。取り下げたものについて尋ね、通達と遵守の期待ではなく、予告、移行のための道具立て、そしてやり切りが語られるかを聞いてください。
- 自動移行を用意したか、自ら変換作業を行った
- 生じる混乱に見合った予告期間を取った
- 削除する前に、古い経路が使われていないことを確認した
面接で尋ねる価値のある質問
候補者が社内の利用者を単位に考えているのか、インフラだけを単位に考えているのかが表れる質問です。御社の採用プロセスの参考としてご用意しています。適合の判断は御社が、御社にしか定められない要件に照らして行うものです。
直近に関わったプラットフォームを説明してください。誰が使っていて、それが存在する前はどうしていましたか。
What a strong answer shows
そのプラットフォームが、観察された必要に基づいて作られたのか、想定された必要に基づいて作られたのかが分かります。重要なのは後半です。以前の状態を説明できない候補者は、おそらくそれを改善できたのかを確かめていません。
あるチームが、あなたの抽象では対応できないものを必要としています。しかも締め切りがあります。どうなりますか。
What a strong answer shows
プラットフォームの評判を決める場面での振る舞いです。優れた回答は、支えられた出口を提示し、その穴をプロダクトへのフィードバックとして扱い、恒久的な特例にも、にべもない拒否にも走りません。
自分が作ったものに、最初のチームをどう乗せましたか。五番目のチームはどうでしたか。
What a strong answer shows
採用の進め方と、その二つが別の問題だという認識です。最初のチームはたいてい協力的な共犯者ですが、五番目は自前のやり方が回っており、変える理由が特にありません。
あなたのプラットフォームが使えなくなりました。組織にはまだ何ができ、何が完全に止まりますか。
What a strong answer shows
すべての依存先であることについて考えてきたかどうかです。障害時の振る舞いを意図的に設計しているか、とくに自身のコントロールプレーンが劣化している最中にもチームが修正をデプロイできるかを見てください。
この規模の組織で、共有プラットフォームが正当化されるかどうかをどう判断しますか。
What a strong answer shows
自制です。どの組織にもプラットフォームが要ると考える候補者は、早すぎる時期に作ります。練られた回答は、チームの数、重複の量、そして当面はテンプレートと共有モジュールのほうが役に立つのではないかを秤にかけます。
チームが慣れていたやり方を止めることになった制御やポリシーの導入について教えてください。
What a strong answer shows
関係を損なわずに基準を徹底できるかどうかです。予告期間、拒否された地点での明確な案内、そして個別のやり取りではなく記録される例外の経路を聞いてください。
誰にも使われなかったものは何ですか。そこから何を学びましたか。
What a strong answer shows
率直さとプロダクトの勘です。この職種の誰もが、使われなかったものを作った経験を持ちます。採用に値する候補者は、それが何で、なぜ必要を読み違え、いまは作る前に何を確かめるようになったかを言えます。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- デリバリーチームの数が増えつつある組織で、各チームがサービスを届け、運用する独自のやり方を組み上げてしまっています。基準は文書として存在し、守られ方はばらつき、プロビジョニングはバックログが伸び続ける少人数のグループに依存し、新しいサービスの立ち上げには時間がかかるためチームはそれを避けています。共有の社内基盤を作ること自体は合意されていますが、作る余力がありません。
- Approach
- 増強された体制は、プラットフォームのグループが既に持つ慣習——インターフェースの設計方針、リリースプロセス、レビュー基準、計画で合意した優先順位——に従って作業します。プラットフォームが何になるか、次にどのチームへ広げるかのロードマップは社内のエンジニアが持ち続け、舗装された経路は、それを使うことになるチームと並んで作られます。
- What this adds to the team
- プラットフォームの方向性と、社内の利用者との関係の主導権は組織の内側に残ります。何を抽象化し、何を見せたままにし、どの基準を既定値にするかは、それを保守する人々が決めることです。
Related disciplines
Frequently asked questions
- プラットフォームエンジニアリングとDevOpsは何が違いますか
- 誰のための仕事かと、何を生み出すかが違います。DevOpsは変更が本番へ移動することと、その後に返るシグナルに関わり、通常はデリバリーチームの内側で、そのチームのために実践されます。プラットフォームエンジニアリングは、多くのチームが利用するものを生み出します。セルフサービスの窓口と、その上を通る支えられた経路を備えた社内プロダクトで、下層の仕組みを知らずに使えます。前者はソフトウェアがどれだけ安全に、どれだけ頻繁に利用者へ届くかで測られ、後者はチームが手助けなしに必要なものを得られるかで測られます。混同は無理もありません。プラットフォームのグループはしばしばデリバリー用の道具を作り、プラットフォームエンジニアの多くはデリバリーの仕事から来ているからです。それでも、誰にも使われないプラットフォームは、生み出したパイプラインがどれほど優れていても失敗しています。
- プラットフォームエンジニアは、インフラやクラウドのエンジニアの呼び名を変えただけですか
- 働き方を変えずにチーム名だけを付け替えた組織では、実質的にそうなっていることがあります。本来は違います。クラウドやインフラのエンジニアリングが生み出すのは基盤そのものです。アカウント構成、アイデンティティモデル、可用性の姿勢、コスト構造です。プラットフォームエンジニアリングが生み出すのは同僚が使うものであり、他所へ行けるかもしれない利用者を持つことから来る義務を伴います。ドキュメント、サポート、バージョニング、移行経路を伴う廃止、そして前提ではなく測定される採用状況です。プラットフォームはその基盤の上に載り、基盤が健全であることに依存します。だからこそ順序が重要になります。
- これが正当化されるには、組織はどのくらいの規模である必要がありますか
- 普遍的な境目はありませんが、信頼できる検査はあります。同じインフラの判断が独立に何回下されているか、そしてその答えがどれだけ違うかを数えることです。チームが二つか三つなら、正直な答えはたいてい、よく手入れされたテンプレート、共有モジュールのライブラリ、そして明確なドキュメントです。チーム数が増え、一貫性の欠如がプラットフォームより高くつくようになるにつれて、根拠は強くなります。利用者が一つしかない段階で作れば、一つのユースケースに仕える抽象ができ、しかもそのユースケースを複雑にします。
- 社内プラットフォームの利用は必須にすべきですか
- 義務にするより、当然の選択肢にするほうがはるかにうまくいきます。強制は採用を遵守に変え、プラットフォームが必要とするフィードバックを覆い隠します。チームは使いにくさを報告しなくなり、黙って迂回するようになります。本当に交渉の余地がないものもいくつかあり、たいていはセキュリティと規制上の統制です。それらは舗装された道の内外を問わず適用される自動ガードレールに置くべきです。それ以外については、チームが別の手段を選ぶことは、チームについての情報ではなくプラットフォームについての情報です。
- プラットフォームチームがチケットの待ち行列になると何が起きますか
- プラットフォームチームであることをやめ、名前の違う共通サービス窓口になります。仕事は依頼を閉じることを軸に組み替えられ、グループはスループットで測られ、依頼そのものを不要にするセルフサービスの機能を作る余地は誰にもありません。そして待ち行列は、どれほど効率よくさばいても伸びます。需要を生んでいるのは、その待ち行列のせいで誰も作れないもの、まさにそれの不在だからです。立て直すには、依頼が続く中でもプラットフォームの作業のための余力を意図的に守る必要があり、それは経営層にしか下せない居心地の悪い判断です。
- プラットフォームのオンコールは誰が担いますか
- プラットフォームについては、プラットフォームチームです。これはこの職種を置く分かりやすい論拠の一つでもあります。共有のコンポーネントが壊れたとき、それを理解している一つのグループが対応するのであって、複数のプロダクトチームが同じ不具合を別々に診断するのではありません。境界は明示されている必要があります。プラットフォームが何に責任を持ち、何がサービスを所有するチームに残り、判然としない場合に呼び出しをどう振り分けるかです。曖昧さは最悪の結果を生みます。インシデントが「これは誰の問題か」の交渉から始まる状態です。
- プラットフォームエンジニアは既存の開発チームとどのように働きますか
- 開発チームの増強という形で御社のチームに参画し、そのチームの既存のやり方に従います。レビューの慣習、リリースプロセス、アーキテクチャの方向性、そして御社の計画サイクルで決まる優先順位です。作業の方向づけは、プロダクト、ロードマップ、エンジニアリング標準とあわせて御社に属します。Talent.IDは、雇用が続くかぎり雇用関係を保持し、タレント管理、給与支払い、従業員福利厚生、そして継続的な従業員関係を担います。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.