DevOpsとは？アジャイル・CI/CDとの違いとDORA 5指標での成果の測り方

DevOps（デブオプス）は、開発（Development）と運用（Operations）が別々の目標で動くのをやめ、変更を作ってから本番で動かし、その結果を次の開発に戻すまでの責任を両者で共有する進め方です。1つのチームに統合する組織もあれば、別チームのまま協業する組織もあります。特定の製品や規格の名前ではなく、文化・自動化・測定を組み合わせた実践の総称を指します。

この記事では、言葉の由来と成立条件（CALMS）、アジャイル・CI/CD・SREとの違い、工程ごとのツールの分担を整理したうえで、DORA（旧称DevOps Research and Assessment。2025年に略語としての扱いをやめ、DORAを正式名とした）が定める現行の5指標で成果を測る方法を扱います。Gitのタグからデプロイ頻度と変更リードタイムを算出するスクリプトも載せているので、指標の計測を自分のリポジトリで始められます。

まとめ：DevOpsの要点と最初に測るもの

• 定義：開発と運用が本番の結果まで責任を共有し、自動化と測定で変更を小さく速く安全に届ける進め方。ツールを揃えただけでは成立しない。
• 違い：アジャイルは短い反復と利用者のフィードバックで価値を届ける考え方、CI/CDは統合と配信を自動化する仕組み。DevOpsは計画から運用までを通じた開発と運用の協働と責任共有に重点がある。SREはDevOpsを運用側から実装する職務と手法の体系。
• 成果の測り方：DORAの指標は2024年から5つ（変更リードタイム・デプロイ頻度・失敗したデプロイの復旧時間・変更失敗率・デプロイ手戻り率）。「Four Keys」の4指標とElite〜Lowの区分で覚えている場合は更新が要る。
• 最初の一歩：ツール選定より先に、デプロイ履歴から現在値を出す。本記事のスクリプトなら、Gitのタグからデプロイ頻度と変更リードタイムの近似値が出る。
• 導入判断：人数やリリース回数ではなく、手作業のリリースと障害対応にかかっている工数・停止の損失と、自動化の構築・保守の費用を比べて決める。

DevOpsの意味と2009年の起源

開発と運用の目標がずれる構造

開発チームは新機能を早く出すことで、運用チームは本番を止めないことで評価されます。変更を増やしたい側と変更を減らしたい側が別々の指標で動くため、リリースのたびに「開発は渡したら終わり、運用は変更を渋る」という対立が起きます。DevOpsはこの対立を、両者を同じ指標に載せ、リリース後の安定までを開発側の責任範囲に含めることで解消しようとする考え方です。

言葉の起点は2009年です。同年6月のVelocityカンファレンスで、FlickrのJohn AllspawとPaul Hammondが「10+ Deploys per Day: Dev and Ops Cooperation at Flickr」と題して開発と運用の協業を発表し、これに触発されたベルギーのPatrick Deboisが同年10月30・31日にゲントで第1回DevOpsDaysを開催しました。DevOpsという語はこのイベント名から広まったもので、特定の企業の製品名ではありません。

CALMSで点検するDevOpsの成立条件

DevOpsが形だけになっていないかは、CALMSと呼ばれる5つの観点で点検できます。2010年、米国初のDevOpsDays（マウンテンビュー）の後にDamon EdwardsとJohn Willisが文化・自動化・測定・共有の4つ（CAMS）をまとめ、のちにJez HumbleがLean（リーン）を加えました（John Willis「DevOps Culture (Part 1)」）。

ツールで解けるのはAutomationとMeasurementの一部だけです。CultureとSharingは評価制度と体制の設計なので、ここを飛ばしてCI/CDだけを入れると、パイプラインはあるのに開発と運用の壁は残ったままになります。

DevOpsとアジャイル・CI/CD・SREの違い

ウォーターフォール・アジャイルとの守備範囲

アジャイルは短い反復と利用者のフィードバックで価値を届けることに重点を置き、運用チームの関与は手法によってまちまちです。DevOpsは計画・開発・配信・運用のすべての段階を通じて、開発と運用が協働し責任を共有することに重点を置きます。両者は競合せず、アジャイルで小さく作った変更を本番で動かし、その結果を次の計画に戻す流れまでをDevOpsが扱うと捉えると実務に落としやすくなります。開発工程全体の中での位置づけはSDLCとは？ソフトウェア開発ライフサイクルの7工程とモデル選定・DevOps連携で整理しています。

CI/CDはDevOpsの自動化部分

CI（継続的インテグレーション）は変更をこまめに統合してテストする工程、CDは2つの意味で使われ、継続的デリバリーはテストを通った成果物をいつでも本番に出せる状態に保つこと、継続的デプロイは本番への反映までを自動で行うことを指します。CI/CDはDevOpsの自動化（CALMSのA）を担う仕組みで、DevOpsそのものではありません。CI/CDを入れても、障害時に開発者が呼ばれない体制のままなら、変更の結果が開発に戻らず改善は回りません。パイプラインの構成と設定例はCI/CDとは：仕組み・パイプライン構成・GitHub Actionsの設定例と導入判断の基準を解説で扱っています。

SREはDevOpsを運用側から実装する手法

SRE（Site Reliability Engineering）はGoogleが体系化した運用の職務と手法で、SLO（サービスレベル目標）とエラーバジェットで「どこまで変更を許すか」を数値で決めます。DevOpsが目指す方向を示す考え方だとすれば、SREはそれを運用の現場で実装する具体策の1つです。両者の関係はSREとは？サイト信頼性エンジニアリングの意味・DevOpsとの違いをわかりやすく解説、目標値の決め方はSLOとは？SLA・SLIとの違いと設定方法をわかりやすく解説が詳しく扱っています。

DevOpsのライフサイクルと工程ごとのツール

DevOpsの自動化は、独立したツールを工程の順につないで組みます。何を入れるかより、どの工程の手作業を外すかで選ぶほうが失敗しません。

インフラの構成をコードで管理するIaC（Infrastructure as Code）が無いと、環境間の設定差や、デプロイ時の手作業を人が管理し続ける負担が生じやすくなります。考え方と導入判断はIaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説を参照してください。監視はリリースして終わりにしないための工程です。異常の検知にはメトリクスやアラート、原因の調査にはログやトレースが使われ、サービスに必要なデータが不足すると、発見や復旧が遅れるおそれがあります。

速さと安定を両立させる要は、変更を小さく刻み、一部の利用者から段階的に出すことです。新バージョンを一部のトラフィックにだけ流して様子を見る手法はカナリアリリースとは？段階リリースの仕組み・他方式との違い・実装と採用判断を実装視点で解説、メトリクスで昇格とロールバックを自動判定する構成はプログレッシブデリバリーとは？自動分析で昇格とロールバックを判断する実装と採用基準で解説しています。

DORAの5指標によるDevOpsの成果測定

スループット3指標と不安定性2指標の定義

DevOpsが効いているかは、DORAが定めるソフトウェアデリバリーの指標で測ります。DORAの公式ガイド（2026年1月5日更新）は指標を5つとし、変更がどれだけ流れるか（スループット）と、デプロイがどれだけ問題を起こすか（不安定性）の2群に分けています。

同ガイドは「速さと安定はトレードオフではない」とし、多くのチームで指標どうしが相関すること、上位のチームは5指標すべてで良い値を出すことを示しています。指標は組織全体で混ぜず、アプリケーションやサービスごとに測るよう求めている点も押さえておきます。

ただし相関は「必ず」ではありません。2024年版レポートの区分では、Eliteが変更リードタイム1日未満・1日複数回のデプロイ・変更失敗率5%・復旧1時間未満だった一方、Highの変更失敗率20%に対してMediumは10%で、スループットが低いMediumのほうが安定していました。区分の境界値は年度ごとに変わるので、自社の値は他社の目安より前四半期の自社と比べるほうが判断を誤りません。

Four Keysから5指標への改定点

「Four Keys」（デプロイ頻度・変更リードタイム・変更失敗率・平均復旧時間）で覚えている場合、DORAの指標の変遷に沿って2点を更新する必要があります。2023年に平均復旧時間（MTTR）が「失敗したデプロイの復旧時間」に置き換わり、デプロイが原因の障害だけを数える定義になりました。2024年には、変更失敗率が手戻りの量を代わりに表しているという仮説を検証するため、5つ目の「デプロイ手戻り率」が加わりました。

2021年版のレポートが「5つ目の指標」と呼んだ信頼性（Reliability）は、DORA自身が「デリバリーの指標ではなく運用の指標で、5つ目と呼んだのは不正確だった」と訂正しています。現在の5つ目はデプロイ手戻り率です。また2025年版のレポートは、デリバリーの指標だけでは不十分だとして、性能・安定性・ウェルビーイングの組み合わせからチームを7つの類型に分けて示しています。4指標それぞれの計算方法と社内での集計方法はFour Keysとは｜DORA 4指標の定義・計算方法とベンチマークが詳しく扱っています。

Gitのタグによるデプロイ頻度と変更リードタイムの近似計測

計測のために専用の基盤を先に作る必要はありません。本番リリースのたびにGitのタグを付けている運用なら、タグの時刻を「デプロイ」、直前のタグからそのタグまでに入ったマージ以外のコミットのコミッター日時を「変更」とみなすことで、スループットのうち2指標の近似値が出ます。タグの時刻は種類で意味が変わり、git tag -a で作る注釈付きタグはタグを付けた時刻、-a を付けない軽量タグはタグが指すコミットの時刻になります（git for-each-refの仕様）。次のスクリプトは追加のPythonパッケージを必要とせず、Gitコマンドが実行できる環境で動きます（Python 3.9で動作を確認）。

# dora_throughput.py：Gitのタグを本番デプロイとみなし、デプロイ頻度と変更リードタイムを出す
import re, statistics, subprocess, sys, time

def git(*args):
    return subprocess.run(["git", *args], capture_output=True, text=True, check=True).stdout

days = int(sys.argv[1]) if len(sys.argv) > 1 else 90
if days <= 0:
    sys.exit("日数は1以上で指定してください")
pattern = re.compile(sys.argv[2] if len(sys.argv) > 2 else r"^v\d+\.\d+\.\d+$")
since = time.time() - days * 86400

tags = []
for line in git("for-each-ref", "refs/tags", "--sort=creatordate",
                "--format=%(refname:short) %(creatordate:unix)").splitlines():
    name, ts = line.rsplit(" ", 1)
    if pattern.match(name):
        tags.append((name, int(ts)))

lead_hours = []
deploys = 0
for i, (tag, tag_ts) in enumerate(tags):
    if tag_ts < since:
        continue
    deploys += 1
    if i == 0:
        continue  # 最初のタグは比べる相手が無いのでリードタイムを出さない
    prev = tags[i - 1][0]
    for ct in git("log", "--no-merges", "--format=%ct", f"{prev}..{tag}").split():
        lead_hours.append((tag_ts - int(ct)) / 3600)

print(f"期間: 直近{days}日 / デプロイ数: {deploys}")
print(f"デプロイ頻度: {deploys / (days / 7):.2f} 回/週")
if lead_hours:
    print(f"変更リードタイム中央値: {statistics.median(lead_hours):.1f} 時間 (対象コミット {len(lead_hours)})")

リポジトリの直下で python3 dora_throughput.py 365 のように、集計する日数を渡して実行します。2つ目の引数で、本番リリースのタグだけに当たる正規表現を指定できます（既定は v1.2.3 形式）。PythonのHTTPライブラリrequests（psf/requests）を2026年10月9日に取得し、直近365日で実行した結果は次のとおりです。

期間: 直近365日 / デプロイ数: 5
デプロイ頻度: 0.10 回/週
変更リードタイム中央値: 452.7 時間 (対象コミット 84)

requestsのタグは軽量タグなので、ここでの「デプロイ」時刻はリリース用コミットの時刻で、配布サイトへの公開時刻ではありません。出力は使い方を示す例であり、本番デプロイの実測値ではない点に注意してください。自社で使う前提として、次の点を確認します。タグを付けた時刻と本番に反映された時刻がずれる運用では値が実態から離れるので、CDツールのデプロイ履歴を代わりに使います。保守ブランチのように複数のリリース系列が並行する場合は、正規表現で1系列に絞らないと時刻順で隣り合う別系列のタグと比べてしまいます。浅いクローンやタグを取得していないクローンでは、履歴が欠けて正しく数えられません。rebaseやsquashマージでコミッター日時が書き換わる運用では、リードタイムが実際より短く出ます。そして5指標のうち、失敗したデプロイの復旧時間と不安定性の2指標は出ません。これら3指標は、どのデプロイが障害につながり、いつ復旧したかという記録が要るため、インシデント管理の記録とデプロイ履歴を結び付ける運用を先に決めてください。

指標をノルマにしたときの失敗パターン

DORAのガイドは、指標を目標そのものにすることを最初の落とし穴に挙げています。「年内に全アプリで1日複数回デプロイ」のような一律の目標を置くと、意味の無い小さなデプロイを増やして数字を合わせる行動が起きます（グッドハートの法則）。ほかにも、指標を1つだけ追う、規制業界であることを改善しない理由にする、モバイルアプリと基幹系のように性質の違うシステムを横並びで比べる、チーム間で競わせる、といった使い方を避けるよう求めています。

改善を判定するときは、スループットと不安定性を必ず組で見ます。同じサービスで比較期間の長さと集計条件を揃え、デプロイ件数も観測値として並べたうえで、変更失敗率・デプロイ手戻り率・復旧時間が悪化しないままリードタイムが複数の四半期にわたって縮み続けていれば、改善の兆候と判断できます。

DevOps導入の進め方：現状計測・制約1つの改善・再計測の反復

DORAが改善の進め方として示しているのは、ツールの一括導入ではなく、次の反復です。

1. 開発・リリース・運用を担うメンバーを集め、DORA Quick Checkなどで現在の値を出す
2. デリバリーの流れを書き出し、どこで待ちや手戻りが起きているかを話し合う
3. 最も大きい制約を1つだけ選び、チーム全員で改善に合意する
4. コードレビューの所要時間やテストの品質など、先行して動く補助指標を決めて計画に落とす
5. 改善を実施し、Quick Checkとふりかえりで結果を確かめて、次の制約へ移る

手作業のデプロイが最大の制約ならCDから、テストが通るまで半日かかるならCIの並列化から、と着手点は組織ごとに変わります。共通する手段は変更の単位を小さくすることで、ガイドも5指標すべてに効く方法としてバッチサイズの縮小を挙げています。復旧時間を縮める具体策はMTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説【2026年版】で扱っています。障害の一次調査をAIエージェントに任せる構成はAWS DevOps Agentの使い方：CLIでの構築とCloudWatchアラームから調査を自動起動する手順が参考になります。

DevSecOps・Platform Engineering・MLOpsへの広がり

DevOpsの考え方は、対象を広げた派生形に分かれています。DevOpsの完成を待つ必要はなく、課題に応じて並行して取り入れられます。

• DevSecOps：パイプラインに脆弱性スキャンや静的解析を組み込み、セキュリティの確認をリリース直前からコミット時点へ移す。実装例はDevSecOpsとは？DevOpsとの違いとGitHub Actionsで組む最小パイプライン。
• Platform Engineering：チームごとに乱立したパイプラインやインフラを、社内共通の開発者基盤として提供し直す。進め方はPlatform Engineering（プラットフォームエンジニアリング）とは？CNCF成熟度モデルとBackstageで始める導入手順。
• MLOps：機械学習モデルの学習・デプロイ・再学習をDevOpsの流儀で回す。データとモデルの版管理という固有の論点がある。詳細はMLOpsとは？機械学習の運用を支える仕組みと導入判断をわかりやすく解説。

DevOpsを導入すべき組織と見送る判断基準

投資対効果を見積もるための比較対象

DORAのガイドは、5指標が組織の業績とメンバーのウェルビーイングの先行指標になると位置づけています。つまり効果は工数の削減だけでなく、変更を利用者に届ける速さと安定にも表れます。そのうえで費用面の判断材料になるのは、いま払っているコストと自動化にかかるコストの比較です。前者には、1回のリリースにかかる手作業の時間×リリース回数、統合の手戻りに使っている時間、障害で止まった時間とその間の売上や業務の損失が入ります。後者には、パイプラインやIaCの構築工数と、それを保守し続ける工数が入ります。複数チームが同じプロダクトを触っていて統合の手戻りが多い開発や、障害対応が特定の担当者に依存して復旧が遅れる運用では、前者がすでに大きく、比較が自動化に傾きやすくなります。

自動化基盤の一括導入を見送る条件

変更がほとんど無い保守フェーズのシステムや、手作業のリリースでも負担と障害リスクが小さいプロダクトでは、パイプラインとIaCを一式組む費用が削減できる工数を上回りやすくなります。ただし停止が許されない業務や、復旧に時間をかけられない要件があるなら、変更が少なくても切り戻しの自動化は検討に値します。範囲を絞る場合も、テストの自動実行とデプロイ履歴の記録から始め、手作業の負担や復旧要件が変わった時点で広げる判断をし直します。

失敗につながる条件の1つは、開発と運用の評価制度が分かれたまま「ツールだけ入れたい」という状態です。この場合、CI/CDを入れても障害の対応は運用側だけが担い、本番で起きた問題が開発に戻らないため、変更の品質を改善する材料が開発者に届きません。先に決めるべきは、本番障害のときに誰が呼ばれ、5指標のどれを誰が追うかです。運用の体制自体が社内に無い場合は、Webシステムの保守運用・内製化支援のような伴走型の支援で現在地を棚卸ししてから、自動化の順序を決める方法もあります。

よくある質問

DevOpsエンジニアの仕事内容は何ですか？

CI/CDパイプラインの構築と保守、IaCによるインフラのコード化、監視とアラートの設計、障害対応の仕組みづくりが中心です。開発者がセルフサービスでデプロイできる状態を作り、デプロイ頻度や復旧時間といった指標を改善することが成果になります。組織によってはSREやプラットフォームエンジニアと呼ばれる職種と仕事が重なります。

DevOpsとアジャイルはどちらを先に導入すべきですか？

順序は固定せず、いま一番大きいボトルネックで決めます。要件が決まらず開発の反復が遅いならアジャイルの進め方から、作った変更が本番に出るまで何週間も待つならデプロイの自動化から着手します。両者は排他ではないので、テストの自動化のように両方に効く施策は並行して進めて構いません。

小規模なチームでもDevOpsは必要ですか？

手作業のリリースや障害対応の負担が小さいなら、本格的な基盤は不要です。ただしバージョン管理、テストの自動実行、デプロイ履歴の記録は小規模でも効果が出やすい施策です。テストの作成と保守には工数がかかるので、壊れると影響の大きい機能から対象にします。本記事のスクリプトのように、タグを付ける運用があれば指標の近似計測も始められます。

DORAの指標はAIの導入でどう変わりますか？

指標の定義は変わっていません。DORAの2025年版レポート（State of AI-assisted Software Development、回答者約5,000人）では回答者の90%が仕事でAIを使っており、Google Cloudの発表は、AIの利用がデリバリーのスループットと正の関係を示した一方、自動テストやバージョン管理などの統制が弱いと変更量の増加が不安定さにつながると述べています。AIの導入前後で、スループットと不安定性の両方の指標を比べるのが効果を確かめる方法です。

DevOpsは何の略で、どう読みますか？

Development（開発）とOperations（運用）を組み合わせた造語で、「デブオプス」と読みます。2009年にベルギーで開かれた第1回DevOpsDaysのイベント名から広まりました。

関連記事

• DevSecOpsとは？DevOpsとの違いとGitHub Actionsで組む最小パイプライン
• Four Keysとは｜DORA 4指標の定義・計算方法とベンチマーク
• SREとは？サイト信頼性エンジニアリングの意味・DevOpsとの違いをわかりやすく解説
• CI/CDとは：仕組み・パイプライン構成・GitHub Actionsの設定例と導入判断の基準を解説
• Platform Engineering（プラットフォームエンジニアリング）とは？CNCF成熟度モデルとBackstageで始める導入手順