# 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とは何だったのか]]) > [!contradiction] DevOpsの誕生時期をめぐる食い違い > 本ページの起源記述(2008年のAgile Infrastructure BoF・2009年のVelocity発表・同年のDevopsdaysの創設)は、独立した2ソース([[@2026__mizzy.org__DevOpsとは何だったのか]]、[[@2018__devops.com__The Origins of DevOps - What's in a Name]])で年号・登場人物レベルまで一致する。これに対し『SREの探求』22章のKurt Andersenは「いくつかの潮流がSREというアイデアに結実したのは2003年から2007年頃のことでした。これは"DevOps"という動向が姿を現してきたのとほぼ同時期で」と述べ、DevOpsの立ち上がりをSREと並ぶ2003〜2007年頃に位置づけている(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 22 成功の文化としてのSRE]] §22.1)。22章はDebois・devopsdays・Agile Infrastructure BoFといった固有名詞には触れておらず、根拠となる一次資料も示していない。年号が一致しない理由(執筆時点の記憶違い、「潮流」という語で正式命名以前の萌芽期まで含めて指しているだけ、等)は特定できておらず、本ページの2008-2009年起源説と22章の2003-2007年説のどちらが正確かは未解決のまま両論併記する。 ## 子概念 - [[ChatOps]] - [[DORA]] - [[DevOpsとSREの関係]] - [[Infrastructure as Code]] - [[プラクティスのコミュニティ]] - [[プラットフォームエンジニアリング]] - [[収束型システム管理]] ## 横断的知見 - **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: [[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: [[A Survey of DevOps Concepts and Challenges]]) - **「ビルド&デプロイの一本化→CI/CD」という分解先の独立領域が、10年後の別書籍で「本番システムと同じ厳密さで計測すべき対象」として詳細化されている**: 本ページの横断的知見は、Velocity 2009のFlickr発表で挙げられた実践要素がそれぞれ独立領域(Infrastructure as Code・CI/CD・フィーチャーフラグ・DORA・ChatOps)へ分解していったと整理する(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。[[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] はこの分解先の一つであるCI/CDを単独の章として扱い、「CI/CDパイプラインは開発者フィードバックのための本番システムである」と位置づけたうえで、ジョブ=スパン・ワークフロー=トレースというオントロジー写像、DAGのクリティカルパス分析、ビルドSLI/SLOという具体的な計測手法を提示する。これは、mizzy(2026)が描く「文化的運動から独立領域への分解」というマクロな見立てが、CI/CDという1領域については単なる名乗りの独立にとどまらず、本番運用と同水準の計測手法・語彙(オブザーバビリティのオントロジー)を獲得するところまで進んでいることを示す具体例になる。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]) - **「文化的運動から職種・技術レイヤーへの縮約」という mizzy(2026) の見立てに対し、Observability Engineering 2nd Edition 最終章(2026)は分断の「解消」そのものをAI起因の必然として予測する**: mizzy(2026)はDevOpsが独立領域への分解と名乗りの消費を経て抽象概念として使われなくなっていった経緯を描く(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。一方 [[@2026__OReilly__Observability Engineering 2E - Chapter 32 Where Do We Go From Here?]] は、AIによるコード生成コストの急落と非決定性の常態化を根拠に、「dev/opsの分断線は破壊されねばならない」ことを第2版の唯一の予測として掲げ、開発者自身が本番の建築者・設計者になるべきだと論じる。これは分解でも名乗りの独立でもなく、CAMSの先頭要素だったCulture(部門間の分断解消という原意)への回帰を、組織論としてではなく技術的必然として主張する点で、mizzy(2026)が懸念する「Culture不在の縮約」とは逆方向の力学を示す。両者が同じ分断線について異なる帰結を予測している以上、実際にどちらの力学が優勢になるかは未解決である。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2026__OReilly__Observability Engineering 2E - Chapter 32 Where Do We Go From Here?]]) - **Limoncelliモデルは、SREとDevOpsの関係を「文化 vs 実装」ではなく「SDLCパイプライン上の注目方向」という空間的軸で捉え直す**: 『SREをはじめよう』第1章で[[David N. Blank-Edelman]]が紹介するTom Limoncelliのモデルは、DevOpsのストーリーが開発者のラップトップから本番稼働へ向かうのに対し、SREは本番環境を起点に「後方」へラップトップへ視線を向けるという向きの違いを図示する。これは[[SRE]]概念ページが記録する「class SRE implements DevOps」(実装としての階層関係)や本ページのCAMS(文化・自動化・測定・共有という要素分解)とは異なる第3の説明軸であり、著者は両者が態度・意図では重ならないように見えて実際には多く重なる理由をこのモデルが説明してくれる点を評価する。同じ疑問(SREとDevOpsの違いは何か)に対し、実装関係・要素分解・注目方向という3種の異なる説明軸が並立していることが分かる (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 1 はじめに]], [[@2026__mizzy.org__DevOpsとは何だったのか]])。 - **『SREエンタープライズロードマップ』第1章は「SREとDevOpsは補完関係」というDORA由来の定式化を再確認しつつ、専門職としてのSREをDevOpsチームへ再導入することへの慎重論という新しい角度を加える**: 同章はGoogleのDORA調査を典拠に「SREとDevOpsは補完関係にあり、組織内でDevOpsをある程度導入していれば通常有益」と述べ、これは[[SRE]]概念ページが記録する「class SRE implements DevOps」(Fong-Jones・Vargo, 2018)という実装としての定式化と整合する。一方で同章は、Dev/Opsの各部署をすでに機能横断的なDevOpsチームへ置き換えている組織では、SREのような専門的な職務を再び導入することは慎重に検討する必要があると注記する。これは、mizzy(2026)が描く「文化的運動から職種・技術レイヤーへの縮約」パターン(本ページ既出の横断的知見)とは逆方向——一度統合した機能横断チームから専門職を再び切り出す動き——が、DevOpsの機能横断という理念と摩擦を起こしうる具体的な組織設計上の緊張として観察される。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 1 エンタープライズSREことはじめ]], [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]], [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **第6章のヘルスケア業界事例は、第1章が抽象的に述べる「DevOpsをある程度導入していればSRE導入は通常有益」という補完関係の裏面——DevOps未導入のままSREを導入しようとする急勾配——を具体的な症状で描く**: 第1章はGoogleのDORA調査を典拠に、組織内でDevOpsをある程度導入していればSREとの補完関係が機能すると述べるにとどまる。第6章のJoseph Bironasは、ヘルスケア業界の組織がDevOpsのプラクティスをまだ導入していないのにSREの導入を希望する状況に直面することが多いと語り、月次リリース、規制・コンプライアンス管理の複雑さに起因する低いCI/CD自動化率、迅速なデプロイ自体を望まない顧客という具体的な症状を挙げる。第1章の補完関係が成立する前提(DevOpsの一定の導入)が欠けた場合に何が起きるかを、第6章は業界事例として補う。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 1 エンタープライズSREことはじめ]], [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]]) - **『SREの探求』6章のSoundCloudは、「you build it, you run it(真のDevOps)」を、SREの基本原則と明示的に対立する選択として位置づける当事者の証言である**: 既出の知見群は、SREとDevOpsの関係を「文化 vs 実装」(class SRE implements DevOps)や「SDLCパイプライン上の注目方向」(Limoncelliモデル)として整理してきたが、いずれも第三者的な理論的整理である。SoundCloudのBjörn RabensteinとMatthias Rampkeは、開発チームと運用チームの区別をなくし1つのチーム内で開発/運用の役割指定をしない「自分が構築し自分で実行(you build it, you run it)、私たちが時に好んで使う表現では真のDevOps」という選択を、「議論の余地はあるものの、これはSREの基本とは反する考え方」だと自ら明言する。彼らの理由づけは、「SREチームとは、運用の懸念をソフトウェアエンジニアの発想とツールボックスで解決するという前提があるとはいえ、あるレベルでは運用チームである」という点にあり、専任の運用機能(たとえ形はSREでも)を残すか、完全に開発機能へ溶かし込むかという二者択一を、実務者自身の言葉で対立軸として名指しした一次資料である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.2, [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]]) - **Gene Kimは『The DevOps Handbook』からの抜粋章で、「class SRE implements DevOps」という後年の定式化とは逆向きに、DevOpsが当たり前とみなす実践の多くがGoogleのSREにおいて先に生まれていたことを著者自身の言葉で明言する**: 既出の知見群は、DevOpsとSREの関係を「実装としての階層関係」(Fong-Jones・Vargo, 2018)・「SDLC上の注目方向の違い」(Limoncelliモデル)・「補完関係」(SREエンタープライズロードマップ)として整理してきたが、いずれも歴史的な先後関係には踏み込まなかった。『SREの探求』11章で Gene Kim は、『The DevOps Handbook』を Jez Humble・John Willis・Patrick Debois と共著する過程で「私たちが積極的に活用していて今では当たり前のことと思えるまでになっているDevOpsのパターンの実に多くについて、Googleが先駆者だったのだと繰り返し気付かされた」と述べ、自動化テスト文化・[[レディネスレビュー]](LRR/HRR)・単一共有ソースコードリポジトリの3パターンをSREの知識体系に由来するものとして紹介する。これは、DevOpsという語自体はDebois・Allspaw・Hammondらの2008-2009年の運動に由来する(本ページ既出の知見)一方で、DevOpsが実践として結晶化させた個別パターンの少なくとも一部はGoogleのSRE実践から抽出・一般化されたものであり、「DevOpsの理念的起源」と「DevOpsパターンの実践的起源」が異なる系譜を持ちうることを、DevOps側の代表的著者自身が認める一次資料である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.0-§11.1, [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]]) - **Googleの2013年時点の自動化テスト・ビルド統計(1日4万行コミット・5万件超ビルド・7,500万回のテスト実行)は、10年以上後にDORAが定式化する4キーメトリクスの構成要素を、指標化される前の生データとして先取りする**: 本ページ既出の知見は、Velocity 2009のFlickr発表で挙げられた実践要素が「メトリック共有→DORAの4キーメトリクス」という形で独立領域に分解していったと整理する(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。『SREの探求』11章が記録するGoogleの統計——1日あたり4万行のコードコミット、1日あたり5万件のビルド(デプロイ頻度に相当する生データ)、12万種類の自動化テストスイートと7,500万回の日次テスト実行(変更失敗率を左右する検証基盤)——は、DORAの4キーメトリクス(デプロイ頻度・変更のリードタイム・変更失敗率・サービス復元時間)がまだ定式化されていない2013年時点で、後にこれらの指標が測定することになる活動の規模を具体的な数値として先に示している。これは、DORAという指標体系が2010年代半ばに現れる以前から、Googleの内部では「測定されないまま」高頻度デプロイと大規模自動テストが実践されていたことを示し、DevOpsパターンのGoogle起源説(本ページ前掲の横断的知見)にもう一つの具体的な裏付けを加える。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.1, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **『SREの探求』12章のコミュニティアンケートは、Limoncelliモデルの一次資料を提供し、また「どちらが先か」という問いに11章とは異なる軸(用語の先後)を持ち込む**: 本ページ既出の横断的知見(Limoncelliモデルの項)は、『SREをはじめよう』1章がDavid N. Blank-Edelmanを介して間接的に紹介するTom Limoncelliのモデルを扱ってきたが、そこではLimoncelli自身の論拠は確認できなかった。『SREの探求』12章は同じモデルの一次資料であり、[[Thomas A. Limoncelli]] 自身が求人広告の傾向分析からこのモデルへ至った経緯、SREが「パラシュート部隊」のようにパイプライン前半へ介入する様子、DevOpsがパイプライン前半を強調してきた経験則的な理由を一人称で説明する(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 12 DevOpsとSRE：コミュニティからの声]] §12.4、図12-1)。加えて同章のMark Rendellは、Google外ではDevOpsという語がSREより少なくとも6年早く定着していたと述べる。これは11章のGene Kimが述べる「DevOpsパターンの実践的起源はGoogleのSREにある」(本ページ既出の知見)とは逆方向の先後関係であり、**用語としての先後**(DevOpsが先)と**実践としての先後**(SRE的実践が先)という2つの異なる軸が同じ問いに対して逆の答えを与えていることが分かる。詳細な整理は [[DevOpsとSREの関係]] concept に切り出した。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 12 DevOpsとSRE：コミュニティからの声]] §12.4, [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.0-§11.1) - **12章のコミュニティ回答が示す「SRE=DevOpsの高度にスケーラブルな実装形」(立場A)という直観は、Google SRE Workbookの「class SRE implements DevOps」と同じ結論に異なる論拠から到達している**: Tanner Lund(Microsoft)は「SREは本質的に、高度にスケーラブルなDevOpsとなる」と述べ、Santiago Suarez Ordoñez(Blameless)は「SREとは基本的にDevOpsのことだと思うが、丸々10年の試行錯誤を経たことで進歩している」と述べる。両者ともSLO・エラーバジェットといった具体的な実装要素には触れず、スケーラビリティや経験の蓄積を論拠とする点で、Google SRE Workbookの定式化(Source: [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]])とは独立に同じ結論へ到達した実務者の直観といえる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 12 DevOpsとSRE：コミュニティからの声]] §12.4, [[@2018__Google SRE Workbook__Chapter 1 How SRE Relates to DevOps]]) - **Infrastructure as Codeの系譜は、DevOps運動由来の説明(mizzy 2026)とは独立した、LISAコミュニティ由来のより古い系譜を持つ**: 本ページ既出の知見は、Velocity 2009のFlickr発表(2009年)由来の「インフラの自動化→Infrastructure as Code」という分解を描く(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。しかしLimoncelli(2022)は、[[LISA]] に併設された configuration management workshop が cfEngine・BCFG2・Puppet を生み、それが Chef・Ansible へ連なって今日の [[Infrastructure as Code]]/GitOps に至ったという、DevOps という語(2008-2009年起源)より前から進行していた別系譜を証言する。LISA 自体は 1987 年創設であり、宣言的か命令的か・ファイルを変更すべきかゼロから生成すべきかといった設計論争は当時から白熱していたという。これは、Gene Kim(『SREの探求』11章、本ページ既出)が述べる「DevOpsパターンの多くはGoogleのSREが先駆者だった」という指摘と同型のパターン——DevOps という名乗り自体は2008-2009年に生まれたが、その中身となる実践は複数の先行コミュニティ(Google SRE・LISA のシステム管理者)で独立に育っていた——をもう一つ加える。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2022__USENIX__LISA made LISA obsolete (That's a compliment!)]]) - **LISAの終了(2022年)とSREconへのバトンタッチは、「業界の常識になったことによる自己陳腐化」というDevOpsの語り(mizzy 2026)を、カンファレンス・コミュニティという制度レベルで先取りした前例である**: 本ページ既出の知見は、DevOpsが独立領域への分解と名乗りの消費を経て抽象概念として使われなくなっていった経緯を描く(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。Limoncelli(2022)は、[[LISA]] が掲げた「急進的アイデア」(システム管理は重要・能動的管理・自動化・人間的プロセス・オープンシステム)が業界の当たり前の常識になったことをもって、LISA自身が2022年に35年の歴史を終えSREconへバトンを渡したと総括する。これはDevOpsが辿った「文化的運動→分解・名乗りの消費→抽象概念化」という3段階(本ページ既出)とは異なり、「理念の浸透→組織・カンファレンス自体の解散」という更に踏み込んだ帰結であり、DevOpsという語がまだ抽象概念として生き残っている状況と対照をなす。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2022__USENIX__LISA made LISA obsolete (That's a compliment!)]]) - **同じ2011年刊行の『ウェブオペレーション』5章は、DevOpsという語を一度も使わずに、CAMSのAutomation(自動化)に相当する技術的基盤を独立に体系化していた**: 本ページはCAMS(Culture・Automation・Measurement・Sharing)がDevOpsの初期の定義の輪郭だったとする(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。同じ書籍『ウェブオペレーション』の6章を執筆した[[Patrick Debois]]がdevopsdaysの創設者であるのに対し、5章を執筆した[[Adam Jacob]]は「コードとしてのインフラ」と題する章で、DevOpsという語には一度も触れないまま、サービス指向アーキテクチャ由来の3原則(モジュール化・協調性・組み立て可能)と[[cfengine]]由来の4原則(宣言的・抽象化・べき等性・収束化)を合わせた「よいインフラサービスの10原則」を提示する。これは、CAMSの4要素のうちAutomationが最も早く独立領域([[Infrastructure as Code]])として結晶化したという本ページ既出の知見に対し、その結晶化がDevOpsという語の普及(Velocity 2009以降)を待たずに、同時期・同一書籍内で語彙的には無関係に進んでいたことを示す一次資料である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1〜§5.2, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **ch5(2011)が列挙する構成管理ツールの実務者的な勢力図は、本ページの未解決の問いが仮説として立てた「IaCの実践的起源はLISAコミュニティに別系統である」という見立てを部分的に裏づける**: 本ページの未解決の問いは、LISA併設のconfiguration management workshop(cfEngine・BCFG2・Puppet起源)がDevOpsという語の起源(2008-2009年)より前から実践的基盤を育てていた可能性を指摘していた。ch5は2011年時点の実務者コミュニティ側の視点から「構成管理ツールにはルネッサンスが起きている。AutomateIT・Bcfg2・[[Chef]](これは私が作った)・[[cfengine]]・[[Puppet]]などが有名だ」と列挙し、これらすべてが[[Mark Burgess]]が開拓した基本原則を具体化したものだと位置づける。DevOpsという語もdevopsdays(2009年)もこの列挙には一切登場せず、ch5の著者Adam Jacobにとって構成管理ツールの系譜はDebois由来のDevOps運動とは独立した技術的な話として語られている。これは「DevOpsパターンの実践的起源」がGoogle SRE([[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]]既出の知見)とLISAシステム管理者コミュニティ(cfEngine・BCFG2・Puppet)の少なくとも2系統に分かれるという既出の未解決の問いに対し、後者の系統が2011年時点で既に実務者に「ルネッサンス」として認識されるほど成熟していたという具体的な傍証を加える。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1.1.3) - **同じ『ウェブオペレーション』10章は、DevOpsという語を生んだVelocity 2009講演の当事者自身の手で、CAMSのAutomation以外の3要素(Culture・Measurement・Sharing)に相当する内容を、こちらもDevOpsという語を一度も使わずに体系化している**: 本ページ既出の知見は、5章の著者Adam JacobがDevOpsという語に触れずCAMSのAutomationに相当する構成管理の技術的基盤を体系化していたことを示した。10章「開発と運用の協力と連携」の著者[[Paul Hammond]]は、まさにそのVelocity 2009講演「10+ Deploys per Day: Dev and Ops Cooperation at Flickr」を[[John Allspaw]]と共同発表した当事者であり(Source: [[@2018__devops.com__The Origins of DevOps - What's in a Name]])、10章はこの発表の内容を書籍の1章として詳述したものである。10章はCulture(開発/運用の組織分割批判・信頼構築・非難を伴わないふりかえり)・Sharing(インフラ・ツール・IRCチャンネルの共有)・Measurement(共有メトリクスによる協力の基盤)に相当する内容を扱うが、5章と同様にDevOpsという語には一度も触れない。同一書籍内で、CAMSの4要素のうちAutomation(5章)とCulture・Measurement・Sharing(10章)が、異なる著者による異なる章で、しかもいずれも語彙的にはDevOpsと無関係に(語の誕生と同時期または直接の当事者の手で)先取りされていたことが、5章と10章を並べて初めて見える。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1〜§5.2, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]] 全章, [[@2018__devops.com__The Origins of DevOps - What's in a Name]]) - **同じ『ウェブオペレーション』16章は、DevOpsという語を生んだ2008年のAgile Infrastructure BoFの当事者自身([[Andrew Clay Shafer]])の手で、5章・10章とは異なり「DevOps」という語を実際に一度使いながら、それを他の候補と並列させて名前そのものの重要性を明示的に相対化している**: 5章(Adam Jacob)・10章(Paul Hammond、既出)はいずれもDevOpsという語に一度も触れなかったが、16章「アジャイルインフラストラクチャ」の著者Shaferは、DevOps誕生の当事者でありながら「アジャイルインフラ・DevOps・リーンオペレーション・エクストリームシステム管理・インフラ2.0——名前は何だってよい。結果が重要だ」と述べ、DevOpsを数ある呼称の1つとして並列に扱う。これは、mizzy(2026、既出)が2020年代後半に指摘する「文化・プラクティスの話が、職種や技術レイヤーの名前として消費されていく」という現象への警戒を、運動の当事者自身が2011年の時点で先取りしていたことを示す一次資料である。5章・10章が語を避けることで(結果的に)名前への無関心を体現したのに対し、16章は語に言及したうえで意図的にその重要性を退けており、同一書籍内で「語らない」(5・10章)と「語ったうえで相対化する」(16章)という2種類の異なる態度が観察できる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.1, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **16章が示すアジャイルの「2つの軸」(技術的なベストプラクティス/仕事の成果をビジネスと結び付ける方法)は、CAMS(Culture・Automation・Measurement・Sharing)の4要素を独立に2つへ圧縮した見立てであり、DevOps運動の当事者自身による「文化 対 自動化」という単純化を先取りする**: 本ページはCAMSが[[John Willis]]による2010年の定式化だとする(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。16章著者Shaferは「アジャイルの過去・現在・未来は大きく2つに分類できる。1つは技術的なベストプラクティス、もう1つは仕事の成果をビジネスと結び付ける方法だ」と述べ、これを「人と技術がかかわる技法」「人と人がかかわる技法」とも言い換える。前者はCAMSのAutomationに、後者はCulture・Measurement・Sharingを合わせた残り3要素にそれぞれ対応すると読め、DevOps運動の当事者自身が(CAMSという用語を使わずに)同時期に独立して同種の二分法へ到達していたことが分かる。ただし16章はこの2軸の「バランスを欠くのは危険」と述べるにとどまり、CAMSのように4要素として明示的に分解してはいない。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.1, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **16章は、DevOps運動の当事者自身の手で「アジャイル開発の実践をそのまま運用へ機械的に移植すべきではない」という方法論的な留保を明言しており、これは5章・10章が扱わなかった第3の軸——技術的基盤(5章)・協働の実践(10章)に続く、方法論そのものの当否——を加える**: 16章著者Shaferは、バージョン管理・構成管理・監視・継続的統合といったアジャイル由来の実践を運用へ適用する具体的な指針を示す一方で、「ソフトウェア開発の考えがシステム管理に当てはまるとは思っていない。むしろ、当てはまるべきではないと思っている」と明言する。具体例として、運用チームのタスク管理には([[アジャイルな計画づくり]]・[[イテレーションの長さ]]が扱うような)タイムボックス化されたイテレーションよりも、進行中のタスクを制限しプルベースで引き取るカンバン方式が向いていると述べており、開発向けに最適化されたアジャイル手法(スプリント・イテレーション計画)を運用にそのまま持ち込むことに慎重な立場を取る。これは、DevOps運動が「開発の方法論を運用へ輸出する」運動だったという単純な理解に対し、当事者自身が運動の初期段階から方法論の無批判な移植に警鐘を鳴らしていたことを示す一次資料であり、5章(技術的基盤としてのIaC)・10章(協働の実践としての小さく頻繁なデプロイ)に続く第3の軸——アジャイルの哲学を運用にどこまで・どう適用できるか、という方法論そのものの当否——を本ページに加える。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.2.1, [[アジャイルな計画づくり]], [[イテレーションの長さ]]) - **16章の「混乱の壁」は、5章・10章が体現した「DevOpsという語を使わずにCAMSの要素を先取りする」というパターンとは異なり、壁の解消それ自体がテクノロジでは達成できないと明言する点で、CAMSのAutomation要素への還元不可能性を運動当事者自身が指摘している**: 5章・10章(既出)はCAMSの技術的・協働的要素を語彙的にDevOpsと無関係に体系化していたが、いずれも「壁が技術で解消できるか」という問いには立ち入らなかった。16章は「両者の緊張関係を解消するにはお互いを認め合う必要がある。これはテクノロジでなんとかなる話ではない」と繰り返し明言し、混乱の壁(図16-1)を越える鍵を信頼構築に置く。これは、CAMSのCulture要素が単なる4要素の1つではなく、Automation(5章)がいかに整っても代替できない独立の課題であることを、当事者自身が運動の初期段階から強調していたことを示す。詳細な突き合わせ(利益共同体・トレーディングゾーン・境界オブジェクト)は [[プラクティスのコミュニティ]] に切り出した。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.1.2, §16.4, [[プラクティスのコミュニティ]]) - **講演本体(2009年)を一次資料として直接確認すると、Velocity 2009発表由来とされてきた「6ツール+4文化」の分解は、書籍化(2011年、10章)以前から既にこの2部構成そのものだった**: 本ページ既出の知見は、Velocity 2009のFlickr発表で挙げられた実践要素がInfrastructure as Code・CI/CD・フィーチャーフラグ・DORA・ChatOpsという独立領域へ分解していったと整理してきたが、その典拠は主にsecondary source([[@2026__mizzy.org__DevOpsとは何だったのか]]、[[@2018__devops.com__The Origins of DevOps - What's in a Name]])だった。講演スライド自体を直接確認すると、6つのツール(自動化インフラ・共有バージョン管理・ワンステップビルド&デプロイ・フィーチャーフラグ・共有メトリクス・IRC/IMロボット)と4つの文化(敬意・信頼・障害への健全な態度・非難の回避)という「ツール/文化」の2部構成は、2009年の講演時点で既に完成した枠組みであり、2011年の『ウェブオペレーション』10章はこの枠組みをほぼそのまま書籍の章立てへ移植したものだと分かる。CAMSの4要素(Culture・Automation・Measurement・Sharing、2010年John Willis定式化)と比較すると、本講演の6ツール+4文化はCAMSより1年早く、より粒度の細かい分解を独立に示していたことになる。(Source: [[@2009__Velocity2009__10+ Deploys Per Day - Dev and Ops Cooperation at Flickr]]) - **講演の核心は「Opsの仕事の再定義」であり、これはCAMSのCulture要素にもmizzy(2026)の「文化的運動」という位置づけにも先立つ、より根源的な問題提起だった**: 講演は「Opsの仕事はサイトを安定・高速に保つことではない」と明言したうえで「Opsの仕事は事業を可能にすることだ(これはDevの仕事でもある)」と再定義し、「ビジネスは変化を要求するが変化こそが大半の障害の根本原因である」という矛盾を提示する。この構図は、DevOpsが後年「文化 vs 実装」(class SRE implements DevOps)や「6要素への分解」として整理される以前の、Dev/Ops双方の職務定義そのものへの問い直しであり、CAMSのCultureがなぜ4要素の先頭に置かれたのか(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])を、講演の一次資料が具体的に裏付ける。(Source: [[@2009__Velocity2009__10+ Deploys Per Day - Dev and Ops Cooperation at Flickr]]) - **『Security Engineering』第3版第27章は、DevOpsがDevSecOpsへ拡張される過程を「Microsoft世界」と「Google世界」という2つの異なる経路として描き、本ページが2009年のFlickr講演から辿ってきたDevOpsの分解([[Infrastructure as Code]]・CI/CD・[[DORA]]等)の先に来る具体的な帰結を示す**: 本ページ既出の知見は、DevOpsが独立領域への分解と抽象概念化を経て使われなくなっていく経緯(mizzy 2026)や、CI/CDが本番運用と同水準の計測手法を獲得していく経緯(Observability Engineering 2E第18章)を扱ってきたが、「セキュリティをどう組み込むか」には踏み込んでいなかった。第27章は2020年時点の観測として、大企業がWindowsからAzureへ移行する「Azureエコシステム」では、脅威モデリング・静的解析・動的解析・ファジングテスト・監視・インシデント対応という数十のツールを統合する作業がDevSecOpsの実質であり、組織原則は「shift left」(セキュリティをコードベースに前倒しで統合する)だとする。一方Googleの2020年の著書『Building Secure and Reliable Systems』に基づく「Googleエコシステム」では、信頼性(SRE由来のエラーバジェット・可観測性)とセキュリティ(マイクロサービスの区画化・耐タンパー性のあるセキュリティコンテキスト・crypto API "Tink"・BeyondProdフレームワーク)を同じチームが統合的に扱う。両者はいずれも「DevOpsという語の分解」ではなく「DevOpsという実践にセキュリティを統合する」という、本ページの既存知見が扱ってこなかった第3の軸を加える。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.5, §27.5.6, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **本章はDevOpsの用語自体を使わず「infrastructure as code, also known as cloud native development or DevOps」と一度だけ定義的に言及し、その実質をGoogleの2013年『Site Reliability Engineering』を「DevOpsの彼らの用語」と位置づけるが、これは既存知見(『SREの探求』11章・12章)が示す「用語としての先後」問題に対し、部外者(セキュリティ研究者)の視点からもう一つの証言を加える**: 本ページ既出の知見は、DevOpsとSREの関係について「用語としての先後」(DevOpsが先、Mark Rendell)と「実践としての先後」(SRE実践が先、Gene Kim)という2つの異なる軸が存在することを『SREの探求』11章・12章から示してきた。セキュリティ研究者であるRoss Andersonは、これらのコミュニティ内部の議論には触れないまま、単純に「SREはDevOpsに対する彼らの用語だ("SRE is their term for DevOps")」と一文で片付けており、これはDevOpsコミュニティの外側から見ると両者の同一視がどれほど自明視されているかを示す一次資料である。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.5) - **2019年の学術サーベイが構築した概念地図は、「文化的運動から独立領域への分解」というmizzy(2026)の見立てを、ブログの回顧的物語より7年早く、文献の系統的分析という異なる経路から独立に裏づける**: 本ページ既出の知見は、Velocity 2009講演由来の実践要素がInfrastructure as Code・CI/CD・DORA・ChatOps等の独立領域へ分解していったというmizzy(2026)の物語的整理を記録してきた(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。Leite et al.(2019)第5章のPeople概念地図(図6)は、これとは独立に、文献の系統的分析からDevOpsが NoOps・SmartOps・ChatOps・SecDevOps という変異形を"originate"(派生させる)関係にあることを図示する。mizzy(2026)がChatOpsを「Velocity 2009のIRC/IMロボットが独立した実践領域に育った」という単一の起源物語として描くのに対し、Leite et al.(2019)はChatOpsを他の3つの変異形(NoOps・SmartOps・SecDevOps)と並列に扱い、いずれも"Global community knowledge"(グローバルなコミュニティ知識)に由来すると位置づける。学術サーベイの文献分析という、ブログの回顧的物語とは独立した方法論が、同じ「DevOpsからの分解」というパターンを2019年の時点ですでに図として定式化していたことになる。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] §5.2 図6, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **Leite et al.(2019)の全体概念地図(図4)が示す「Engineering perspective対Management perspective」「Ops related対Dev related」という2軸は、『SREをはじめよう』が紹介するLimoncelliモデル(パイプライン上の注目方向)に先行する、独立した幾何学的定式化である**: 本ページ既出の知見(Limoncelliモデルの項)は、DevOpsのストーリーが開発者のラップトップから本番稼働へ「前方」に向かうのに対し、SREは本番環境から「後方」へ視線を向けるという向きの違いを扱ってきた(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 1 はじめに]])。Leite et al.(2019)第5章の図4は、これとは独立に、DevOpsの概念空間全体を「Engineering perspective(Runtime・Delivery)対Management perspective(People・Process)」という縦軸と「Ops related(Runtime・People)対Dev related(Delivery・Process)」という横軸で4分割し、「deliveryは開発者に、runtimeは従来の運用者ロールに近い」と明示する(§5)。これはLimoncelliモデルが暗黙に前提する「dev寄り/ops寄り」という区分を、2019年の時点で学術的な概念地図として先取りしていたことを示す——ただし両者の軸は完全に同一ではない。Limoncelliモデルがパイプライン上の「注目する方向」という単一の軸を扱うのに対し、Leite et al.(2019)はさらに「エンジニアリング視点かマネジメント視点か」という直交する第2軸を加えており、DevOpsの内部構造を1軸でなく2軸で捉える点でより粒度が細かい。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] §5, [[@2024__OReillyJapan__SREをはじめよう - Chapter 1 はじめに]]) - **Leite et al.(2019)は学術サーベイとして「この運動は2008年にDevOpsと名付けられた[68]」と明記しており、これは本ページが実務者側の記事(mizzy 2026・devops.com 2018)から再構成してきた2008年のAgile Infrastructure BoF起源説を、独立した学術的な出典からも裏づける**: 本ページ既出の知見は、mizzy(2026)とdevops.com(2018)という独立した2つの実務者向け記事が2008年のAgile Infrastructure BoF・2009年のVelocity発表・同年のDevopsdays創設という経緯を年号・登場人物レベルで一致させていることを示してきた。Leite et al.(2019)第2章は、開発者と運用担当者の対立・デプロイの遅延・頻繁で信頼できるリリースの必要性からこの運動が2008年に「DevOps」と名付けられたと述べ、固有名詞(Debois・Shafer等)には触れないものの2008年という年号を実務者記事と独立に確認する。これにより、本ページ冒頭のcontradiction calloutが記録する『SREの探求』22章の2003-2007年説との対比で、2008-2009年起源説を支持する情報源が実務者記事2件に加え学術サーベイ1件へ増える。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 2 DevOps]] §2, [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2018__devops.com__The Origins of DevOps - What's in a Name]]) - **Leite et al.(2019)が採用する定義は「協働的かつ学際的な組織内の取り組み」を核とし、CAMSのCulture要素を定義の主語に据える点で本ページのCAMS(John Willis, 2010)の整理と構造的に対応する**: 本サーベイは「DevOpsとは、新しいソフトウェアバージョンの継続的デリバリを自動化しつつ、その正しさと信頼性を保証するための、組織内における協働的かつ学際的な取り組みである」という定義をDyck et al.の定義に類似する形で独自に作成し、全編で採用する。この定義は「協働的(collaborative)・学際的(multidisciplinary)」という組織文化的な性質を主語に置き、「自動化」は目的語(継続的デリバリを自動化する)として従属させており、本ページが記録するCAMS(Culture・Automation・Measurement・Sharing、John Willis 2010)でCultureが先頭に置かれAutomationが4要素の1つに過ぎなかったという整理と符合する。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 2 DevOps]] §1, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **Leite et al.(2019)は、DevOpsをアジャイル運動の進化形として位置づけ、その系譜をエクストリームプログラミング(XP)がデプロイに関するプラクティスを一つも持たなかったという具体的な欠落から説き起こす**: 本サーベイは「DevOpsはアジャイル運動の進化形である」としたうえで、黎明期のアジャイル文献(XPを含む)がデプロイ固有のプラクティスをほとんど扱っていなかったことを、本番移行が組織にとってストレスの多い手作業・誤りを伴うプロセスになりがちだったことの原因として説明する。この系譜づけは、本ページが16章(『ウェブオペレーション』)から記録するShaferの「アジャイルの2軸」(技術的ベストプラクティス/ビジネス結合)や、16章がDevOpsを「アジャイルを補完するプラクティス群」と位置づける記述と重なるが、Leite et al.はより明確に「アジャイル→(デプロイの欠落)→DevOps」という単線的な進化の物語として提示する点で、実務者の一次資料(16章)が示す並立的な2軸モデルとは異なる整理の仕方をしている。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 2 DevOps]] §2, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.1) - **Leite et al.(2019)第7章は、第5章の概念地図(Engineering視点対Management視点の2軸)とは別に、実践上の提言(implications)をエンジニア・管理者・研究者という3つの主体へ切り分けて再編成する**: 本ページ既出の知見は、第5章の図4がDevOpsの概念空間そのものをEngineering/Management×Ops/Devの2軸4象限に整理していたことを示した(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]])。同じサーベイの結論部にあたる第7章は、これとは異なる分析単位——文献から得た示唆をエンジニア(§7.1・15項目)・管理者(§7.2・9項目)・研究者(§7.3・3項目)という3つの読者層へ向けて個別に再編成する——を採用する。研究者は第5章の2軸には存在しない第3の立場であり、概念構造としては2軸で捉えられるDevOpsが、実践上の含意としては立場ごとに別々の問題として立ち現れることを、同一サーベイ内の異なる章の対比が示す。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 7 Implications for Engineers, Managers, and Researchers]] §7〜§7.3, [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] §5) - **同じ主題(ソフトウェアアーキテクチャ/組込みシステム)が、第7章内でエンジニア向けには確立した実践的助言として、研究者向けには未解決の研究課題として、立場によって異なる確度で提示される**: §7.1「Microservices」はエンジニアに向けて「継続的デリバリと合わせてマイクロサービスアーキテクチャを採用することが推奨される」という文献上既に確立した助言を提示するのに対し、§7.3「Software Architecture」は同じ主題を「望ましいアーキテクチャの実現が最初のDevOpsプロジェクト単体では非現実的な場合があり、移行戦略の調査が必要」という未解決の研究課題として提示する。組込みシステム/IoTについても同様に、§7.1は「エンジニアが更新機構をカスタマイズすべき」という実務対応として、§7.3は「IoT文脈での効果的なDevOps導入は未解決の研究課題」として同じ主題を扱う。立場の違いが、同一の対象に対する記述の確度・粒度そのものを変えることを示す一次資料である。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 7 Implications for Engineers, Managers, and Researchers]] §7.1, §7.3) - **Leite et al.(2019)は継続的デリバリと継続的デプロイメントをDevOpsと「密接に関連する」が同一ではない概念として明確に区別しており、この区別は本ページが記録する分解先の独立領域(Infrastructure as Code・CI/CD等)の整理に定義上の前提を与える**: 本サーベイはHumbleの『Continuous Delivery』を引き、コミットされたすべてのバージョンが本番投入候補版でなければならない自動化デプロイパイプラインを継続的デリバリと定義し、パイプラインを通過したすべてのバージョンを自動的に本番へ送る継続的デプロイメントをその派生形と位置づける。そのうえで「多くの著者がDevOpsを継続的デリバリ・デプロイメントと密接に関連付けている」と述べ、Yasarの「デプロイパイプライン=DevOpsプラットフォーム」という呼称を例示するが、DevOps自体をこれらの実践と同一視してはいない。本ページ既出の知見は、Velocity 2009のFlickr講演由来の実践要素が「ビルド&デプロイの一本化→CI/CD」という独立領域へ分解したと整理してきたが、Leite et al.の定義上の区別は、この分解が起きる前から「DevOpsは継続的デリバリそのものではなく、それを含意する広い取り組みである」という前提が学術文献にも存在したことを示す。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 2 DevOps]] §2, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **第5章の概念地図(図6)が名前だけ列挙するDevOps変異形「NoOps」に、第8章は定義と実現条件を与えるが、同時に「学術文献はまだこの主題を扱っていない」という2019年時点での文献上の空白を自ら明記する**: 本ページ既出の知見は、Leite et al.(2019)第5章の図6がPeople概念地図の中でNoOps・SmartOps・ChatOps・SecDevOpsという変異形を"originate"関係として図示するにとどまり、内容には立ち入らないことを示した(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] §5.2 図6)。同じサーベイの第8章§8.2は、この図6で名前だけ挙がっていたNoOpsについて「運用が支援サービス(継続的インテグレーション・監視)を提供し、プロダクト信頼性が適切に設計されていれば、運用をサードパーティのクラウドサービスに置き換えられる」という実現条件と、「IT環境が十分に自動化・抽象化された結果、社内でソフトウェアを管理する専任チームが不要になるという概念」という定義[108]を与える。ただし著者ら自身が「一部のブログ記事はNoOps概念を推進しているが、学術文献はまだこの主題を扱っていない」と明記しており、同一サーベイ内で図として名前を与えられた変異形が、本文では未だ学術的な検証を欠く概念として扱われているという二重性が、第5章と第8章を並べて初めて見える。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] §5.2 図6, [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 8 Unresolved Challenges]] §8.2) - **Leite et al.(2019)が「2008年に DevOps と名付けられた」と述べる際の参照 [68] は Patrick Debois の Agile 2008 Toronto での発表であり、本ページの起源記述の一次文献が学術サーベイの参考文献として明示的に特定できた**: 本ページは 2008 年の Agile Infrastructure BoF 起源説を実務者記事 2 件([[@2026__mizzy.org__DevOpsとは何だったのか]]・[[@2018__devops.com__The Origins of DevOps - What's in a Name]])と学術サーベイ 1 件(Leite et al. 2019 第 2 章)から支持してきたが、サーベイ側が引く一次文献の同定は保留していた。本サーベイの参考文献一覧は `[68] Patrick Debois. 2008. Agile Infrastructure Operations. At Agile 2008 Toronto.` と記載しており、Debois 本人の 2008 年 Agile カンファレンス発表が命名の起点であることを、実務者記事とは独立の学術的引用として確認できる。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 2 DevOps]] §2 と同サーベイの参考文献 [68]) - **第6章のTable 4(ツール分類)は、本ページが「DevOpsパターンの実践的起源」として記録してきたLISAコミュニティ系譜(cfEngine・Puppet)の技術的到達点を、DevOps自身の学術サーベイの側から独立に確認する**: 本ページ既出の知見は、『ウェブオペレーション』5章(Adam Jacob, 2011)がDevOpsという語に触れないまま「構成管理ツールのルネッサンス」としてChef・cfengine・Puppetを列挙していたことを記録した。Leite et al.(2019)第6章§6.5のTable 4は、これとは独立に、DevOpsツールの体系的分類としてChef・PuppetをDeployment automationカテゴリの代表ツールに位置づけ、「Configuration management」「Infrastructure as code」という概念と対応づける。8年の間隔を置いた2つの独立した文献(実務者の回顧2011年、学術サーベイ2019年)が、いずれもChef・Puppetを構成管理の中心的ツールとして扱っている点で一致する一方、2019年のサーベイは同時にDocker(コンテナ化)との「補完に見えて実際は競合」という新しい対立軸を明示的に加えており、2011年時点では列挙のみだった構成管理ツール群が、2019年までにコンテナ化という対抗戦略との緊張関係のなかで再定義されていたことを示す。ツールと概念の対応の詳細は [[収束型システム管理]] に切り出した。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1.1.3, [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]] §6.5, Table 4) - [LISA '11(2011年)] LISA '11では、Ben Rockwood(Joyent)の基調講演「DevOpsはツールでも肩書きでもなく文化的・専門的な活動である」、Luke Kanies(Puppet Labs)の招待講演「DevOpsはAgile Manifestoの4原則をシステム管理に適用する文化的変化である」、Etsyの Deployinator 事例(単一デプロイマスター体制から誰でも常時デプロイ可能な体制への移行)、Google SREのreadiness reviewモデルが同一カンファレンス上で並走して語られており、DevOpsという語がまだ定義の定まらないバズワードとして扱われていたことがAdvanced Topics Workshopでも指摘されている。(Source: [[@2012__login__USENIX LISA '11 - 25th Large Installation System Administration Conference]]) ## 未解決の問い - マイクロサービスはDevOpsを「促進する」(Balalaie et al.)のか「要求する」(Callanan and Spillane)のか、Leite et al.(2019)第8章が引く文献間で決着していない。APIバージョニングの是非(Humbleは推奨するが一部コミュニティは通常非推奨とする)も同様の技術的対立として未解決のまま残る。 - デリバリ自動化が十分な増分化によってデプロイを「非日常的な出来事(non-event)」にするなら、「開発チームと運用チームがリリース成功を共に祝うべきである」という実践(Humble)は矛盾しないか。Leite et al.(2019)第8章はこの緊張を指摘するにとどまり、解消は示していない。 - NoOpsは2019年時点で「学術文献がまだ扱っていない」概念として第8章に明記されている。運用をサードパーティのクラウドサービスへ完全に置き換えるというNoOpsの実現条件は、その後の学術文献でどこまで検証されているか。本 concept の現ソース群では未検証。 - DevOpsプラクティスの成熟度モデル(Feijter et al.等)は複数提案されているが、Leite et al.(2019)第8章の時点で業界に広く採用されたものはない。測定データをチームの処罰に使うと収集自体が信頼できなくなるという指摘(Forsgren and Kersten)を踏まえたとき、罰への転用を構造的に防ぐ成熟度モデルの設計は可能か。 - 100種類を超えるDevOpsツールをエンジニアにどう教育するかについて、演習の自動採点はDockerを用いても(Christensen)マルチサーバ環境でのエラー検知という技術的難点のため完全自動化に至らなかった(Leite et al. 2019第8章§8.4)。この採点自動化のギャップは、その後どこまで埋まっているか。 - SoundCloudが「you build it, you run it」を「SREの基本とは反する」と自認しながらも、章の結論部では「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものである」というSREの基本原則(Treynor Sloss)を引いて自らの実践を正当化する。この一見矛盾する自己認識(反する/しかし体現している)は、DevOpsとSREが「対立する二者択一」ではなく「同じスペクトルの両端」であることを示すのか、それとも用語の恣意的な使い分けにすぎないのか。本 concept の現ソース群では未検証。 - DevOps未導入のままSRE導入を急ぐヘルスケア業界のような組織(第6章)は、DevOpsを先に導入してからSREへ進む王道の順序へ後から追いつくべきか、それとも規制産業に特有の制約(月次リリース・低いCI/CD自動化率)を前提に別の導入順序を設計すべきか。本 concept の現ソース群では未検証。 - Dev/Opsをすでに機能横断的なDevOpsチームへ統合した組織で、専門職としてのSREを再導入する場合、DevOpsが目指した機能横断性を損なわずに専門性を確保する組織設計パターンは何か。 - CI/CDが「本番システムと同じ計測厳密さ」を獲得した後も、DevOpsのCulture(CAMSの先頭要素)に相当する部分——部門間の分断解消——はCI/CDオブザーバビリティ([[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]])のような技術的枠組みだけで達成できるか、それとも別の組織的介入が必要か。 - CAMSの4要素のうちAutomationとMeasurementには明確な後継語(Infrastructure as Code・CI/CD・DORA)ができたが、Cultureの後継(Team Topologies・Learning from Incidents・Resilience Engineering)は、部門間の分断解消という原意をどこまで実際に引き継げているか。 - Observability Engineering 2nd Edition 最終章が予測する「AI起因のdev/opsの分断線の破壊」([[コードのキャッシュ化]] の議論と地続き)は、mizzy(2026)が描く「文化から職種・技術レイヤーへの縮約」を逆転させる力になるか、それとも「AIOps」「Platform Engineering」に続く新たな名乗りの独立領域を生むだけに終わるか。 - DevSecOps(2013年頃登場)やPlatform Engineeringのように、DevOpsから分岐して新語が必要になり続けている現象は、DevOpsという語が対象とする組織的分断そのものが解決していないことの証拠と言えるか、それとも単なる自然な専門分化か。 - 「class SRE implements DevOps」のような定式化は、SREという語についても同じ「文化→職種・技術レイヤーへの縮約」を繰り返す可能性があるが、それを防ぐための語彙・実践は何か。 - Gene Kimが11章で挙げる3パターン(自動化テスト・レディネスレビュー・単一共有リポジトリ)以外にも、『The DevOps Handbook』はGoogleのSRE実践に由来するパターンをさらに含んでいるか。11章は「筆者が特に気に入っている3種類のパターン」と述べており、抜粋されなかった他のパターンの存在を示唆するが、本 concept の現ソース群では未確認。 - Googleの2013年統計(自動化テスト・ビルド頻度)とDORAの4キーメトリクスとの対応関係を、DORA自身の文献(State of DevOps Report等)は明示的に参照しているか。本 concept の現ソース群では、両者が同種の活動を測定していることの構造的な類似は指摘できるが、DORA側からGoogleのこの実践への直接の言及があるかは未検証。 - 『SREの探求』22章がDevOpsの立ち上がりを2003〜2007年頃と述べる根拠は何か。本ページの2008-2009年起源説(Debois・Agile Infrastructure BoF・devopsdays)を裏づける2ソースとは年号が一致せず、22章側は固有名詞・一次資料を示していないため、どちらが正確か、あるいは双方が異なる局面(非公式な萌芽期 対 正式命名・コミュニティ形成期)を指しているだけなのかは未解決(本ページ冒頭の contradiction callout 参照)。 - 12章のコミュニティ回答が示す7つの説明軸(実装関係・アプローチ対役割・成熟度移行・パイプライン注目方向・用語先後・組織事情・相補的反応、詳細は [[DevOpsとSREの関係]])は、本ページが独立に蓄積してきた説明軸(文化vs実装・分解・起源)とどこまで同一で、どこまで独自か。両concept間の突き合わせは着手したばかりで、体系的な対応表は未作成。 - LISAの終了(2022年)とSREconへのバトンタッチは、mizzy(2026)が描く「DevOpsが独立領域への分解・名乗りの消費を経て抽象概念として使われなくなった」プロセスと同じ力学の別表現(コミュニティ・カンファレンスというインフラの世代交代)と言えるか。それとも、システム管理者という職能自体がSRE/DevOpsへ吸収・専門分化していく別のプロセスなのか。本 concept の現ソース群では未検証。 - LISA併設のconfiguration management workshop(cfEngine・BCFG2・Puppet起源)が具体的にいつ始まったかは Limoncelli(2022)では特定できない。DevOpsという語の起源(2008-2009年、本ページ既出)より前からIaCの実践的基盤が育っていたとすれば、「DevOpsパターンの実践的起源」を巡る系譜はGoogle SRE・LISAシステム管理者コミュニティの少なくとも2系統に増える。両系統の時系列的な先後関係は本 concept の現ソース群では未整理。 - 16章著者Shafer自身の「アジャイルの2軸」(技術的なベストプラクティス/仕事の成果をビジネスと結び付ける方法)と、John WillisのCAMS(2010年)は、どちらが先に定式化されたか。両者は独立と思われるが、16章刊行(2011年)とCAMS提示(2010年)の前後関係だけでは、着想の先後まで確定できない。 - 16章が示す「カンバン(流れ・プルベース)を運用のタスク管理に、イテレーション(タイムボックス)を開発に」という使い分けは、DevOps文献一般でどこまで共有された立場か、それとも16章固有の見解か。本ページの現ソース群では他のDevOps起源文献(Debois・Hammond)がこの対比に触れているかは未検証。 - DevSecOpsの「Azureエコシステム」(ツール統合中心)と「Googleエコシステム」(信頼性・セキュリティ統合中心)という2つの経路(『Security Engineering』第27章)は、[[プラットフォームエンジニアリング]]が扱う後継の組織論とどこまで同じ現象を指しているか。本ページの現ソース群では未検証。 - 16章の「DevOpsという語を使ったうえで相対化する」という態度(名前は何だってよい)は、当事者自身の言葉でありながら、その後(2013年以降)のDevOps普及・大衆化(『The Phoenix Project』等、既出)が進むにつれて、Shafer自身の立場が変化したかどうかは本ページの現ソース群では追えていない。 - Leite et al.(2019)の図6が挙げるDevOps変異形(NoOps・SmartOps・ChatOps・SecDevOps)と、mizzy(2026)が挙げる分解先の独立領域(Infrastructure as Code・CI/CD・フィーチャーフラグ・DORA・ChatOps)は、ChatOpsのみ重複し他は重ならない。両リストの差(NoOps・SmartOps・SecDevOpsがmizzy側に現れない理由、IaC・CI/CD・DORAがLeite et al.側の図6に現れない理由)は、前者が「Peopleカテゴリの変異形」、後者が「CAMS4要素の分解先」という異なる分類軸によるものと推測されるが、本ページの現ソース群ではこの軸の違いを明示的に突き合わせた記述はない。 ## 関連 - 実装としての関係: [[SRE]](「class SRE implements DevOps」) - 注目方向としての関係: [[@2024__OReillyJapan__SREをはじめよう - Chapter 1 はじめに]](Limoncelliモデル、Donovan Brownの「デリバリー」) - 分解先の独立領域: [[Infrastructure as Code]] / [[ChatOps]] / [[DORA]] / [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] - 後継の組織論: [[プラットフォームエンジニアリング]] - 起源の人物: [[Patrick Debois]] / [[Andrew Clay Shafer]] / [[John Allspaw]] / [[Paul Hammond]] / [[John Willis]] - 普及の担い手: [[Gene Kim]] / [[Kevin Behr]] / [[George Spafford]](『The Phoenix Project』) - 学術的な体系化: [[A Survey of DevOps Concepts and Challenges]]([[Leonardo Leite]]・[[Carla Rocha]]・[[Fabio Kon]]・[[Dejan Milojicic]]・[[Paulo Meirelles]]によるconceptual framework構築) - 定義・起源・アジャイル/継続的デリバリとの系譜(学術サーベイ側): [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 1 Introduction]] / [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 2 DevOps]] - AIによる分断線破壊の予測: [[@2026__OReilly__Observability Engineering 2E - Chapter 32 Where Do We Go From Here?]] / [[コードのキャッシュ化]] - 専門職再導入への慎重論: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 1 エンタープライズSREことはじめ]] - DevOps未導入下でのSRE導入の急勾配: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]] / [[Joseph Bironas]] - 当事者による対立軸の明言: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] / [[SoundCloud]] / [[Björn Rabenstein]] / [[Matthias Rampke]] - DevOpsパターンのGoogle起源説(著者自身の証言): [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] / [[Gene Kim]] / [[The DevOps Handbook]] / [[レディネスレビュー]] - 起源年の食い違い: [[@2021__OReillyJapan__SREの探求 - Chapter 22 成功の文化としてのSRE]] / [[Kurt Andersen]] - Limoncelliモデルの一次資料と用語先後の軸: [[@2021__OReillyJapan__SREの探求 - Chapter 12 DevOpsとSRE：コミュニティからの声]] / [[Thomas A. Limoncelli]] / [[DevOpsとSREの関係]] - IaCの別系譜とLISA/SREconの制度的世代交代: [[@2022__USENIX__LISA made LISA obsolete (That's a compliment!)]] / [[LISA]] / [[USENIX]] / [[SAGE]] - DevOps語彙を使わない同時期の技術的基盤(CAMSのAutomation相当): [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] / [[Adam Jacob]] / [[cfengine]] / [[Mark Burgess]] - DevOps語彙を使わない同時期のCulture/Measurement/Sharing相当の体系化(Velocity 2009講演当事者自身による記述): [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]] / [[Paul Hammond]] / [[Flickr]] - 方法論としてのアジャイル適用可否・運動としての起源(Agile Infrastructure BoFの当事者自身による記述): [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] / [[Andrew Clay Shafer]] / [[プラクティスのコミュニティ]] / [[アジャイルな計画づくり]] / [[イテレーションの長さ]] - 起源講演の一次資料(スライド・音声): [[@2009__Velocity2009__10+ Deploys Per Day - Dev and Ops Cooperation at Flickr]] - DevSecOpsへの拡張(Azure/Googleエコシステム、外部研究者による用語の同一視): [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] - 学術サーベイの概念地図(process/people/delivery/runtime、DevOps変異形、2軸構造): [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]] - 立場(エンジニア/管理者/研究者)による含意の切り分け: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 7 Implications for Engineers, Managers, and Researchers]] - ツール分類と概念地図の対応(コンテナ化対継続的構成収束): [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]] / [[収束型システム管理]] / [[Chef]] / [[Puppet]] / [[Docker]] - ソース: [[@2012__login__USENIX LISA '11 - 25th Large Installation System Administration Conference]] ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]](アダム・ジェイコブ, 2011, §5.1〜§5.2)— DevOpsという語を使わず構成管理をコードとして扱う技術的基盤(CAMSのAutomationに相当)を体系化。同書6章の著者Patrick DeboisがDevOpsdaysの創設者である一方、5章はDevOpsという語に一度も触れない - [[@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]] - [[A Survey of DevOps Concepts and Challenges]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 32 Where Do We Go From Here?]] - [[@2024__OReillyJapan__SREをはじめよう - Chapter 1 はじめに]] - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 1 エンタープライズSREことはじめ]] - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]] - [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] — 「you build it, you run it(真のDevOps)」をSREの基本と対立する選択として明言する当事者証言 - [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]](Gene Kim, 『SREの探求』, オライリー・ジャパン, 2021, 11章; 原典『The DevOps Handbook』2016)— DevOpsが当たり前とみなす実践の多くにGoogleが先駆者だったという著者自身の証言、2013年時点のGoogleの自動化テスト・ビルド統計 - [[@2021__OReillyJapan__SREの探求 - Chapter 22 成功の文化としてのSRE]](Kurt Andersen, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 22章)— DevOpsの立ち上がりをSREとほぼ同時期(2003〜2007年頃)と位置づける、本ページの2008-2009年起源説と食い違う年号(冒頭の contradiction callout 参照) - [[@2021__OReillyJapan__SREの探求 - Chapter 12 DevOpsとSRE：コミュニティからの声]](David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 12章)— Thomas A. Limoncelliによるモデルの一次資料、業界用語としてのDevOps/SREの先後関係(Mark Rendell) - [[@2022__USENIX__LISA made LISA obsolete (That's a compliment!)]](Thomas A. Limoncelli, ;login: online, USENIX, 2022-10-27)— LISA併設workshop起源のIaC系譜、LISA終了とSREconへのバトンタッチという制度レベルの世代交代 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]](ポール・ハモンド, 2011, 全章)— Velocity 2009講演の当事者自身による、CAMSのCulture・Measurement・Sharing相当の内容の体系化。DevOpsという語には一度も触れない - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]](アンドリュー・クレイ・シェーファー, 2011, §16.1, §16.2.1, §16.4)— Agile Infrastructure BoFの当事者自身による、DevOpsという名前そのものの相対化、アジャイルの2軸(技術的ベストプラクティス/ビジネス結合)、アジャイル手法の運用への機械的移植への留保 - [[@2009__Velocity2009__10+ Deploys Per Day - Dev and Ops Cooperation at Flickr]](John Allspaw・Paul Hammond, Velocity 2009, 2009-06-23)— DevOpsの語誕生につながった講演本体の一次資料。「6ツール+4文化」の完成した2部構成、Opsの仕事の再定義 - [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]](Ross Anderson, 2020, §27.5.5-§27.5.6)— DevOpsからDevSecOpsへの拡張を「Azureエコシステム」「Googleエコシステム」という2経路で描く、セキュリティ研究者側からの一次資料 - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 5 Fundamental Concepts]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §5)— DevOps全体概念地図(Engineering/Management×Ops/Dev の2軸)、process/people/delivery/runtime4カテゴリ、People領域のDevOps変異形(NoOps・SmartOps・ChatOps・SecDevOps) - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 1 Introduction]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §1)— 本サーベイが採用するDevOps定義の初出、エンジニア/マネージャー/研究者3視点によるDevOps論の枠組み - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 2 DevOps]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §2)— DevOpsをアジャイル運動の進化形と位置づける系譜、開発/運用サイロの記述、2008年の命名[68]、継続的デリバリ・デプロイメントとの関係、SREの初出言及 - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 7 Implications for Engineers, Managers, and Researchers]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §7〜§7.3)— DevOps文献の含意をエンジニア・管理者・研究者の3つの立場に個別に切り分けて再編成する構成、同一主題(ソフトウェアアーキテクチャ・組込みシステム)が立場によって確立した助言/未解決の研究課題という異なる確度で現れる対比 - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §6.5, Table 4)— DevOpsツール分類(Table 4)とDevOps概念の対応づけ、コンテナ化(Docker)対継続的構成収束(Chef・Puppet)の対立