なぜ「書くことがない」と感じるのか
運用保守は「何も起きない状態」を作る仕事です。成果が出来上がったものとして残らないので、書く材料が見えにくくなります。
開発の仕事
作ったもの・リリースしたものが残る。「何を作ったか」がそのまま実績になる
運用保守の仕事
何も起きない状態を保つのが成果。残るのは作業の記録で、判断は記録に出てこない
加えて、運用の作業は手順書に沿って進みます。手順があると「決められたことをやっただけ」と感じますが、実際には対応の順番、確認する範囲、エスカレーションするかどうかを、その場で自分が判断しています。書くべきなのはこの部分です。
書くのは「やった作業」ではなく
「自分が決めたこと」と「変わったこと」
実績の材料が残っている5つの場所
記憶をたどるのではなく、記録を見に行きます。1年分をざっと見返すだけで材料は十分に出てきます。
チケット・インシデントの履歴
自分が対応した件を一覧で見る。件数、傾向、再発しているもの、自分が根本対応まで進めたものを拾う
手順書・社内Wikiの更新履歴
自分が追記・整備したページは、そのまま「仕組みを改善した記録」になる
監視設定の変更履歴
しきい値の見直し、不要なアラートの停止、新しい監視項目の追加。判断した理由を思い出す
自分が書いたスクリプト・設定
小さなシェルスクリプトや定期実行の設定も、手作業を減らした実績として書ける
定例会・報告資料
月次の報告に載せた改善提案や対応状況。数字が残っていることが多い
引き継ぎ・教育の記録
新しく入った人への説明や、当番を任せられるようにした手順の整備も成果
見返すときのコツは、「困ったこと」で検索することです。何度も鳴っていたアラート、毎回時間がかかっていた作業、問い合わせが集中していた機能。困りごとと、それに対して自分がやったことの組み合わせが、そのまま実績の1行になります。
「作業」を「判断」に書き換える
作業の名前に「何を決めたか」と「何が変わったか」を足すだけで、担当範囲が伝わる書き方になります。
運用の職務経歴書でいちばん多いのは、担当業務が単語で並んでいる状態です。同じ「監視・障害対応」でも、人によってやっていることはまったく違います。その違いが読み取れる形にします。
| よくある書き方 | 足す視点 | 書き換えたあと |
|---|---|---|
| サーバーの死活監視、アラート対応 | アラートの中身をどう扱ったか | 毎日鳴っていたディスク使用率のアラートを調査し、一時ファイルの削除を定期実行に変更。月100件近いアラートのうち、対応不要なものを9割減らした |
| 障害の一次対応 | 切り分けの手順を誰が決めたか | 発生頻度の高い3事象について、確認するログと切り分けの順番を手順書に追記。二次対応へ引き継ぐまでの時間を平均で半分程度に短縮した |
| 定常作業（バックアップ確認、ログ収集） | 手作業のどこを減らしたか | 毎朝30分かかっていた確認作業をシェルスクリプトにまとめ、結果をチャットへ通知する形に変更。月あたり約10時間の手作業をなくした |
| 問い合わせ対応 | 同じ問い合わせを減らしたか | 問い合わせ内容を分類し、上位5件をFAQとして社内Wikiに整備。同種の問い合わせが月20件から5件程度に減った |
| ミドルウェアのバージョンアップ | 検証と切り戻しをどう設計したか | 検証環境で影響範囲を確認したうえで手順と切り戻し条件を先に決め、無停止で本番に適用。障害なく完了した |
担当業務のNG / GOOD
・サーバーの監視、アラート対応
・障害の一次対応、エスカレーション
・バックアップの確認、ログの管理
・問い合わせ対応、手順書の作成
Webサービス（サーバー約40台）の24時間運用を、4名の当番体制で担当。
・監視・障害対応：頻発していたディスク使用率のアラートを調査し、一時ファイルの定期削除に切り替えて対応不要なアラートを9割削減。よく起きる3事象の切り分け手順を手順書に追記し、二次対応への引き継ぎ時間を短縮。
・定常作業の改善：毎朝30分の確認作業をスクリプト化し、結果をチャットに通知する形へ変更（月あたり約10時間の手作業を削減）。
・問い合わせ対応：内容を分類して上位5件をFAQに整備し、同種の問い合わせを月20件程度から5件程度へ。
NGの方も嘘は書いていませんが、誰が担当しても同じ文章になります。GOODは、規模（40台・4名）と、自分が決めたこと、その結果が入っています。数字の作り方は実績を数字で書く方法もあわせて読んでください。
運用保守で数えられる数字
売上や利用者数がなくても、運用には数えられるものが多くあります。減ったもの・速くなったものが特に伝わります。
規模
サーバー台数、対象サービス数、監視項目数、ユーザー数の規模、当番の人数と交代の頻度
件数
月あたりのアラート件数、インシデント件数、問い合わせ件数、リリース・変更作業の回数
減らしたもの
対応不要なアラート、手作業の時間、同種の問い合わせ、障害の再発件数
速くなったもの
一次対応までの時間、復旧までの時間、定常作業の所要時間、リリース作業の時間
保った水準
稼働率の運用基準、対応時間の約束（何分以内に一次回答）、期間中の重大障害の発生件数
広げた範囲
自分が単独で対応できるようになった領域、引き継いで任せられるようにした作業の数
数字が残っていないときの概算
- 1
1回の時間を思い出す
朝の確認作業は1回30分。長かった日を基準にせず、いつもの時間で
- 2
回数を掛ける
平日のみなら月20回。30分 × 20回 = 月10時間
- 3
人数を掛ける
2人で当番制なら、チーム全体では月20時間ぶんの作業
- 4
幅を付けて書く
「月10時間程度（チームでは約20時間）の手作業を削減」と書く
3つの型で1件書いてみる
運用の実績は「安定させた」「速くした」「減らした」の3つに収まります。まずは1つの型で1件書いてみてください。
① 安定させた
週に1〜2回発生していたバッチの遅延について、実行時間のログを2ヶ月分集計して処理量が増える曜日を特定。実行順序の入れ替えと並列数の見直しを提案し、遅延の発生をほぼなくした（発生後の再実行対応も不要に）。
② 速くした
障害時の連絡と確認が口頭中心で時間がかかっていたため、発生から一次回答までの流れをテンプレート化し、確認するログの場所を手順書に明記。一次回答までの時間を平均30分程度から10分程度に短縮した。
③ 減らした
毎月の定期作業（証明書の期限確認、ログの退避、容量レポート作成）を棚卸しし、スクリプトと定期実行に置き換え。3人で分担していた月次作業を1人30分程度で終わる形にした。
どの型でも、「状況 → 自分が調べたこと・決めたこと → 変わったこと」の順で書きます。自分から提案した場合はそう書き、指示を受けて進めた場合は無理に手柄にしないでください。面接で聞かれたときに説明が一致していることの方が大事です。
設計・構築に近い経験を拾う
構築や設計の求人に応募したい場合は、運用の中にある「作った経験」を前に出します。
運用を長く担当していると、実は構築に近い作業を少しずつ経験しています。小さくても「作った」「決めた」経験は、運用の作業より先に書いた方が読まれます。
検証環境の構築
本番と同じ構成を自分で立てた経験。手順を作った、構成を決めたなら書ける
サーバーの増設・リプレース
台数追加、OSやミドルウェアの入れ替え、移行手順の作成と切り戻しの設計
監視の設計
何を見るか、しきい値をいくらにするか、誰に通知するかを決めた経験
スクリプト・自動化
シェル・Python・Ansible・Terraformなど、自分で書いたものと解決した課題
原因調査でのコード読み
アプリのログやコードを追って原因を特定した経験は、開発への接続点になる
手順の標準化
ばらついていた運用を統一し、他の人が同じ品質でできる状態にした経験
職務要約でも、応募先に合わせて並べ替えます。運用の求人なら安定運用の実績を先に、構築やSREの求人なら自動化と設計の経験を先に置いてください。職種ごとの要点は職種別・職務経歴書の書き方、SES・客先常駐で案件が多い場合の整理は案件が多いSESの職務経歴書にまとめています。
材料が揃ったら、そのまま書き始めてください。作成ツールには運用保守向けの記入例が入っているので、空欄を前に止まらずに進められます。
よくある質問
Q.障害の件数や稼働率は、書いても問題ありませんか？
公開されていない数字は、そのままの値では書かないでください。「月に数十件の一次対応」「稼働率は99.9%の基準で運用」のように、幅を持たせたり運用基準として書けば伝わります。判断に迷う数字は自社の営業担当や上長に確認するのが確実です。面接で根拠を聞かれて説明できる範囲に留めるのも大事です。
Q.監視やヘルプデスクの経験だけでも、開発の求人に応募できますか？
応募そのものは問題ありませんが、開発経験を求める求人では書類の通過率は下がります。通すには、運用の中で自分が書いたスクリプトや手順の自動化、検証環境の構築、障害の原因調査でコードを読んだ経験など、開発に近い部分を前に出すことです。経験がない部分は「これから学ぶ」と書くより、実際に手を動かした小さな成果物を1つ添える方が伝わります。
Q.数字がまったく残っていない場合はどうすればいいですか？
概算で構いません。「1回30分の作業を月20回、2人で担当」なら、削減できた時間は見積もれます。「約」「程度」を付けて幅で書き、計算の根拠を自分の中で持っておいてください。逆に、思い出せないものを具体的な数字にして書くのは避けます。面接で崩れます。
Q.夜勤や当番の経験は、マイナスに見られませんか？
それ自体がマイナスになることはありません。24時間の運用を回した経験は、障害時の判断や手順の整備ができる根拠として読まれます。ただし、次の職場で夜勤を避けたい場合は、希望条件としてはっきり伝えてください。書類では経験として書き、条件は希望欄や面接で伝えるのが整理しやすい形です。
Q.作った手順書や自動化スクリプトは、成果物として見せられますか？
業務で作ったものは会社の資産で、社外に出すと契約違反になり得ます。GitHubなどに上げるのは避けてください。書類では「何を解決するために、どういう仕組みにしたか」を一般化して書けば十分です。手元で作り直したものを公開用に用意するなら、業務の内容が特定できない形にしてから公開してください。
