# SRE・Platform Engineering 入門ガイド（経営層向け）
**〜非エンジニアでも理解できる「デジタルインフラ投資」の考え方〜**

---

## この文書を読むべき理由

もしあなたが：
- 「システムが動いてるのに、なぜインフラチームに予算が必要なのか分からない」
- 「開発者を増やせば開発が速くなるはずなのに、なぜ速くならないのか」
- 「障害が起きたら対応すればいいのでは？」

と感じたことがあるなら、この文書はあなたのためのものです。

**所要時間：10分**
**この文書を読むと：** デジタルサービスを支える「見えないインフラ」への投資判断ができるようになります。

---

## 1. 前提：デジタルサービスは「建物」ではなく「都市」

### よくある誤解

「システムは一度作れば、あとはメンテナンスだけで動き続ける」

→ **これは誤りです。**

### 実際は

デジタルサービスは：
- 毎日成長し続ける（ユーザー増、機能追加）
- 絶えず変化する環境に適応する必要がある（技術の進化、セキュリティ脅威）
- 24時間365日、休まず動き続ける必要がある

**つまり、デジタルサービスは「都市」に近い。**
都市には警察・消防・上下水道・道路整備が必要なように、デジタルサービスにも「見えないインフラ」が必要です。

---

## 2. SREとは何か：デジタル都市の「警察・消防」

### SRE = Site Reliability Engineering（サイト信頼性エンジニアリング）

**一言で言うと：**
「サービスが安定して動き続けるための、予防と対応を行うチーム」

### 警察・消防との類似点

| 警察・消防 | SRE |
|---|---|
| 火事や犯罪が起きたら駆けつける | システム障害が起きたら対応する |
| 防災訓練、パトロールで予防 | 監視システム構築、障害予測で予防 |
| 消防設備の点検 | システムの健全性チェック |
| 防犯カメラ・街灯の設置 | 監視基盤・アラートの構築 |
| 大規模災害への備え | トラフィック急増への備え |

### SREの仕事内容

**①予防活動（70%）**
- システムの監視基盤を作る
- 障害を起こさないアーキテクチャ設計
- キャパシティプランニング（「3ヶ月後にサーバー増強が必要」など）
- 自動化による人的ミス削減

**②対応活動（30%）**
- 障害発生時の緊急対応
- 原因分析と再発防止策
- ポストモーテム（振り返り）

### よくある誤解

❌「問題が起きたら呼ばれる人たち」
⭕「問題を起こさない仕組みを作る人たち」

---

## 3. Platform Engineeringとは：デジタル都市の「道路・上下水道」

### Platform Engineering = 開発者が効率的に働けるインフラ整備

**一言で言うと：**
「開発者全員が自分で安全にデプロイできる『セルフサービス基盤』を作るチーム」

### 都市インフラとの類似点

| 都市インフラ | Platform Engineering |
|---|---|
| 水道：蛇口をひねれば水が出る | デプロイ：ボタンを押せば本番反映 |
| 道路：誰でも目的地に行ける | CI/CD：誰でも安全にリリースできる |
| 電力網：どの家にも電気が届く | 監視基盤：全サービスに監視が入る |
| 下水道：見えないが必須 | ログ基盤：見えないが解析に必須 |

### なぜ必要か：開発者の時間の使い方

**Platform Engineeringがない場合：**

開発者が毎回手作業で：
- サーバーを立ち上げる（30分）
- デプロイ設定を書く（1時間）
- 監視設定を追加（1時間）
- 誰かの承認待ち（数時間〜数日）

**Platform Engineeringがある場合：**

開発者がボタン一つで：
- 標準化された環境が自動起動（3分）
- 自動デプロイ（5分）
- 監視も自動設定済み
- 承認不要（ガードレール付き）

### ビジネスインパクト

**例：50人の開発チーム**

- デプロイ1回あたり2時間の削減
- 週20回デプロイ × 50週 = 年間2,000時間削減
- エンジニア時給5,000円 × 2,000時間 = **年間1,000万円の工数削減**
- Platform構築費500万円 → **半年で投資回収**

---

## 4. なぜ投資が必要か：「見えない損失」を可視化する

### 投資しない場合のコスト

#### ケース1：大規模障害

- ECサイトが2時間ダウン
- 時間売上500万円 × 2時間 = **1,000万円の機会損失**
- 顧客の信頼失墜（数値化困難だが、最も大きい損失）

**SREに年間500万円投資していれば、防げた可能性が高い。**

#### ケース2：開発速度の低下

- デプロイに毎回半日かかる
- 週1回しかリリースできない
- 競合は毎日リリース → **市場投入スピードで負ける**

**Platform Engineeringに年間1,000万円投資すれば、毎日リリース可能に。**

#### ケース3：優秀なエンジニアの離職

- 「手作業ばかりで、やりたいことができない」
- エンジニア1人の採用・育成コスト：500万円〜1,000万円
- **年間2-3人離職 = 1,500万円〜3,000万円の損失**

### 投資の考え方：「保険」として見る

企業は火災保険に年間数百万円払います。「火事が起きないから無駄」とは言いません。

**同じ考え方で：**
- 期待損失：年間3,000万円（障害リスク）
- 投資額：年間500万円（SRE）
- **投資額 < 期待損失 なら、合理的**

---

## 5. どれくらい投資すべきか：3つの目安

### ①エンジニア比率

**目安：開発者10〜20人に対して、SRE 1人**

- 開発者50人 → SRE 3〜5人
- 開発者100人 → SRE 5〜10人

※サービス規模や複雑性により変動

### ②売上比率

**目安：IT予算の10〜20%を運用・保守（SRE含む）に**

- 年間IT予算1億円 → 1,000万〜2,000万円

### ③ダウンタイムコストから逆算

**計算式：**
1. 1時間のダウンタイムで失う売上を計算
2. 年間許容ダウンタイムを決める（例：99.9% = 8.76時間）
3. 潜在的年間損失を算出
4. その10〜20%を投資

**例：**
- 1時間のダウンタイム損失：500万円
- 年間許容ダウンタイム：8.76時間
- 潜在的損失：4,380万円
- **投資額：500万〜1,000万円**

---

## 6. よくある誤解と真実

### 誤解1：「今動いてるから大丈夫」

**真実：** システムは絶えず劣化します（技術的負債、キャパシティ限界）。今動いていても、3ヶ月後は分かりません。

### 誤解2：「障害が起きたら対応すればいい」

**真実：** 大規模障害1回のダメージ（売上損失 + 信頼失墜）> 予防的投資の数年分

### 誤解3：「開発者を増やせば速くなる」

**真実：** インフラが整っていないと、むしろ遅くなります（手作業の待ち行列、属人化、障害増加）。

### 誤解4：「クラウドを使えば運用不要」

**真実：** クラウドは「道具」であり、使いこなすにはSREやPlatform Engineeringが必要です。

### 誤解5：「SREは開発に貢献しない」

**真実：** SREが作る基盤の上で、開発者は安心して開発できます。土台がなければ、家は建ちません。

---

## 7. 投資しないとどうなるか：負のスパイラル

```
予算削減
   ↓
人員不足・ツール不足
   ↓
障害増加・開発速度低下
   ↓
「なぜこんなに不安定なんだ？」
   ↓
さらに予算削減（悪循環）
```

**これは警察・消防でも同じ構図：**
予算削減 → パトロール減少 → 犯罪増加 → 「警察は何やってるんだ」 → さらに予算削減

---

## 8. 経営判断のチェックリスト

以下の質問に「No」が多い場合、SRE・Platform Engineeringへの投資を検討すべきです：

### SRE関連

- [ ] 過去1年間、サービスに影響する障害がゼロだった
- [ ] 障害発生時、30分以内に対応できる体制がある
- [ ] システムの監視基盤が整っており、問題を事前に検知できる
- [ ] 3ヶ月後のキャパシティ予測ができている
- [ ] 全エンジニアが障害対応のドキュメントを理解している

### Platform Engineering関連

- [ ] 開発者は1日に何度でもデプロイできる
- [ ] 新しいサービスを立ち上げるのに1日以内
- [ ] デプロイ作業は完全自動化されている
- [ ] 開発者は「待ち時間」にストレスを感じていない
- [ ] エンジニアの離職率が業界平均以下

---

## 9. 次のアクション：何から始めるか

### ステップ1：現状把握（1ヶ月）

- 過去1年の障害履歴と損失額を計算
- 開発者にヒアリング（何に時間を取られているか）
- デプロイ頻度とリードタイムを測定

### ステップ2：小さく始める（3ヶ月）

- SRE 1〜2人を採用 or 社内から異動
- 1つのチームでPlatform Engineering施策を試験導入
- 効果測定（デプロイ時間、障害件数、開発者満足度）

### ステップ3：段階的拡大（6ヶ月〜）

- 効果が出たら予算を増やし、全社展開
- 定期的にROIを測定し、経営会議で報告

---

## 10. まとめ：デジタルインフラは「コスト」ではなく「投資」

### 最後に理解すべきこと

1. **デジタルサービスは「都市」である**
   警察・消防・道路が必要なように、SREとPlatform Engineeringが必要

2. **「見えない損失」は実在する**
   障害による売上損失、開発速度の低下、人材流出

3. **予防的投資はROIが高い**
   障害1回の損失 > 予防的投資の数年分

4. **業界標準は「開発者10〜20人にSRE 1人」**
   これを下回ると、負のスパイラルに陥るリスク

5. **投資判断は「リスク管理」である**
   火災保険と同じ：起きないことに賭けるのではなく、起きた時に備える

### 経営者としての視点

**「SREやPlatform Engineeringに投資するか」ではなく、
「どれだけ投資すれば、事業成長を支えられるか」を問うべきです。**

デジタルサービスが事業の中核なら、そのインフラへの投資は **optional（任意）ではなく、mandatory（必須）** です。

---

**この文書についての質問や、具体的な投資計画の相談は、CTOまたはVPoEにお声がけください。**