プラットフォームエンジニアの職務経歴書の書き方｜書類通過率を上げる実例テンプレート
プラットフォームエンジニアの職務経歴書は、インフラ・SRE・DevOpsなど隣接職種との境界が曖昧なため、「何を担当してきたか」だけでなく「どの粒度で意思決定・設計に関与したか」を明示することが書類通過の鍵になります。本記事では、職務経歴書の構成設計から各セクションの記述方針、採用担当者が実際に見るポイント、よくある失敗パターンまでを体系的に解説します。
プラットフォームエンジニアの職務経歴書が難しい理由
プラットフォームエンジニアという職種は、社内でのポジション定義が企業ごとに異なります。ある企業では「開発者向けの内部プラットフォーム（IDP: Internal Developer Platform）の構築・運用」を指し、別の企業では「クラウドインフラ全般の標準化・自動化」を担う役割として定義されることもあります。
この職種名の曖昧さが、職務経歴書作成の難しさに直結します。具体的には次のような問題が起きやすい傾向があります。
- インフラエンジニアやSREとの違いが伝わらず、「インフラ運用担当」として読まれてしまう
- 使用技術の列挙だけになり、設計・意思決定への関与度が見えない
- 「基盤を整備した」という抽象的な表現に終始し、事業インパクトが不明瞭になる
職務経歴書において重要なのは、応募先の「プラットフォームエンジニア像」に対して、自身の経験が構造的に対応していることを示すことです。
全体構成：推奨するセクション順
職務経歴書のセクション構成は、採用担当者が「3分で概要を掴めるか」を基準に設計します。プラットフォームエンジニアの場合、以下の順序が読みやすい傾向があります。
| セクション | 目安の分量 | 目的 |
|---|---|---|
| 職務要約 | 5〜7行 | スキルセットと経験年数の概観を示す |
| スキルマップ | 表形式 | 技術領域ごとの習熟度を一覧化する |
| 職務経歴（社歴・プロジェクト単位） | 各プロジェクト200〜350字 | 担当範囲・役割・成果を具体的に記述する |
| 保有資格・学習活動 | 3〜5行 | 継続的な技術習得の姿勢を示す |
A4で2〜3枚に収めることを目安とし、3枚を超える場合はプロジェクト記述を絞るよりも「直近5年以内の経験に重点化する」方針で整理すると読みやすくなります。
職務要約の書き方
職務要約は、採用担当者が最初に目を通す箇所です。ここで「この人が何をできる人か」が伝わらないと、以降のセクションが読まれないリスクがあります。
書く要素は以下の3点です。
- 経験年数と主な担当領域：「Kubernetes基盤の構築・運用を中心に、CI/CDパイプラインの設計・標準化に従事してきました」など
- 規模感・文脈：開発チームへの内部プラットフォーム提供、マルチクラウド環境の管理、といった背景
- 強みの方向性：設計・自動化・可観測性・セキュリティなど、自分の軸となる専門性
「あらゆる領域に対応できます」という書き方は、かえって特徴が掴みにくくなります。経験の幅よりも「何に最も深く関与してきたか」を前面に出すほうが、担当者の印象に残りやすい傾向があります。
スキルマップの記述方針
スキルマップは技術スタックを列挙するだけでなく、経験の深さが伝わるように分類することが重要です。習熟度の表現には「設計・構築・運用が可能」「運用・改善が中心」「知識・補助的使用レベル」などの段階を設けると、採用担当者が判断しやすくなります。
以下は記載カテゴリの例です。
| カテゴリ | 例示する技術・ツール |
|---|---|
| コンテナ・オーケストレーション | Kubernetes（EKS/GKE/AKS）、Helm、Argo CD、Fluxなど |
| CI/CDパイプライン | GitHub Actions、CircleCI、Tekton、Jenkinsなど |
| IaC・構成管理 | Terraform、Pulumi、Ansible、Crossplaneなど |
| クラウドプラットフォーム | AWS、GCP、Azure（使用サービスを具体的に列挙） |
| 可観測性・モニタリング | Prometheus、Grafana、Datadog、OpenTelemetryなど |
| セキュリティ・ガバナンス | OPA/Gatekeeper、Trivy、Vault、SCIMなど |
| 開発言語・スクリプト | Go、Python、Bash（ツール開発・自動化スクリプト用途） |
スキルマップで留意したいのは、「使ったことがある」レベルのものと「設計から担当できる」レベルのものを混在させないことです。後者に絞って記載するほうが信頼性は高くなります。
職務経歴の記述方法：ケーススタディ
プロジェクト単位の記述は、以下の構造で書くと情報が整理されます。
①背景・課題 → ②担当範囲・役割 → ③取り組み内容 → ④成果・変化
記述例（実例の型）
以下は「社内Kubernetes基盤の整備」プロジェクトを想定した記述の型です。
【プロジェクト概要】 開発者100名規模のプロダクト組織において、サービスごとに個別管理されていたインフラ環境を統合し、開発者が自律的にデプロイ・運用できる内部プラットフォームを整備するプロジェクトを担当。
【担当範囲・役割】 プラットフォームチーム4名（うち自身がリード）にて、Kubernetes（EKS）上へのマルチテナント基盤設計・構築から、Argo CDを用いたGitOpsパイプラインの整備、Namespaceごとのリソースポリシー設計（OPA/Gatekeeper）まで一貫して担当。
【主な取り組み】
- EKS上にマルチテナント構成を設計し、開発チームごとの権限分離・リソースクォータ管理を実装
- Terraformモジュール化による環境構築の標準化（新規サービス環境の立ち上げ工数を削減）
- Prometheus＋Grafanaによる可観測性レイヤーの整備と、アラートルールのSLO連携
【成果】 新規サービスの環境立ち上げリードタイムが従来比で大幅に短縮。開発者からのインフラ関連問い合わせ件数が減少し、開発チームの自律的なデプロイ頻度が向上した。
この記述例で重要なのは、「Kubernetesを使った」という事実だけでなく、「何人規模の組織の、どのような課題に対して、どこまで設計・判断したか」が読み取れる点です。成果は定量的な数値を書ける場合はそれが望ましいですが、開示できない場合は「傾向としての変化」（短縮された・減少した・向上した）を明記することで、評価者が経験の意味を理解しやすくなります。
採用担当者・面接官が実際に確認するポイント
プラットフォームエンジニアの書類選考において、採用側が見る観点を整理すると以下のようになります。
| 確認ポイント | 書類での示し方 |
|---|---|
| 設計判断の経験があるか | 「要件定義から担当」「設計方針を策定」などの表現を使う |
| プロダクトチームとの協働経験 | 「開発者体験（DX）改善」「内部顧客向けの運用」など文脈を記載 |
| 自動化・効率化への志向性 | IaCや自動化ツールの具体的な適用事例を記述する |
| セキュリティ・ガバナンス意識 | ポリシー設計・コンプライアンス対応の経験に言及する |
| スケールへの対応経験 | チーム規模・サービス数・トラフィック規模の目安を添える |
「担当した」という記述だけでは、実施者（Doer）なのか設計者（Designer）なのか判断できません。前者と後者では、シニアポジションでの評価が大きく変わる傾向があります。
よくある失敗パターン
①「環境構築・運用」という表現だけで終わっている
「AWS環境の構築・運用を担当」という記述は、設計関与度・規模感・課題背景がすべて不明です。「200サービスが稼働するマルチアカウントAWS環境において、Landing Zone設計を担当」のように、文脈を加えることで読み手の理解が深まります。
②技術スタックの網羅性を優先している
「使ったことがある技術」を全件列挙すると、強みの核心が見えにくくなります。職種・レベルに見合った「設計・構築まで担当した技術」と「補助的に扱った技術」を分けて記載することを推奨します。
③成果の記述が「〜を実現した」で止まっている
「高可用性を実現した」「安定稼働を維持した」という表現は評価が難しいです。「SLO 99.9%に対して達成率が改善した」「前四半期比でインシデント件数が減少した」など、比較基準を加えると評価者の判断がしやすくなります。
よくある質問
Q. SREやインフラエンジニアの経験がある場合、そのまま記載してよいですか？
職種名ではなく「担当した内容」ベースで整理することを推奨します。SREとして取り組んだ可観測性基盤の設計や、インフラエンジニアとして行ったIaC化・自動化の経験は、プラットフォームエンジニアの文脈で十分に評価されます。職種名にとらわれず、「開発者向けの基盤整備に関わった経験」として再構成することで、応募職種との関連性が伝わりやすくなります。
Q. 経験年数が3年未満の場合、書類で不利になりますか？
経験年数そのものよりも、「設計・判断に関与した経験があるか」「技術選定の背景を説明できるか」を重視する企業が増えています。年数が短くても、担当プロジェクトにおける自身の貢献範囲・意思決定の経緯を具体的に記述することで、評価を得られるケースは少なくありません。
Q. 資格は記載すべきですか？
AWS認定（Solutions Architect・DevOps Engineerなど）、CKA/CKAD（Kubernetes認定）、HashiCorp Terraformアソシエイトなどはプラットフォームエンジニアの文脈で関連性が高く、記載することが望ましいです。ただし、資格取得の時期が古く実務との乖離がある場合は、「現在の実務スキル」を本文で明示した上で補足的に記載する形が自然です。
Q. 職務経歴書の分量はどの程度が適切ですか？
経験年数5〜10年程度であればA4・2〜3枚が目安です。枚数を増やすことよりも、直近3〜5年の経験に情報を集中させることを優先してください。古い経験については「プロジェクト名・期間・担当概要」程度に圧縮し、詳細は面接で補う設計のほうが書類全体の読みやすさが上がります。
まとめ
プラットフォームエンジニアの職務経歴書において最も重要なのは、「何を使ったか」ではなく「どの粒度で設計・判断に関与したか」を伝えることです。職種名の定義が企業によって異なる以上、担当内容・役割・成果を構造的に記述し、応募先のポジション要件と自身の経験を読み手が結びつけられる状態にすることが書類通過の基本条件になります。スキルマップの整理・プロジェクト記述のフォーマット化・成果の比較基準の明示という3点を改善するだけで、書類の完成度は大き