# DevOps ## 定義 DevOpsは、開発(Dev)部門と運用(Ops)部門という組織上の分断を解消するための文化的運動として生まれた語である。[[Patrick Debois]] が2009年10月にベルギーのゲントで開催した最初の devopsdays(dev + ops + days)というカンファレンス名に由来し、Debois自身は業界用語として固定する意図はなく、あえて定義しなかった。技術スタック上のレイヤー、開発工程上の一段階、特定のツール群を指す語ではない。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]]) 初期の定義の輪郭を示したのは [[John Willis]] が2010年に提示したCAMS(Culture・Automation・Measurement・Sharing)であり、Cultureが先頭に置かれ、Automationは4つのうちの1つに過ぎなかった。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]]) ## 横断的知見 - **DevOpsとSREは「文化 vs 実装」の関係として整理されるが、その整理自体がDevOpsの原意を職種・技術レイヤーへ縮約する動きの一部でもある**: [[SRE]] 側の文献は「class SRE implements DevOps」([[Liz Fong-Jones]]・Seth Vargo、2018年)を、SREがDevOpsの哲学(サイロ除去・小さく頻繁な変更・測定・共有・ブレームレスな振り返り)を具体的な実装(SLO・エラーバジェット・トイル上限)に落とし込むものとして肯定的に位置づける(Source: [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]])。一方でmizzy(2026)は、この定式化自体が「文化・プラクティスの話が、職種や技術レイヤーの名前として消費されていく」というDevOpsに起きたのと同じパターンの反復であり、SRE NEXT 2026でmaru氏が指摘した「開発の時系列上の役割・技術レイヤー・組織上のロールの混同」問題と地続きだと論じる。両者は矛盾ではなく視点の違いで、前者は実装としての価値を、後者は原意の希薄化への懸念を強調している。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]]) - **DevOpsが包含していた実践要素は、それぞれ独立した名乗れる領域へ分解され、DevOps自体は抽象概念化して使われなくなっていった**: Velocity 2009のFlickr発表(John Allspaw・Paul Hammond)で挙げられた要素は、インフラの自動化→[[Infrastructure as Code]]、ビルド&デプロイの一本化→CI/CD、機能フラグ→フィーチャーフラグ、メトリック共有→[[DORA]]の4キーメトリクス、IRC/IMのロボット→[[ChatOps]]という形で、それぞれ実践・ツール・市場を持つ独立領域に育った。2025年にDORAが年次レポート名を「State of AI-assisted Software Development」に改称し組織名からもDevOpsの語が消えたことが、この分解の到達点として象徴的。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **『Effective DevOps』の小文字devops表記は、原意(排除ではなく開放の運動)を綴りに埋め込む試みだったが定着しなかった**: 著者Jennifer Davis・Ryn Danielsはオンライン投票でDevOps表記が圧勝したにもかかわらず、企業がDevとOpsだけに重点を置くことへの抵抗として意識的に小文字表記を選んだ。だがAWSドキュメントやGoogle CloudのDORAレポートは一貫してDevOps表記であり、これは訳語や言語(英語/日本語)の問題ではなく、「文化の運動より、職種・ツール・資格という名乗れる/買えるものの方が流通しやすい」という構造的な理由による。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **起源の事実関係(Debois・Shafer・Allspaw・Hammond・Devopsdays)は独立した2つのソースで一致し、2013年の『The Phoenix Project』出版がDevOps概念の一般大衆への普及点として追加で確認できる**: [[@2026__mizzy.org__DevOpsとは何だったのか]] が描く2008年のAgile Infrastructure BoF・2009年のVelocity発表・同年のDevopsdays創設という経緯は、独立に書かれた [[@2018__devops.com__The Origins of DevOps - What's in a Name]] でも年号・登場人物レベルで一致する。後者はさらに、2010年の米国初Devopsdays(マウンテンビュー)開催と、2013年に [[Gene Kim]]・[[Kevin Behr]]・[[George Spafford]] が『The Phoenix Project』というビジネス小説を出版しDevOps概念を物語形式で一般に広めた経緯を補足しており、mizzy(2026)が描く「モノの名前への消費」プロセスの前段階として、まず物語による普及があったことがわかる。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2018__devops.com__The Origins of DevOps - What's in a Name]]) - **2019年時点の学術サーベイは既に「DevOpsは広く合意された定義を欠く」と明記しており、定義の希薄化は2020年代に始まった現象ではない**: Leite et al.(2019)は「DevOpsの運動は10年近く議論されてきたにもかかわらず、広く受け入れられた定義を欠く」と述べ、最も引用されるDevOps定義を統合して独自定義を採用せざるを得なかった。これは、mizzy(2026)が描く「文化から職種・技術レイヤーへの縮約」が2020年代後半に急に起きたのではなく、DevOps誕生(2008-2009年)から10年後の2019年時点で既に定義の不安定さが学術的に認識されていたことを示す。ただし両者の力点は逆方向で、Leite et al.は既存のDevOps SLR群(Erich・França等)がprocess/people(協働文化・組織論)のカテゴリに偏り、delivery/runtime(技術的含意)を軽視してきたと批判するのに対し、mizzy(2026)はCAMSのAutomation偏重による文化面の希薄化を懸念しており、2010年代のアカデミック文献では文化面がむしろ相対的に重視されていた可能性がある。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges]], [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **Site Reliability Engineeringは2019年の学術サーベイの時点で既に「運用エンジニア役割の進化形」としてDevOps文献に組み込まれていた**: Leite et al.(2019)は8.2節で、DevOps組織導入の3方式(collaborating departments・cross-functional team・DevOps team)を議論する中で、Googleの「Site Reliability Engineering (SRE)」を運用エンジニア役割の一発展形として明示的に言及し、SREチームが運用作業に使える時間の上限を50%とする仕組みまで説明している。これは [[SRE]] 概念ページで扱う「class SRE implements DevOps」(Fong-Jones・Vargo, 2018)という定式化が2018年のGoogle SRE Workbook刊行時点で唐突に現れたのではなく、DevOps研究コミュニティが2019年の時点で既にSREを自らの文献の一部として位置づけていたことを示す。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges]]) ## 未解決の問い - CAMSの4要素のうちAutomationとMeasurementには明確な後継語(Infrastructure as Code・CI/CD・DORA)ができたが、Cultureの後継(Team Topologies・Learning from Incidents・Resilience Engineering)は、部門間の分断解消という原意をどこまで実際に引き継げているか。 - DevSecOps(2013年頃登場)やPlatform Engineeringのように、DevOpsから分岐して新語が必要になり続けている現象は、DevOpsという語が対象とする組織的分断そのものが解決していないことの証拠と言えるか、それとも単なる自然な専門分化か。 - 「class SRE implements DevOps」のような定式化は、SREという語についても同じ「文化→職種・技術レイヤーへの縮約」を繰り返す可能性があるが、それを防ぐための語彙・実践は何か。 ## 関連 - 実装としての関係: [[SRE]](「class SRE implements DevOps」) - 分解先の独立領域: [[Infrastructure as Code]] / [[ChatOps]] / [[DORA]] - 後継の組織論: [[プラットフォームエンジニアリング]] - 起源の人物: [[Patrick Debois]] / [[Andrew Clay Shafer]] / [[John Allspaw]] / [[Paul Hammond]] / [[John Willis]] - 普及の担い手: [[Gene Kim]] / [[Kevin Behr]] / [[George Spafford]](『The Phoenix Project』) - 学術的な体系化: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges]]([[Leonardo Leite]]・[[Carla Rocha]]・[[Fabio Kon]]・[[Dejan Milojicic]]・[[Paulo Meirelles]]によるconceptual framework構築) ## 出典 - [[@2026__mizzy.org__DevOpsとは何だったのか]] - [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]] - [[@2018__devops.com__The Origins of DevOps - What's in a Name]] - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges]]