DevOpsの概要

この講座では、DevOpsの基本的な考え方と導入のメリット、そしてITエンジニアとしてなぜDevOpsを理解するべきかについて学びます。

• DevOpsとは何か、なぜ生まれたのか
• DevOpsが解決する従来の開発・運用の課題
• DevOpsの主な施策とそれを支える技術
• DevOpsの成熟度を測るCALMSモデル

1. DevOpsとは

DevOps（デブオプス）とは、開発（Development）と運用（Operations）を組み合わせた言葉で、ソフトウェアの開発チームと運用チームが密接に連携し、リリース速度や品質を高めながら継続的な改善を行うための考え方や文化を指します。

DevOpsは単なるツールや技術の話ではなく、チームの協調文化やプロセスの改善を含む包括的なアプローチです。開発と運用の壁を取り払い、ソフトウェアのライフサイクル全体を通じて協力する体制を作ることが目的です。

1.1 従来の開発・運用の課題

DevOpsがなぜ必要とされるようになったのかを理解するために、従来の開発・運用体制で起きていた課題を見てみましょう。

従来、多くの組織ではソフトウェアの開発チームと運用チームが別々の組織として独立しており、それぞれ異なる目標を持って業務にあたっていました。開発チームは「新しい機能を素早くリリースしたい」と考える一方、運用チームは「システムを安定稼働させたい」と考えるため、両者の間に対立構造が生まれやすい状況でした。

この分断によって、以下のような課題が発生していました。

• 開発と運用の責任が分かれているため、障害対応やフィードバックに時間がかかり、同じ問題が繰り返し発生する
• リリース作業が手動で行われるため、手順のミスや属人化が起きやすい
• リリース頻度が低く一度の変更量が大きいため、ビジネスが求めるスピードに追いつかない

こうした課題を解決するために生まれたのがDevOpsという考え方です。

1.2 DevOpsの3つのキーワード

DevOpsの考え方を理解するうえで重要な3つのキーワードを紹介します。

プロセスの自動化

1つ目はプロセスの自動化です。CI/CDパイプラインやIaC（Infrastructure as Code、インフラのコード化）などの技術を活用し、ビルド、テスト、デプロイといった工程を自動化します。自動化によって手作業を減らし、リリースまでの時間を短縮するとともに、人的ミスを防ぐことができます。

フィードバック

2つ目はフィードバックです。DevOpsでは、できるだけ早く市場にソフトウェアを届け、ユーザからのフィードバックを素早く受け取ることを重視します。（可視化）の仕組みを通じてシステムの状態を常に把握し、問題があれば迅速に対応します。フィードバックのサイクルが速ければ速いほど、改善のスピードも上がります。

継続的な改善

3つ目は継続的な改善です。DevOpsでは、一度仕組みを作って終わりではなく、運用データやユーザからのフィードバックをもとに改善を繰り返します。小さな変更を頻繁にリリースし、その結果を計測して次の改善につなげるというサイクルを回し続けることが重要です。

2. DevOpsの主な施策

DevOpsを実現するために必要な施策や技術は多岐にわたります。ここでは、それらを「コア施策」「支える技術」「前提となる知識」の3つに整理して紹介します。

2.1 DevOpsのコア施策

DevOpsの中核をなす3つの施策について説明します。

CI/CDパイプライン

CI/CDパイプラインは、ソフトウェアのビルド、テスト、デプロイを自動化する仕組みです。開発者がコードを変更するたびに、自動でテストやビルドが実行され、問題がなければそのままデプロイまで進みます。これにより、手動でのリリース作業が不要になり、リリース頻度を高めることができます。

代表的なツールとしては、GitHub Actions、CircleCI、Jenkinsなどがあります。DevOps Campでは、この後の講座でGitHub Actionsを使ってCI/CDパイプラインを構築していきます。

インフラのコード化

インフラのコード化（IaC）は、サーバやネットワークなどのインフラ構成をコードで定義し、管理する手法です。手動でサーバを構築する代わりに、コードを実行することでインフラを自動的に構築・変更できます。コードで管理するため、バージョン管理やレビューが可能になり、環境の再現性も高まります。

代表的なツールとしては、Terraform、AWS CloudFormationなどがあります。DevOps Campでは、Infra as a Code講座でTerraformを使ったインフラのコード化を学びました。

オブザーバビリティ

オブザーバビリティ（Observability、可観測性）は、システムの内部状態を外部から観測・把握できるようにする仕組みです。従来のモニタリング（Monitoring）が「事前に定義した指標を監視し、既知の問題を検知する」ことに重点を置いていたのに対し、オブザーバビリティは「システムの振る舞いをデータから読み解き、未知の問題も発見・分析できる」という、より広い概念です。

オブザーバビリティを実現するためには、主に以下の3つのデータ（三本柱と呼ばれます）を収集・分析します。

• メトリクス … CPU使用率、メモリ使用量、レスポンスタイムなどの定量的なデータ
• ログ … アプリケーションやサーバが出力するイベントの記録
• トレース … リクエストがシステム内のどのコンポーネントをどの順序で通過したかの追跡データ

これらのデータを組み合わせることで、障害の原因特定やパフォーマンスのボトルネック分析を迅速に行うことができます。

代表的なツールとしては、Amazon CloudWatch、Datadog、New Relic、Grafanaなどがあります。DevOps CampではAWS講座でCloudWatchの基本を学びました。オブザーバビリティに特化した講座は今後追加予定です。

2.2 DevOpsを支える技術

コア施策を効果的に運用するためには、いくつかの技術が必要になります。

自動テスト

自動テストは、あらかじめ用意したテストコードに従ってテストを自動で実行する仕組みです。CI/CDパイプラインに組み込むことで、コードの変更のたびにテストが自動実行され、品質を継続的に確認できます。

DevOps CampではPython講座でテストフレームワークPytestを使った自動テストを学びました。この後のCI/CDパイプライン講座では、そのテストをパイプラインに組み込む方法を学びます。

クラウド

クラウドは、サーバやストレージ、データベースなどのITリソースをインターネット経由で利用するサービスです。DevOpsにおいては、インフラの構築や管理をクラウド上で行うことが一般的であり、IaCやオブザーバビリティとの親和性も高いです。

DevOps CampではAWS講座でAWS（Amazon Web Services）を中心に、EC2、S3、RDS、IAM、VPCなどの主要なサービスを学びました。

コンテナ

コンテナは、アプリケーションとその実行に必要な環境をひとまとめにパッケージ化する技術です。開発環境と本番環境の差異をなくし、「開発環境では動くのに本番では動かない」という問題を防ぐことができます。また、コンテナイメージをCI/CDパイプラインでビルド・デプロイすることで、リリースの自動化にも貢献します。

DevOps Campではコンテナ講座でDocker、Docker Compose、Amazon ECR、Amazon ECS/Fargateなどを使ってコンテナ技術を学びました。

セキュリティ

DevOpsにセキュリティを統合した考え方をDevSecOps（デブセックオプス）と呼びます。従来、セキュリティはリリース前の最終段階でチェックされることが多かったですが、DevSecOpsでは開発の早い段階からセキュリティを組み込みます。

具体的には、SAST（Static Application Security Testing、静的アプリケーションセキュリティテスト）やDAST（Dynamic Application Security Testing、動的アプリケーションセキュリティテスト）をCI/CDパイプラインに組み込んだり、WAF（Web Application Firewall）でアプリケーションを保護したりします。DevOps CampではPython講座で静的解析ツールを学びました。セキュリティに特化した講座は今後追加予定です。

2.3 DevOpsの前提となる知識

DevOpsの各施策を理解し、実践するためには、いくつかの基礎知識が前提となります。

プログラミング

DevOpsでは、テストコードの作成やIaCの記述、CI/CDパイプラインの設定など、さまざまな場面でプログラミングの知識が求められます。DevOps CampではPython講座でPythonを使ったアプリケーション開発やテストコードの作成を学びました。

データベース

多くのWebアプリケーションはデータベースを利用しています。データの保存や取得を行うためのSQL（Structured Query Language、構造化問い合わせ言語）の基礎知識は、アプリケーション開発だけでなく、テストやインフラ構築においても必要です。DevOps CampではPython講座でMySQLを使ったデータベースの基礎を学びました。

Webアプリケーション開発

CI/CDパイプラインで自動化する対象は、多くの場合Webアプリケーションです。HTTP（HyperText Transfer Protocol）の仕組みやREST API（Representational State Transfer Application Programming Interface）の設計を理解しておくことで、テストやデプロイの自動化をより効果的に行えます。DevOps CampではPython講座でFastAPIを使ったWebアプリケーション開発を学びました。

OS/サーバ

アプリケーションが動作するOS（Operating System）やサーバの基本的な操作を理解しておくことも重要です。デプロイやオブザーバビリティでは、Linuxのコマンド操作やファイルシステムの知識が求められる場面があります。DevOps CampではAWS講座でEC2を使ったサーバ構築を通じて、Linuxの基本操作を学びました。

3. DevOpsのCALMSモデル

ここまでDevOpsの施策や技術について見てきましたが、DevOpsは技術だけで成り立つものではありません。DevOpsの成熟度を測るフレームワークとしてCALMSモデルがあります。CALMSは、Culture（文化）、Automation（自動化）、Lean（無駄の排除）、Measurement（計測）、Sharing（共有）の頭文字を取ったものです。

3.1 Culture（文化）

DevOpsにおいて最も重要とされるのが文化の要素です。いくらツールを導入しても、チームの文化が変わらなければDevOpsは機能しません。

Blameless（責めない文化）

DevOpsではBlameless（ブレイムレス）と呼ばれる「責めない文化」が重視されます。システム障害やインシデントが発生した際に、個人を責めるのではなく、プロセスやシステムの問題として原因を分析し、再発防止に取り組むという考え方です。

個人を責める文化があると、メンバーは失敗を隠したりリスクを取ることを避けたりするようになり、結果として改善のスピードが落ちてしまいます。障害が発生した際にはポストモーテム（振り返り）を実施し、「何が起きたのか」「なぜ起きたのか」「どうすれば防げるのか」をチーム全体で議論することが大切です。

共通責任

従来の体制では、開発チームは「コードを書くまでが自分たちの仕事」、運用チームは「システムを動かし続けるのが自分たちの仕事」と考えがちでした。DevOpsでは、開発と運用の両チームがソフトウェアのライフサイクル全体に対して共通の責任を持ちます。

開発チームは自分たちが書いたコードが本番環境でどのように動作するかに関心を持ち、運用チームは開発プロセスの改善に協力します。この共通責任の意識が、チーム間の壁を取り払い、協力体制を生み出します。

3.2 Automation（自動化）

前のセクションでも触れましたが、自動化はDevOpsを実現するための重要な柱です。CALMSモデルにおいても、自動化は文化と並んで中核的な要素として位置づけられています。

自動化の対象

DevOpsにおける自動化の対象は多岐にわたります。

• ユニットテスト、E2Eテスト、セキュリティテストなどを自動で実行する
• コードを実行可能な形式に自動で変換する
• 本番環境への反映を自動化する
• サーバやネットワークの構築・変更をコードで自動化する
• 異常検知時に自動で通知する

これらの自動化を段階的に導入していくことで、チームの作業負荷を軽減し、より価値の高い作業に集中できるようになります。

Shift Left

Shift Left（シフトレフト）とは、開発プロセスのできるだけ早い段階（左側）で問題を検出・対処するという考え方です。

従来は、テストやセキュリティチェックは開発プロセスの後半（右側）で行われることが一般的でした。しかし、問題の発見が遅れるほど修正コストは大きくなります。Shift Leftの考え方では、静的解析やユニットテスト、セキュリティスキャンなどをCI/CDパイプラインに組み込み、コードの変更直後に自動で実行することで、問題を早期に発見します。

3.3 Lean（無駄の排除）

Lean（リーン）は、無駄を省いて効率的に価値を届けるという考え方です。もともと製造業（トヨタ生産方式）で生まれた概念で、ソフトウェア開発にも適用されています。

小さな変更を繰り返す

Leanの考え方をソフトウェア開発に適用する際に重要なのが、小さな変更を頻繁にリリースするというアプローチです。

大きな変更を一度にリリースすると、問題が発生した場合にどの変更が原因なのかを特定するのが難しくなります。また、リリース作業自体のリスクも高まります。一方、小さな変更を頻繁にリリースすることで、以下のメリットがあります。

• 問題が発生した場合に原因を特定しやすい
• リリースごとのリスクが小さい
• フィードバックを早く得られる
• 方向修正がしやすい

CI/CDパイプラインを整備することで、小さな変更を安全かつ迅速にリリースできる体制を作ることができます。

3.4 Measurement（計測）

DevOpsでは、感覚や経験だけに頼るのではなく、データに基づいて判断することが重要です。計測によって現状を正確に把握し、改善の効果を客観的に評価します。

SLOとSLI

サービスの品質を計測するための指標として、SLO（Service Level Objective、サービスレベル目標）とSLI（Service Level Indicator、サービスレベル指標）があります。

SLIは、サービスの品質を測定するための具体的な指標です。例えば、レスポンスタイム、エラーレート、可用性（システムが正常に稼働している時間の割合）などが該当します。

SLOは、SLIに対して設定する目標値です。例えば「可用性を99.9%以上に保つ」「レスポンスタイムの95パーセンタイルを200ms以下にする」といった形で定義します。

SLIで現状を計測し、SLOで目標を設定することで、サービスの品質を客観的に管理できるようになります。

Error Budget

Error Budget（エラーバジェット）は、SLOの目標値から逆算して「許容される障害の量」を定量化したものです。

例えば、SLOで「可用性99.9%」を設定した場合、月間のダウンタイムは約43分まで許容されます。この43分がError Budgetです。Error Budgetに余裕がある場合は積極的に新機能のリリースを進め、Error Budgetが少なくなっている場合は信頼性の改善に注力するという判断ができます。

このように、Error Budgetは「開発のスピード」と「システムの安定性」のバランスを取るための仕組みとして機能します。

Four Keys（DORA metrics）

DevOpsの効果を計測するための指標として、Four Keys（DORA metrics）が広く知られています。これはDORA（DevOps Research and Assessment）という研究チームが提唱した4つの指標です。

• デプロイ頻度（Deployment Frequency）: 本番環境へのデプロイがどれくらいの頻度で行われているか
• 変更のリードタイム（Lead Time for Changes）: コードの変更がコミットされてから本番環境にデプロイされるまでの時間
• 変更障害率（Change Failure Rate）: デプロイが原因で障害が発生する割合
• サービス復旧時間（Time to Restore Service）: 障害が発生してからサービスが復旧するまでの時間

これらの指標を計測・改善することで、DevOpsの成熟度を客観的に評価し、継続的な改善につなげることができます。

3.5 Sharing（共有）

DevOpsでは、知識や情報をチーム内外で積極的に共有することが重要です。共有が不足すると、属人化や認識のずれが生まれ、チームとしてのパフォーマンスが低下します。

適切なツールの導入

情報共有を円滑に行うためには、適切なツールの導入が欠かせません。チャットツール（Slackなど）、チケット管理ツール（Jira、GitHub Issuesなど）、ドキュメント管理ツール（Confluenceなど）を活用し、情報が一箇所に集約される環境を整えます。

オープンコミュニケーション

DevOpsでは、チーム間の壁を取り払ったオープンコミュニケーションが求められます。開発チームと運用チームが同じチャンネルで情報を共有し、障害対応やリリース計画を一緒に議論する体制を作ることが大切です。

情報がサイロ化（特定のチームだけが知っている状態）していると、問題の発見や対応が遅れる原因になります。誰でもアクセスできるオープンな場で情報を共有することで、チーム全体の状況把握が容易になります。

ChatOps

ChatOps（チャットオプス）とは、チャットツールを中心にして運用作業や情報共有を行う手法です。チャット上でコマンドを実行してデプロイを行ったり、オブザーバビリティのアラートをチャットに通知したりすることで、作業の実行と情報共有を同時に行うことができます。

例えば、Slackのチャンネルにデプロイの通知やアラートを集約することで、チームメンバー全員がリアルタイムでシステムの状況を把握できます。また、チャット上の操作ログがそのまま作業の記録として残るため、「誰がいつ何をしたのか」を後から確認することもできます。

4. まとめ

この講座では、DevOpsの基本的な考え方と主な施策、そしてCALMSモデルについて学びました。

• DevOpsは開発（Development）と運用（Operations）を統合し、リリース速度と品質を高める考え方
• 従来の開発・運用の分断が生む課題（属人化、リリースの遅延、フィードバックの不足）をDevOpsで解決できる
• DevOpsの3つのキーワードは「プロセスの自動化」「フィードバック」「継続的な改善」
• コア施策としてCI/CDパイプライン、インフラのコード化（IaC）、オブザーバビリティがある
• それらを支える技術として自動テスト、クラウド、コンテナ、セキュリティ（DevSecOps）がある
• CALMSモデル（Culture、Automation、Lean、Measurement、Sharing）でDevOpsの成熟度を総合的に評価できる
• Blameless（責めない文化）や共通責任といった文化面がDevOpsの基盤となる
• Four Keys（DORA metrics）でデプロイ頻度、リードタイム、変更障害率、復旧時間を計測し、継続的に改善する