客先常駐5年目、運用保守から自社開発への転職に効く翻訳術

「運用保守しかやってきていないので、自社開発は無理だと思います」——客先常駐で5年目を迎えたタイミングの面談で、こう切り出すエンジニアに私はここ数年、何度も会ってきました。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、実務経験が監視や保守で止まっている人ほど、経験の量より経験の書き方で損をしているケースが目立ちます。今回は、客先常駐5年目という節目で運用保守から自社開発への転職を考える人に向けて、必要な実務経験の目安と、詳細設計の経験がほぼない人でも書類選考を通す職務経歴書の翻訳の仕方を、実例を交えてお伝えします。

目次

1. 客先常駐5年目、運用保守から自社開発への転職はもう遅いのか
2. 運用保守が「やめとけ」「経験にならない」と言われる理由
3. 監視・保守・設計構築、3段階で経験の価値は変わる
4. 転職に必要な実務経験の目安、年代別の相場感
5. 運用保守の経験は何年で見切りをつけるべきか
6. 運用保守の経験を自社開発向けに翻訳する対応表
7. 職務経歴書のBefore/After実例
8. 詳細設計の経験がほぼゼロでも書ける、掘り起こしの視点
9. SESに在籍したまま設計経験を積む、案件の見つけ方
10. 相談事例、監視ログの経歴書を前に立ち止まったDさんの5年目
11. SESから自社開発への転職で失敗しがちな3つのパターン
12. 30代でも手遅れではない、動き出すタイミングの見極め方
13. よくある質問に答えます
14. まとめ、5年目は「経験不足」ではなく「翻訳不足」で止まっている

客先常駐5年目、運用保守から自社開発への転職はもう遅いのか

5年目という年次は、SESの現場では中堅と呼ばれ始める頃です。案件によっては後輩の面倒を見る立場にもなりますが、担当業務自体は1年目からほとんど変わっていない、という声を面談の場で何度も聞いてきました。監視画面を眺め、決まった手順でアラートに対応し、月次のパッチ適用をこなす。技術力が伸びていないわけではないのに、実装や設計の経験として語れる材料が積み上がっていない感覚だけが残ります。

この焦りは、周囲の同期や後輩が自社開発企業に転職していく様子を見たときに一気に強まります。5年という数字自体は転職市場でマイナスに働きませんが、その5年間に何を判断してきたかを言葉にできていないと、書類選考の段階で「経験年数の割に実務内容が薄い」と読まれてしまいます。

私が見てきた限り、客先常駐5年目で運用保守から自社開発への転職を考える人の多くは、経験が不足しているのではなく、経験を自社開発の採用担当者が理解できる言葉に置き換える作業をしていないだけです。この記事の後半で扱う「翻訳」という視点を持てるかどうかが、書類選考の通過率を大きく左右します。

もう一つ付け加えると、5年目という節目は「マンネリを自覚しやすい」タイミングでもあります。1〜2年目は覚えることが多く忙しさに紛れますが、3〜4年目を過ぎると業務の大半が既視感のあるものになり、成長の実感が薄れていきます。この感覚自体は自然なもので、焦って結論を急ぐ必要はありませんが、放置すると次の節目である10年目まで同じ状態が続きかねない、というのが多くの相談を見てきた実感です。

運用保守が「やめとけ」「経験にならない」と言われる理由

運用保守という業務が転職市場で厳しく見られがちなのには、はっきりした理由があります。相談者からよく聞く不満と、選考側の見方を並べると次のようになります。

これらはどれも事実で、私も否定しません。ただし、この一覧だけを見て「運用保守の経験は転職で使えない」と結論づけるのは早計です。実際には、運用保守という括りの中にも経験の質にかなりの差があり、その差を見分けずに一括りにしてしまっていることが、選考で損をする一番の原因になっています。

インターネット上のコラムでは「運用保守は底辺の仕事」といった強い言葉で括られることもありますが、現場で選考を見てきた立場から言うと、それは職種そのものへの評価というより、業務内容を言語化できていない職務経歴書への評価だと私は見ています。同じ運用保守という肩書きでも、判断の中身を説明できる人とできない人とでは書類選考の通過率に明確な差が出るというのが、添削を重ねてきた実感です。

監視・保守・設計構築、3段階で経験の価値は変わる

運用保守と一口に言っても、担当している作業のレベルによって評価のされ方はまったく違います。私が職務経歴書を見るときに実際に分けている3段階を表にしました。

多くの人は自分の業務を「監視」の枠でしか語っていません。実際には一次対応や改善提案の経験を持っているのに、職務経歴書には「監視、障害対応、手順書更新」と並列で書いてしまい、担当者から見ると全部が同じレベルの定型作業に見えてしまうのです。3段階のどこに自分の実務が当てはまるかを分けて書くだけで、読み手の印象は変わります。

客先常駐5年目まで来ていれば、監視だけを続けている人はむしろ少数派で、大半は一次対応レベルの経験を最低限持っています。問題は、一次対応と設計構築に近い保守の境目にある業務——原因分析や改善提案——を、自分では「たいしたことをしていない」と過小評価してしまう点です。この境目にある経験こそ、自社開発企業が最も知りたがっている部分だと、添削のたびに感じます。

転職に必要な実務経験の目安、年代別の相場感

求人票の必須要件を見ていると、応募のハードルは年代によって変わっているのが分かります。あくまで私が日々の書類選考のフィードバックややり取りの中で感じている相場観であって、公式な基準ではありませんが、20代後半であれば実装経験2〜3年程度、30代以降であれば詳細設計に近い経験が3年程度あるかどうかが、書類選考の通過ラインとして意識されやすい印象です。

客先常駐5年目の相談者の多くは、この年数条件自体はすでにクリアしています。問題は「詳細設計に近い経験」の有無を、自分でも把握できていない点にあります。障害の原因分析や手順書の改訂を「設計」だと認識していないため、職務経歴書に書く発想すら浮かばないケースがほとんどです。

ポイント： 選考で最初に聞かれるのは経験年数ではなく、その年数の中で何を自分の判断で決めてきたかです。年数を満たしているのに書類が通らない人は、たいてい判断の中身を書けていません。

この相場感は企業の規模やフェーズによっても幅があります。社員数十名規模の自社開発企業では、一人が担当できる範囲の広さを重視するため、運用保守で複数の業務を横断してきた経験がそのまま評価されやすい傾向があります。一方、社員数百名を超えるメガベンチャーでは職種の分業が進んでいる分、詳細設計や実装の経験がより明確に求められる印象です。応募先の規模感によって、翻訳した経験のどこを前面に出すかも変わってきます。

運用保守の経験は何年で見切りをつけるべきか

「あと何年運用保守を続けたら手遅れになりますか」という聞かれ方をされることもよくありますが、私はこの質問自体の前提を少しずらして答えるようにしています。見切りをつけるべきかどうかを決めるのは経過年数ではなく、直近1年で担当業務に変化があったかどうかです。1年前と比べて任される範囲が広がっている、判断を求められる場面が増えているのであれば、その環境にもう少しとどまって経験を積み増す選択も十分あります。

逆に、1年前とまったく同じ業務を同じ手順でこなしているだけなら、環境を変えない限り翻訳できる材料はこれ以上増えません。5年目という数字は、そうした振り返りをする一つのきっかけに過ぎず、絶対的な期限ではないと私は考えています。

運用保守の経験を自社開発向けに翻訳する対応表

ここからが今回の本題です。運用保守の実務は、言葉を変えるだけで自社開発企業が求めるスキルに近づきます。私が添削で実際に使っている対応表を挙げます。

この作業は、事実を大げさに書き換えることではありません。すでに自分がやってきた判断を、選考側が理解できる言葉に置き換えるだけです。「監視をしていました」で終わらせず、その監視をどんな基準で設計し、どんな場面で基準を見直したかまで踏み込んで書くと、途端に自社開発向けの職務経歴書らしくなります。

職務経歴書のBefore/After実例

実際にあった添削の一例です。Before(最初の職務経歴書)は、こう書かれていました。「決済システムの運用保守業務を担当。監視、障害の一次対応、手順書更新を実施」。事実として間違ってはいませんが、これでは担当者に何も伝わりません。

After(書き直した後)は、「月間平均3件発生していた障害のうち再発率の高かった上位2件について原因分析を行い、監視の異常検知の閾値見直しと手順書の改訂を提案・実装。半年間で当該障害の再発をゼロに抑えた」という書き方に変えました。件数と期間という具体的な数字を入れ、原因分析から改善提案、結果までの一連の判断を書くことで、単なる保守作業ではなく課題解決のプロセスとして読めるようになります。

詳細設計の経験がほぼゼロでも書ける、掘り起こしの視点

「対応表は分かったが、そもそも改善提案なんてしたことがない」という相談も少なくありません。その場合でも、掘り起こせる材料はたいてい見つかります。

例えば「毎回目視で確認していたログチェックを、簡単なシェルスクリプトで自動化した」という程度の経験でも、業務改善のために自分で仕様を考え、実装し、運用に乗せたという一連の流れが含まれています。これは立派な設計と実装の経験です。誇張して書く必要はなく、実際にあった判断のプロセスを具体的に書くことが重要で、この部分を盛ってしまうと面接で深掘りされた瞬間に崩れます。

私が添削で必ず確認するのは、「その判断をしたのは誰か」という点です。上司や客先の指示でやっただけの作業を自分の判断のように書いてしまうと、面接で経緯を聞かれたときに答えに詰まります。逆に、指示された作業の範囲内であっても、やり方を自分で選んだ部分——手順の順番を工夫した、確認項目を増やしたといった小さな判断——があれば、それは正直に「自分の判断」として書いて問題ありません。

後輩への手順書レクチャーや、客先担当者への状況報告の場で「なぜこの手順にしたのか」を説明した経験があれば、それも意思決定を人に伝えた経験として使えます。運用保守の中に眠っている「なぜ」を思い出す作業こそが翻訳作業の本体です。

SESに在籍したまま設計経験を積む、案件の見つけ方

書類の翻訳だけでは埋まらないほど、担当業務が本当に監視作業に限定されているケースもあります。その場合は、転職活動と並行して今の現場で設計に近い業務を取りに行く動き方も検討する価値があります。

現実的に効果があったのは、障害の再発防止策を「口頭で提案する」だけでなく、簡単な資料にまとめて客先の担当者や自社の営業経由で正式に提案する形にすることです。口頭の提案は記録に残らず、後から職務経歴書に書いても裏付けが弱くなりますが、資料として残しておけば「提案し、採用され、実装した」という一連の流れを具体的に語れます。案件によっては、この提案がきっかけで運用の改善プロジェクトに正式にアサインされ、詳細設計に近い作業を任されるようになった相談者も複数見てきました。

自社の営業に対しては、単に「別の案件に変えてほしい」と伝えるより、「運用の中でも設計要素のある業務を増やしたい」と具体的に希望を伝えるほうが、次の契約更新時に近い性質の案件を提案してもらいやすくなります。契約更新のタイミングと転職活動を合わせて考える視点は、別記事SES多重下請けと案件ガチャ、動き出すべきタイミングでも詳しく触れているので、あわせて参考にしてください。

現場の裁量が小さく、提案を出しても取り合ってもらえない案件もあります。その場合は、無理にその現場で設計経験を積もうとせず、書類の翻訳作業と並行して転職活動そのものを進めてしまう方が早いと私は判断しています。現場を変える交渉に時間を使いすぎて、気づけば5年目が6年目になっていた、という声も何度か聞いてきました。今の現場で経験を積み増す道と、今ある経験を翻訳して動く道の両方を、期限を決めて同時に検討しておくのが現実的です。

相談事例、監視ログの経歴書を前に立ち止まったDさんの5年目

深夜のアラート対応ログをそのまま貼り付けたような職務経歴書を前に、Dさん(31歳・経験5年)は「これのどこが経験になるのか分かりません」とつぶやきました。独立系SES企業に所属し、決済システムの運用保守チームに客先常駐で5年目。担当は監視・障害の一次対応・手順書更新が中心で、開発と呼べる作業をした記憶はほとんどないという話でした。

自社開発のBtoB SaaS企業5社に応募した最初のラウンドでは、書類選考の通過はゼロ。職務経歴書には「監視、障害一次対応、手順書更新を担当」とだけ書かれていて、業務レベルの違いも、判断の中身もまったく見えない状態でした。志望動機の欄にも「裁量を持って開発に携わりたい」とだけ書かれており、これまでの経験と志望理由がまったく接続していないことも、通過しない理由の一つでした。

私が最初に聞いたのは、月にどれくらいの障害が発生し、そのうち自分が原因分析まで担当したものがいくつあるかという数字でした。Dさんは記憶をたどりながら、「月3件くらいの障害のうち、同じ原因で繰り返すものが2件あって、監視の閾値を見直す提案をしたことがある」と話し始めました。この時点で本人は気づいていませんでしたが、これはまさに設計構築に近い保守の経験です。

職務経歴書を先ほどの対応表に沿って書き直し、数字と判断のプロセスを盛り込んだ上で応募先を4社に絞り直しました。結果は3社が書類選考を通過し、うち1社の技術面接では「詳細設計の経験はありますか」という質問を受けています。Dさんは一瞬詰まりましたが、「詳細設計書を書いた経験はありませんが、監視の異常検知の閾値を見直す際には、過去半年分の障害履歴を分析して基準値を決め、実装後の効果も数値で検証しました」と、手元にある具体的な数字を使って答えました。この受け答えが決め手になり内定。提示年収は現職より45万円高い水準でした。Dさんが変えたのは経験の中身ではなく、経験の見せ方だけです。

SESから自社開発への転職で失敗しがちな3つのパターン

経験の翻訳ができて選考が進み始めると、今度は「どこでもいいから抜け出したい」という焦りが判断を狂わせることがあります。書類が急に複数社通り始めると、それまで年単位で止まっていた反動から気持ちが前のめりになり、条件確認を後回しにしたまま内定を承諾してしまう人を何人も見てきました。私が実際に見てきた失敗パターンを3つ挙げます。

客先常駐で単価と業務内容が一致しない不満を抱えている人ほど、この3つに陥りやすい傾向を私は繰り返し見てきました。単価と業務内容の乖離が続く案件ガチャの構造そのものについては前の章で触れた別記事でも扱っていますが、動機が「逃げ」だけになっていないかは、応募先を決める前に一度立ち止まって確認してほしいポイントです。

それぞれのパターンには共通点があります。激務ベンチャーへの逃げ込みは、裁量という言葉に安心してしまい、実際の労働時間や評価制度を面接で確認しないまま進んでしまうこと。「とりあえず辞める」転職は、内定が出た時点で判断基準を後付けしてしまい、入社後に「本当にここでよかったのか」と悩むこと。過度な理想化は、SNSやブログで見た自社開発企業の一部の事例を、業界全体の実態だと思い込んでしまうことです。いずれも、応募先を決める前に一次面接・二次面接で具体的な質問をぶつけて確認すれば、事前に避けられる失敗です。

30代でも手遅れではない、動き出すタイミングの見極め方

「客先常駐5年目でこの状態なら、30代になったらもう手遅れではないか」という相談もよく受けます。私の答えは一貫していて、手遅れかどうかを決めるのは年齢ではなく、経験を翻訳できているかどうかです。30代以降は詳細設計に近い経験を求められる場面が増えるのは事実ですが、5年目の時点で運用保守の中にある設計的な判断を言語化する習慣を持てていれば、30代に入っても不利にはなりません。

逆に、5年目で「まだ大丈夫」と先延ばしにして、判断の中身を振り返らないまま10年目を迎えると、翻訳できる材料そのものが薄いまま年齢だけが上がっていきます。動き出す基準として私が勧めているのは、直近1年の業務の中で「なぜその対応をしたか」を3つ以上具体的に説明できるかどうかです。説明できるなら翻訳の材料は揃っているので、あとは書類に落とし込む作業だけです。説明できないなら、まずは日々の業務で「なぜ」を意識するところから始める必要があります。

実際に相談を受けていても、30代前半までに動いた人と、30代後半以降に動いた人とで、選考結果に決定的な差があるとは感じていません。差が出るのは年齢よりも、経験を振り返る作業をどれだけ丁寧にやったかです。30代後半で相談に来た方でも、直近数年の障害対応を一つずつ棚卸しして言語化した結果、書類選考の通過率が目に見えて上がったケースを何件も見てきました。

翻訳した経験がそのまま年収に反映されるかどうかも気になるところだと思いますが、経験年数によって上がり幅に差が出やすいというデータをSESから自社開発企業への転職、年収は本当に上がるのか?にまとめています。無事に転職できた後も、客先常駐時代の働き方の癖が抜けず評価されない不安を抱える人は少なくないので、その対処法は客先常駐から自社開発フルリモートへ、評価されない不安の乗り越え方を参考にしてください。

よくある質問に答えます

ここまでの内容と重なる部分もありますが、相談の場でよく聞かれる質問を3つにまとめました。

まとめ、5年目は「経験不足」ではなく「翻訳不足」で止まっている

客先常駐5年目で運用保守しか経験していないという不安の多くは、経験の量ではなく、経験を選考側の言葉に翻訳する作業を一度もしていないことから生まれています。監視・一次対応・手順書整備という運用保守の実務は、書き方を変えるだけで自社開発企業が求めるトラブルシューティング力や設計的な判断力として読み替えられます。

詳細設計の経験がほぼゼロでも、障害対応の原因分析や手順書の改訂には設計に近い判断が含まれています。この判断の中身を思い出して言語化できるかどうかが、書類選考を通過できるかどうかの分かれ目です。年数が足りているのに書類が通らないと感じたら、まずは自分の業務を先ほどの対応表に当てはめ直してみてください。

上位の解説記事の多くは「必要な実務経験の年数」を示して終わっていますが、実際に選考を左右しているのは年数そのものではなく、その年数の中身をどこまで具体的に語れるかです。客先常駐5年目という節目で立ち止まっている人ほど、実は語れる材料をすでに十分持っています。5年間積み上げてきたものは、翻訳すれば思っている以上に武器になります。