「信頼性向上は組織全体の取り組みだ」という掛け声に異論を唱えるエンジニアはいない。しかし現実には、SREの民主化はうまくいかないことが多い。ログラス社のSREエンジニア・見形氏が公開したこの記事は、その「なぜうまくいかないのか」を1年間の実践を通じて正直に語っており、同じ悩みを抱えるSRE・プラットフォームエンジニアには刺さる内容だ。
民主化の壁は「悪意」ではなく「認知負荷」だった
1年前に掲げた3つの方針——アラート整理・CI/CD再整備・インシデント対応再構築——は一定の成果を出した。しかし最大の気づきは「掛け声だけでは民主化は実現しない」という厳しい事実だった。
問題の核心はこうだ。新サービスをひとつデプロイするだけで、開発者は以下を全部やる必要があった：
- Terraformでネットワーク・IAMロール・ECSタスク定義を記述
- CI/CDパイプラインの設定
- 監視ダッシュボードの用意
- セキュリティグループの調整
4〜5箇所のリポジトリ・設定ファイルに手を入れる必要があり、SREチームへの依頼が発生。レビュー待ちで1〜2週間ブロックされることも珍しくなかった。「自分でやるより頼んだほうが早い」というマインドが定着し、民主化とは真逆の悪循環が生まれていた。
マルチプロダクト展開が課題を一気に顕在化させた
ログラスは複数プロダクトへの展開を進める中で、さらなる問題が噴出した。チームごとに「動いているからOK」という基準で設定が作られ、同じ組織のサービスなのに設定のばらつきが拡大。リソースリミット未設定・ヘルスチェック抜けが散見され、ベストプラクティスが属人化していく。
この状況が、Platform Engineeringという選択に踏み切る最大の動機となった。
Platform Engineeringの実装：EKS + Helm + GitOps
2025年8月頃、まだ共通基盤の方針が正式決定する前から、EKSを使ったプロトタイプをひっそり作り始めていた点が面白い。最小のHelmチャートとGitOpsの仕組みを構築し、社内sandboxとして公開。方針決定時にはすでに手触り感がある状態を作るというアプローチは、プラットフォーム構築の現実的な戦略として参考になる。
現在整備している要素は4つ：
- Golden Path（推奨される標準化されたパス）
- セルフサービス（チケット不要で開発者が自分で環境構築）
- 宣言的な運用モデル（マニフェストベース管理）
- ガードレール（セキュリティ・ガバナンスを仕組みとして組み込み）
EKSを選んだ理由は明快だ。KubernetesのNamespace/RBACでマルチテナント境界を表現でき、Helmテンプレートで共通チャートを提供し、開発者はvalues.yamlに必要な値だけを書けばよい。
# 開発者が管理するのはこれだけ（values.yaml のイメージ）
app:
image: your-registry/your-app:v1.2.3
port: 8080
resources:
cpu: "500m"
memory: "256Mi"チャートやオペレータの管理はSREチームが担い、軽量なアプリであれば10分程度でデプロイできる状態が実現した。
「仕組み」が変えたもの——SREチームと開発者それぞれの変化
開発者側のフィードバックとして「マイクロサービス的なアプローチを進めやすくなった」という声が挙がっている。プラットフォームが選択肢を広げた証拠だ。一方で「自由な設定を許可した部分がかえって認知負荷になった」という失敗談も正直に公開しており、設定をどこまで開放しどこからプラットフォームが吸収するかの塩梅は使う側との対話で磨いていく必要があるとしている。
SREチーム側にも変化があった。「インフラだけでなくシステム全体に興味を持てるようになった」という声は、Platform Engineering推進がチームのスコープを広げる効果をもたらしている。
「努力でSREを回す」のではなく「仕組みでSREを実現する」——この思想の転換は、スタートアップがスケールしていく過程で必ず直面する壁だ。元記事には時系列での取り組みや開発者の生の声など、このまとめに収まりきらない具体的な内容が詰まっている。マルチプロダクト展開を控えている組織のSREやプラットフォームエンジニアは必読だ。