「手順書どおりに作業した経験しかないので、職務経歴書に書けることがありません」
監視・運用・定型作業を担当しているエンジニアから、よく聞かれる悩みです。
確かに、設計や構築、要件定義の経験がある人と比べると、担当業務をそのまま並べるだけではアピールが弱く見えてしまうかもしれません。
しかし、手順書作業しか経験していないことと、職務経歴書に書けることがないことは別問題です。
手順書に沿って行ってきた仕事にも、次のような経験が含まれています。
- 作業前の確認
- 作業手順の理解
- ミスを防ぐためのチェック
- 障害や異常の検知
- 関係者への報告
- 作業記録の作成
- 手順書の修正や改善
- チームメンバーとの連携
重要なのは、「手順書に従いました」と書くのではなく、どのような環境で、何を確認し、どのように品質を守ったのかを具体的に表現することです。
この記事では、監視・運用・定型作業を中心に経験してきた人が、自分の経験を整理し、評価されやすい職務経歴書へ変換する方法を解説します。
この記事の対象者
- ネットワークやサーバーの監視業務を担当している人
- 手順書に沿った設定変更や機器交換が中心の人
- 定型作業しか経験がなく、転職に不安がある人
- 設計・構築案件へステップアップしたい人
- 職務経歴書に何を書けばよいか分からない人
この記事で分かること
- 手順書作業を職務経歴書に書く方法
- 担当業務を具体化するための整理方法
- 実績や数字がない場合のアピール方法
- 職務要約・業務内容・自己PRの記載例
- 職務経歴書で避けるべき表現
結論：作業内容ではなく「任されていた役割」を書く
手順書作業しか経験していない人が、職務経歴書で最も意識すべきポイントは次のとおりです。
「何の手順書を使ったか」ではなく、「その作業によって何を守っていたか」を書く。
例えば、次の記載では担当者の能力がほとんど伝わりません。
手順書に沿ってネットワーク機器の設定変更を実施しました。
この文章を、作業の目的や確認内容まで含めて書き換えると、次のようになります。
手順書および作業チェックリストに基づき、拠点ネットワーク機器の設定変更を担当しました。作業前後のコンフィグ差分、インターフェース状態、疎通結果を確認し、サービス影響がないことを確認したうえで作業完了報告を実施しました。
どちらも同じ「手順書作業」ですが、後者からは次の能力が読み取れます。
- 事前確認ができる
- 設定変更の影響を理解している
- 作業後の正常性確認ができる
- 記録と報告ができる
- 安全に作業を進められる
職務経歴書では、作業名だけではなく、確認・判断・品質管理・報告まで含めて書くことが重要です。
1. 手順書作業が評価されにくい理由
手順書作業が評価されにくいのは、仕事そのものに価値がないからではありません。
職務経歴書の書き方によって、担当者の役割が見えなくなっていることが主な原因です。
「実施しました」だけで終わっている
次のような文章では、指示されたことを機械的に実行した印象になります。
- アラート監視を実施
- 定例作業を実施
- 機器交換を実施
- 設定変更を実施
- 問い合わせ対応を実施
採用側が知りたいのは、作業名だけではありません。
「何を確認できるのか」「どこまで一人で対応できるのか」「問題が起きたときにどう動けるのか」という部分です。
対象環境が書かれていない
同じ監視業務でも、対象によって経験の意味が変わります。
- 監視対象は10台なのか、1,000台なのか
- 社内システムなのか、顧客向けサービスなのか
- 平日日中だけなのか、24時間365日なのか
- ネットワークだけなのか、サーバーやクラウドも含むのか
環境や規模を書かなければ、経験の大きさが伝わりません。
自分の担当範囲が曖昧
チーム全体の仕事内容をそのまま記載すると、自分が何を担当したのか分からなくなります。
「チームとして実施したこと」と「自分が担当したこと」を分けて書く必要があります。
2. 手順書作業を5つの要素に分解する
職務経歴書を書く前に、担当していた作業を次の5つに分解します。
| 要素 | 確認する内容 |
|---|---|
| 対象 | 何を扱っていたか |
| 目的 | 何のための作業だったか |
| 行動 | 自分が何をしたか |
| 品質 | ミスを防ぐために何を確認したか |
| 連携 | 誰に、何を報告・相談したか |
例：ネットワーク監視業務
| 要素 | 内容 |
| 対象 | 顧客拠点のルーター、スイッチ、ファイアウォール |
| 目的 | 通信障害の早期発見とサービス影響の最小化 |
| 行動 | アラート確認、ログ確認、疎通確認、一次切り分け |
| 品質 | 対象機器、発生時刻、継続時間、関連アラートを確認 |
| 連携 | 二次対応チームへのエスカレーション、顧客への状況報告 |
これを文章にすると、次のように書けます。
顧客拠点のルーター、スイッチ、ファイアウォールを対象とした監視業務を担当しました。アラート発生時には、対象機器、発生時刻、関連アラート、疎通状況を確認し、手順書に基づく一次切り分けを実施しました。復旧が確認できない場合は、取得したログと確認結果を整理し、二次対応チームへエスカレーションしました。
単に「監視を担当」と書くよりも、担当範囲と行動が明確になります。
3. 最初に作るべき「経験棚卸し表」
職務経歴書をいきなり書き始めると、自分の経験をうまく思い出せません。
最初に、次の項目を表にして整理しましょう。
| 項目 | 記入例 |
| 担当期間 | 2024年4月～現在 |
| 業務の目的 | 顧客ネットワークの安定運用 |
| 対象システム | ルーター、スイッチ、ファイアウォール |
| 製品・サービス | Cisco Catalyst、FortiGate、Zabbix |
| 環境規模 | 約200拠点、約800台 |
| チーム人数 | 8名 |
| 自分の担当 | 監視、一次切り分け、定例作業、報告 |
| 使用した資料 | 手順書、構成図、パラメーターシート |
| 確認した項目 | ログ、疎通、インターフェース、CPU、メモリー |
| 報告先 | チームリーダー、二次対応チーム、顧客担当者 |
| 工夫したこと | チェックリスト作成、手順書の追記 |
| 身についたこと | 正常性確認、エスカレーション、作業記録 |
すべてを職務経歴書に載せる必要はありません。
まず材料をできるだけ多く出し、その後、応募する仕事に合わせて必要な情報を選びます。
4. 手順書作業でアピールできる7つの能力
4-1. 正確に作業する能力
手順書作業では、正確性が重要です。
特にネットワークやサーバーの設定変更では、一つの入力ミスが障害につながる可能性があります。
職務経歴書では、単に「正確に作業しました」と書くのではなく、具体的な確認方法を書きます。
記載例
作業前後の設定差分、対象機器名、ポート番号、IPアドレスを複数回確認し、チェックリストを使用して設定漏れや確認漏れを防止しました。
4-2. 正常性を確認する能力
作業を終えることと、正常に完了したことを確認することは別です。
設定変更後に何を確認していたのかを書きましょう。
確認項目の例
- Pingによる疎通確認
- インターフェース状態
- ルーティングテーブル
- VLANの所属状況
- CPU・メモリー使用率
- エラーログ
- 監視アラート
- 通信試験
- 利用部門からの確認
記載例
設定変更後は、インターフェース状態、ルーティング情報、監視アラート、対象拠点との疎通を確認し、変更前と同等の通信が維持されていることを確認しました。
4-3. 異常を発見する能力
手順書どおりに進めるだけでなく、通常と異なる状態に気づいた経験もアピール材料です。
自分で原因を解決できなかったとしても、異常を発見し、正しく報告した経験には価値があります。
記載例
作業後確認において想定外のログ出力を発見し、作業を中断しました。取得したログ、実施済み手順、発生時刻を整理してリーダーへ報告し、影響範囲を確認したうえで作業を再開しました。
この文章からは、独断で作業を続けず、リスクを考えて行動できることが伝わります。
4-4. エスカレーション能力
運用業務では、すべての問題を一人で解決する必要はありません。
重要なのは、必要な情報を整理して、適切な担当者へ引き継ぐことです。
エスカレーション時に整理する情報
- 発生日時
- 対象機器・対象サービス
- アラート内容
- 利用者への影響
- 確認した項目
- 実施した対応
- 取得したログ
- 現在の状態
- 依頼したい内容
記載例
障害発生時には、対象機器、アラート内容、発生時刻、影響範囲、確認済み項目を整理し、二次対応チームへエスカレーションしました。担当者が追加調査を開始しやすいよう、ログと確認結果を時系列で共有しました。
4-5. ドキュメント作成能力
作業記録、日報、障害報告、手順書の更新も実務経験です。
記載例
作業結果、確認項目、取得ログを所定のフォーマットに記録し、第三者が作業内容を追跡できる状態で管理しました。また、実際の画面と手順書の記載に差異があった場合は、修正内容を整理して管理者へ報告しました。
4-6. 改善する能力
小さな改善でも、十分なアピール材料になります。
- 手順書に注意事項を追記した
- チェックリストを作成した
- よくあるエラーを一覧化した
- 引き継ぎ資料を作成した
- ファイル名や保存場所を統一した
- 作業前確認の項目を追加した
- 新人向けに補足説明を加えた
記載例
作業担当者によって確認項目に差が出ていたため、作業前後の確認項目をチェックリストとして整理しました。チーム内で共有し、確認漏れを防止できる運用に改善しました。
大規模な自動化や業務改革でなくても構いません。
「問題に気づき、自分なりに改善した」という行動が重要です。
4-7. チームで仕事を進める能力
定型作業でも、実際には複数の関係者と連携しています。
- 作業承認を得る
- ダブルチェックを依頼する
- 作業開始を連絡する
- 異常を報告する
- 次のシフトへ引き継ぐ
- 顧客へ完了報告をする
記載例
交代勤務における情報の抜け漏れを防ぐため、未完了作業、継続監視対象、顧客からの問い合わせ状況を引き継ぎシートに整理し、次シフトへ共有しました。
5. 職務経歴書の基本構成
手順書作業を中心に経験してきた人は、次の順序で職務経歴書を作ると整理しやすくなります。
- 職務要約
- 活かせる経験・スキル
- 職務経歴
- 担当業務
- 工夫・実績
- 使用技術・製品
- 資格
- 自己PR
6. 職務要約の書き方
職務要約は、これまでの経験を3～5行程度でまとめる部分です。
「手順書作業しかしていません」と書く必要はありません。
次の4項目を入れます。
- 経験年数
- 担当領域
- 対象環境
- 身につけた能力
職務要約の記載例
ITインフラ運用担当として約2年間、顧客ネットワークの監視、障害一次対応、設定変更、機器交換、定例作業に従事してきました。ルーター、スイッチ、ファイアウォールを対象に、手順書に基づく作業、作業前後の正常性確認、ログ取得、二次対応チームへのエスカレーションを担当しています。正確な作業と確認を重視し、手順書の修正やチェックリスト作成にも取り組んできました。
設計経験がない場合も、設計経験があるように見せる必要はありません。
現在できることを具体的に書く方が、信頼性の高い職務経歴書になります。
7. 「活かせる経験・スキル」の書き方
製品名だけでなく、「何ができるか」をセットで書きます。
悪い例
- Cisco
- FortiGate
- Zabbix
- Linux
- Excel
製品に触れたことしか伝わりません。
改善例
| 分野 | 経験・スキル |
| ネットワーク監視 | Zabbixを使用したアラート確認、障害一次切り分け |
| Cisco機器 | showコマンドによるインターフェース、ルーティング、ログ確認 |
| FortiGate | 手順書に基づくポリシー変更、変更前後の疎通確認 |
| Linux | 基本的なログ確認、ファイル操作、サービス状態確認 |
| ドキュメント | 作業手順書、チェックリスト、作業完了報告の作成 |
| 障害対応 | 発生状況、影響、確認内容を整理したエスカレーション |
| チーム連携 | シフト引き継ぎ、ダブルチェック、作業進捗の共有 |
8. 職務経歴の記載例
プロジェクト概要
顧客ネットワークの運用・監視業務
期間：2024年4月～現在
チーム人数：8名
担当工程：監視、運用、障害一次対応、定例作業
対象環境：全国約200拠点、ネットワーク機器約800台
主な製品：Cisco Catalyst、Cisco ISR、FortiGate、Zabbix
担当業務
- ネットワーク機器および回線のアラート監視
- アラート発生時のログ確認、疎通確認、一次切り分け
- 手順書に基づく設定変更および定例作業
- ネットワーク機器交換時の事前確認と作業後確認
- 作業前後のコンフィグ取得および差分確認
- 二次対応チームへのエスカレーション
- 顧客向け作業完了報告の作成
- シフトメンバーへの引き継ぎ
- 手順書、チェックリストの修正
工夫・実績
- 作業前後の確認項目をチェックリスト化し、担当者による確認内容のばらつきを抑制
- 手順書と実機画面の差異を整理し、手順書の修正を提案
- エスカレーション時に必要なログと確認項目を一覧化し、引き継ぎ情報を標準化
- 新規参画者向けに、監視画面の見方と初動対応をまとめた補足資料を作成
9. 書き方のビフォー・アフター
例1：監視業務
書き換え前
ネットワークの監視を担当しました。
書き換え後
顧客拠点のルーター、スイッチ、回線を対象としたアラート監視を担当しました。アラート発生時には、対象機器、発生時刻、継続時間、関連アラート、疎通状況を確認し、手順書に基づく一次切り分けを実施しました。
例2：設定変更
書き換え前
手順書に沿って設定変更をしました。
書き換え後
承認済みの作業手順書に基づき、ネットワーク機器の設定変更を担当しました。作業前のコンフィグ取得、対象機器と設定値の確認、設定投入、作業後の差分確認および疎通確認まで実施しました。
例3：障害対応
書き換え前
障害が発生したら上司に報告しました。
書き換え後
障害発生時には、アラート内容、対象機器、影響範囲、ログ、疎通結果を整理し、チームリーダーへ報告しました。手順書の対応範囲を超える場合は、確認済み項目を明示して二次対応チームへエスカレーションしました。
例4：手順書修正
書き換え前
手順書を修正しました。
書き換え後
作業中に判明した画面表示の変更や注意事項を記録し、手順書の修正案を作成しました。レビュー担当者の確認後、チーム内で共有して後続作業へ反映しました。
10. 数字で示せる実績がない場合の書き方
「対応件数を数えていない」「改善率が分からない」という人も多いでしょう。
無理に数字を作ってはいけません。
正確な数字が分からない場合は、次の情報を使います。
環境の規模
- 約100拠点
- 数百台規模
- 24時間365日の監視環境
- 10名体制
- 複数顧客を担当
業務の頻度
- 日次
- 週次
- 月次
- シフトごと
- 定期メンテナンス時
- 障害発生時
担当範囲
- 一次受付からエスカレーションまで
- 作業前確認から完了報告まで
- ログ取得から関係者への共有まで
- 手順書の修正案作成からレビュー依頼まで
記載例
24時間365日のネットワーク監視体制において、アラート確認から一次切り分け、二次対応チームへのエスカレーションまでを担当しました。
数字がなくても、業務の範囲と責任を具体的に示すことは可能です。
11. 設計・構築経験がない場合の見せ方
設計・構築経験がないにもかかわらず、「設計補助」「構築支援」と曖昧に書くのは避けましょう。
面接で具体的な内容を質問されたときに、説明できなくなる可能性があります。
代わりに、設計・構築につながる基礎経験を記載します。
設計・構築につながる経験
- ネットワーク構成図を確認して作業した
- パラメーターシートを確認した
- コンフィグの変更箇所を確認した
- 変更前後の差分を確認した
- テスト項目に沿って疎通確認をした
- 設定変更時の影響範囲を確認した
- 機器交換時に既存設定を移行した
- 作業手順書を修正した
記載例
設定変更作業では、構成図、パラメーターシート、既存コンフィグを確認し、変更対象と影響範囲を把握したうえで作業を実施しました。
これは設計経験ではありませんが、設計書や構成情報を読みながら作業できることを示せます。
12. 自己学習は実務経験と分けて書く
設計・構築へ進みたい場合、学習している内容も記載できます。
ただし、実務経験と自己学習を混ぜてはいけません。
記載例
自己学習・検証
- Cisco Packet Tracerを使用したVLAN、STP、OSPFの構築検証
- AWS上でのVPC、サブネット、ルートテーブル、セキュリティグループの作成
- Wiresharkを使用したARP、DNS、TCP通信の確認
- Ansibleを使用したネットワーク機器設定の自動化学習
- GitHubでの検証手順、構成図、設定例の公開
実務経験ではないことを明確にしつつ、次の仕事へ進むために行動していることを示します。
13. 自己PRの作り方
自己PRでは、性格だけでなく、実際の行動を示します。
「真面目です」「責任感があります」だけでは、他の応募者との差がつきません。
次の構成を使うと書きやすくなります。
- 自分の強み
- 強みが表れた場面
- 実際に取った行動
- 今後どのように活かすか
自己PR例：正確性
私の強みは、作業の正確性を保つために確認方法を工夫できる点です。ネットワーク機器の設定変更では、手順書を読むだけでなく、対象機器、設定値、作業前後のコンフィグ差分、疎通結果をチェックリストで確認してきました。また、手順書と実際の画面に差異があった場合は、作業後に修正案を作成し、チーム内で共有しました。今後は、運用業務で身につけた確認力を活かし、ネットワークの構築やテスト業務へ担当範囲を広げたいと考えています。
自己PR例：障害対応
私の強みは、問題発生時に状況を整理して関係者へ共有できる点です。監視アラートが発生した際には、対象機器、発生時刻、影響範囲、ログ、疎通結果を整理し、確認済み項目を明示して二次対応チームへエスカレーションしてきました。原因を推測だけで断定せず、事実と未確認事項を分けて報告することを意識しています。今後はネットワーク知識を深め、一次切り分けだけでなく、原因調査や復旧対応まで担当できるエンジニアを目指します。
14. 職務経歴書で避けたいNG表現
NG1：「手順書どおりに作業した」だけで終わる
手順書の使用自体は悪くありません。
ただし、確認内容や責任範囲まで書かなければ、能力が伝わりません。
NG2：「さまざまな業務を経験」と書く
「さまざま」「多数」「幅広く」といった言葉は、具体性がありません。
担当した機器、作業、確認項目を書きましょう。
NG3：チームの実績を自分の実績として書く
プロジェクト全体で達成した成果と、自分が担当した行動を分けます。
NG4：経験を過大に表現する
手順書に従って設定を投入した経験を、「ネットワーク設計・構築」と書くのは危険です。
面接で設計理由や構築方法を質問されたときに説明できません。
NG5：製品名だけを大量に並べる
製品名は、「どの機能を、どの程度扱ったか」とセットで記載します。
NG6：受け身の表現ばかり使う
「指示を受けて」「教えてもらいながら」「言われたとおりに」という表現が続くと、受け身な印象になります。
事実を変えず、次のように書き換えます。
- 指示を受けて確認した
→ 指定された確認項目に基づき、ログと疎通状況を確認した - 教えてもらいながら対応した
→ リーダーへ確認しながら、障害一次対応を実施した - 言われたとおりに報告した
→ 所定の報告フォーマットを使用し、影響と対応状況を共有した
15. 面接で説明できる内容だけを書く
職務経歴書に書いた内容は、面接で詳しく質問されます。
次の質問に答えられるようにしておきましょう。
- どのような環境でしたか
- 何台・何拠点程度を担当しましたか
- どの製品を扱いましたか
- 作業前に何を確認しましたか
- 作業後に何を確認しましたか
- 異常が起きたときはどうしましたか
- どこまで一人で対応できましたか
- 誰にエスカレーションしましたか
- 手順書を改善した経験はありますか
- 作業で失敗しないために何を意識しましたか
- 今後どの工程を担当したいですか
職務経歴書を作る目的は、経験を大きく見せることではありません。
自分が実際に行ってきたことを整理し、相手に分かりやすく説明できる状態にすることです。
16. そのまま使える職務経歴書テンプレート
職務要約
ITインフラ運用担当として〇年間、〇〇を対象とした監視、障害一次対応、設定変更、定例作業に従事してきました。主に〇〇製品を扱い、手順書に基づく作業、作業前後の正常性確認、ログ取得、エスカレーション、作業完了報告を担当しています。また、〇〇の改善にも取り組みました。
プロジェクト概要
- 期間：
- 業務内容：
- 対象システム：
- 環境規模：
- チーム人数：
- 担当工程：
- 使用製品・ツール：
担当業務
- 〇〇の監視
- アラート発生時の〇〇確認
- 手順書に基づく〇〇作業
- 作業前の〇〇確認
- 作業後の〇〇確認
- 障害発生時のログ取得
- 二次対応チームへのエスカレーション
- 作業記録、完了報告の作成
- 手順書、チェックリストの修正
工夫・実績
- 〇〇をチェックリスト化し、確認漏れを防止
- 〇〇の手順を整理し、作業担当者間のばらつきを低減
- 手順書と実際の画面の差異を発見し、修正案を作成
- エスカレーションに必要な情報を整理し、共有方法を標準化
- 新規参画者向けに〇〇資料を作成
自己PR
私の強みは〇〇です。〇〇業務では、〇〇という課題に対して、〇〇を実施しました。その結果、〇〇につなげることができました。今後は、この経験を活かして〇〇まで担当範囲を広げたいと考えています。
17. 30分でできる職務経歴書作成手順
最初の10分：経験を書き出す
これまで担当した作業を、大小に関係なく書き出します。
- 監視
- ログ確認
- Ping確認
- 機器交換
- 設定変更
- 定例作業
- 問い合わせ対応
- 障害報告
- シフト引き継ぎ
- 手順書修正
次の10分：作業前後の行動を追加する
それぞれの作業について、次を追記します。
- 作業前に何を確認したか
- 作業後に何を確認したか
- 異常時にどう対応したか
- 誰に報告したか
- 何を記録したか
最後の10分：一つの文章にする
次の型に当てはめます。
〇〇を対象に、〇〇を目的とした業務を担当しました。作業時には〇〇を確認し、〇〇まで実施しました。異常発生時には〇〇を整理し、〇〇へ報告しました。
この作業を担当業務ごとに繰り返すだけでも、職務経歴書の具体性は大きく変わります。
まとめ：手順書作業は、次の工程へ進むための土台になる
手順書作業しか経験がないからといって、職務経歴書に書けることがないわけではありません。
大切なのは、担当してきた仕事を次の要素に分けることです。
- 何を扱っていたか
- 何のための作業だったか
- 作業前後に何を確認したか
- 異常時にどう動いたか
- 誰と連携したか
- どのような改善をしたか
職務経歴書には、派手な実績だけを書く必要はありません。
正確に作業すること、異常を発見すること、必要な情報を整理して報告すること、手順を改善することも、現場で必要とされる能力です。
まずは「手順書に従って作業した」という一文を、次の形へ書き換えてみてください。
手順書に基づき、作業前確認、設定変更、正常性確認、結果記録、完了報告までを担当した。
現在の経験を正確に言語化できれば、自分に不足しているスキルも見えてきます。
手順書作業の経験を隠すのではなく、そこで身につけた確認力、報告力、改善力を整理し、次の設計・構築業務へ進むための土台として伝えましょう。
コメント