対象試験と出題頻度
DevOpsは、ITパスポート・基本情報技術者・応用情報技術者の3区分すべてで出題されるテーマです。
近年はアジャイル開発・ウォーターフォール開発・プロトタイプ開発との比較問題として定番化しており、「開発と運用の連携」「自動化ツールの活用」というキーワードを正確に押さえられるかが問われます。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「DevOpsって結局アジャイル開発と何が違うの？」と混乱しがちです。まずは一言でスッキリさせましょう。
DevOps（デブオプス）とは、一言で言うと
「開発担当チームと運用担当チームが密接に連携し、自動化ツールを活用して機能の導入や更新を迅速に進める取り組み」
のことです。
イメージとしては、「レストランの厨房とホールの一体運営」です。
厨房（開発）が新メニューを作っても、ホール（運用）が「うちはもう出せない」と突き返していては、料理はお客様に届きません。
両者が同じゴール「お客様に喜んでもらう」を共有し、注文票や配膳ロボット（自動化ツール）でスムーズに連携してこそ、新メニューが素早く食卓に並びます。DevOpsもまったく同じ発想です。
📊 DevOpsの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | DevOps（Development + Operations） |
| 提唱年 | 2009年（DevOpsDays カンファレンスにて） |
| 主な目的 | リリース速度・品質・信頼性の同時向上 |
| 代表的なツール | Jenkins、GitLab CI、Docker、Kubernetes、Ansible、Terraform |
| 3つのプラクティス | 継続的インテグレーション（CI）、継続的デリバリ（CD）、継続的デプロイメント |
解説
なぜDevOpsが生まれたのか
従来のシステム開発では、開発チームは「新しい機能を早く出したい」、運用チームは「本番環境を安定させたい」という相反する目標を持っていました。
この対立構造は「サイロ化」と呼ばれ、リリースのたびに揉め事が起き、結果として変更が滞り、ユーザーへの価値提供が遅れていました。
この壁を取り払い、両チームが同じ目標を共有して動こうという文化的・技術的な運動として、2009年に提唱されたのがDevOpsです。
サイロ化された組織から DevOps 組織への変化
［ 従来型：サイロ化 ］
開発
Development
運用
Operations
部門の壁／責任の押し付け合い／
リリースのたびに摩擦
［ DevOps型：一体運営 ］
開発 ＋ 運用
Dev & Ops（同一チーム）
共通ゴールの共有／自動化基盤／
継続的なリリースサイクル
DevOpsを支える3つのプラクティス（CI / CD / 継続的デプロイメント）
DevOpsは精神論だけでは回りません。
連携を成り立たせるために、コードの変更からリリースまでを自動化する3段構えの仕組みがセットで採用されます。
| プラクティス | 何を自動化するか |
|---|---|
| 継続的インテグレーション （CI） |
コードを共通リポジトリへ頻繁に統合し、ビルドとテストを自動実行する。バグの早期発見が狙い。 |
| 継続的デリバリ （CD） |
テストを通過したコードを「いつでも本番投入できる状態」に常に保つ。本番反映は手動承認。 |
| 継続的デプロイメント | 承認すら省き、テスト通過したコードを自動で本番環境へ反映する。最も高度な段階。 |
DevOps のライフサイクル（無限に回り続けるループ）
Dev
＋
Ops
止まらない循環
⑧監視で得たフィードバックが①計画に戻り、輪が止まらず回り続ける ── これが DevOps の本質。
CI/CDパイプラインの実例（コード）
イメージを掴むために、GitHub Actionsで書く最小のCI/CD設定を載せておきます。
試験では暗記不要ですが「自動化ツールってこんな見た目か」と知っておくと選択肢の判別が速くなります。
# .github/workflows/ci-cd.yml
name: CI/CD Pipeline
on: [push]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– name: ビルド
run: npm run build
– name: 自動テスト
run: npm test
– name: 本番デプロイ
run: ./deploy.sh production
「コードをpushしたら、自動でビルド・テスト・デプロイまで一気通貫で走る」――これがDevOpsで言う「自動化ツールの活用」の正体です。
アジャイル開発・ウォーターフォール開発との違い
DevOpsを正しく位置づけるには、紛らわしい開発手法と「対象範囲」で並べてみるのが近道です。
| 手法 | 対象範囲 | 見分けキーワード |
|---|---|---|
| DevOps | 開発〜運用までの組織連携と自動化 | 開発と運用の連携、自動化ツール |
| アジャイル開発 | 開発フェーズの進め方 | 小さな単位、短い期間で繰り返す |
| ウォーターフォール | 開発フェーズの進め方 | 工程ごとに完了判定、後戻りしない |
| プロトタイプ開発 | 要件確認の手法 | 試作品を作って妥当性を評価 |
ポイントは、DevOpsは「アジャイルの代替」ではないこと。
アジャイルで素早く作ったソフトを、運用と連携して素早く届ける。両者は補完関係にあります。
💡 DevOpsの核心を3行で
・開発（Dev）と運用（Ops）が密接に連携する文化＋仕組み
・CI／CD／継続的デプロイメントの3プラクティスと自動化ツールが土台
・アジャイル開発が「作り方」なら、DevOpsは「届け方まで含めた組織運営」
では、この用語が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
DevOpsはIP・FE・APの全区分で「適切な記述を選ぶ」形式の定番問題として登場します。出題パターンはほぼ1つに収束しているため、押さえるべきキーワードも明確です。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| IP R元秋 問55 |
ソフトウェア開発におけるDevOpsに関する記述として最も適切なものを選ぶ問題。 | ・正解：「開発側と運用側が密接に連携し，自動化ツールなどを活用して機能などの導入や更新を迅速に進める」 ・ひっかけ：プロトタイプ開発／ウォーターフォール／アジャイル |
| IP R2-10月 問46 |
DevOpsの実践方法に関する記述を選ぶ問題。 | ・「開発側と運用側が緊密に連携」がキーワード ・WBS／プロジェクト計画の説明文がダミーで紛れ込む |
| FE 公開問題 サンプル |
DevOpsを実践する組織の特徴を問う問題。 | ・「役割を厳密に分離」「互いに干渉しない」は誤り ・正解は「両部門が一体となって業務を進める」 |
📝 IPA試験での出題パターン
パターン1：「DevOpsの説明として適切なものを選べ」
4つの選択肢に「DevOps」「ウォーターフォール」「アジャイル」「プロトタイプ」の説明が並ぶ。キーワード「開発側と運用側の連携」「自動化ツール」「迅速」が含まれる選択肢が正解。
頻出ひっかけ選択肢
① 「小さな単位に分割し、固定した期間で繰り返す」→ アジャイル開発
② 「工程の完了を判断した上で次工程に進む」→ ウォーターフォール開発
③ 「プロトタイプを作成し、性能を実測して妥当性を評価」→ プロトタイプ開発
④ 「開発と運用の役割を厳密に分離する」→ DevOpsの正反対なので誤り
深追いポイントとしてCI/CDの細かい違いまで問われることはほぼないので、ここまででOKです。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発におけるDevOpsの説明として、最も適切なものはどれでしょうか？
- A. 利用者のニーズの変化に柔軟に対応するため、ソフトウェアを小さな単位に分割し、固定した短い期間で開発とリリースを繰り返す手法。
- B. プロジェクトの各工程について完了判定を行い、後戻りせず次工程へ進むことで品質と進捗を管理する手法。
- C. 開発担当チームと運用担当チームが密接に連携し、自動化ツールを活用して機能の導入や更新を迅速に進める取り組み。
正解と解説を見る
正解：C
解説：
選択肢Cが、「開発と運用の連携」「自動化ツール」「迅速」というDevOpsを構成する3つの核心キーワードをすべて含んでいるため正解です。IP R元年秋期 問55の正答選択肢とほぼ同じ文言で出題されています。
選択肢Aはアジャイル開発の説明です。「小さな単位」「固定した短い期間で繰り返す」はアジャイル（特にスクラム）の特徴であり、開発と運用の連携には言及していません。選択肢Bはウォーターフォール開発の説明です。「工程ごとの完了判定」「後戻りしない」が典型的な特徴で、DevOpsが目指す継続的・反復的な連携とは方向性が逆になります。
よくある質問（FAQ）
Q. DevOpsとアジャイル開発は「同じもの」と覚えてよいですか？
同じではありません。アジャイルは「ソフトウェアの作り方」を扱い、DevOpsは「作ったものを運用まで含めて素早く届ける組織と仕組み」を扱います。両者は対立せず、多くの現場ではアジャイルで開発しつつDevOpsで届けるという併用形になります。試験ではこの両者をひっかけ選択肢として並べてくるため、対象範囲が違うと意識しておくと迷いません。
Q. DevSecOpsという派生語を見かけますが、何が違いますか？
DevSecOpsは、DevOpsのライフサイクルにセキュリティ（Sec）を組み込んだ考え方です。従来は開発・運用が終わった後にセキュリティ部門がチェックする流れでしたが、それでは脆弱性が遅れて見つかります。DevSecOpsでは脆弱性スキャンや依存ライブラリ検査をCI/CDパイプラインに組み込み、早い段階で問題を検出します。応用情報や情報処理安全確保支援士で稀に登場するので、名前だけは覚えておくと安全です。
Q. 小さな会社でもDevOpsは導入できますか？
むしろ小規模なほど導入しやすい面があります。開発と運用を兼任する一人エンジニアの環境では、すでに両者の境界線が薄いからです。GitHub ActionsやGitLab CIなど無料枠のあるツールでCI/CDを組み、Dockerでローカルと本番の環境差をなくすところから始めるのが定番ルートです。専用のSREチームを置く大企業型のDevOpsは、組織が大きくなってから検討すれば十分です。
Q. DevOpsの効果はどう測定するのですか？
Google傘下のDORA（DevOps Research and Assessment）が提唱する「Four Keys（4つの主要指標）」が業界標準です。具体的にはデプロイ頻度、変更のリードタイム、変更失敗率、平均修復時間（MTTR）の4つで、上位企業は1日に複数回デプロイし、変更失敗率も15%未満という基準が知られています。試験範囲外ですが、実務で「DevOps始めました」と言うだけで終わらないための物差しとして覚えておくと役立ちます。
