運用監視の夜勤経験を構築経験に書き直す職務経歴書の作り方

夜勤明けの朝8時過ぎに、こんなメッセージが届くことがあります。「構築経験の欄が書けません。手順書どおりに動いているだけなので、構築はやったことがないんです」——運用監視のオペレーターからインフラ構築職を目指す方の相談で、私はこの一文を何度も受け取ってきました。

IT・Web業界を中心に800名以上の転職を支援してきて、こうした方の職務経歴書を並べて見ると、構築経験が本当にゼロの人は意外なほど少数です。多くは構築工程の端に触れた経験が「運用の言葉」のまま書かれていて、読み手に届いていません。今回は、夜勤の運用監視の経験を構築側の工程名と語彙で書き直す方法と、「構築経験」と書いてよい線引き、求人票の要件ごとの書き分けを、実例を交えてお伝えします。

目次

1. 運用監視の夜勤から構築職へ、職務経歴書が「経験なし」と読まれる理由
2. 「構築経験」と書いてよい線引き
3. 夜勤中の業務から構築工程に触れた経験を拾う棚卸し
4. 手順書業務を構築側の語彙に書き直すBefore/After
5. 職務経歴書の全体構成、運用監視の経験者はどう並べるか
6. 求人票の必須要件別の書き分け
7. 「構築経験2年以上」が必須の求人
8. 「設計・構築経験」とだけあり、年数の指定がない求人
9. 「運用経験歓迎」「運用監視経験者可」の求人
10. 「運用監視経験半年以上で応募可」型の入口求人
11. 相談事例：夜勤の作業チケットを並べ直したBさんの書き直し
12. 盛ると面接で崩れる、資格・自宅検証・自動化はどこまで実績か
13. 夜勤から抜けるために、面接で聞くべき質問
14. よくある質問
15. まとめ、同じ夜勤を「どの工程名で書くか」で書類の読まれ方は変わる

運用監視の夜勤から構築職へ、職務経歴書が「経験なし」と読まれる理由

構築職の書類を読む側が最初に見るのは、年数よりも「どの工程に、どの規模で、何の技術で関わったか」です。民間メディアの職務経歴書の解説でも、規模（サーバーの台数など）、工程（設計・構築・運用）、技術要素（OSやミドルウェア、クラウド）を書くよう案内されています（参考：お名前.com「インフラエンジニアの職務経歴書の書き方」）。

ここに「24時間365日の運用監視。アラート一次対応、手順書に基づく復旧作業」とだけ書くと、読み手には工程名として「運用」しか見えません。規模も技術要素も書かれていないので、手順書の待機要員と同じ扱いで読まれます。夜勤だと書類上はさらに不利に見えがちですが、私が見てきた範囲では、夜勤か日勤かが選考の分かれ目になった例はほとんどありません。見られているのは書かれた工程名です。

なお、監視オペレーターに固定される期間について、転職メディアのアルクの記事は「2年以内が許容範囲」「入社前に2年以内の設計・構築への昇格実績を確認する」と述べています。統計ではなく一媒体の主張ですが、私が現場で見てきた感覚とは概ね重なります。ただ、気にすべきは年数そのものより、その期間に担当範囲が何か変わったかどうかです。

私の見立てでは、運用監視のオペレーターが「構築経験なし」と感じる原因の半分は、実際の経験不足ではなく、自分の業務を運用の語彙でしか見ていないことにあります。変更作業の立会いや設定値の確認など、構築工程の周辺に触れる機会は、夜勤の現場にも思いのほか転がっています。

「構築経験」と書いてよい線引き

書き直しの前に、盛らないための線引きを決めておきます。構築経験を膨らませて書いた職務経歴書は、書類は通っても面接の深掘りで必ず崩れるからです。工程ごとに、夜勤の現場で触れうる場面と、書いてよい範囲を並べてみます。

判定の基準は3つあります。自分の手で操作したか、その判断の理由を口で説明できるか、そして成果物（確認記録や手順書の改訂履歴）が残っているか。3つとも満たすなら「実施」、操作はしていないが内容を理解して確認した場合は「確認」「補助」「立会い」と書きます。

ポイント： 面接で「その設定値は、なぜその値だったのですか」と聞かれて答えられる範囲が、書いてよい上限です。答えられない行を足して盛るより、答えられる行だけで固めた書類のほうが、面接まで含めた通過率は上がります。

私の感覚では、補助や立会いと正直に書いてある書類のほうが、読む側の信頼が高いです。「構築経験3年」と書いてあるのに技術要素の欄が薄い書類より、「構築補助（設定値の突合せ確認）」と書かれた書類のほうが、実際に面接へ呼ばれる率は高いと感じています。採用側は、運用監視から来た人にいきなり設計力を期待していません。

夜勤中の業務から構築工程に触れた経験を拾う棚卸し

では、実際に何を拾えばよいのか。やり方は単純で、直近3か月分の作業チケットや引き継ぎノート、手順書の更新履歴を机に並べて、「監視していた」以外の動詞が付く行を拾っていきます。次の6つの視点で見ると、拾い漏れが減ります。

拾うときのコツは、動詞を「対応した」で終わらせないことです。たとえば変更作業の立会いなら、対象のOSやミドルウェア、台数、自分が確認した項目、不具合を見つけたかどうかまで残します。件数は大雑把でかまいません。「月に4〜5回」「3か月で十数回」という実感のある数字で十分です。

もうひとつ、拾った行を「実施・確認・補助・立会い」のどれかに必ず仕分けておきます。この仕分けが、先ほどの線引きを職務経歴書の上で守るための作業になります。仕分けを飛ばして書くと、書いた本人でも何をどこまでやったのか曖昧になり、面接で詰まります。

夜勤の現場で見落とされやすいのは、「監視設定の追加登録」です。新しいサーバーが構築された際に監視項目を登録し、閾値を構築担当と詰める作業は、監視設計の一部です。閾値の案を自分で出して採用されたなら、先ほどの線引きどおり「監視項目の設計に参加」と書けます。言われた値を登録しただけなら「登録」にとどめます。誰も構築と呼ばないので本人も忘れていますが、構築担当と会話した場面は、たいてい記憶に残っています。

手順書業務を構築側の語彙に書き直すBefore/After

拾った経験を、構築側が読み取れる語彙に置き換えます。ここでは夜勤の運用監視でよく出てくる3つの業務を例にします。置き換えの発想は共通していて、「作業をした」ではなく「どの工程の、何の判断に関わったか」を書くことです。

手順書の改訂

Before：「障害対応手順書の更新を担当」

After：「障害一次対応の手順書（約40ページ）を、対応ログの分析に基づき改訂。復旧手順の分岐を整理し、夜勤帯の一次対応を担当者の経験に依存しない形に標準化。改訂後3か月で、エスカレーション件数が減少」

読み手が拾うのは「標準化」「運用設計」に近い仕事です。改訂の根拠（対応ログの分析）と効果（件数の変化）まで書けると、構築後の運用を設計できる人として読まれます。

アラートの閾値調整

Before：「監視アラートの閾値見直しを実施」

After：「ディスク使用率・CPU使用率の閾値を、過去半年のアラート履歴から再設定。誤検知の多かった項目を整理し、構築担当と協議して新規サーバー12台分の監視項目を設計・登録」

「見直した」という動詞を「設計・登録」に変えるだけで、監視設計の経験として読まれます。ただし「設計」と書けるのは、閾値の案を自分で出した場合だけです。値を指示されて入れただけなら「登録」に絞ってください。構築担当と協議したという一文が、構築工程との接点を示しています。

定型作業のスクリプト化

Before：「日次のログ確認作業を効率化」

After：「手作業で行っていた日次のログ確認（約40分）をシェルスクリプトで自動化し、確認作業を約10分に短縮。スクリプトは運用チーム内で共有し、引き継ぎ資料に実行手順を記載」

自動化の成果は、構築工程で言う「作業の自動化・標準化」に直結します。ただし、そのスクリプトが実際に誰に使われていたかまで確認したうえで、盛りすぎない範囲で書きます（詳しくは後の章で触れます）。

この3つに共通するのは、書き換える前の行に事実を足してはいないことです。事実はそのままで、工程名と判断の中身、規模を加えただけです。なお、自社開発企業やWeb系を志望している場合は、翻訳の方向がやや違ってきます。その場合は、客先常駐5年目の運用保守から自社開発へ転職する翻訳術のほうが合います。

職務経歴書の全体構成、運用監視の経験者はどう並べるか

個々の行を書き直したら、次は書類全体の並べ方です。運用監視の経験者は、業務欄を時系列の箇条書きにしがちですが、構築職の応募では工程別に並べ替えたほうが読み手に伝わります。

私が添削でよく使う並びは、職務要約、工程別の業務内容、技術要素、改善・自動化の実績の4つです。職務要約の冒頭には「運用監視を軸に、変更作業の立会いや設定値の検証など構築工程の補助を担当」のように、工程の幅を一文で示します。ここで「運用だけの人」という先入観を先に崩しておくと、後ろの行が読まれやすくなります。

工程別の業務内容では、運用・構築補助・改善の順に、それぞれ2〜3行を書きます。技術要素の欄は、OS（Linuxのディストリビューション、Windows Server）、監視ツール、ネットワーク機器、クラウドなど、触れた範囲を製品名とバージョンの粒度で並べます。「触ったことがある」程度のものは「参照のみ」と添えると、盛っていない書類として信頼されます。

夜勤そのものについては、勤務形態の説明として一行で十分です。「交代制勤務（夜勤月◯回）」と書き、夜勤をやり遂げた根性を強調する必要はありません。構築職の書類を読む人が知りたいのは、夜中に何時間起きていたかではなく、その時間に何を判断したかです。

求人票の必須要件別の書き分け

同じ経歴でも、応募する求人の要件によって前面に出す行は変わります。ここが書類選考で一番差がつくところです。求人票の文言を4つに分けて、それぞれの書き方を整理します。

「構築経験2年以上」が必須の求人

正直に言うと、補助や立会いの経験だけでこの要件を満たすと書くのは難しいです。無理に「構築2年」と書くと、面接で設定投入の手順やパラメータの根拠を聞かれて崩れます。

私はこうした求人への応募を、無理に押し通さないよう案内しています。要件を満たしていなくても通る例はゼロではありませんが、まずは「歓迎」「可」の求人に先に応募し、通過率の高い求人から実績を積むほうが、結果的に近道です。

「設計・構築経験」とだけあり、年数の指定がない求人

この表記は、実は一番ねらい目です。年数を問わないので、先ほどの工程別の線引きに従って、設計・構築のどこに触れたかを分解して書けます。

書き方のコツは、「構築経験あり」と一括りにせず、「パラメータシートの確認（作成ではなくレビュー）」「変更作業の立会いと事後確認」のように、工程の粒度で書くことです。読み手は粒度が揃っている書類ほど「この人は工程を理解している」と受け取ります。

「運用経験歓迎」「運用監視経験者可」の求人

ここでは運用経験が強みになります。構築した後に運用がどう回るかを知っている人は、構築側にとっても貴重だからです。夜勤で何を見てきたかを具体的に書くほど評価されます。

書くべきは、障害の傾向、アラートの多かった要因、手順書で毎回詰まった箇所のような、運用側から見た構築への示唆です。「構築段階で監視項目やログ出力をこう決めておけば、運用が楽になる」と語れる人は、構築チームから見て即戦力に近く映ります。

「運用監視経験半年以上で応募可」型の入口求人

構築職の中には、運用監視で入社して、一定期間後に構築へ上がる育成コースを設けている企業があります。この型の求人は経験の量よりも、学習の継続性と、入社後の動機が見られます。

職務経歴書には、保有資格や自宅での検証環境を、実績ではなく学習の姿勢として書き添えます。「何を作ったか」より「何を調べて、どこまで再現できたか」を書くほうが誠実で、面接官にも伝わります。

相談事例：夜勤の作業チケットを並べ直したBさんの書き直し

ここで、私が支援した26歳のBさん（経験3年半）の例を紹介します。中堅のITインフラサービス会社で、顧客企業のサーバー・ネットワークの運用監視センターに勤務していました。月の半分が夜勤シフトで、職務経歴書の業務欄は「運用監視業務（24時間365日）。アラート一次対応、手順書に基づく復旧作業」の一行でした。

応募先の書式にある「担当工程」の欄では、設計・構築にチェックが付けられず、6社応募して書類を通ったのは1社だけでした。Bさん自身も「構築はやったことがない」と考えていたので、書き足せる事実を探しようもない状態でした。

面談でまず頼んだのは、直近3か月分の作業チケットを並べてみることです。すると、変更作業の立会いが十数回、パラメータシートと実機設定の突合せ確認が数回あり、不一致を2件指摘していたことが出てきました。さらに、新規サーバー12台分の監視項目の登録も、Bさんが構築担当と閾値を詰めながら進めていました。本人にとっては「いつものお手伝い」で、経歴として意識していなかったそうです。

書き直した職務経歴書では、担当工程の欄に「構築：補助（作業手順の確認・設定値の検証）」と書きました。業務欄は、変更作業の立会いと事後確認、パラメータシートとの突合せで不一致2件を指摘、新規サーバー12台分の監視項目登録の3行に分けています。「構築経験あり」とは書いていません。

応募先は「運用経験歓迎」「構築は入社後に育成」と書かれた求人を中心に、7社に絞りました。書類を通ったのは3社、二次面接まで進んだのが2社で、1社から内定が出ました。面接では、パラメータシートの不一致をどう見つけたのかを具体的に聞かれ、Bさんは手順を順に説明できたそうです。

入社後の最初の半年は、構築補助の位置づけでした。夜勤手当がなくなる分、年収はほぼ横ばいです。それでも「設定値を自分で入れる側に回れた」ことが一番の変化だったと、半年後に聞きました。もちろん、この結果は再現性を保証するものではありません。ただ、事実を足さずに粒度と語彙を変えただけで書類の通り方が変わったという点は、私が見ている他の相談者にも共通しています。

盛ると面接で崩れる、資格・自宅検証・自動化はどこまで実績か

書類を通すことだけを考えると、つい書き足したくなる項目があります。資格、自宅の検証環境、スクリプトによる自動化の3つです。それぞれ「どこまで書いてよいか」の私の線引きを書いておきます。

資格（CCNAやLinuC、AWS認定など）は、実績ではなく学習の証拠として書きます。書類の通過に直接効くことは少ないものの、入口求人では「学ぶ姿勢がある」と読まれて加点になります。資格が構築経験の代わりになると考えている方は、そこで期待値がずれます。

自宅の検証環境は、実績として書くなら「何を構築したか」だけでなく「構築中に何で詰まって、どう解決したか」まで語れる状態にします。仮想マシンを3台立ててWebサーバーを動かした、で止まると、面接では「で、何が分かったのですか」と聞かれます。書くなら、業務経験の下に学習として添える位置が適切です。

シェルスクリプトやAnsibleによる自動化は、運用チーム内で実際に使われ、時間削減などの効果が出ているなら実績として書けます。逆に、自分用に作っただけで誰も使っていない場合は、実績とは言いにくいです。この見極めは、スクリプトが運用の中に定着しているかで判断します。

この3つに答えられない行は、職務経歴書から外すか、「確認」「補助」の表記に落とします。業務を業務の言葉で書き直した書類は、面接でそのまま話せるという意味で、強い書類です。

面接の準備としては、書類の各行について「自分が何をして、何を判断したか」を30秒で話せるように用意しておきます。夜勤の経験は、昼間の面接官から見ると具体的な場面を想像しにくいので、「深夜2時にディスク使用率の警告が出て、何を確認して、誰に連絡したか」のような時刻つきの描写が効きます。場面が見える話は、手順書をなぞっただけという印象を最も早く覆せます。

職種は違いますが、テクニカルサポートの開発職転職が未経験扱いされる理由を扱った記事も、根は同じ問題です。事実は変えず、工程と判断の粒度だけを変えて読み手に届けます。

夜勤から抜けるために、面接で聞くべき質問

職務経歴書を書き直しても、転職先が「また監視ばかり」では意味がありません。入口求人に応募するときは、面接や面談の場で次の質問を聞いておくと、入社後のずれを減らせます。

「構築も任せます」と求人票に書いてあっても、実態は監視中心のまま固定される会社は存在します。私が候補者から聞いてきた範囲では、「異動した人はいますか」と尋ねて具体的な事例がすぐ返ってくる会社は、入社後の配属も動きやすい傾向があります。返答が曖昧な会社では、配属が半年以上そのままというケースを何度か耳にしました。

SRE求人に見えて実態は監視当番だった、というケースは別の記事でも取り上げています。肩書きが構築職でも、中身は運用のままという求人はあるので、確認の観点はSRE求人と実態のずれの記事も参考になります。

よくある質問

夜勤の運用監視は何年で辞めるのがよいですか。 年数で一律には決められません。アルクの記事は2年以内を目安としていますが、一媒体の主張です。私は年数より、担当範囲が広がっているかを見ています。直近1年で変更作業の立会いや設定値の確認など新しい工程に触れていれば、3年目でも動けます。

構築経験がない場合、書類選考は厳しいですか。 「構築経験○年以上」が必須の求人は厳しいです。一方で、運用経験歓迎や入口求人は、経験の量より工程の理解と学習姿勢が見られます。応募先の選び方で通過率が大きく変わります。

運用保守と構築の違いは、職務経歴書でどう書き分けますか。 運用保守は稼働中のシステムを維持する工程、構築は設計に基づいて環境を立ち上げる工程です。書くときは、担当した工程名を明記し、設定を入れたのか確認したのかを動詞で分けます。

構築以外の行き先はありますか。 あります。インフラの運用経験は、セキュリティ運用など別の職種でも評価されます。経験の活かし方はセキュリティエンジニアへの転職でインフラ経験が評価される理由で詳しく書いています。

まとめ、同じ夜勤を「どの工程名で書くか」で書類の読まれ方は変わる

夜勤の運用監視から構築職を目指すとき、足りないのは経験の量より、経験を書く語彙と工程名の粒度だというのが、この記事で一番お伝えしたかったことです。事実を増やすのではなく、すでにある事実を、設計・構築の工程名で分解して書き直す。この作業は、今日の夜勤の記録からでも始められます。

線引きは単純です。自分の手で操作し、理由を説明でき、記録が残っているものだけを「実施」と書く。それ以外は「確認」「補助」「立会い」と正直に書く。この線を守った書類は、一次面接でも崩れません。

求人票の要件が重い求人を無理に追わず、「設計・構築経験（年数不問）」や「運用経験歓迎」の求人から先に当たることも大切です。直近3か月の作業チケットを並べて、「監視した」以外の動詞が付いた行を探すところから始めてみてください。