[完全ガイド] Platform Engineer: プラットフォームエンジニアの年収・将来性・未経験ロードマップ

導入：Platform Engineerという職業の「光と影」

「モダンな技術スタックを操り、開発組織全体の生産性をレバレッジさせる、エンジニア界のアーキテクト」 「KubernetesやTerraformを駆使し、自動化の魔法でインフラを構築する、クラウド時代の花形」

もしあなたが、Platform Engineer（プラットフォームエンジニア）という職種に対して、こうしたキラキラしたイメージだけを抱いているのなら、今すぐその幻想を捨ててほしい。いや、半分は正解だ。しかし、残りの半分は「泥臭い調整」「終わりのない技術的負債との格闘」「他人の尻拭い」で構成されている。

Platform Engineeringの本質は、単なるインフラ構築ではない。それは、「開発者が、開発にだけ集中できる環境（黄金の道：Golden Path）」を舗装する舗装工であり、同時に、「好き勝手に荒らされたジャングルを、誰でも歩ける公園に作り変える」ような、途方もなく忍耐強い作業の連続だ。

なぜ今、この職種がこれほどまでに熱望されているのか。それは、クラウドネイティブ化が進みすぎて、一般のアプリケーション開発者が覚えるべきことが「認知負荷」の限界を超えてしまったからだ。Docker、K8s、CI/CD、監視、セキュリティ、コスト最適化……。これらをすべて個々の開発者に任せるのは無理がある。そこで、それらを抽象化し、セルフサービス化された「プラットフォーム」として提供する専門家が必要になった。

だが、勘違いしてはいけない。プラットフォームを作るということは、「全チームの失敗の責任を、間接的に背負う」ということだ。あなたが作ったCI/CDパイプラインが止まれば、会社全体の開発が止まる。あなたが設計した権限管理に穴があれば、全データが流出する。この重圧に耐えながら、なおかつ「開発者の体験（Developer Experience）」を向上させるために、技術と人間心理の両面からアプローチし続ける。それがPlatform Engineerという生き方だ。

本気でこの道を志すなら、覚悟を決めてほしい。ここから先は、教科書には載っていない、現場の血と汗が滲む「真実」を語る。

💰 リアルな年収相場と、壁を越えるための「残酷な条件」

Platform Engineerの年収は、一般的なバックエンドエンジニアよりも1〜2割高い傾向にある。しかし、その高年収の裏には、明確な「選別」が存在する。単に「IaCが書ける」レベルでは、早々に年収の天井にぶつかるだろう。

なぜ、あなたの年収は「800万円」で止まるのか？

多くのエンジニアが、年収800万円から1,000万円の壁にぶつかる。その理由はシンプルだ。「技術オタク」から脱却できないからだ。 「新しいツールを使いたい」「K8sの最新機能を試したい」……その欲求自体は素晴らしい。しかし、Platform Engineerの価値は「技術の難易度」ではなく、「どれだけ他人の時間を節約したか」で決まる。

シニア層に食い込む人間は、技術を「手段」として冷徹に割り切る。時には「あえて自作せず、マネージドサービスを使い倒す」という判断を下し、余ったリソースで開発者との対話やドキュメント整備に時間を割く。この「組織貢献の視座」を持てるかどうかが、数百万単位の年収差となって現れるのだ。

⏰ Platform Engineerの「生々しい1日」のスケジュール

華やかな「自動化」の裏側にあるのは、予期せぬトラブルと、他部署との調整に追われる泥臭い日常だ。あるシニアPlatform Engineerの1日を覗いてみよう。

• 09:00：出社・Slackチェック（絶望の始まり） 夜間に走らせていた全社共通のCI/CDパイプラインが、特定の条件下でエラーを吐いている。開発チームのチャンネルでは「デプロイできない」「リリースが遅れる」という悲鳴が上がっている。まずはこの火消しからスタートだ。
• 10:00：朝会（詰められる時間） 「昨日合意したはずの権限設定が、開発環境で反映されていない」とテックリードから詰められる。原因はIaCのコードレビューが漏れていたこと。謝罪しつつ、即座に修正してデプロイを回す。
• 11:00：集中タイム（深い思考と絶望） 全社的なKubernetesクラスターのバージョンアップ計画を練る。APIの非推奨対応を全チームに強制しなければならない。どう伝えれば「またプラットフォームチームが面倒なことを言ってきた」と思われずに済むか、言葉選びに神経を削る。
• 12:00：ランチ（という名の情報収集） 他チームのエンジニアとランチ。雑談の中から「実は今のデプロイフロー、手動の手順が多くて苦痛なんです」という本音を拾い上げる。これが次の改善のヒントになる。
• 13:30：他部署からの無茶振り対応 セキュリティ部門から「全リソースに特定のタグを24時間以内に付与せよ」というお達し。手動では無理だ。スクリプトを書いて一括適用するが、副作用で一部の古いシステムが動かなくなるリスクに冷や汗をかく。
• 15:00：プラットフォーム改善ミーティング 「内部開発者ポータル（Backstageなど）」の導入について議論。上層部からは「それでいくら儲かるの？」と聞かれ、開発者からは「覚えることが増えるのは嫌だ」と言われる。板挟みの中で、中長期的なメリットを熱弁する。
• 17:00：本番障害発生（地獄の入り口） 共通のログ基盤が詰まり、全サービスの可観測性が失われる。原因は、あるチームが無謀なデバッグログを大量に吐き出したこと。犯人探しをしている暇はない。即座に流量制限をかけ、インフラをスケーリングさせる。
• 19:00：退勤（…の前のドキュメント作成） 今日の障害のポストモーテム（振り返り）を書き始める。「なぜ防げなかったのか」「どう自動で防ぐか」。これを書かない限り、明日も同じ火消しをすることになる。

⚖️ この仕事の「天国（やりがい）」と「地獄（きつい現実）」

Platform Engineerは、極端な職種だ。最高に報われる瞬間もあれば、全てを投げ出したくなる瞬間もある。

【やりがい：天国】

1. 「神」の視点で組織を最適化できる 一人のアプリ開発者が救えるのは、そのアプリのユーザーだけだ。しかし、Platform EngineerがCI/CDを1分短縮すれば、100人の開発者の100分を毎日救うことができる。この「レバレッジ（てこ）」の効き方は、一度味わうと病みつきになる。
2. 技術の最先端に強制的に触れ続けられる 「全チームが使いやすい基盤」を作るためには、クラウドベンダーの最新仕様や、CNCF（Cloud Native Computing Foundation）の動向に誰よりも詳しくなければならない。学習の強制力が、あなたを圧倒的な技術者へと押し上げる。
3. 「ありがとう」の質が違う 「今回のツールのおかげで、週末のオンコール対応がなくなりました！」という言葉。これは単なる社交辞令ではない。同僚の人生の質を向上させたという、エンジニア冥利に尽きる瞬間だ。

【きつい部分：泥臭い現実（地獄）】

1. 「動いて当たり前、止まれば無能」の減点方式 プラットフォームは空気のような存在だ。完璧に動いている時は誰も感謝しない。しかし、一度でもトラブルを起こせば、「プラットフォームチームは何をやっているんだ」と全社から非難の矢が飛んでくる。この「透明な功績と、可視化された失敗」のギャップはメンタルを削る。
2. 終わりのない「他人の尻拭い」と「板挟み」 開発チームが書いたクソコードが原因でインフラが悲鳴を上げても、まずはインフラ側でなんとかしなければならない。また、経営層からのコスト削減要求と、開発者からのリソース増強要求の板挟みになり、どちらからも嫌われる「悪役」を演じる場面も多い。
3. 「技術的負債」の最終処分場 古いシステムをコンテナ化したり、カオスな権限設定を整理したりするのは、常にあなたの仕事だ。最新のK8sを触っている時間よりも、「10年前の秘伝のタレのようなシェルスクリプト」を解読している時間の方が長いことさえある。

🛠️ 現場で戦うための「ガチ」スキルマップと必須ツール

教科書に書いてある「Linuxの基本」なんてものは前提だ。ここでは、現場で「こいつ、できるな」と思われるための、より実践的なスキルを挙げる。

🎤 激戦必至！Platform Engineerの「ガチ面接対策」と模範解答

Platform Engineerの面接官（多くはCTOやシニアSRE）は、あなたの「知識」ではなく「思想」と「経験の深さ」を見ている。

質問1：「あなたが構築したシステムで、大規模な障害を起こした時の話をしてください」

• 面接官の意図: 失敗の責任を他人のせいにしないか。障害から何を学び、どう「仕組み」で再発防止策を講じたかを確認したい。
• NGな回答例: 「同僚の設定ミスで障害が起きましたが、私がすぐに直しました」
• 評価される回答: 「Terraformの適用範囲を誤り、本番DBを削除してしまいました。原因はレビューフローの形骸化でした。復旧後、即座に『破壊的変更の検知ツール』をCIに組み込み、さらに重要リソースの削除保護をコードレベルで強制する仕組みを導入しました」

質問2：「開発チームから『自由度が下がるから、プラットフォームを使いたくない』と言われたらどうしますか？」

• 面接官の意図: 技術の押し付け（象牙の塔）になっていないか。ユーザー（開発者）視点を持っているかを見たい。
• NGな回答例: 「会社の方針なので、強制的に使わせます」
• 評価される回答: 「まずは彼らの『自由』が具体的に何を指しているのかヒアリングします。もし特定のツールが必要なら、プラットフォーム側でそのサポートを追加するか、あるいは『自由に伴う運用責任』を彼らが負うことを条件に例外を認めます。プラットフォームは『強制』ではなく『使ったほうが楽だから選ばれる』ものであるべきだと考えています」

質問3：「IaC（Infrastructure as Code）を進める上で、最も苦労することは何だと思いますか？」

• 面接官の意図: ツールを使えるだけでなく、実務上の「コードと実態の乖離（ドリフト）」や「リファクタリングの困難さ」を理解しているか。
• NGな回答例: 「HCL（Terraformの言語）の文法を覚えることです」
• 評価される回答: 「既存の手動構築リソースを、稼働させたままコード管理下に置く（importする）際の整合性チェックです。また、コード化した後の『変更の心理的ハードル』をどう下げるか、テスト環境での検証プロセスをどう自動化するかという、運用設計の部分に最も苦労します」

質問4：「Developer Experience (DX) をどう数値化しますか？」

• 面接官の意図: 感覚値ではなく、データに基づいて改善を回せるか。
• NGな回答例: 「アンケートをとって、みんなが満足しているか聞きます」
• 評価される回答: 「DORAの4つの指標（デプロイ頻度、変更リードタイム、変更失敗率、平均修復時間）をベースにします。特にプラットフォーム導入前後で、新規プロジェクトの『最初のデプロイまでにかかる時間』がどれだけ短縮されたかを重視します」

質問5：「最新の技術トレンド（例：AIによる自動運用）を、実際の業務にどう取り入れますか？」

• 面接官の意図: 新しいもの好きの「技術ミーハー」か、それとも「実利重視のプロフェッショナル」か。
• NGな回答例: 「流行っているので、とりあえずChatGPTを全パイプラインに組み込みます」
• 評価される回答: 「まずは toil（定型作業）の分析を行います。例えば、アラートのトリアージに時間がかかっているなら、過去の対応履歴を学習させたLLMで初動のサジェストを行う仕組みをPoCとして導入します。技術ありきではなく、課題解決の手段として費用対効果を検証してから導入します」

💡 未経験・ジュニアからよくある質問（FAQ）

Q1. プログラミングスクールを出たばかりですが、Platform Engineerになれますか？

A. 正直に言いましょう。極めて厳しいです。 Platform Engineeringは、アプリケーション開発、インフラ、ネットワーク、セキュリティの「総合格闘技」です。まずはバックエンドエンジニアとして、自分が作ったコードがどう動き、どう壊れるかを2〜3年経験することをお勧めします。「開発者の痛み」を知らない人間に、良いプラットフォームは作れません。

Q2. 数学の知識はどこまで必要ですか？

A. 高度な微積分は不要ですが、「統計」と「論理学」は必須です。 SLO（サービスレベル目標）を決める際に、確率や統計の知識がないと、根拠のない数字を並べることになります。また、複雑な分散システムのトラブルシューティングには、極めて高い論理的思考力が求められます。

Q3. SRE（Site Reliability Engineering）との違いは何ですか？

A. 焦点が「信頼性」か「生産性」か、の違いです。 SREは「サービスの稼働（信頼性）」に責任を持ちます。Platform Engineerは「開発者の体験（生産性）」に責任を持ちます。ただし、現場では兼任することも多く、境界線は曖昧です。Platform Engineeringは、SREの思想をさらに「組織全体へのツール提供」という形に具体化したものと言えます。

Q4. 英語は必要ですか？

A. 「必須」です。逃げ場はありません。 あなたが使うツールの最新ドキュメント、GitHubのIssue、CNCFのカンファレンス動画……。これらはすべて英語です。日本語の情報を待っていたら、その技術はもう古くなっています。完璧な発音は不要ですが、技術文書を読み解く力がないと、Platform Engineerとしての寿命は短くなります。

Q5. ずっと自動化のコードを書き続ける仕事ですか？

A. いいえ。半分は「人間との対話」です。 どれだけ優れたプラットフォームを作っても、他チームに使ってもらえなければゴミと同じです。他チームの不満を聞き、合意を取り付け、使い方をレクチャーする。この「エバンジェリスト（伝道師）」のような活動が、業務の大きな割合を占めます。孤独にコードを書きたい人には、向いていない職種かもしれません。

最後に：Platform Engineerを志す君へ

Platform Engineerの道は、決して楽ではない。あなたが苦労して作った仕組みは、うまく動いている間は誰にも気づかれない。失敗すれば責められる。常に新しい技術を追いかけ、泥臭い調整に奔走する毎日だ。

しかし、自分の作った「プラットフォーム」の上で、何百人ものエンジニアが楽しそうにコードを書き、次々と新しいサービスを世に送り出していく光景を見たとき、あなたは気づくはずだ。

「自分こそが、この巨大なシステムの心臓部を動かしているのだ」と。

その誇りと責任を背負う覚悟があるなら、この世界へ飛び込んできてほしい。現場は、君のような「熱狂的な舗装工」を待っている。