DevOps（Development and Operations）
開発する人と運用する人が協力し、変更を早く確実に本番へ届けられるようにする考え方。
もう少し詳しい説明
DevOps は、Development（開発）と Operations（運用）をつないだ言葉です。
開発する人と運用する人が、同じ目標に向かって一緒に働く。それだけを言っています。特定の製品の名前でも、決まった手順書の名前でもありません。
なぜ、わざわざ言う必要があるのか
この2つは、放っておくと対立します。立場からして求めるものが逆だからです。
| 求めるもの | 困ること | |
|---|---|---|
| 開発する人 | 新しい機能を早く出したい | 出す手続きが重い。待たされる |
| 運用する人 | サービスを止めたくない | 変更のたびに壊れる。夜中に呼ばれる |
どちらも正しい。 開発が機能を出さなければ利用者は離れますし、運用が止めれば利用者は使えません。
ところが組織を分けると、壁の向こうへ放り投げる形になりがちです。開発は「渡したから終わり」、運用は「受け取ったからには守る」。すると、出す回数を減らすのが運用にとっていちばん安全、ということになります。
DevOpsは、この壁をなくそうという話です。どちらかが折れるのではなく、届けるまでの流れそのものを一緒に直すところに要点があります。
何をするのか
人の判断が要る場所を減らし、機械にできることは機械にやらせます。
| 言葉 | 中身 |
|---|---|
| 継続的インテグレーション（CI） | 書いた変更を頻繁に統合し、そのつど自動でビルド（書いたものを実行できる形に変換すること）とテストを流す |
| 継続的デリバリ（CD） | テストを通ったものを、いつでも本番へ出せる状態まで自動で用意する |
| 継続的デプロイメント | そこからさらに進めて、本番への反映まで自動で行う |
CDの2つは紛らわしいので、分けておきます。 デリバリは「出せる状態にする」ところまで、デプロイメントは「実際に出す」ところまでです。出す判断を人が持つかどうかが分かれ目になります。
合わせて、運用の側も変わります。何が起きているかを測るしくみ（監視・ログ・利用状況）を整え、その結果を次の変更へ返します。作って終わりでも、守って終わりでもない、という形です。
アジャイル開発との関係
アジャイル開発は、短い期間でくり返し作り、動くものを少しずつ出していく開発のやり方です。並べて出題されるので、受け持ちを分けておきます。
| 見ているところ | |
|---|---|
| アジャイル開発 | 何を、どう作るか。短い反復で動くものを出す |
| DevOps | 作ったものを、どう届けて動かし続けるか |
アジャイルで2週間ごとに動くものができても、本番へ出すのに1か月かかれば、利用者には2週間ごとには届きません。 アジャイルの後ろ半分を詰まらせないための考え方が DevOps だ、と見ると関係がはっきりします。
そのため両方そろって効きます。片方だけでも始められますが、片方だけでは速さが頭打ちになります。
よくある取り違え
ツールを入れればDevOpsになる、ではありません。 自動化の道具はいくつもありますが、入れただけで開発と運用の目標が共有されるわけではないからです。試験でも「ツールの導入」を答えにした選択肢は誤りとして置かれます。
運用部門をなくすことでもありません。 役割は残ってよく、分断されていることが問題です。
変更管理が要らなくなるわけでもありません。 自動で流せるようにしても、本番へ出してよいかという判断自体は残ります。手順が軽くなるだけで、管理の外に出るのではない、というのは変更管理の緊急変更と同じ考え方です。
覚え方：工場のラインに置き換える
製造の現場に置き換えると、言っていることは昔からある話です。
- 設計部門 … 新しい仕様をどんどん出したい
- 製造部門 … ラインを止めたくない
- 壁がある状態 … 図面を投げて終わり。現場で作れないと分かるのはライン上
- DevOps … 設計が現場に入り、試作から量産までを一本の流れとして一緒に直す
変えたい側と止めたくない側の対立は、どの業種にもあります。 新しいのは対立の構図ではなく、その流れを機械で自動化できるようになったことのほうです。
試験ではこう出る
科目A（旧・午前）のソフトウェア開発管理技術の分野で出ます。多いのは、DevOpsの考え方として適切なものはどれかを選ばせる問題です。応用情報では、CIとCDの区別や、アジャイル開発との関係まで問われます。
判断の軸は1つです。開発と運用が、目標を共有して一緒に流れを直しているか。 片方がもう片方を検査する、片方の仕事をもう片方が引き取る、といった選択肢は、壁を前提にしているので誤りです。そしてツールの導入そのものを答えにした選択肢は、ほぼ誤答として置かれます。
関連する用語
- アジャイル開発
- 短い反復で動くものを出す開発手法。DevOpsは、その「出す」側を支える
- 変更管理
- 変更してよいかを判断する活動。自動化しても、判断を省く話にはならない
- インシデント管理
- 止まったサービスを早く戻す活動。運用側が何に困っているかが、ここに表れる
- ホワイトボックステスト
- プログラムの中身を見るテスト。自動で繰り返し流す対象になりやすい
- SLA
- サービスの品質水準の取り決め。変更を速くしても、ここを下回ってはいけない
ミニクイズ
DevOpsの考え方として、最も適切なものはどれか。
正解は 1番：開発側と運用側が目標を共有し、変更を本番へ届けるまでの流れを一緒に改善する
開発側は変えたい、運用側は止めたくない、という相反する立場から対立が生まれます。DevOpsは、どちらが正しいかを決めるのではなく、目標を共有して届けるまでの流れそのものを一緒に改善する考え方です。検査して受け入れるかを決める形は、壁を挟んで引き渡す従来のやり方そのもので、DevOpsが解こうとしている状態にあたります。運用部門をなくすことでもありません。役割はあってよく、分断されていることが問題です。ツールや書き方をそろえるのは手段のひとつで、それだけではDevOpsになりません。
この分野をまとめて解く → システム開発とユーザーインタフェースのミニテスト（全40問）
最終更新：2026-10-01