2025年9月29日·1 分
Werner Vogels の「You Build It, You Run It」を解説
Werner Vogels が提唱した「You Build It, You Run It」の意味と適用方法を学ぶ：所有権、オンコール、SLO、インシデント対応、安全なリリースの実践。
Werner Vogels が提唱した「You Build It, You Run It」の意味と適用方法を学ぶ：所有権、オンコール、SLO、インシデント対応、安全なリリースの実践。
「You build it, you run it」はストレートな一言で記憶に残りやすいフレーズです。モチベーション用のポスターや「もっとDevOpsになろう」といった掛け声ではありません。これは責任に関する明確な宣言です：サービスをデプロイするチームが、本番でそのサービスがどのように振る舞うかについても説明責任を持つ、ということです。
実務では、機能を設計してコードを書く同じプロダクトチームが次も担います：
それは誰もが一晩でインフラの専門家になるという意味ではありません。重要なのはフィードバックループが現実になることです：リリースがアウトテージ、ページノイズ、顧客の痛みを増やすなら、そのチームが直接それを感じ、学ぶということです。
この哲学は繰り返すのは簡単ですが、実装するのは難しいです。期待を明確にした運用モデルとして扱わなければなりません。「run it」は通常、ある形のオンコール、インシデント対応の所有、ランブック作成、ダッシュボードの維持、そして継続的改善を含みます。
また制約も意味します：チームに「run it」を求めるなら、問題を修正するためのツール、アクセス、権限、そしてロードマップ上の時間を与えなければなりません。
「You Build It, You Run It」が広まる前、多くの企業はソフトウェア開発をリレーレースのように組織していました：開発者がコードを書き、それを運用チームに“壁越しに投げる”と、運用チームがデプロイと稼働を引き受ける。
その手渡しは短期的には解決しました（経験ある人が本番を見てくれる）が、より大きな問題を生み出しました。
別のオプスチームが本番を所有すると、開発者は問題を遅く（あるいはまったく）知ることになります。バグは数日後に「サービスが遅い」や「CPUが高い」といった曖昧なチケットとして現れるかもしれません。その時点ではコンテキストは失われ、ログはローテーションされ、変更を行った人はもうほかへ移っていることが多いです。
手渡しは所有のあいまいさも生みます。障害が発生したとき、開発は「運用がキャッチするだろう」と思い、運用は「開発がリスクのある変更を出した」と思う。結果は予想どおりです：インシデント解決の遅延、同じ失敗モードの繰り返し、チームが顧客体験より自分の最適化を優先する文化です。
「You Build It, You Run It」はループを短くします。同じチームが変更を出し、その振る舞いに対して説明責任を負うと、実践的な改善が上流で起きます：明確なアラート、安全なロールアウト、見やすいダッシュボード、運用しやすいコード。
皮肉なことに、これは多くの場合、配信を速めます。チームがリリースプロセスを信頼し、本番挙動を理解すると、小さな変更をより頻繁に出せるようになります—ミスの影響範囲が小さくなり、問題の診断も容易になります。
すべての組織が同じ人員、コンプライアンス要件、レガシーを抱えているわけではありません。この哲学は方向性であり、スイッチではありません。多くのチームは段階的に採用します—共有オンコール、改善された可観測性、明確なサービス境界から始めて、完全なエンドツーエンドの所有へ移行します。
Amazon の CTO である Werner Vogels は「You build it, you run it」というフレーズを広め、Amazon（と後の AWS）がソフトウェアをプロジェクトとして手渡すのではなく、運用するサービスとして考えてほしいと説明しました。
重要な変化は技術的側面だけでなく心理的な側面でもあります。チームが障害でページされることを知っていると、設計の決定が変わります。標準設定を整えること、明確なアラート、優雅な劣化、ロールバック可能なデプロイ経路を重視するようになります。つまり、ビルドには現実の混沌に備える計画も含まれます。
AWS 時代のサービス思考は、信頼性とスピードを不可欠にしました。クラウドの顧客は API が常に利用可能であることを期待し、改善が四半期ごとの“ビッグリリース”ではなく継続的に届くことを期待します。
その圧力が促したもの：
この哲学は広義の DevOps ムーブメントと重なります：開発と運用のギャップを縮め、ハンドオフを減らし、可用性・レイテンシ・サポート負荷といった成果を開発ループに取り込むことです。また小さな自律チームが独立して出荷できるという考えにも合致します。
Amazon のやり方をそのままテンプレートとしてコピーしたくなりますが、「You Build It, You Run It」は厳格な組織図というよりも方向性です。チーム規模、規制、製品の成熟度、稼働要件によって適応が必要です—共有オンコールやプラットフォームサポート、段階的な導入など。
実用的にこの考えを行動に移すには、/blog/how-to-adopt-you-build-it-you-run-it-step-by-step へ進んでください。
「You Build It, You Run It」は本質的に所有に関する宣言です。チームがサービスを出荷するなら、そのチームは実世界でそのサービスがどう振る舞うかに責任を持ちます—リリース当日のテストが通るかどうかだけではありません。
サービスを運用することは、成果に対してエンドツーエンドで気を配ることを意味します：
通常週では「run it」はヒーロー的対応より日常的な運用が中心です：
このモデルが機能するのは、説明責任が「修正は我々の仕事だ」という意味であり、「誰かを罰するために犯人捜しをする」ことではない場合だけです。何かが壊れたら、目標はシステムのどこがそれを許したか（アラート不足、限界の不明瞭、リスクあるデプロイ）を理解し、その条件を改善することです。
サービスがあいまいだと所有は混乱します。サービス境界（何をするか、依存関係、約束）を定義し、名前付きの所有チームを割り当てましょう。その明確さがハンドオフを減らし、インシデント対応を速め、信頼性と機能が競合するときの優先順位を明確にします。
オンコールは「You Build It, You Run It」で中心的な役割を果たします。変更を出すチームが運用影響（レイテンシのスパイク、デプロイ失敗、顧客の苦情）を直接感じることで、優先順位が明確になります：信頼性作業が「誰か他の人の問題」ではなくなり、より多く出荷する最速の方法は多くの場合システムを落ち着かせることになります。
健全なオンコールは予測可能性とサポートが中心です。
重大度レベルを定義して、システムがすべての欠陥でページを飛ばさないようにする。
シンプルなルール：起こしても結果が変わらないなら、チケットにする。
オンコールは罰ではなくシグナルです。ノイジーなアラート、繰り返す障害、手作業の修復はすべてエンジニアリング作業にフィードバックされるべきです：より良いアラート、自動化、安全なリリース、ページを不要にするシステム設計。
「you run it」が現実なら、チームは意見戦にならない共通の信頼性の話し方が必要です。SLI、SLO、エラーバジェットがそれを提供します：明確な目標と、速さと安定性の公正なトレードオフです。
覚え方：SLI = 指標、SLO = 目標、SLA = 外部への約束。
ユーザー体験に結びつく具体的なもの：
エラーバジェットは SLO を満たしながら許容できる“悪さ”の量です（例：SLO が 99.9% 可用性なら、月次のエラーバジェットは 0.1% のダウンタイム）。
サービスが健全で予算内なら、チームはより多くの配信リスクを取れます。予算を速く消費しているなら、信頼性作業が優先されます。
SLO は信頼性を計画入力に変えます。エラーバジェットが少ないなら、次のスプリントはレートリミット、安全なロールアウトの導入、フラッキーな依存の修正を優先するかもしれません。予算に余裕があれば、プロダクト作業を自信を持って優先できます。
「You build it, you run it」は、本番へのデプロイが日常であり、ハイステークスなイベントでないことが前提です。目標はローンチ前の不確実性を減らし、ローンチ後の影響範囲を限定することです。
サービスを“準備完了”とみなす前に、一般的に必要な運用的基盤：
すべてを一度に全員へリリースする代わりに、影響を制限する手法：
ロールバックを標準機能として扱ってください：安全に戻せるほど、実際の「you run it」は現実味を帯びます。
不確実性を減らす2つのテスト：
軽量に：リポジトリやチケットテンプレートに1ページのチェックリスト（例：「可観測性」「オンコール準備」「データ保護」「ロールバック計画」「容量テスト」「ランブックへのリンク」）。“準備できていない”を普通の状態にしておく方が、本番で学ぶよりはるかにマシです。
インシデントは「you run it」が現実になる場です：サービスが劣化し、顧客が気付き、チームが迅速かつ明確に対応する必要があります。目標はヒーロー的対応ではなく、影響を減らし改善を生む再現可能なワークフローです。
多くのチームは同じ段階に収束します：
実用的なテンプレートが欲しいなら軽量なチェックリストを常備してください（参照：/blog/incident-response-checklist）。
ブレームレスなポストモーテムは「誰もミスをしていない」という意味ではありません。ミスが本番に到達するのをシステムやプロセスがどのように許したかに焦点を当てる、という意味です。それにより人々が早期に詳細を共有しやすくなり、学習が促進されます。
記録すること：
良いポストモーテムは、具体的で所有者と期限が決まったフォローアップで終わります。典型的には四つのカテゴリ：ツーリング改善（アラート／ダッシュボード改善）、テスト（回帰やエッジケースの追加）、自動化（安全なデプロイ／ロールバック、ガードレール）、ドキュメント（ランブック、明確な運用手順）。所有者と期日を割り当てないと学びは理論のまま終わります。
ツールは「You Build It, You Run It」を持続可能にするレバレッジですが、ツールだけで所有権は生まれません。チームが運用を“誰か別の人の問題”と扱っているなら、一番高級なダッシュボードも混乱を記録するだけです。良いツールは摩擦を減らし、正しい行動（観測、対応、学習）を行いやすくします。
サービス所有者は、ソフトウェアが本番で何をしているかを一貫して見て、問題時に迅速に行動できる方法を必要とします：
監視が分断していると、チームは調査に多くの時間を費やします。統一的なオブザーバビリティのアプローチが助けになります（参照：/product/observability）。
組織が成長すると「これは誰が所有している？」が信頼性リスクになります。サービスカタログ（内部デベロッパーポータル）がこれを解決します：チーム名、オンコールローテーション、エスカレーション経路、ランブック、依存関係、ダッシュボードへのリンクを一箇所に保持します。
重要なのは所有メタデータを最新に保つことです。ワークフローの一部にしてください：新サービスはオーナーなしで本番に出せない、所有権の変更はコード変更のようにレビューと追跡を行う。
最良のセットアップはチームを健康的な行動に誘導します：ランブックテンプレート、SLO に結びつく自動アラート、数秒で「ユーザーに影響があるか？」に答えるダッシュボード。しかし人の側の仕組みも重要です—チームにはこれらのツールを維持し、アラートを刈り込み、運用方法を継続的に改善する時間が必要です。
プラットフォームチームは「You Build It, You Run It」を現実にしやすくします。彼らの仕事は皆のために本番を運用することではなく、プロダクトチームが毎スプリント運用を再発明しなくても所有できるような“舗装された道”を提供することです。
良いプラットフォームは間違えにくく採用しやすいデフォルトを提供します：
ガードレールは出荷を阻害せずリスクを防ぐべきです。"secure by default" を目指す設計が好ましい。
プラットフォームチームは共有サービスを運用できるが、プロダクトサービスの所有を奪ってはいけません。
境界はシンプルです：プラットフォームチームはプラットフォームの稼働とサポートを所有し、プロダクトチームはその上で自分のサービスがどう振る舞うかを所有します。
チームが入社初日から CI/CD、認証、シークレットを深く理解しなくてよいとき、サービスの振る舞いとユーザー影響に集中できます。
負担を減らす例：
結果は、カスタムな“オプスの雪片”を減らしつつ迅速な配信を実現し、核心の約束を保ちます：作るチームがそのまま運用するということです。
「You build it, you run it」は信頼性と速度を向上させますが、組織がチームの周囲の条件を変えないと失敗します。標語だけ採用して支える習慣が伴わない失敗例は多いです。
繰り返し現れるパターン：
特定の環境では調整が必要です：
この哲学が最も早く失敗するのは、信頼性作業が「おまけ」と見なされる場合です。リーダーは明確に以下のためのキャパシティを確保する必要があります：
その保護がないと、オンコールは税になり、システムを改善するフィードバックループにはなりません。
展開は一度に全社で発表するよりも、段階的な変更として進めるのが最良です。小さく始め、所有を可視化し、準備ができたら拡大します。
境界が明確でリスクが管理しやすい単一サービスを選びます（理想は明確なユーザーと管理可能なリスクを持つもの）。
定義するもの：
鍵は：変更を出すチームがそのサービスの運用成果も所有すること。
パイロットを複数サービスに拡大する前に、パイロットチームがヒーローに頼らずに運用できるようにする：
所有権が出荷と安定を改善しているかを示す少数の指標を使う：
「you build it, you run it」を採用して出荷を速めようとすると、ボトルネックはしばしば同じです：アイデアから本番準備されたサービス（明確な所有権と安全なロールバック経路を持つ）までの距離。
Koder.ai はチャットインターフェースで Web／バックエンド／モバイルアプリを支援するプラットフォームで、サービス所有のオペレーティングモデルに役立つ機能があります：
今週パイロットサービスを決め、最初の SLO、オンコールローテーション、ランブックのオーナーを決める 60 分のキックオフを予定してください。出荷・ロールバック・所有権周りのワークフローを支えるツールを検討する場合は、/pricing で Koder.ai の無料／プロ／ビジネス／エンタープライズ各プランを確認してください—ホスティング、デプロイ、カスタムドメイン等のオプションがあります。
それは、サービスを設計・構築・デプロイするチームが、本番運用後に起こること（監視、オンコール対応、インシデント後の改善など）も責任を持つという意味です。
これは単なるツール選定や役職の変更ではなく、責任モデル（誰が所有するかが明確であること）です。
全てのエンジニアがインフラの専門家になる必要はありません。
意味するところは：
別チームによる運用の手渡しは、フィードバックが遅れ、責任の所在があいまいになりがちです。
エンドツーエンドの所有は通常、次を改善します：
「run it」に含まれる典型的な責任は：
人に負担を強いることなく始めるには、人間中心の設計が必要です：
良いオンコールの目標は「来月のページが減ること」であり、ヒーロー的対応を常態化させることではありません。
シンプルなルール：起こしても結果が変わらないならチケットにする。
実務的には：
SLO とエラーバジェットは測定可能な信頼性目標を提供します：
バジェットを速く消費しているときは信頼性作業を優先し、余裕があるときは機能開発のリスクを取れます。
不確実性と被害範囲を減らすリリース運用が必要です：
インシデントは「検出 → トリアージ → 緩和 → 通信 → 学習」の反復プロセスで扱います。
その後、ブレームレスなポストモーテムを書き、システムとプロセスのギャップに焦点を当て、具体的で期限付きのフォローアップを割り当てます。
軽量なチェックリスト（例：/blog/incident-response-checklist）を用意すると標準化に役立ちます。
プラットフォームチームは「paved roads」を提供し、再発明を防ぎつつプロダクトチームの所有権を奪わないことが使命です。
実務上の境界：
テンプレート、CI/CD、ガードレール、共通サービス（認証やオブザーバビリティ）で認知負荷を下げます。