去年より速くコードは書けるようになったのに、エンジニアとして前に進んでいる感覚だけが薄い。
SESエンジニアとして5年ほど、業務システムの現場を4社ほど渡り歩いてきましたが、この妙な手応えのなさは、現場が変わってもなかなか消えませんでした。
厚生労働省の調査でも自己啓発を行っている正社員は4割強にとどまっており、足りない分を自力で埋め続けられる人ばかりではないようです。
今回は、SESでスキルが身につかないと感じる正体が何だったのかと、今いる現場で経験が積めるかどうかを見分ける観点を、実体験からお伝えします。3社目では、同じ現場で、身につかない時期と身についた時期の両方がありました。
この記事で分かること
- 「スキルが身につかない」という感覚の正体が、作業量ではなくどこにあるのか
- データ移行の時期に身につかなかったことと、保守改善の時期に身についたこと
- 同じ現場でも、担当の中身で積めるものが変わる理由
- 4社目の今の現場で、3社目の経験のうち役立っているもの
- 今の現場で経験が積めるかを見分ける4つのチェックポイント
目次
SESでスキルが身につかないと感じる正体
結論増えないのは作業量ではなく、自分で決めて結果を引き受けた経験です。それは担当の中身で変わります。
私が感じていた「身につかなさ」は、仕事の量が足りないことでも、簡単すぎる作業ばかりだったことでもありませんでした。現場でこなす作業そのものは年々増えています。それなのに、「自分で決めて、その結果を引き受けた」という経験だけが、同じペースでは積み上がってくれない時期がありました。
なぜこの構成なのか、なぜこの粒度でテーブルを分けたのか。そうした設計の検討に自分が加わる機会は、少なくとも移行の時期にはありませんでした。
ただ、これは現場全体に当てはまる話ではありませんでした。同じ現場の中でも、担当が「決まったことを実行する役」の時期と、「自分で調べて設計して完結させる役」の時期とで、積み上がるものは大きく違いました。
転職サイトや業界メディアの記事を読むと、「SESは単純作業しか任されないからスキルがつかない」という説明をよく見かけます。私の実感とは少しずれます。任される作業が単純だったかどうかより、担当の中身に判断が含まれているかどうかのほうが、積み上がるものを分けていました。
データ移行の時期は、手順書を実行する役でした
結論3社目の前半の約1年は、手順書に沿って移行作業を実行する役でした。作業量は多かったものの、設計や構造の理解、コードを書く経験は積みにくい時期でした。
3社目は二次請けで、金融系のWebサイトの案件でした。前半の約1年は、旧システムの顧客・契約データを新システムへ移すデータ移行で、リハーサルと本番切り替えを実行する役を担当しました。
3社目のデータ移行の規模。
規模は小さくありません。移行作業では、件数や値の不一致、作業の時間超過、手順書の誤りや漏れといった問題が全部ありました。
私の場合
この時期は、手順書に沿って移行作業を実行する役でした。決められた手順を、決められた順に、間違えずに実行する側でした。
作業量は多く、夜間や休日の対応もありましたが、振り返ると、身につかなかったと感じることがはっきりあります。システム全体の設計や構造の理解、そしてコードを書く経験です。
手順書に沿って実行していると、目の前の作業は進みますが、システム全体がどういう構造で、なぜそう作られているのかを理解する機会は多くありませんでした。
コードを書く機会も多くありませんでした。作業は忙しかったのに、自分で決めたことが成果物に残る感覚は薄い。これが、同じ現場にいながら「身につかなさ」を感じていた時期の正体でした。
保守改善の時期は、判断を含む担当でした
結論後半の約1年半は、依頼ごとに設計から実装・テストまでを担当できました。判断を含む経験が積み上がった時期です。
後半の約1年半は、同じWebサイトの保守改善でした。フロントとサーバー側の両方で、改修依頼の対応、障害調査、不具合修正を担当しました。
担当は、依頼ごとに割り振られました。特定の画面や領域に固定されることはなく、依頼の内容ごとに、設計から実装・テストまでを一人で完結させることも、チームで分担することもありました。
保守改善で関われた工程
- 依頼内容の確認と、要件の整理
- 改修の設計と、設計書の更新
- 実装
- テスト(単体・結合)と、証跡の作成
しかも、書いたコードは毎回レビューを受けました。移行期とは違い、自分で決めたことが成果物に残り、指摘を受けて直す、というサイクルが回りました。
この時期に身についたこと
この時期に、身についたと感じるものを並べます。
保守改善で身についたこと
- 影響範囲の調査の進め方小さな改修でも、影響範囲の調査に1件あたり半日から1日かかりました。何を調べるかの型が、調べるたびに増えていきます。
- 障害の原因特定原因の特定に時間がかかる障害もありました。再現させ、ログを読み、切り分けて絞り込む手順が身につきました。
- 設計から実装・テストを一人で完結する力依頼1件を、最初から最後まで自分で引き受ける経験です。
- レビューでの指摘を反映する習慣毎回レビューを受けることで、指摘を受けて直すことが当たり前になりました。
保守改善の現場で、リリース手順が重く、証跡やドキュメントが多いことも、実務として身につきました。
こうした力は、地味ではありますが、どの現場でも通用します。ゼロから作る機会よりも、他人が書いたコードに手を入れる機会のほうが多い受託開発では、実用的な能力だと思っています。
4社目の今の現場で役立っていること
3社目の経験のうち、4社目の現場で実際に役立っているものは、次の3つです。
- 実装やテストの手法 保守改善で毎回レビューを受けて身についたやり方が、今も土台になっています
- 影響範囲の調査の型 改修の前に、どこまで調べるかの型が、そのまま使えています
- リリース手順・証跡の作り方 本番反映の手順や、証跡の残し方です
4社目は、今は自社の役職上の管理職になり、手を動かしつつ3〜5名のメンバーを見ています。判断を含む経験は、移行期ではなく、保守期に積んだものが、今の仕事の土台になっています。
同じ現場でも、担当の中身で積めるものが変わる
3社目の前半と後半を並べると、違いがはっきりします。
| データ移行(約1年) | 保守改善(約1年半) | |
|---|---|---|
| 担当の形 | 手順書に沿って実行する役 | 依頼ごとに割り振られ、設計から完結することもある |
| 判断の余地 | 手順書に沿った実行が中心 | 調査・設計・実装の方針を自分で決める |
| レビュー | — | 書いたコードを毎回レビューされる |
| 身につかなかったこと | システム全体の設計・構造の理解、コードを書く経験 | — |
| 身についたこと | — | 影響範囲の調査、障害の原因特定、一人で完結する力、指摘の反映 |
同じ現場、同じ会社、同じ客先でも、担当の中身が変わると、積み上がるものが変わります。「SESだからスキルが身につかない」のではなく、担当が判断を含むかどうかが、分かれ目でした。
ポイント: 現場を変えなくても、担当が変わるだけで積めるものは変わります。移行のような「実行する役」の時期に身につかなさを感じたとしても、それを現場全体、あるいはSES全体の問題だと受け取る必要はありません。
逆に、保守のような「判断を含む役」の時期でも、レビューや質問の機会がなければ、積み上がるものは減ります。担当の中身と、フィードバックの有無の両方を見ます。
客先常駐で担当範囲が切り出される仕組み
結論客先常駐では、担当が契約の単位で切り出され、決定そのものが上から降りてくることが多いと感じています。
私が入ってきた現場の多くは、契約がある範囲を切り取る形で結ばれていました。自分に割り当てられるのは、その契約の範囲内の帯です。
二次請け・三次請けとして入る案件では、使う技術はもちろん、開発の進め方や品質基準まで、上位の会社の決定として降りてきます。保守改善でも、依頼内容の確認と改修の設計には関われましたが、新規の大きな要件定義や基本設計は、契約の外側にあることが多いと感じています。
もう一つ、現場に長く居続けられないことも影響します。私が現場を変えてきた理由は、自分の意思による転職活動ではなく、そのほとんどが契約終了・案件終了による移動でした。
一つの現場に慣れてきたころに案件が終わり、次の現場では新しい業務や環境を覚え直すところから始まります。浅いところで区切られ続けるので、深い部分に降りる前にリセットがかかる。この繰り返しが、「何年やっても同じところにいる」という感覚を強めていたと思います。
フレームワーク固有の知識は、持ち越せるとは限りません
3社目の保守改善で触ったフレームワークは、ObjectWorksでした。
特定のフレームワークの現場でも、判断を含む経験は積めます。ただ、そのフレームワーク固有の知識が、次の現場でどこまで通用するのかは、別の問題として残ります。技術が古い現場の場合については、別の記事にまとめています。
今の現場で経験が積めるか見分ける4つのチェックポイント
では、今いる現場が自分にとってどういう場所なのかを、どう判断すればいいのか。私が現場を経験するたびに確認するようになった観点を挙げます。参画してから1〜2ヶ月あれば、だいたい答えが出ます。
今の現場で確かめる4つのこと
- 1. 自分の担当に、判断を含む余地があるか 手順書やチケットの指示を実行するだけか、調査・設計の方針を自分で決める部分があるか
- 2. 書いたものがレビューされるか 成果物に対して指摘を受け、直す機会があるか。レビューがない現場は、積み上がりにくい
- 3. 仕様の「なぜ」を聞ける相手が現場の中にいるか 背景を語れる人が誰もいない現場は、判断の経験を取りにくい
- 4. 自分の判断が採用された例が、参画後にひとつでもあるか 小さな実装方針でも構わない。ゼロのまま数ヶ月が過ぎる現場は、その後も変わらない可能性が高い
1と2は、担当の形を見る観点です
1つ目は、担当を渡されたときに、どこまでが指示で、どこからが自分の判断かを見ます。移行期の私の担当は、手順書の範囲に判断が収まっていました。保守期の私の担当は、依頼の内容の確認から設計まで、判断を含んでいました。
2つ目のレビューは、積み上がり方に直結します。自分の判断が、他人の目に触れ、指摘され、直る。この往復があるかどうかで、同じ作業量でも積み上がるものが変わります。
どちらも、参画した直後の数週間で分かります。
3つ目は、決定の理由が残っているかどうか
3つ目の「仕様のなぜを聞ける相手がいるか」は、少し見えにくい観点です。判断材料になるのは、質問したときの返事です。返ってくるのが仕様書の該当箇所の引用だけなのか、それとも「この項目はこういう業務上の事情があるのでこうしています」という説明が添えられるのか。
前者しか返ってこない現場は、背景を知っている人が現場の中にいない可能性があります。決定の理由が現場に残っているかどうかで、同じ工程を担当していても得られるものが変わります。
4つ目が一番ごまかしが効きません
このうち一番当てになると感じているのは、4つ目です。1から3までは現場の建付けの話なので、恵まれていれば良い、程度のものです。4つ目だけは、実際に自分の言ったことが通ったという事実なので、ごまかしが効きません。
規模は問いません。小さな実装方針でも、自分が出した案が現場の成果物に一行でも残った、という事実があるかどうかです。この一回があるかないかで、次の現場で口を開くときのハードルはずいぶん変わります。
「外れ」の現場を引いたと分かったら
正直に書くと、このチェックで「積みにくい現場だ」と分かったところで、私にできることはほとんどありません。現場を選ぶ権利は基本的にこちら側にないからです。
現場の当たり外れは、私の実感では運次第です。経験を積むほど当たりを引きやすくなる、という手応えは今のところありません。ただ、3社目のように、同じ現場の中でも担当が変わることはあります。現場を変えられないときは、担当の中身を変える(判断を含む依頼を引き受ける、レビューを受ける)ことが、現実的な選択肢になります。
積みにくい現場だと早めに分かっていれば、そこで足踏みしている自分を責めずに済みますし、期待の置き場所を現場の外に移すという選択もできます。
現場を選べない立場でやってきたこと
現場が選べない以上、私が実際にやってきたのは、業務外で埋めるという地味な方法です。会社の教育制度やスクールはほとんど使っていません。使う機会があまりなかった、というのが実情です。
基本情報技術者も独学で取りました。現場での実感は、別の記事に書いています。
厚生労働省の令和7年度「能力開発基本調査」によれば、自己啓発を行った労働者の割合は次のとおりです。
自己啓発を行った労働者の割合。正社員でも半数以上は、自己啓発を行っていない計算になります。
SESに限った数字ではありませんが、「足りない分は自分で埋める」という前提が、実際にはかなり成立しにくいものだということは押さえておいたほうがいいと思います。
そのうえで、自分の中で効いたと感じているのは、勉強の内容そのものより「現場で取れないものを、意識して外で取りに行く」という切り分けのほうでした。現場で実装量が積めているなら、外で積むべきは実装量ではありません。
設計の意図を考える経験や、自分で技術を選んでみる経験を、小さくても自分の手で作るしかない。個人開発でも、既存の設計を写経して「なぜこうなっているか」を自分なりに言語化してみるだけでも構いません。
一人で進めると、書いたものに誰からも意見をもらえないのが弱点です。そこを補う手段としては、講師に個別で見てもらえる個人レッスン形式のスクール(Winスクール
など)もあります。独学で行き詰まったときの候補として挙げておきます。
また、29歳以下で、関東・関西・東海でIT系の職場を探し直したいなら、学習サポートと就職支援を無料で受けられるサービス(ウズウズIT
など)もあります。現場を変えるかどうかを決める前に、外から自分の経験を見てもらう場として挙げておきます。エンジニアとして1年以上の実務経験があり、39歳以下で勤務地が一都三県か大阪なら、経験者向けの転職エージェントのユニゾンキャリアで、市場価値や年収の相場を聞く手もあります。
とはいえ、これを「工夫すれば大丈夫」という話に着地させるつもりはありません。業務外の時間で埋められる量には限りがありますし、忙しい案件に入っていれば、そもそもその時間が取れません。
構造的に取れないものは取れない、というのが前提で、そのうえでどこを諦めてどこを取りに行くかを決める、という順番だと考えています。
「身につかないなら辞めるべき」に飛びつく前に
この手のテーマを検索すると、ほとんどの記事が「自社開発企業へ転職を」という結論に着地します。転職エージェントが運営しているメディアが多いので、当然といえば当然の流れです。
自社開発に移れば技術選定に関われる可能性が上がるのは事実だと思います。ただ、その結論に飛びつく前に、確認しておいたほうがいいことがあります。今感じている物足りなさが、環境の問題なのか、担当の中身の問題なのかの切り分けです。
3社目では、同じ現場の中で、身につかない時期と、身についた時期の両方がありました。現場を変えていないのに、担当が変わっただけで、手応えが変わったわけです。
自分を責める話ではありません
身につかないと感じる時期があるのは、能力が足りないからではなく、担当が「実行する役」だった、という構造の問題であることが多いです。
ただ、担当の中身は、依頼を引き受ける、質問する、提案する、といった動きで変わる余地があります。動いてみないと、環境の問題なのか担当の問題なのかは判別できません。
環境を変える前に確認しておきたいこと
- 今の担当に、自分で判断する部分があるか。なければ、判断を含む依頼を引き受けられるか
- 書いたものがレビューされているか。されていなければ、レビューを頼めるか
- 今の現場で積み上がっているもの(実装速度、読解力、影響範囲の調査など)を過小評価していないか
- 移った先で何を取りに行くのかが、技術名ではなく経験の種類で言えるか
私は今も現役でSESの現場にいます。辞めるべきかどうかについて、他人に言えるほどの答えは持っていません。
ただ、判断の経験が担当の中身で決まるという事実を知った上で働くのと、知らずに「自分の能力が足りないのかもしれない」と思いながら働くのとでは、精神的な負担は違ってくると思います。
まとめ
SESでスキルが身につかないと感じる原因は、作業が単純だからでも、量が足りないからでもありませんでした。自分で決めて結果を引き受ける経験が、担当の中身によって積めたり積めなかったりする、という構造が原因です。
3社目では、データ移行の時期(手順書を実行する役)には、システム全体の設計・構造の理解とコードを書く経験が積めず、保守改善の時期(依頼ごとに設計から完結する役)には、影響範囲の調査、障害の原因特定、一人で完結する力、指摘を反映する習慣が積み上がりました。
この記事の要点
- 手応えのなさの多くは、努力不足ではなく、担当が「実行する役」か「判断を含む役」かの違いから来ている
- 今いる現場は、この記事で挙げた4つの観点、とくに「自分の判断が採用された例が参画後にひとつでもあるか」で見分ける
- 保守改善のように、判断とレビューがある担当で積んだものは、4社目の今の現場でも役立っている
そこから先、環境を変えるかどうかは人それぞれです。私自身は現場を選べる立場にないので、取れないものは取れないと割り切った上で、担当の中身を変えられるところは変え、外で何を取りに行くかを決める、という付き合い方をしています。
少なくとも、伸びていない気がするのは自分の努力不足だ、と結論づけるのは早すぎます。手に入りにくいものが、担当の中身や契約の位置で決まっている、というだけの話であることのほうが、私の見てきた範囲では多いです。




