開発者だった私がPlatform Engineeringの道を志す理由
はじめに
PE（Platform Engineer）を目指しているokcclと申します。
GitHubでポートフォリオを作成しているのですが、その紹介や背景説明の場としてZennを始めてみました。
初回記事なので軽く自己紹介もしつつ。
もともと私は新卒で入った小規模SIerでWebアプリの開発をやってました。バックエンドをC#で作ってましたと説明することが多いですが、実態としてはローコードツールが特に流行ってた時期で、案件としては一番多かったです。
ローコードってブラックボックスが多くて扱ってると不安になるところがあって、やがて、もっと自分で関われる範囲を増やしたいと考えるようになりました。というわけで、より上流を担当できるITコンサルに転職して、それが現職です。いくつかの案件を掛け持ちしてますが、主にはKubernetesの構築・設計・運用支援の案件を担当してます。
Platform Teamの誕生を内側から見ていた
実はこの案件の始まりって、k8sを知ってた担当者が抜けて、独学でかじっていた程度の私に声がかかっただけでした。最初の1年は運用のタスクを回すのにも苦労しましたが、必死に勉強しつつ、手順書などドキュメントを整備して属人化を防ぐことでチームに貢献してました。結果としてある程度評価していただき、やがて構築や設計のフェーズにも関わるようになりました。かれこれ5年ほど、今もお世話になっております。
そんなこんなで気づいたらインフラの人間になっていたわけですが、現場ではその後もいろいろな変化がありました。チームメンバーが何度か入れ替わり、徐々にk8sの専門家が増えてチームのレベルが上がっていったんですよね。Argo CDが特に印象的ですが、ポートフォリオ内でも触れてる様々なツールが導入され、k8sを動かすのに精いっぱいだったところから「Platform Team」としての姿になっていくところを中で経験することができました。
その過程である概念に出会うんですが、それが「Golden Path」というものです。
2〜3時間が20分になった。でも——
正直、「Golden Path」を作ろうと言われた段階では、意味がよくわかりませんでした。k8s上の開発環境を開発者に払い出すのが私の主な業務の一つだったわけですが、その作業を「自動化して楽にしようね」くらいの話かな、と説明をきいて思ってました。
まぁでもやりたいことの方向性はわかったので、手は動かしました。Argo CDを活用したりスクリプトを書いたりして、環境の払い出し作業を半自動化。それまで2〜3時間かかっていた作業が20分程度になりましたので、自分としてはけっこうな達成感でしたよ。
でも今ならわかります。
早くなったのは自分の作業だけだと。
開発者のフローは何も変わっていなかったんです。Excelに設定値を書いて申請して、PEチームリーダーがレビューして、私が環境を作って、確認して、引き渡す。このフローはそのままでした。しかもdev/stg/prodの3環境をセットで申請する前提になっていたので、「とりあえずdevで試したい」というだけでも全部書かないといけなかったり。
開発者からすれば「便利になった」実感はほぼゼロだったと思います。
Golden Pathが「もう一歩先」にあると気づいた
今回このポートフォリオを設計するにあたって「Golden Path」の本当の意味というか、目指すものを改めて知って、腹落ちしました。
目指していた姿はもう一歩先にあったと。
開発者が必要なときにさっと環境を作れる。使い捨てのdev環境くらいは申請なしに自分で作れる。PEチームはそれを安全に実現する「道」を整備する。
それが「Golden Path」なんですね。
私が「できた」と思っていたのは、道の途中だったわけです。
自分たちが楽になればいいのではない、開発者の体験を向上させるのがPlatform Engineerの役割である。
当たり前だと怒られそうですが、日々の業務の中ではしっかりと意識できてなかったですね。反省です。
だからこのポートフォリオを作ることにした
もともとWebアプリを書いていた人間として、「開発者がインフラを意識しなくていい環境」がどういうものか、そのありがたみも含め、体感としてわかっているつもりです。
それを今度は作る側として実現したい。
そのためにk8sを使ったローカルプラットフォームをゼロから設計・構築するポートフォリオを始めました。
Helm Library Chart（開発者の記述量を最小化するため） や Kyverno（ポリシー強制による安全なセルフサービスの実現）など、現職では導入できていない仕組みも含めて、「自分が理想とするプラットフォーム」を形にしていくつもりです。
k3dによるローカルk8sクラスタを土台に、GitOps・Observability・CI/CDパイプライン・PostgreSQL HAまでを一貫して構築します。
詳細はGitHubのポートフォリオページにまとめています。 現在Phase11まで完了済み。見ていただけると嬉しいです。
| Phase | テーマ | 解決すること |
|---|---|---|
| 0 | Local Foundation |
make init 1コマンドで全ツールを再現。環境差異をコードで排除 |
| 1 | k3d Cluster IaC |
cluster.yaml によるクラスタ構成の宣言化。1コマンドで作成・破棄・再作成 |
| 2 | GitOps & Secrets | Argo CD による Git = クラスタ状態の実現。ESO で Secret をコードから分離 |
| 3 | Connectivity | ingress-nginx + cert-manager。*.localhost で即 HTTPS 公開できる基盤 |
| 4 | Observability | LGTM スタック（Loki / Grafana / Tempo / Mimir）でメトリクス・ログ・トレースを統合 |
| 5 | Platform Abstraction | Helm Library Chart で K8s マニフェストを抽象化。開発者は values.yaml だけ書けばよい |
| 6 | Golden Path (CI/CD) | push → イメージビルド → GitOps PR → ArgoCD 自動同期までを完全自動化 |
| 7 | Guardrail (Kyverno) | ポリシーエンジンで latest タグ禁止・リソース制限必須などをデプロイ前に強制 |
| 8 | Data & State | CNPG Operator による PostgreSQL HA 構成と MinIO を使ったバックアップ |
| 9 | Resilience & Chaos | 3ノード構成 + Anti-Affinity + kubectl drain による障害シミュレーションと RTO 計測 |
| 10 | DX & DR | SOPS × Age による Secrets as Code。make init 一発での DR 手順を確立 |
| 11 | Hardening & Exploration | Trivy / Argo Rollouts / KEDA / Crossplane / Cilium など個別の検証 |
| 12 | IDP（Internal Developer Platform） | Keycloak（SSO・認証認可の分離）、Backstage（セルフサービス窓口）、vCluster（仮想クラスタ払い出し） |
| 13 | Cloud Expansion（AWS） | Terraform + EKS に同じ GitOps フローを展開。ツールの比較や検証。 |
| 14 | Cloud Expansion (GCP) & Multi-Cloud Comparison | GKE に展開し AWS との差分を確認。Crossplane でマルチクラウド管理を実証 |
Discussion