共通基盤を作るかどうか ─ 外さない 8 軸
このシリーズの結びとして 2 つを扱う：
- そもそもこの基盤を作るべきか？ ── “作らない判断” を含む
- 作ると決めたら、外さないための 8 軸 ── 全章を集約したチェックリスト
”作らない判断” を含めた意思決定
新しい共通基盤を立ち上げる場面で、最初に問うべきは 本当に作るべきか。
作らないでいい場合
| 状況 | 代替策 |
|---|---|
| 利用者が 1-2 ドメインのみ | shared library で十分 |
| 機能が枯れた SaaS で代替できる | SaaS 採用（Auth0、Twilio、Datadog 等） |
| OSS で代替できる | OSS をそのまま運用 |
| 試験的な需要 | 各 Stream Team で独自実装 |
| 短命（< 1 年）の用途 | 一時的に shared utility |
「作る」は最終手段。作らずに済むなら作らない。
作るべき場合
| 状況 | 理由 |
|---|---|
| 複数の Stream Team が同じ問題を抱える | 重複が大きい |
| 専門性が高く、各チームでは持てない | 認可、暗号、決済等 |
| 全社的に標準化したい | セキュリティ、監査、Compliance |
| SaaS では満たせない要件（cost / 規制） | 自前で持つ価値がある |
Build vs Buy vs Adopt vs Copy
Spotify Backstage の元になった考え方 や Adrian Cockcroft の Microservices でよく語られるフレーム：
graph TB
Q[新しい基盤の必要性]
Q --> Buy[Buy: SaaS 購入]
Q --> Adopt[Adopt: OSS をそのまま]
Q --> Copy[Copy: OSS を fork して改造]
Q --> Build[Build: フルスクラッチ]
Buy -.推奨度.-> 1[1: 最も推奨]
Adopt -.推奨度.-> 2[2]
Copy -.推奨度.-> 3[3]
Build -.推奨度.-> 4[4: 最後の手段]
style Buy fill:#e1ffe1
style Build fill:#ffe1e1「Build」を選ぶ前に、Buy / Adopt / Copy を真剣に検討する。自前で作るのは最後の手段。
Build を選ぶときの覚悟
自前で作ると：
- 長期保守責任（5-10 年）
- セキュリティパッチ追従（業界標準を 1-2 年遅れで追いかける羽目に）
- 専門知識の蓄積（属人化のリスク）
- 機能拡張が止まる（SaaS なら勝手に進化する）
「作るのは簡単、保守するのが大変」が、Platform 領域では特に当てはまる。
“薄く始める” 原則
第 2 章の TVP の原則を再確認：
Wiki ページ 1 枚から始めても良い。
graph LR
V0[v0: Wiki] --> V1[v1: Script + Doc]
V1 --> V2[v2: 最小 API]
V2 --> V3[v3: SDK]
V3 --> V4[v4: Self-service Portal]
V4 --> V5[v5: Platform-as-a-Product]
Note1[各段階で<br/>「ここで止めるべきか」を問う]
style V0 fill:#e1ffe1段階ごとに進化を止める判断ができる。「もう SaaS で十分なフェーズに来た」「もう自前にする価値がある」を、各段階で判定する。
外さない 8 軸 ── シリーズの集約
ここまでの 14 章を、新規 / 既存基盤の点検チェックリストとして集約する。
軸 1：責務と境界（TVP）
□ 何を提供し、何を提供しないかが明確か？
□ TVP（最小限）から始めているか？
□ 利用者ドメインの責務を奪っていないか？
□ Boring API を選んでいるか？思い出すべき章：第 1-2 章
軸 2：抽象度と制御の所在
□ 抽象度は階段状に提供されているか（L1-L4）？
□ Pit of Success のデフォルトが正しいか？
□ Sharp Tools が明示的な引数で残されているか？
□ Library / Framework のどちらを選んだかが意識的か？思い出すべき章：第 3-4 章
軸 3：API 設計と進化容易性
□ Idempotency が POST に保証されているか？
□ エラー設計が構造化されているか（type / code / retry_after）？
□ Versioning 戦略が決まっているか？
□ 後方互換ルール（足すは OK、引くは NG）を守っているか？軸 4：可用性（SLO）
□ 利用者の SLO の和を見ているか？
□ SLI を Metrics で実装しているか？
□ Error Budget を運用ルールに組み込んでいるか？
□ 5 9 を約束する前にコストを見積もったか？思い出すべき章：第 6 章
軸 5：性能とレジリエンス
□ p50/p95/p99 の予算を持っているか？
□ Cache 階層が設計されているか？
□ Backpressure で過負荷時に守れるか？
□ Timeout / Retry / Circuit Breaker / Bulkhead が組み合わされているか？軸 6：セキュリティと可観測性
□ Zero Trust（mTLS / SPIFFE）か？
□ Tenant 分離が tier 別に設計されているか？
□ Policy as Code（OPA / Cedar 等）を使っているか？
□ Three Pillars（Metrics / Logs / Traces）が揃っているか？
□ 利用者が観測できる Dashboard / Status Page があるか？軸 7：マルチテナンシー
□ Isolation tier 戦略があるか？
□ Quota + Rate Limit が tier 別か？
□ Hot tenant 検知 + 対応 (throttle / quarantine) があるか？
□ Per-tenant Metrics で観測できるか？思い出すべき章：第 11 章
軸 8：利用者体験と組織
□ Time-to-First-Win 5 分以内を目指しているか？
□ Golden Path / SDK / Self-service Portal があるか？
□ Documentation が階層化されているか？
□ Platform-as-a-Product の mindset で運用しているか？
□ Platform Team が Gatekeeper になっていないか？8 軸の関係
graph TB
subgraph "前提：作るかどうか"
Z[Build vs Buy vs Adopt]
end
subgraph "境界（軸 1-3）"
A1[責務と境界]
A2[抽象度と制御]
A3[API と進化]
end
subgraph "非機能（軸 4-7）"
A4[可用性]
A5[性能・レジリエンス]
A6[セキュリティ・可観測性]
A7[マルチテナンシー]
end
subgraph "体験（軸 8）"
A8[利用者体験と組織]
end
Z --> A1
A1 --> A2 --> A3
A3 --> A4
A4 --> A5 --> A6 --> A7
A7 --> A8
style Z fill:#fff4e1
style A1 fill:#e1f5ff
style A4 fill:#ffe1e1
style A8 fill:#e1ffe1このシリーズが伝えたかったこと
第 1 章の冒頭で挙げた 3 つの違和感：
「何を作るんだっけ？」「責任はどこまで持てばいい？」「非機能要件、なんでこんなに重い？」
15 章を通って答えはこうだ：
- 何を作るか：TVP の哲学に従う、薄く始めて利用者の声で進化させる
- 責任の境界：利用者ドメインの責務を奪わない、自分の Bounded Context に閉じる
- 非機能要件の重さ：利用者の SLO の和、集約トラフィック、tenant 分離、これらが「桁が違う」の正体
ドメインから来たエンジニアが共通基盤に違和感を覚えるのは、設計の対象が違うから。利用者ドメインなら「Order を作る」が答え。共通基盤なら「Order を作る他チームを支える」が答え。同じ「設計」でも、目線がメタになる。
このメタな目線に慣れることが、共通基盤の設計者になることの本質。15 章を歩き終えた後、あなたが共通基盤に立つときの 足元の地図 が少しでも増えていたら、シリーズの目的は達成された。
関連シリーズ
- Platform Engineering 実践地図 2026：規模・業種別の事例カタログ。本シリーズが「設計論」、姉妹シリーズが「事例集」
- DB 設計の軸 2026：第 16 章の “ドメインから使われる側” がこのシリーズの起点
参考文献・情報源
Team Topologies / 組織論
- Matthew Skelton & Manuel Pais『Team Topologies』
- Thinnest Viable Platform 公式解説
- Platform as a Product 解説
- Melvin Conway “Conway’s Law” 1968
設計哲学
- Brad Abrams “The Pit of Success”
- Jeff Atwood “Falling Into The Pit of Success”
- Martin Fowler “Inversion of Control”
- Robert C. Martin『Clean Architecture』第 30-32 章
API 設計・進化
- Stripe API Versioning
- Stripe Engineering “APIs as infrastructure”
- Brandur “Why Doesn’t Stripe Automatically Upgrade API Versions?”
- Stripe Engineering “Designing robust APIs with idempotency”
SRE / 非機能
Resilience
Multi-tenancy
- AWS SaaS Tenant Isolation Strategies (Whitepaper)
- Microsoft Azure Architecture: Noisy Neighbor antipattern
- Kata Containers
可観測性
認可
Internal Developer Platform
書籍
- Sam Newman『Building Microservices』(O’Reilly, 2nd ed)
- Adam Bellemare『Building Event-Driven Microservices』(O’Reilly)
- Vladimir Khononov『Learning Domain-Driven Design』
- Vaughn Vernon『実践ドメイン駆動設計』
ここまで読んでくれた読者のあなたへ。共通基盤の設計は、ドメインの設計とは別の言語で動いている。慣れない違和感を抱きながら、それでも作る・運用する立場に立つあなたへ、この 15 章が 少しの足場 になっていれば嬉しい。
次にあなたが共通基盤に向き合うとき、8 軸を持って臨めばいい。それがこのシリーズのゴールだった。