1. はじめに
はじめまして！
普段はインフラ領域を中心に業務をしている社会人3年目のSEです。
プロジェクトなどでクラウドやコンテナを扱う中で、よく「DevOps」という言葉を耳にするようになりました。単語としては聞いたことはあるものの、実際、どのような考え方でどのような手法で行われているのか。そんな疑問を解消するために、学びながら自分なりに理解を整理し、アウトプットしていくことにしました。
本記事はその第１回として 「そもそもDevOpsってなんなの？」 という基本的なところからまとめていきます。自分と同じように、これからDevOpsを学ぼうとしている方の参考になれば幸いです。
2. DevOpsとは何か
DevOpsとは、「Development（開発）」と「Operations（運用）」を組み合わせた造語で、開発と運用が連携して協力しながらソフトウェアを提供・改善していく考え方です。
Wikipediaでは、以下のように定義されています：
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用(Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。ソフトウェアを迅速にビルドおよびテストする文化と環境により、確実なリリースを、以前よりも迅速に高い頻度で可能とする組織体制の構築を目指している。
つまり、開発と運用が分かれていた従来のやり方を見直し、一体となってサービスの安定と高速なリリースを両立させようという考え方です。
3. DevOpsの誕生と広まり（2009年の出来事）
しかし、なぜこのような考え方が広まったのでしょうか。
DevOpsという言葉が広まり始めたのは、2009年の 「Velocity Conference」 での発表がきっかけでした。
- イベント名：Velocity Conference 2009（アメリカ）
- 登壇者：John Allspaw（Flickrの運用担当）と Paul Hammond（開発担当）
- 講演タイトル：
"10+ Deploys per Day: Dev and Ops Cooperation at Flickr"
（1日10回以上のリリースを可能にした開発と運用の協力）
この講演では、Flickrが開発と運用の協力によって、1日10回以上の頻度で安全にリリースできていることが紹介され、大きな注目を集めました。
当時は頻繁なリリースが「危険」「不安定」とされていた時代だったので、
- 「そんなにリリースして本当に大丈夫なの！？」
- 「どうやって開発と運用が連携してるの？」
と、多くの関心が寄せられました。
この発表をきっかけに、同年には「DevOpsDays」というイベントも開催され、"DevOps" という言葉と考え方が世界中に広まっていきます。
4.DevOpsの目的
Devopsの目的は以下のようなものがあります。
①開発と運用の壁をなくす
DevOpsの大きな目的の一つは、従来分断されていた開発チームと運用チームの間の壁をなくすことです。
よくある例：
開発「機能追加したから、すぐにリリースして！」
運用「いや、変更はできるだけ避けて。安定稼働が最優先だから！」
このように、開発と運用の目的や評価軸が異なるため、チーム間に摩擦が生まれやすく、リリースが遅れたり、トラブル対応が属人的になったりすることが多々ありました。
この壁があると、コミュニケーションの齟齬や責任の押し付け合いが発生し、スムーズなリリースやトラブル対応が難しくなります。
DevOpsでは、チーム間の協力を促進し、共通の目標に向かって一丸となる文化を醸成します。
②ソフトウェアのリリース速度と品質の両立
近年のサービス開発では、頻繁な機能追加や修正が求められています。
わかりやすい話だと、スマホのゲームアプリが挙げられます。バグが出たり、新しいイベントを開催されるとなると、その都度変更やアップデートを加えないといけません。
しかし、高速なリリースは品質低下やトラブルのリスクを伴います。
DevOpsは、自動化や継続的インテグレーション／デリバリー（CI/CD）などの技術を活用し、リリースの速度と品質を両立させることを目指します。CI/CDついては、後ほど詳しく解説します。
③継続的な改善とフィードバックの促進
DevOpsは単なる技術的手法ではなく、サービスや組織を継続的に改善する文化も含みます。
監視やログ収集、ユーザーからのフィードバックを迅速に反映し、サービスの品質向上と運用効率化を図ります。
これにより、顧客満足度を高め、ビジネスの成長を支える仕組みを築きます。
5.CI/CDについて
先ほどお伝えした通りDevOpsは、「開発」と「運用」の壁をなくし、スピーディかつ高品質なサービス提供を目指す考え方です。
その実現に欠かせないプラクティスの1つがCI/CDです。
CI/CDは、コードの統合からリリースまでの一連のプロセスを自動化する仕組みです。
CI/CD とは - 継続的インテグレーション/継続的デリバリー | Red Hatより引用
上の図をもとに、CIとCDについてそれぞれ説明していきます。
CI（Continuous Integration：継続的インテグレーション）
CIは、開発者が日々書いたコードを頻繁に共有リポジトリへ統合し、自動でテストを実行するプロセスです。上の図で言うと、「BUILD → TEST → MERGE」の部分が該当します。
CD（Continuous Delivery / Continuous Deployment）
CIの後に続くのがCDです。
CIで作られた成果物を、実際の環境に届ける（デプロイ）プロセスを自動化するのがCDの役割です。上の図で言うと、「AUTOMATICALLY RELEASSE TO REPOSITORY」の部分が該当します。
この2つを併せてCI/CDと言われます。
実際にGitHubにコードをデプロイするケースを想定して一連の流れを見てみましょう。
【GitHubへのプッシュをトリガーにしたCI/CDフロー】
[1. 開発者がローカルでコードを編集]
│
▼
[2. GitHubリポジトリにコードをプッシュ（push）]
│
▼
[3. GitHub Actions（CI）が自動起動]
├─ コードのビルド（例：コンパイルやパッケージ作成）
├─ 自動テスト（ユニットテスト、静的解析）
└─ 成功 → 次へ進む
└─ 失敗 → 開発者へ通知（プルリクにコメントなど）
│
▼
[4. CD開始（GitHub Actionsや別ツール）]
├─ ステージング環境へ自動デプロイ
├─ 統合テストや動作確認
└─ 成功 → 本番環境へリリース（手動承認 or 自動）
└─ 失敗 → 開発者/運用に通知
│
▼
[5. 本番環境に反映完了 → ユーザーが新機能を利用可能に]
【補足】
GitHub ActionsはGitHubが提供するCI/CD自動化ツールで、
リポジトリへのコード変更をトリガーにビルド・テスト・デプロイを自動実行できます。
DevOpsでは「頻繁なデリバリー」と「安定した運用」の両立が求められます。
その中でCI/CDは、コードの品質を保ちつつ、迅速かつ安全に変更を本番環境に届けるための鍵となるプラクティスです。
CIによって「常に動く状態のコード」を保ち、CDによって「その成果物を確実にユーザーの元へ届ける」ことで、開発と運用のギャップを埋め、継続的な価値提供を実現します。
6.まとめ
DevOpsとは、開発と運用の対立構造を乗り越え、チーム一体となって高速かつ高品質なソフトウェア提供を実現するための考え方です。その実現手段の一つがCI/CDであり、自動化されたビルド・テスト・デプロイの仕組みによって、リリースのスピードと信頼性を両立します。単なる技術論ではなく、文化やマインドセットの変革も伴うDevOpsは、これからのシステム開発において欠かせない重要なアプローチと言えます。
次回もお楽しみに！