この記事はアフィリエイト広告（PR）を含みます
こんにちは！とも（@tomo_ITBizBlog）です！
本記事はこんな悩みを解決！
- 保守運用の仕事を続けているが、手順書どおりの作業ばかりで「作る側」に進める気がしない
- 設計や構築の仕事に興味はあるが、実績がないため案件にも求人にも届かない
- 運用から設計構築へ進んだ人が、どんな順番で動いたのかを知りたい
この記事で分かること
- 保守運用が「沼」になりやすい構造と、設計構築へ進めない本当の理由
- 運用・保守の経験が、設計構築の現場でどう評価されるか
- 手順の背景理解→小さな構築→設計の学習→構築案件への移動という、具体的な順番
まず筆者の歩みを、正直に書いておきます。
キャリアの始まりは運用監視です。JP1を使ったジョブ監視とアラート対応を約3年、24時間365日体制のシフトで働きました。その現場では「手順書どおりに正確にこなすこと」が仕事の中心で、設計や構築は別の世界の話でした。
次に移ったインフラ全般の現場で、景色が変わります。サーバの運用保守と並行して、VMwareの仮想基盤52台の構築など、「作る側」の仕事に触れることができました。
その後、AWS特化の会社でクラウド移行の標準モデルを作る側に回り、現在はフリーランスとしてAWSと生成AIの案件を受けています。
この記事は、その中でも「保守運用のフェーズから、設計構築のフェーズへ移る」という一番最初の工程の移動に絞って、順番を手順化したものです。
【保守運用の「沼」の構造｜手順書の外に出られない仕組み】
保守運用の仕事は、大きく次のようなものです。
- 定例作業：バックアップやバッチの確認、定期レポートなど、決まった作業を正確に回す
- 障害対応：起きた障害の一次切り分け、手順に沿った復旧、記録と報告
- 保守作業：パッチ適用や設定変更など、決められた変更を手順書どおりに実施する
- 問い合わせ対応：利用部門や顧客からの連絡窓口
どれも「止めないための仕事」で、現場に欠かせません。筆者も運用監視の現場では、この仕事の大切さと大変さを身をもって知りました。
問題は、担当範囲の固定され方です。沼の構造は3つあります。
1つ目は、判断が手順書と上流に固定されていることです。
「このアラートが出たらこの手順」「この変更はこの手順書」。判断の材料と結論は手順書の中にあり、担当者は実行する側に固定されます。なぜその手順なのか、どういう設計だからそうなるのか、という背景は仕事の範囲の外に置かれます。
2つ目は、作る側の工程が回ってこないことです。
サーバーの構成を決める、設計する、構築する。こうした工程は別のチームや別の会社の担当で、保守運用の手元には降りてきません。「運用はできるが、構築は未経験」という状態が、年数とともに固まっていきます。
3つ目は、成果が見えにくく、評価と給料が伸びにくいことです。
筆者が運用監視をしていた現場では、昇給は月¥2,000〜3,000ほどでした。「止め続けること」は問題が起きていない状態そのものなので、成果として示しにくい。3年で15名を超えるメンバーが辞めていったのも、この構造と無関係ではないと感じています。
筆者自身、監視の現場でサブリーダーとして新人教育や進捗管理も担いましたが、それでも仕事の中身は「手順を回す側」のままでした。役回りが増えても工程が上がるわけではない、というのも、この沼の分かりにくいところです。
運用監視という仕事の実態そのものは、本体記事で詳しくまとめています。
運用監視オペレーターの仕事はきつい？3年間続けた現場の実態と本音
インフラ全体のロードマップは、インフラエンジニアの記事もあわせてどうぞ。職種全体の中での位置づけは、カオスマップの記事のマップと、エンジニアキャリアマップでも確認できます。
【なぜ設計構築へ進めないのか｜立ちはだかる4つの壁】
構造が見えても、設計構築へは簡単には進めません。壁はだいたい次の4つです。
- 実績の循環：構築案件は「構築経験者」が前提で募集され、保守運用の実績だけでは書類で届かない。実績を作る場所がないまま年数が過ぎる
- 経歴の書き方：「保守運用○年」としか書けず、設計側が知りたい「何をどう判断して作れるのか」が伝わらない
- 学ぶ時間と機会の不足：現場は止められないため忙しく、設計を体系立てて学ぶ時間も、構築に立候補できる機会も限られる
- 「運用の人」という固定観念：社内でも転職市場でも、一度ついた担当イメージが先に立ち、別の工程への挑戦として見てもらいにくい
この中で一番重いのは、1つ目の循環です。
「構築の実績がない→構築の現場に入れない→実績ができない」。能力の問題ではなく、入口の構造の問題です。だから手順は、この循環を小さく破るところから組み立てます。いきなり「設計構築エンジニア」を名乗るのではなく、今の現場で背景を理解し、小さな構築の実績を1つ作ることが先です。
もう1つ見落とせないのが、体力と時間の問題です。夜勤やシフトを含む現場では、勤務の外で腰を据えて学ぶ余力が残りにくい。筆者も監視時代は、休日はまず体を休めることで精一杯でした。だからこそ手順は「根性で学ぶ」ではなく、勤務の中身そのものを学習に変えるステップ1から始める形にしています。
【設計構築の現場の現実｜運用経験はこう評価される】
設計構築のフェーズの仕事は、要件をもとに構成を決める（基本設計・詳細設計）、実際にサーバーやネットワークを組み上げる（構築）、動くか確かめる（テスト）、本番へ移す（移行・リリース）という流れです。
ここで意外に効くのが、運用・保守の経験です。翻訳すると、次のようになります。
- 障害対応の経験 → 「どこが壊れやすいか」を知っている。設計の場面で、壊れにくい構成と、壊れたときに切り分けやすい構成を選べる
- 保守作業の経験 → パッチや設定変更の「やりにくさ」を知っている。保守しやすい設計と、手順に落としやすい構成を考えられる
- 定例作業・監視の経験 → 運用の引き継ぎで何が必要かを知っている。監視項目や運用手順まで含めた「渡せる設計」ができる
設計側が運用経験者を評価するのは、この翻訳が効く場面があるからです。設計構築の現場に入った直後に任されるのは、いきなり全体の基本設計ではありません。詳細設計の補助、構築手順書の作成、構築後のテストといった、運用経験が直接活きる部分から始まることが多いものです。「設計書を書いたことがない」ことより、「手順書を読み書きしてきた正確さ」のほうが、入口では効きます。
逆に、運用経験は「運用しかできない」ではなく「運用を知っている設計側」として書き換えたときに、初めて市場で伝わります。
なお、この記事の担当範囲をはっきりさせておきます。
この記事が扱うのは、保守運用フェーズから設計構築フェーズへという「工程の移動」です。その先にある「インフラ運用からクラウドエンジニアへの転身」については、姉妹記事で手順をまとめています。
インフラ運用からクラウドエンジニアへ！転身に必要な資格と勉強の順番
需要の背景も見ておきます。経済産業省「IT人材需給に関する調査」（2019年公表）の試算では、2030年にIT人材は中位シナリオで約45万人、最も厳しい前提では最大で約79万人不足するとされています。レバテックの調査でも、2025年12月時点のIT転職求人倍率は10.4倍と報告されています。
不足が深いのは、定型作業を回す側より、設計と構築を担える側です。工程を1つ上がることが、そのまま市場での立ち位置を変えます。
求人の文面を見ても、設計・構築の担当では「構築経験」「設計経験」が前提に並び、保守運用の経験は「活かせる経験」として書かれることが多いものです。つまり市場は、運用経験を土台として認めたうえで、その上に「作った経験」を求めています。この記事の手順は、その1段をどう作るかに絞ったものです。
【設計構築へ進む具体的手順｜筆者も通った4つの順番】
筆者自身の移動も含め、進んだ人に共通する順番は次の4段階です。
ステップ1：手順の「背景」を理解する
まずは、今の手順書の外側を読みます。
- その手順は、なぜその順番なのか
- 対象のサーバーやシステムは、どういう構成で動いているのか（構成図を読む）
- 障害が起きたとき、なぜその切り分け手順になるのか
手順を「覚える対象」から「設計の結果」として読み直すと、保守作業そのものが設計の学習に変わります。現場の構成図と設計書に触れられる範囲で、読み込むことが第一歩です。
この段階で作るのは、資格でも応募書類でもなく「構成を説明できる言葉」です。自分の担当システムを、図とセットで第三者に説明できるかどうかが、背景理解の到達点になります。
ステップ2：小さな変更・構築に立候補する
次に、小さな「作る仕事」を1つ取ります。
- 機器やサーバーの更改・増設への参加
- 設定変更のうち、手順書の作成から担えるもの
- 小規模な環境構築や検証環境の用意
筆者も、インフラ全般の現場で仮想基盤の構築に加わったことが、工程を上がる転機になりました。最初から大きな設計を任されることはありません。小さな構築の実績が、次の案件への推薦と、転職時の自己申告の材料になります。
立候補のコツは、「何でもやります」ではなく範囲を小さく区切ることです。「この更改の手順書作成から担当させてください」のように相手が任せやすい形にすると、現場側も渡しやすくなります。
ステップ3：設計を体系立てて学ぶ
実務と並行して、設計の基礎を体系で入れます。サーバー設計、ネットワーク設計、可用性やバックアップといった「構成を決める考え方」です。
資格は、この学習の道しるべとして使えます。筆者自身は、LPIC-1やCCNAを保有していますが、資格そのものが構築実績の代わりにはなりません。
資格の勉強で得た「構成の言葉」は、ステップ1の背景理解と、ステップ2の立候補の場面で、そのまま説明の道具になります。資格は単体で効くのではなく、手順の中に置くことで効く、という位置づけです。順番は「学習の裏づけ」として置き、資格全体の進め方は資格まとめで確認しながら決めるのがおすすめです。
動画講座で設計の考え方を体系立てて学ぶ形が合う方には、Udemyのインフラ設計系の講座も選択肢になります。
＼ 設計の考え方を、体系立てて学ぶなら ／
ステップ4：構築案件へ移動する
実績と言語化がそろったら、環境を変えます。選択肢は、社内での異動・担当替えと、転職です。
職務経歴書では「保守運用○年」ではなく、「運用保守と並行して、○○の構築に参画し、構成と手順を作成した」という形に書き換えます。筆者も企業Aの運用監視から、企業Bで構築に触れる現場へ移るという形で、この移動を経験しました。
【転職・フリーランス・副業で変わる進み方の現実】
働き方の3形態で、設計構築への進み方を見ます。
まず転職（正社員）と社内移動です。
工程を上がる移動の本線はここです。構築を含む案件を持つ会社や部署へ移る形で、筆者自身もこのルートを通りました。ステップ2の小さな実績があるかどうかで、書類の通り方ははっきり変わります。
逆に、実績の言語化ができないまま応募すると、「保守運用の継続」と受け取られ、同じ工程の求人に落ち着いてしまいます。工程を上げる転職は、年数ではなく「作ったものの有無」で決まる、というのが実感です。
次にフリーランスです。
フリーランスのインフラ案件は、設計・構築の即戦力が前提です。「これから構築を学びたい」では案件に入れません。筆者自身が独立したのは、構築とクラウドの実務を積んだ後でした。フリーランスは「工程を上がった先」にある選択肢です。
最後に副業です。
インフラの設計構築は、本番環境や顧客情報に触れる仕事が中心で、副業単体での入口は狭いのが正直なところです。副業は、設計の学習や小さな実績づくりの場として補助的に使う位置づけが現実的です。
【設計構築のその先｜クラウドと「型を作る側」へ】
設計構築に移った後も、道は続きます。筆者自身の続きを書きます。
1つ目は、クラウドへの展開です。
オンプレミスの設計構築で身につけた「構成を決める力」は、クラウドの設計にそのまま持ち込めます。筆者も、インフラ全般の現場の後にAWS特化の会社へ移り、クラウド移行を担いました。この先の手順は、姉妹記事のクラウド転身編が担当します。
2つ目は、「型を作る側」への移行です。
AWS特化の会社では、クラウド移行の標準モデルを作り、複数の案件へ展開する仕事を担いました。個別の構築だけでなく、再現できる型を作れるようになると、任される範囲が変わります。
3つ目は、専門の複合です。
現在はフリーランスとして、AWSに生成AIを掛け合わせた案件も受けています。工程を上がる最初の移動があったからこそ、その先の複合が可能になっています。
どの方向でも土台は同じで、「運用の現場感覚×設計構築の判断力」の掛け合わせが、市場価値の中心になります。
振り返れば、筆者の転機はすべて「工程を1つ上がる移動」でした。監視から構築へ、構築からクラウドへ、クラウドから型づくりと複合へ。大きな跳躍ではなく、小さな工程の移動の積み重ねが、結果的に一番遠くまで運んでくれました。
【まとめ｜手順書の「外側」を取りに行く】
要点を3つにまとめます。
- 保守運用の沼の正体は、能力ではなく「判断が手順書に固定され、作る側の工程が回ってこない」構造にある
- 運用・保守の経験は、設計の場面で「壊れにくい・保守しやすい・渡せる」設計として翻訳できる。捨てるものではない
- 進む順番は、手順の背景理解→小さな変更・構築への立候補→設計の学習→構築案件への移動。実績の循環は、小さな1件から破る
今、保守運用の現場で「このままではまずい」と感じているなら、その感覚は正しいサインです。最初の一歩は転職活動ではなく、手元の手順書の「なぜ」を追うことです。
手順書は、抜け出すべき相手であると同時に、設計側への一番の教材でもあります。今日の手順の「なぜ」を1つ追うところから、工程の移動は始まります。
職種全体の地図の中で現在地を確認したい方は、カオスマップの記事に戻って、インフラやクラウドとの位置関係を眺めてみてください。
＼ 設計構築への第一歩は、体系立てて学ぶことから ／
