西田 由貴の学習プラン

SREエンジニア → プラットフォームエンジニア

更新 最終更新: 2026-09-08
西田 由貴のアバター画像

西田 由貴(29歳)

SREエンジニア プラットフォームエンジニア

プラットフォームエンジニア: 開発者体験を最大化する内製プラットフォームを設計・構築・運用し、開発者が価値を届けやすい環境を提供するエンジニア職種。

完全プランを見る

プロフィール / 経歴

Web系事業会社のSREチームで4年勤務。Datadogを用いた監視基盤運用、SLO設定、オンコール対応、ポストモーテム運営など信頼性領域を中心に経験を積んできた。担当サービスのKubernetes化やGitOps化にも関わったが、設計の中心は別チームが行っており、自分はあくまで『運用側』の立場だった。サービス数が増え、開発チームから『デプロイ環境を統一してほしい』『新規マイクロサービスを安全に立ち上げたい』という要望が増える中、社内開発者プラットフォーム(IDP)の構築を主導する役割に挑戦したいと考えている。 これまでSREエンジニアとして現場での運用と改善を積み重ねてきたが、事業のスケールに伴いインフラへの要求は質・量ともに増大し、属人化した知識や場当たり的な対応では限界を感じる場面が増えている。特に信頼性・可観測性・コスト最適化・セキュリティを横断的に設計できる人材の不足を痛感しており、自分が次のステップとしてプラットフォームエンジニアを担うことで、組織全体の技術的意思決定に貢献したいという思いが強くなっている。そのために体系的な知識の再学習と、現場で得た経験の言語化を並行して進めている。

きっかけ・モチベーション

「SREとして守ってきた信頼性の知見を、開発者がデフォルトで享受できる『製品』として提供したい。黄金パスを整えることで、各チームが車輪の再発明をせずに本来の価値創出に集中できる環境を作り、組織全体のデリバリ速度と安定性を同時に底上げするプラットフォームエンジニアになる。 日々の運用で見えてきた課題を、その場しのぎではなく根本から設計し直したい。プラットフォームエンジニアとしてアーキテクチャ意思決定の責務を負うには、特定ベンダーや特定スタックに閉じない普遍的な原理原則を自分の言葉で語れるレベルまで引き上げる必要があると考えている。学習を通じて短期的なキャッチアップではなく、長期にわたって判断軸として機能する基盤を築きたい。」

— 西田 由貴

学習ストーリー

西田 由貴さん本人の学習設計の語り

既に持つSREとKubernetesの実務経験を起点に、プラットフォームエンジニアリング特有の発想——黄金パス、Backstage的ポータル、開発者体験(DevEx)——を学んでいく。チームトポロジーを通じてストリームアラインドチームとイネーブリングチームの関係を理解し、IaCと監視を組み合わせてセルフサービス基盤を設計できる視座を育てる。学習成果は社内勉強会でアウトプットする。 学習は週末と平日夜の限られた時間で進めるため、最初に全体像を掴んでから各論に入る順序を徹底している。読んだ内容はその週のうちに小さな検証環境で手を動かして確かめ、理解が曖昧な箇所は同僚や勉強会で議論することで定着させている。プラットフォームエンジニアとして通用する判断力を身につけるため、単なる知識の収集ではなく『なぜそう設計するのか』を説明できる状態を毎章のゴールに置いている。挫折しそうになったときは、最初に書き出した転身後の理想像を読み返して軌道修正している。

現在の課題

  • プラットフォームを『プロダクト』として顧客(開発者)視点で設計した経験がない
  • Backstage等の開発者ポータルの導入実績がない
  • プラットフォームのROIや採用率を定量的に語る指標を持っていない
  • 他チームとの合意形成と段階的ロールアウトの設計経験が浅い

スキルギャップ

現在のスキル水準とプラットフォームエンジニアに必要な水準を並べ、何を伸ばすべきかを可視化しています。

Kubernetes運用
4 5
監視/SLO
4 5
AWS
4 4
Terraform
3 4
CI/CD
3 4
インシデント対応
4 4
Go/Python
3 3
プラットフォーム設計
2 4

埋めるべきギャップ

IDP/開発者ポータル設計 ゴールデンパス設計 Terraformによる大規模管理 DevExの定量化 プラットフォームのプロダクト思考

最初の3冊(ここから始める)

迷ったらこの順番で読むのが推奨。基礎 → 実践 → 視座を上げる、という流れで構成されています。

  1. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計の表紙

    なぜこの本か

    SREからプラットフォーム側に移るうえで最も重要なのが組織設計の理解。プラットフォームチームの責務範囲とインタラクションモードを整理でき、社内提案の言語化に直結する。 プラットフォームエンジニアを目指す上で、本書が扱うテーマは現状の自分に決定的に欠けている領域であり、日々の業務で直面する課題を体系立てて理解し直すために最も優先度の高い一冊と判断した。読了後はチーム内で要点を共有し、設計判断の場で参照できるレベルまで落とし込む計画である。

学習プラン全体像

5
ヶ月
週8
時間
3
フェーズ
  1. Phase 1: プラットフォーム設計の基礎

    8週間

    Kubernetesパターンとチーム設計、IDPの全体像

    このフェーズで読む本

    チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計の表紙
  2. Phase 2: IaCとデリバリ自動化

    6週間

    Terraformと CI/CDで再現性のある基盤を作る

    このフェーズで読む本

  3. Phase 3: 可観測性とSLO高度化

    6週間

    プラットフォームレイヤーでの可観測性提供

    このフェーズで読む本

    SLO サービスレベル目標の表紙

    SLO サービスレベル目標

    Hidalgo Alex、山口 能迪、成田 昇司

    中級
    Amazonで購入する

似た背景のペルソナ

同じ職種・近いレベル感を目指す他のペルソナです。学習プランや読む順番のバリエーションとして参考にしてください。

プラットフォームエンジニアのロードマップへ

西田 由貴さんの学習プランは「プラットフォームエンジニア」を目指す一例です。 職種全体のロードマップ・必要スキル・代表的な書籍は専用ページで体系的に確認できます。

プラットフォームエンジニアのロードマップを見る →