DevOpsの文化と実践

Etsyの1日55回デプロイが救った会社

2009年、Etsy。

世界最大のハンドメイドマーケットプレイスが、崩壊寸前だった。

サイトは頻繁にクラッシュ。新機能のデプロイは月に1回、それも深夜の恐怖の儀式。エンジニアは週末も出勤してサーバーの面倒を見る。運用チームと開発チームは互いを敵視していた。

開発チーム：「また運用が俺たちの完璧なコードを壊しやがった」 運用チーム：「また開発が動かないコードを投げてきた」

CEOのチャド・ディッカーソンは、この状況に業を煮やした。会社の成長は止まり、競合のAmazon Handmadeに市場を奪われつつあった。

そんな時、一人の男がEtsyに加わった。ジョン・オールスポー。元Flickrのエンジニアで、「DevOps」という新しい考え方を持っていた。

ジョンが入社して最初にしたことは、驚くべきものだった。開発チームのエンジニアを、本番サーバーの前に座らせたのだ。

「君が書いたコードで障害が起きたら、君が直せ」

最初、エンジニアたちは猛反発した。「俺たちはコードを書く人間だ。サーバーを触るのは運用の仕事だ」

しかし、ジョンは続けた。「君のコードが動く環境を、君が一番よく知っているはずだ。なぜそれを他人に任せる？」

3ヶ月後、魔法が起きた。

エンジニアは自分のコードが本番でどう動くかを学んだ。監視ツールを見るようになった。ログを詳しく書くようになった。運用チームは開発プロセスを理解し、より良いインフラを提案するようになった。

2010年、Etsyはついに1日1回のデプロイを達成した。

2012年、1日10回。

2014年、1日55回。

コードを書いてから本番に反映されるまで：わずか11分。

この変化により、Etsyは急成長を遂げた。2015年、IPO。時価総額17億ドル。障害は90%減少。新機能の開発速度は10倍に。

ジョンが持ち込んだのは、単なる技術ではなかった。それは新しい働き方の哲学「DevOps」だった。

2008年のベルギーから始まった革命

2008年、ベルギー・ヘント。

パトリック・デボワは、システム管理者として働いていた。しかし、彼は開発者と運用者の分離に疑問を抱いていた。

O'Reilly Velocity Conference で、Flickrのジョン・オールスポーとポール・ハモンドが行った伝説のプレゼンテーション「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」を見て、インスピレーションを得た。

「開発と運用が協力すれば、1日10回以上デプロイできる」

この講演に感銘を受けたパトリックは、翌年ベルギーで「DevOpsDays」という小さなカンファレンスを開催した。参加者はわずか80人。しかし、この集まりが「DevOps」という言葉を世界に広めるきっかけとなった。

DevOpsの核心は何か？パトリックは言った。

「技術ではない。文化だ」

マイクロソフトの文化大革命

2014年、マイクロソフト。

サティア・ナデラがCEOに就任した時、同社は危機に瀕していた。クラウド競争でAmazonに大きく遅れ、開発者コミュニティからは「遅い、古い」と揶揄されていた。

問題は技術ではなく、組織文化にあった。

Windows チーム、Office チーム、Azure チーム。それぞれが独立した王国のように運営され、互いの足を引っ張り合っていた。新機能のリリースは年に1回。顧客のフィードバックが開発に反映されるまで、数年かかることもあった。

ナデラは、大胆な文化改革に乗り出した。その中心にあったのが、DevOpsの導入だった。

最初の実験は、Visual Studio Team Services（現在のAzure DevOps）チームで行われた。

以前のプロセス： 開発者がコードを書く → テストチームに投げる → バグが見つかる → 開発者に戻る → 修正 → 再テスト → 運用チームが本番に配置 → 問題発生 → 原因調査に数日

この無限ループを断ち切るため、彼らは「One Engineering System」を作った。

開発者は自分のコードをテストし、自分でデプロイし、自分で監視する。問題が起きれば、自分で解決する。

結果は驚異的だった。

Visual Studio Team Servicesのデプロイ頻度：年1回 → 週3回 → 1日8回 バグ修正時間：平均2週間 → 平均2時間 顧客満足度：60% → 95%

この成功を見て、他のチームも追随した。2016年には、マイクロソフト全体がDevOpsを採用。Windows 10の更新頻度は年1回から月1回に。Office 365は継続的にアップデート。

2024年現在、マイクロソフトは世界第3位のクラウドプロバイダーに成長した。その原動力は、DevOpsによる文化変革だった。

シェフが教える「レシピ」の力

2013年、Chef Software。

創業者のアダム・ジェイコブは、元シェフ（料理人）だった。彼がプログラマーになって最も驚いたのは、サーバー設定の「レシピ」がないことだった。

「料理の世界では、同じ料理を作るためのレシピがある。なぜサーバー構築にはレシピがないんだ？」

従来のサーバー管理は、職人芸だった。ベテランのシステム管理者が手作業でサーバーを設定し、その知識は頭の中だけに保存されていた。その人が辞めると、誰もサーバーを触れなくなる。

アダムは、Infrastructure as Code（IaC）の概念を作り出した。

// 従来：手作業でサーバー設定（再現不可能）
// 1. SSHでサーバーにログイン
// 2. Nginxをインストール
// 3. 設定ファイルを編集
// 4. サービスを開始
// 5. ファイアウォール設定
// 6. ログローテーション設定
// （手順書があったとしても、人によって微妙に違う結果に）

// IaC：コードでサーバー設定（再現可能）
const webServer = {
  packages: ['nginx', 'logrotate'],
  services: {
    nginx: {
      enabled: true,
      config: '/etc/nginx/nginx.conf',
      ports: [80, 443]
    }
  },
  firewall: {
    allow: [80, 443, 22]
  }
};

// このコードを実行すれば、いつでも同じサーバーが作れる

Chefの思想は、AWS、Google Cloud、Azureに採用された。現在、世界中のクラウドプロバイダーがIaCをサポートしている。

料理のレシピが料理を標準化したように、IaCはインフラストラクチャを標準化した。

GitLabの驚異的な透明性

2011年、ウクライナのハリコフ。

ドミトリー・ザポロジェッツは、自分用のGitリポジトリ管理ツールを作っていた。GitHubに満足していなかったからだ。

この小さなオープンソースプロジェクトは、後にGitLabに成長する。2024年現在、3000万人の開発者が利用する世界最大級のDevOpsプラットフォームだ。

GitLabが特異なのは、その透明性だ。同社は「リモートワーク」と「透明性」を徹底している。

GitLabの透明性の例：

• 全社員の給与体系を公開
• 四半期の売上目標と実績を公開
• 製品ロードマップを公開
• 会議の議事録を公開（機密事項以外）
• エンジニアの作業時間をリアルタイム公開

この透明性が、DevOpsの実践に大きな影響を与えた。

一般的な会社では、開発チームと運用チームの間に情報の壁がある。「開発は運用の苦労を知らない」「運用は開発の意図を理解していない」

GitLabでは、すべての情報がオープンだ。開発者は運用チームがどんな問題に直面しているかをリアルタイムで知ることができる。運用チームは開発者がなぜその技術選択をしたかを理解できる。

結果として、GitLab社内のDevOps成熟度は業界トップクラスだ。

コードコミットから本番稼働まで：平均6分 デプロイ頻度：1日平均20回 障害からの復旧時間：平均8分

CEOのシド・シーブランディは言う。「透明性は、DevOpsの最も重要な要素の一つだ。情報を隠すことで生まれる無駄と摩擦を排除できる」

Spotifyの「失敗パーティー」

2013年、Spotify。

エンジニアのパトリックは、大きな失敗をしてしまった。本番データベースの誤操作で、30分間サービスが停止。100万人のユーザーに影響。

普通の会社なら、パトリックは厳重注意、最悪の場合解雇だっただろう。

しかし、Spotifyで起きたのは違った。

CTO のAndreas Ehn が、パトリックにこう言ったのだ。「今夜、失敗パーティーをしよう」

その日の夕方、Spotifyのオフィスにエンジニア全員が集まった。ピザとビールが用意されていた。そして、パトリックが壇上に立った。

「皆さん、私は今日、素晴らしい失敗をしました」

パトリックは失敗の詳細を説明した。何が起きたのか、なぜ起きたのか、どうやって復旧したのか。そして最も重要なのは、この失敗から何を学んだかだった。

聴衆のエンジニアたちは、真剣にメモを取った。質問をした。似たような経験を共有した。

失敗パーティーの最後に、Andreasが立ち上がった。

「パトリック、ありがとう。君の失敗のおかげで、我々全員が学ぶことができた。この知識は、会社の貴重な資産だ」

そして彼は続けた。「誰も失敗を恐れてはいけない。失敗を隠してはいけない。失敗を共有し、学び、改善する。それがSpotifyの文化だ」

この文化により、Spotifyは急速にイノベーションを続けることができた。エンジニアたちは失敗を恐れることなく、新しい技術や手法を試すようになった。

現在、Spotifyは世界最大の音楽ストリーミングサービス。5億人のユーザーを抱える。その成長の原動力の一つが、この「失敗を歓迎する文化」だった。

DevOpsが変える開発者の日常

2019年、ある日本の大手銀行。

エンジニアの田中（仮名）の一日は、こんな感じだった。

午前9時： コードレビュー。同僚の書いたコードをチェック。 午前10時： 新機能の開発。顧客管理システムの改修。 午後2時： テスト環境でのテスト実行。バグを発見。 午後4時： バグ修正。再テスト。 午後5時： 運用チームにデプロイ依頼書を提出。

そして、運用チームがそのコードを本番に適用するまで、最短でも2週間。通常は1ヶ月かかっていた。

2020年、同行はDevOpsを導入した。田中の一日は一変した。

午前9時： コードレビュー。GitHubでプルリクエストを確認。 午前10時： 新機能の開発。同時に、そのコードのテストも書く。 午前11時： コミット。自動でCI/CDパイプラインが起動。 午前11時05分： 自動テストが実行され、すべて通過。 午前11時10分： ステージング環境に自動デプロイ。 午後2時： ステージング環境で動作確認。問題なし。 午後2時30分： 本番環境にデプロイボタンを押す。 午後2時35分： 本番環境に新機能が反映完了。 午後3時： 監視ダッシュボードで新機能の動作を確認。

コードを書いてから本番反映まで：1ヶ月 → 5時間。

田中は言う。「最初は不安だった。自分のコードがすぐに本番に行くなんて。でも、自動テストと監視が充実しているから、むしろ以前より安全だ。そして何より、作った機能をすぐにユーザーに使ってもらえる喜びがある」

ナイキの「Just Do It」哲学

2015年、Nike。

同社のデジタル部門は、大きな課題に直面していた。Nike+ アプリ、オンラインストア、在庫管理システム。それぞれが異なる技術スタックで作られ、連携が困難だった。

新商品のキャンペーンを開始するのに、IT部門では3ヶ月の準備期間が必要だった。マーケティング部門からは「競合他社はもっと早い」と不満の声。

CTO のAndrew Campion は、抜本的な改革を決断した。DevOps導入プロジェクト「Just Do IT」の開始。

Nikeらしく、プロジェクト名は同社のスローガン「Just Do It」をもじったものだった。

2018年、変革は完了した。

新商品キャンペーンの準備時間：3ヶ月 → 1週間 コードから本番までの時間：2週間 → 30分 障害復旧時間：4時間 → 15分

Nike の SNKRS アプリ（限定スニーカーの抽選販売）は、発売開始から数秒で完売する人気商品を安定して販売できるようになった。以前なら間違いなくサーバーダウンしていたであろう負荷にも耐えられる。

Andrew は言う。「DevOpsは技術改革だけではない。組織の DNA を変える文化改革だ。『Just Do It』の精神で、エンジニアリングの世界でも挑戦し続ける」

日本企業の挑戦：楽天の事例

2016年、楽天。

同社はEコマース事業で日本最大手の地位を築いていたが、グローバル展開で苦戦していた。特に、システム開発のスピードが海外競合に劣っていた。

CTO の森雄一郎（当時）は、この状況を変えるためDevOpsの本格導入を決定した。

しかし、日本企業特有の課題があった。

課題1：稟議文化 新しいツールを導入するのに、3ヶ月の稟議期間。DevOpsのスピード感とは真逆。

課題2：終身雇用制 「運用専門」「開発専門」という職種の壁が厚い。スキル転換への不安。

課題3：品質重視文化 「絶対に本番で障害を起こしてはいけない」という文化。実験的な取り組みへの抵抗。

楽天の解決策は、段階的なアプローチだった。

2020年、楽天モバイルの正式サービス開始。このプロジェクトは、楽天グループ史上最大規模のDevOpsプロジェクトだった。

クラウドネイティブなアーキテクチャ、完全自動化されたCI/CD、リアルタイム監視。300万人の契約者を獲得する大規模サービスを、少数精鋭のチームで運用している。

三木谷社長は言う。「楽天モバイルの成功は、技術力だけでなく、DevOps文化があったから実現できた」

The Netflix Way：カオスエンジニアリング

2010年、Netflix。

AWS上で稼働するサービスが急成長していた。しかし、クラウドの不安定性に悩まされていた。AWSの障害により、サービス停止が頻発。

エンジニアのGreg Orzellは、逆転の発想をした。

「障害が避けられないなら、意図的に障害を起こしてシステムを鍛えよう」

彼が作ったのが「Chaos Monkey」。本番環境で稼働するサーバーをランダムに停止させるツール。

最初、社内では大反対だった。「わざと障害を起こすなんて狂気の沙汰だ」

しかし、Gregは続けた。Chaos Monkeyが停止させたサーバーで障害が発生するたびに、システムはより頑丈になった。単一障害点が除去され、自動復旧機能が改善された。

6ヶ月後、驚くべき効果が現れた。AWS の大規模障害が発生した時、多くのサービスが停止する中、Netflix だけは正常に動作し続けた。

Chaos Monkeyは、Netflixの「Chaos Engineering」文化の象徴となった。現在では、様々な種類の障害を意図的に発生させるツール群「Simian Army」に発展している。

この文化により、Netflix は世界で最も安定したストリーミングサービスとなった。2億人以上のユーザーがいるにも関わらず、大規模障害はほとんど発生しない。

Greg は言う。「DevOpsは『動かし続ける技術』だ。障害を恐れるのではなく、障害に慣れ、障害から学び、障害に強いシステムを作る」

アーキテクチャは進化する：Netflixの7段階変革

Netflixの成長は、DevOps進化の教科書と言える。2000年のDVDレンタル企業から、2024年の世界最大ストリーミングサービスまでの道のりを見てみよう。

各段階で、Netflixは技術的制約ではなく、ビジネス成長に応じてアーキテクチャを進化させた。重要なのは、完璧なアーキテクチャを最初から作ろうとしなかったことだ。

エイドリアン・コックロフト（元Netflix クラウドアーキテクト）は語る。「アーキテクチャに完成はない。ビジネスが成長すれば、アーキテクチャも成長する必要がある」

実践への第一歩

ここまで見てきた事例が示すのは、DevOpsの真価は技術よりも文化にあるということだ。

では、あなたの組織でDevOpsを始めるには何から手をつけるべきか？

重要なのは、完璧を求めないことだ。Etsy、Microsoft、Netflix、どの会社も最初から完璧ではなかった。小さな改善を積み重ね、文化を変革し、結果として大きな成果を得ている。

DevOpsは目的地ではない。それは旅だ。そして、その旅は今日から始めることができる。

あなたのチームも、明日から少し違う働き方を始めてみてはどうだろうか。