「運用保守はずっとやる仕事じゃない」という呪縛
運用保守に配属された当初、正直に言うと「ここは通過点だ」と思っていた。
早く設計・構築に移りたい。上流に行きたい。でも、どうすれば行けるのかが全然わからなかった。
異業種からIT転職した自分には、設計書を書いた経験もなければ、構築を主導した経験もない。「上流に行きたい」という気持ちはあっても、手段が見えなかった。
結果として、運用保守を3年やったあとフリーランスになり、今は設計・構築案件に入っている。
その転換は、転職でも資格取得でもなかった。今の現場の中でやれることを3つ変えただけだった。
ステップ①：設計書を「読む」習慣をつける
運用保守の仕事をしていると、設計書に触れる機会は意外と多い。
サーバ構成図、ネットワーク図、パラメータシート。これらは「なんとなく存在する書類」として扱いがちだが、上流に転換したいなら毎日の定例作業と設計書を結びつける習慣が効く。
具体的にやったこと：
- バックアップ確認のたびに「このサーバの用途は何か」を設計書で確認する
- 監視アラートが出たとき「なぜこのアラートが設定されているか」を構成図から読む
- 手順書の背景にある「なぜこの順番なのか」を設計意図から逆算する
これを続けると、設計書を「読む」のではなく「使う」感覚になっていく。
上流SEが書いたものの意図が読めるようになると、上流側から見ても「話が通じる人」に見える。
ステップ②：障害の根本原因を「文書化」する
運用保守で「直った」で終わらせない人間が、上流に転換できる。
これは自分が上流案件に入って確信したことだ。
障害が起きたとき、多くの人は「対処方法」を記録する。でも上流で必要なのは「なぜ起きたか」と「何が設計として防げたか」だ。
自分が運用保守時代にやっていたこと：
- 障害対応後、必ず「根本原因・再発防止策・設計へのフィードバック」を個人ノートに書く
- 「この障害は設計段階でどうすれば防げたか」を毎回1行だけ考える
- 蓄積したノートを、次の現場での提案材料として使う
これは誰にも評価されない地味な作業だ。でも3年後に「運用経験をベースにした設計提案」ができる土台になる。
ステップ③：お客さんの「業務」を理解する
運用保守SEが上流に転換できる最大の武器は、「このシステムが何のビジネスを支えているか」を知っていることだ。
設計・構築専門のエンジニアは、システムは作れる。でも「夜間バッチが毎日3時間かかっていて、月次処理が間に合わないことがある」という業務上の現実を知らないことが多い。
運用保守SEはその現実を、日々の仕事の中で見ている。
これを言語化して提案できると、上流案件の評価が変わる。
自分がフリーランスで初めて設計案件に入ったとき、お客さんに言われた言葉がある。
「運用経験がある設計者は、業務の制約を知っている。それが一番ありがたい」
運用保守は、上流への「最強の下準備」だ。
まとめ：転職しなくていい、今の現場が訓練場
3つのステップをまとめると：
- 設計書を毎日の作業と結びつけて読む
- 障害の根本原因を文書化して蓄積する
- お客さんの業務を言語化して提案材料にする
どれも「今の現場」の中でできる。資格取得も転職活動も必要ない。
自分が上流に転換できたのは、運用保守時代にこの3つを続けたからだ。
現場のリアルな体験・ノウハウはnoteでも発信しています。