求人を開くと「設計」「構築」「運用」「保守」と工程の名前が並びます。でも、それが1つのシステムのどこの話なのかが見えないまま、言葉だけを暗記していないでしょうか。この記事では、システムが作られて動き続ける流れを1本の道として描き、求人の言葉をその道のどこかに置けるようにします。
この記事の結論
- システムは完成したら終わりではなく、動いている間ずっと「運用」と「改善」が続きます。仕事の多くは公開後にあります。
- 流れは企画・設計・構築・運用・改善の5つです。職種名や求人の言葉は、この流れのどこを担うかの名前です。
- 昔は工程ごとに担当が分かれ、渡して終わりでした。クラウドでは構築が自動化され、作る人が運用も見る形が増えました（DevOps の考え方）。
- 構築を自動化する道具（IaC、CI/CD）と、運用を支える監視・ログは、工程をつなぐ部品です。
- 自分がどの工程から入るかを決めると、最初に学ぶ領域が絞れます。
システムは「作って終わり」ではない：公開後に続く仕事とは
建物は完成して引き渡せば、作った側の仕事はひと区切りです。システムは違います。公開した瞬間から、利用者が使い、データが増え、部品に古い版が出て、要望が変わります。運用（動いているシステムを保つ仕事）が始まるのは、公開の日からです。
つまり、システムの一生のうち「作る」期間は短く、「動かし続ける」期間のほうが長いのが普通です。仕事の名前に「構築」だけでなく「運用」「保守」が多く並ぶのは、公開後の仕事が多いからです。
ここで大事なのは、運用のあとに終わりが来ないことです。動かしてみて分かった不都合は直され、直した結果が次の企画につながります。システムの仕事は、直線ではなく輪の形をしています。
5つの工程は何をするのか：企画・設計・構築・運用・改善
システムが生まれて動き続ける流れを、5つの工程に分けます。会社や現場によって呼び方や区切りは違いますが、役割の並びは共通しています。
FROM IDEA TO RUNNING5つの工程を旅で
システムは企画から改善まで5つの駅を通り、また企画へ戻る
-
企画
何のために作るか
-
設計
構成と決まりを決める
-
構築
設計どおりに作る
-
運用
動かし続け、見守る
-
改善
直して次へ
| 工程 | 何をするか | 手元に残るもの |
|---|---|---|
| 企画 | 何のために作るか、誰が使うか、何を満たせば成功かを決める | 要件、目的、予算の枠 |
| 設計 | 要件を満たす構成と、守るルールを決める | 構成図、設計書、決めた理由 |
| 構築 | 設計のとおりに作り、動くことを確かめる | 動くシステム、構築の手順や設定 |
| 運用 | 動いているものを見守り、起きた問題に対応し、決まった作業をこなす | 監視の記録、障害の記録、作業の記録 |
| 改善 | 運用で見えた不都合や要望をもとに、直す・変える | 変更の内容、次の企画への入力 |
工程は輪になっている
表の最後の「改善」は、行き止まりではありません。改善で見つかった「もっと速くしたい」「費用を下げたい」といった課題は、次の企画の材料になります。運用で見えた事実が、次の設計の根拠になる、ともいえます。
AWS の Well-Architected フレームワークは、設計の良し悪しを見る6本の柱のひとつに「運用上の優秀性」を置いています。運用が、作り終えたあとの付け足しではなく、設計の段階から考える対象だと位置づけられているということです。
CHECK 1ここまでの確認
システムが公開されたあとも続く仕事は、5つの工程のどれ?
答えと解説
答え: 2. 運用と改善
公開はゴールではなく、運用の始まりです。動いている間は運用と改善が続き、改善の結果が次の企画に戻ります。「5つの工程」の章を読み直してください。
求人の「設計・構築・運用・保守」はどの工程の言葉か
求人の言葉は、5つの工程のどこを担う仕事かに置き換えると読めます。
WHERE YOU STAND自分の担う場所
求人の言葉は、どの層を自分が担うかで読める
運用側の入口
- 工程の流れ（企画〜改善）
- 自動化の部品（IaC・CI/CD）
- 見る部品（監視・ログ）
- 求人の言葉（構築・運用など）
構築側の入口
- 工程の流れ（企画〜改善）
- 自動化の部品（IaC・CI/CD）
- 見る部品（監視・ログ）
- 求人の言葉（構築・運用など）
最初に手を動かす層まず周りが担う層
| 求人にある言葉 | おもに当たる工程 | 読み方の目安 |
|---|---|---|
| 要件定義・企画 | 企画 | 何を作るかを決める側。業務の理解が問われやすい |
| 設計・アーキテクト | 設計 | 構成と理由を決める側。判断の責任が重い |
| 構築・導入・環境作成 | 構築 | 決まった設計どおりに作る側 |
| 運用・監視・障害対応 | 運用 | 動いているものを保つ側 |
| 保守 | 運用か改善 | 運用と重なる。不具合の修正や更新まで含むことが多い |
| 改善・最適化 | 改善 | 運用で見えた課題を直す側 |
「運用と保守は同じか」は、よく出る疑問です。求人では重なって使われるので、名前では決められません。書かれている作業が、見守りと定期作業なのか、不具合の修正や変更なのかで読んでください。
1つの求人に複数の工程が入る
小さなチームでは、1人が構築も運用も改善も担います。大きな組織では工程ごとに人が分かれます。同じ「クラウドエンジニア」という名前でも、どこまでを担うかは職場で違います。名前より、書かれた作業の中身を見るのが確実です。誰が担うかの側から整理した話は、クラウドの仕事は誰が何をしているかにあります。ここでは工程の側から見ています。
CHECK 2ここまでの確認
「監視・障害対応・定期作業」が中心の求人は、主にどの工程の仕事?
答えと解説
答え: 3. 運用
動いているものを保つ仕事だからです。求人の言葉は工程の名前に置き換えて読みます。「求人の言葉」の章を読み直してください。
昔の分業とクラウドの流れは何が違うのか：渡して終わりから、回し続けるへ
昔のオンプレミスの現場では、機械を買い、置き場所を用意し、ケーブルをつなぐ必要がありました。構築には時間がかかり、手作業も多くありました。作る人と動かす人が別の組織になり、構築が終わったら運用へ「渡す」形が自然でした。
クラウドでは、サーバーやネットワークをコードや設定で用意できます。構築が速く、同じものを何度でも作り直せるようになりました。すると、作る人が動かしたあとの様子まで見るほうが、改善が速く回ります。
HANDOFF VS LOOP流れの違い
渡して終わりから、作る人が運用も見る流れへ
昔の分業
工程ごとに渡す
- 構築が終わったら運用へ渡す
- 担当が組織ごとに分かれる
- 運用の気づきが設計に戻りにくい
クラウドの流れ
作る人が運用も見る
- 構築が自動化され作り直せる
- 作る人が動かしたあとも見る
- 運用の気づきが改善に戻る
この「開発と運用の壁をなくして、一緒にシステムを回す」考え方が DevOps です。AWS の説明でも、開発チームと運用チームが分かれず、作ることから動かすことまでを通して受け持つ姿が示されています。
分業がなくなったわけではない
ここは誤解しやすい点です。DevOps は、全員が全工程をやるという意味ではありません。大きな組織では、今も専門ごとにチームが分かれます。変わったのは、渡して終わりにしないことです。運用で分かったことが設計に戻る道が、組織の中でつながっていることが大切になりました。
CHECK 3ここまでの確認
作る人が運用も見る、という考え方に近い名前はどれ?
答えと解説
答え: 1. DevOps
DevOps は、開発と運用の壁をなくして一緒にシステムを回す考え方です。「昔の分業とクラウドの流れ」の章を読み直してください。
工程をつなぐ部品の仕組み：IaC・CI/CD・監視とログ
クラウドで流れが速く回るのは、工程をつなぐ部品があるからです。名前だけ押さえます。使い方はここでは扱いません。
- IaC（Infrastructure as Code）：サーバーやネットワークの構成を、手作業ではなくコードで書いて用意する方法です。構築が手順書ではなくコードになるので、同じ環境を再現しやすくなります。
- CI/CD（継続的インテグレーション／継続的デリバリー）：変更を小さく何度も取り込み、確認と公開を自動で流す仕組みです。構築と公開の間の手作業を減らします。
- 監視とログ：動いているシステムの状態を数字や記録で見えるようにする部品です。運用で異常に気づき、改善で原因を探す土台になります。
AWS には、これらに当たるサービスがあります。たとえば構築の自動化に AWS CloudFormation、監視に Amazon CloudWatch といった名前があります。ここでは「部品の例」として名前だけ挙げておきます。
部品は工程の外に置く
この3つは、どれかの工程の中に閉じていません。IaC で書いた構成は構築の成果物であり、運用での変更の対象にもなります。監視で得た記録は、運用の材料であり、改善の根拠にもなります。部品が工程をまたいで情報を運ぶことで、輪が回り続けます。
自分はどの工程から入るか：未経験の入口の考え方
最初から5つの工程のすべてを担う人はいません。入口は、おもに2つの考え方があります。
- 運用側から入る：監視、障害対応、定期作業といった、動いているものを保つ仕事です。システムが実際にどう壊れ、どう直されるかを近くで見られます。
- 構築側から入る：決まった設計どおりに作る仕事です。構成の部品とつなぎ方を、手を動かして覚えやすい入口です。
どちらが上、ということはありません。自分の関心で選びます。設計は、構築や運用で何が起きるかを知っているほど判断しやすくなるため、あとから近づく人が多い、というのが一般的な見方です。
学ぶ順番に迷ったら、気になる工程を1つ決め、その工程の前後の工程が何を渡してくるかを確かめてください。次の記事 クラウドエンジニアとは何か で、職種の中身を読めます。
Cloudory 執筆者（AWS 認定 全冠）
求人の言葉に迷ったら、工程の名前に置き換えて読んでください。「それは5つのうちどれか」が言えるようになると、自分が何を学べばよいかが絞れます。
まとめ
- システムは、企画・設計・構築・運用・改善の輪で動き続けます。公開は運用の始まりです。
- 求人の言葉は、工程のどこを担うかの名前です。名前より作業の中身で読みます。
- クラウドでは、構築が自動化され、作る人が運用も見る形が増えました。分業が消えたのではなく、渡して終わりにしなくなりました。
- IaC・CI/CD・監視とログは、工程をつなぐ部品です。
- 入口は運用側と構築側があり、自分の関心で選びます。
参照ソース
- AWS「DevOps とは」 — 開発と運用の壁をなくす考え方、継続的インテグレーション・デリバリー、IaC、監視とログの説明の根拠に使用
- AWS Well-Architected Operational Excellence Pillar — 6本柱に運用上の優秀性があること、運用を開発や事業から切り離さない考え方の根拠に使用
