IT土方とは？意味と由来や抜け出す方法をわかりやすく解説

客先常駐でテストや修正の作業を繰り返すなかで、自分の仕事は「IT土方」と呼ばれるものではないかと感じたことはないでしょうか。

IT土方という言葉は、多重下請け構造の末端で単純作業を担うエンジニアを指す俗称として使われてきました。ただし、そう呼ばれる状況に置かれているのは、スキルや努力が足りないからではありません。

公正取引委員会の調査でも、商流の深い位置にいる事業者ほど不必要な中抜きの存在を感じたと回答しており、最終下請けでは33.5%に達しています。どの工程を任され、どの商流で働くかは、個人の頑張りとは別のところで決まっているのが実情です。

この記事では、以下の内容を解説します。

• IT土方という言葉の意味と由来
• 多重下請け構造がIT土方を生む仕組み
• 自分がIT土方に当てはまるかを確認するチェックリスト
• このまま働き続けた場合に何が起きるか
• 商流の浅い企業へ移るための行動と実例

下流工程での作業に限界を感じているエンジニアの方に、状況を変えるための具体的な指針をお伝えしているので、ぜひ参考にしてください。

IT土方とは客先常駐で下流工程を担う下請けエンジニアを指す言葉

IT土方は、辞書に載っている正式な職業名ではありません。多重下請け構造の末端に置かれ、テストや修正といった下流工程の作業を担うエンジニアを揶揄する俗称として使われてきました。

ここでは、この言葉の成り立ちを整理します。

建設業界の「土方」が語源になっている

土方とは、建設や土木の現場で作業に従事する人を指す言葉です。IT土方という呼び方は、この土方をIT業界に当てはめて生まれました。

両者が重ねられた理由は、産業構造の似かたにあります。建設業界では、発注元から直接仕事を請けた元請けのゼネコンが、一次請け・二次請けへと工事を分割して流していく仕組みです。

日本のシステム開発も同じで、大手のシステムインテグレーターを頂点に、下へ下へと開発が再委託されます。現場で手を動かす人ほど発注元から遠い位置に置かれる点が、両業界に共通しています。

また、労働環境の表し方も引き継がれました。建設現場の過酷さを示す3Kは、きつい・汚い・危険の3語を指します。IT業界ではこれをもじった新3Kという言い方が生まれ、きつい・帰れない・給料が安いの3点で語られてきました。

2007年には大手システムインテグレーターの経営者が決算発表の場でこの言葉に触れ、業界の課題として報じられています。

2ch・5ch発のネットスラングとして広まった

IT土方が広く使われるきっかけになったのは、インターネット上の匿名掲示板でした。2004年には2ちゃんねるに携帯電話開発の現場を題材にしたスレッドが立てられ、開発現場の過酷さを伝える書き込みとして拡散しています。

ただし、この言葉が掲示板だけで生まれたとまでは断定できません。2005年にはIT系の専門メディアが実施した川柳の企画で、デジタル土方という語を含む作品が入賞しました。掲示板の外にある業界メディアでも、すでに通じる言葉だったわけです。

背景には、当時のIT業界が置かれた状況がありました。1990年代後半からシステム開発の需要が急増する一方、不況下で開発コストを抑えたい企業が増え、末端の技術者に負担が集中します。デスマーチという言葉が使われはじめたのも同じころでした。自虐を込めて自分たちをそう呼ぶ書き込みが積み重なり、業界の外へも広がっていきます。

Wikipediaでは「デジタル土方」として記載されている

日本語版のWikipediaでIT土方を調べると、デジタル土方という項目に転送されます。百科事典の見出し語としてはデジタル土方が正式な扱いで、IT土方はその別名という位置づけです。

項目内では、システムエンジニア、カスタマーエンジニア、プログラマーといった情報技術産業で働く労働者の俗称と定義されています。ほかにコンピューター土木作業員、システム屋という呼び方も併記されました。

記述の中心にあるのは、やはり産業構造です。元請けが下請けに仕事を丸投げする建設・土木業界に似た多層構造であること、そして多重派遣や偽装請負が起きやすいことが問題として挙げられています。

言葉の由来をたどって行き着くのは、個人の能力ではなく契約の重なり方です。

なぜ“IT業界の闇”を象徴する言葉として使われてしまうのか？

待遇が厳しい仕事は、どの業界にも存在します。それでもIT土方という言葉が業界の暗部を指す代名詞として定着したのは、問題が外から見えにくいところで起きているからです。

公正取引委員会が2022年に公表した実態調査では、その見えにくさが数字で示されました。ソフトウェアの制作取引では細分化と再委託が繰り返され、極端に長い商流が形成される場合があり、最大で6次下請けの事例が報告されています。

同じ調査で、下請法違反にあたると考えられる経験を尋ねたところ、買いたたきを挙げた事業者は15.7%、不当な給付内容の変更は14.2%でした。

さらに深刻なのが、不必要な中抜き事業者の存在です。感じたことがあると答えた割合は次のように分かれました。

• 元請けは18.5%
• 中間下請けは29.2%
• 最終下請けは33.5%

商流の下にいる人ほど中抜きを実感している一方、上にいる人にはその実感が薄いという構図です。発注元は自分が支払った金額が末端でいくらになっているかを把握しておらず、現場のエンジニアは自分の単価がいくらで取引されているかを知らされません。当事者同士が互いの数字を見られない状態で、契約だけが積み重なっていきます。

そして、この言葉を最も多く使ってきたのは業界の外にいる人ではなく、現場のエンジニア自身でした。自虐として口にされ、内部から漏れ聞こえてきたことが、闇という語感を強めたと言えます。

参考：公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書（概要）」 参考：IT Leaders「公取委が情報サービス業の多重下請け問題を調査、問題を解くカギはエンドユーザーにあり！」

IT土方が生まれる原因は多重下請け構造にある

下流工程に固定される状況は、配属先の運や個人の力量だけで決まるわけではありません。仕事が発注元から現場へ届くまでの流れそのものに、原因があります。

ここでは、多重下請け構造がエンジニアの働き方に影響する仕組みを、次の4つの段階に分けて解説します。

• 元請けから下請けへ仕事が再委託されていく
• 商流が深くなるほど単価が削られていく
• 人月計算によって頭数として扱われる
• 下流工程に固定され裁量が生まれない

それでは、順に見ていきましょう。

元請けから二次請け・三次請けへ仕事が流れていく

システム開発の仕事は、発注元の企業から直接エンジニアに届くわけではありません。まず大手のシステムインテグレーターが元請けとして受注し、そこから一次請け、二次請けへと工程を分割して再委託していきます。

この流れが生まれる理由は、大規模な開発に必要な人数を1社では抱えきれないからです。案件の規模は時期によって大きく変動するため、自社で全員を雇うと仕事のない期間に人件費だけが残ります。そこで外部の企業へ委託する方式が定着しました。

問題は、再委託がどこかで止まるとは限らない点です。公正取引委員会の実態調査では、細分化と再委託が繰り返されて極端に長い商流ができる場合があると指摘され、最大で6次下請けの事例が報告されました。間に何社が入っているかは、現場に立つエンジニアからは見えません。

参考：公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書（概要）」

商流が深くなるほど人月単価が削られていく

再委託が重なると、間に入る企業がそれぞれ利益を確保します。発注元が支払った金額のうち、現場のエンジニアに届くまでに差し引かれる部分が増えていくわけです。

中間マージンそのものが不当なわけではありません。案件を探す営業活動や、案件が切れた待機期間の給与保証は所属企業が負っており、その対価という側面があります。問題視されているのは、価値を加えないまま取り分だけを取る事業者が挟まる場合です。

公正取引委員会の調査では、不必要な中抜き事業者の存在を感じたことがあるという回答が、最終下請けで33.5%に達しました。元請けの18.5%と比べると、下にいるほど実感が強まる傾向がはっきり表れています。

同じ調査では、買いたたきにあたる経験があると答えた事業者が15.7%、下請代金の減額が13.5%でした。上流で削られた金額は、そのまま下流へ押し出されていきます。

スキルが同じでも、どの商流に所属しているかで報酬が変わるのはこのためです。

参考：公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書（概要）」

人月計算で「頭数」として扱われてしまう

日本のシステム開発では、費用の見積もりに人月という単位が長く使われてきました。1人が1ヶ月働く量を1人月と数え、必要な人数と期間を掛け合わせて金額を出す方式です。

この計算式には、成果の質を測る要素が入っていません。効率よく仕上げて工数を減らすほど請求額が下がるため、受注する側には短時間で終わらせる動機が働きにくくなります。

エンジニア個人にとっての影響は、評価の軸がずれる点に表れます。人月で契約が結ばれている以上、現場で見られるのは何を実現したかではなく、何人が何ヶ月そこにいたかです。同じ工数枠に入っている限り、成果の差は金額に反映されません。

さらに、この方式は交代可能な人材を前提としています。誰が入っても1人月は1人月と数えられるため、個人の経験や工夫が単価に結び付きにくくなります。

頭数として扱われていると感じる場面は、この見積もり方から生まれています。

下流工程に固定され裁量が生まれない

システム開発は、要件定義から始まって設計、実装、テスト、運用保守へと進みます。多重下請け構造では、この工程が商流の位置とほぼ重なります。

上流の工程は発注元との交渉を伴うため、契約上の窓口になっている企業が引き受けます。下請けに回ってくるのは、仕様が決まったあとの作業です。

この分担が続くと、裁量を持つ機会そのものが訪れません。何を作るかを決める場に呼ばれず、決まったものをどう作るかの範囲でも判断は上流に委ねられます。

裁量がないのは意欲の問題ではなく、裁量を渡す設計になっていないからです。

自分がIT土方に当てはまるか確かめる5つのチェックポイント

構造の問題だとわかっても、自分がその影響をどれだけ受けているかは別の話です。判断材料になるのは、待遇への不満ではなく、経験の積み上がり方と評価のされ方でした。

まずは以下の5つに当てはまるかを確認してみましょう。

• 直近1年で新しい技術に触れていない
• 自分の単価と商流の位置を知らない
• 設計や要件定義の会議に呼ばれたことがない
• 成果ではなく稼働時間で評価されている
• 現場が変わるたびに仕事内容がリセットされている

それでは、順に見ていきましょう。

直近1年で新しい技術に触れていない

まず振り返ってほしいのが、この1年で扱った技術の中身です。使う言語もツールも1年前と変わっていないなら、注意が必要でしょう。

下流工程の作業は、仕様と手順が決まったあとに始まります。決められたとおりに実装し、決められた観点でテストする流れのため、新しい技術を試す場面が入り込みません。技術に触れていないのは学ぶ気がないからではなく、触れる作業が回ってこないからです。

会社からの支援も期待しにくい状況があります。IPAの「DX動向2025」によると、人材の育成施策について「とくに支援はしていない」と回答した日本企業は36.6%にのぼりました。米国の1.0%、ドイツの1.9%と比べると開きは大きく、学ぶ機会を会社任せにできない実態が浮かびます。

現場でも会社でも新しい技術に触れる機会がないなら、経験は現状のまま止まります。

参考：IPA「DX動向2025－AI時代のデジタル人材育成」

自分の人月単価と商流の位置を知らない

次に確認したいのが、自分が何次請けの立場で働いているかです。常駐先の企業名は知っていても、その企業と自社のあいだに何社入っているかを答えられる人は多くありません。

単価についても同じです。発注元が支払っている金額と、自分の給与のあいだにどれだけの差があるかを把握しないまま働いている状態は、自分の評価額を知らないまま契約を続けているのと変わりません。

まずは所属企業に商流の位置を確認してみましょう。答えを避けられる場合や、企業側も把握していない場合は、その反応自体が判断材料になるでしょう。

設計や要件定義の会議に呼ばれたことがない

3つ目は、上流の議論に参加した経験があるかどうかです。何を作るかを決める場に一度も同席していないなら、担当範囲が実装以降に限定されています。

要件定義や基本設計の打ち合わせは、発注元と直接やり取りする企業が担います。商流の深い位置にいるエンジニアには、決定事項が仕様書として降りてくるだけです。会議の存在自体を知らされない場合もあるでしょう。

見落としやすいのが、この経験の有無が転職市場での評価に直結する点です。職務経歴書に書けるのは担当した工程であり、実装とテストだけが並ぶ経歴と、要件定義から関わった経歴では、応募できる求人の幅が変わります。

呼ばれていないという事実は、経歴に空白として残ります。気づかないうちに選択肢が狭まっていく部分です。

成果ではなく稼働時間で評価されている

4つ目に確認したいのは、何をもって評価されているかです。月末に提出する書類が作業内容の報告ではなく稼働時間の集計だけなら、契約上の評価軸は時間に置かれています。

これには人月という見積もり方が背景にあります。1人が1ヶ月働く量を単位として金額を決めるため、契約が守られたかどうかは規定の時間を満たしたかで判断されます。品質を高めても、効率化して工数を減らしても、請求額は増えません。

この仕組みのもとでは、次のような状況が生まれます。

• 早く終わらせても次の作業が割り当てられるだけになる
• 改善提案が契約範囲外として扱われる
• 昇給の根拠を示す材料が手元に残らない

時間で測られている限り、努力を金額に変換する経路がありません。評価されていないと感じる原因は、意欲でも実力でもなく契約の形にあります。

現場が変わるたびに仕事内容がリセットされている

最後は、これまで参画した現場のつながりです。担当してきた業務に一貫性がなく、現場ごとに扱う領域も技術も入れ替わっているなら、経験が積み上がっていない可能性があります。

客先常駐では、契約の切れ目で次の現場へ移ります。前の現場で得た業務知識や人間関係は引き継がれず、新しい環境で一から立場を作り直す流れです。移動そのものは避けられませんが、移動のたびに前提知識が使えない状態が続くと、年数だけが増えていきます。

厚生労働省の「jobtag（令和7年賃金構造基本統計調査）」に掲載された年収データでは、この積み上がりにくさが表れています。

受託開発やプログラマーなどを含む職種の平均年収は、経験1〜4年で423.08万円、15年以上で578.06万円でした。一方、基盤システムのシステムエンジニアやプロジェクトマネージャーを含む職種では、同じ15年以上で860.58万円に達します。

同じ15年でも、到達する水準に282万円の差がつきます。現場が変わるたびに振り出しに戻る働き方では、この差を埋める材料が残りません。

評価や経験の積み上がり方については、次の記事でも解説しています。ぜひ参考にしてください。

参考：厚生労働省「システムエンジニア（受託開発） - 職業詳細 | 職業情報提供サイト（job tag）」 参考：厚生労働省「システムエンジニア（基盤システム） - 職業詳細 | 職業情報提供サイト（job tag）」

エンジニアの市場価値はどう決まる？高める方法と将来性を徹底解説

IT土方のまま働き続けた先に起きる4つのこと

チェックポイントに当てはまった状態を放置すると、時間の経過とともに選択肢が狭まっていきます。年齢を重ねてから動こうとしても、そのときには打てる手が減っている場合が多いです。

ここでは、このまま働き続けた場合に起きる変化を4つ取り上げます。

• 年齢が上がるほど案件を選べなくなる
• 職務経歴書に書ける実績が残らない
• 生成AIに代替されやすい作業に留まる
• 現場が変わるたびに評価をやり直すことになる

それでは、順に見ていきましょう。

30代後半でも単価が上がらず案件を選べなくなる

客先常駐で働き続けた場合、最初に表れるのが単価の頭打ちです。年齢とともに給与が上がる仕組みが働きにくく、30代後半に差しかかると停滞が明確になります。

理由は、単価の決まり方にあります。人月で見積もる方式では、担当できる工程が同じであれば経験年数が加算されにくいです。同じテスト工程を任せるなら、単価の低い若手を選ぶ判断が働く場面もあります。

厚生労働省の「jobtag」のデータでは、この停滞が年収に表れていました。受託開発のシステムエンジニアやプログラマーなどを含む職種の平均年収は、経験10〜14年で561.26万円、15年以上で578.06万円です。10年目以降では、伸びは17万円ほどにとどまります。

業界内では、35歳前後で単価の伸びが止まりやすいという見方も語られてきました。公的な統計で裏付けられた話ではないものの、40代に入ると年齢を要件に挙げる案件が増えるという声は現場から出ています。

単価が上がらないまま年齢だけが上がると、応募できる案件そのものが減っていきます。

職務経歴書に書ける実績が積み上がらない

次に効いてくるのが、転職しようとした段階で気づく経歴の薄さです。長く働いていても、書類に落とし込める内容が数行で終わってしまう場合があります。

採用担当者が確認するのは、在籍年数ではなく担当した工程と役割です。実装とテストのみが並ぶ経歴では、何を任せられるかの判断がつきません。参画した現場の数が多くても、それぞれが短期間で役割も同じなら、評価の材料は増えないでしょう。

とくに不利になるのが、次のような書き方しかできない状態です。

• 参画したプロジェクト名と期間だけが並ぶ
• 担当工程が単体テストと結合テストで統一されている
• 使用技術欄に同じ言語とツールが繰り返される
• 自分の判断で決めた事柄を説明できない

書けないのは実績がなかったからではなく、実績として記録される形で仕事を任されなかったからです。とはいえ、選考の場でその事情は考慮されません。経歴の空白は、そのまま応募できる求人の少なさに変わります。

生成AIに置き換わりやすい作業に張り付いてしまう

3つ目は、担当している作業そのものの価値が下がっていく変化です。生成AIの普及によって、影響はすでに金額に表れはじめました。

日本経済新聞が2026年7月に報じた調査では、2022年以降、AIに代替されにくい仕事の単価が2割上昇した一方、自動化が進む下流工程の単価は5割下落しています。同じ期間に、上流と下流で正反対の動きが起きました。

たとえば、コーディングやテストの一部は、AIが担える範囲に入りました。実装したコードを人がレビューする時間のほうが、自分で書く時間より長くなったという調査結果も出ています。要件定義や設計は残る一方、決められた仕様どおりに作る作業の希少性は下がります。

将来の需給予測も同じ方向を示しています。経済産業省の試算によると、人材の転換が進まなかった場合、2030年には従来型IT人材が10万人余る一方で、先端IT人材は55万人不足する見通しです。

IT人材が足りないと言われる状況のなかで、下流に留まる人材だけが余る側に回ります。

参考：参考：日本経済新聞「エンジニア賃金、二極化 コード生成など5割安、AI代替で雇用縮小」 参考：参考：経済産業省「IT人材需給に関する調査（概要）」

常駐先が変わるたびに評価と人間関係をリセットされる

最後は、現場を移るたびに立場を作り直す負担です。契約が切れれば次の現場へ移り、そこでの信頼をまた一から積み上げていきます。

常駐先で高く評価されても、その評価は所属企業の給与には直接反映されにくいです。評価する人と給与を決める人が別の会社にいるため、現場での貢献が昇給の根拠として届きません。異動すれば、評価してくれた相手との関係も終わります。

負担は業務面にも及びます。業務知識や社内の進め方を覚え直し、誰に何を聞けばよいかを把握するまでに時間がかかるでしょう。その期間は成果を出しにくく、力を発揮しはじめたころに契約が切り替わる場合もあります。

積み重ねが断ち切られる働き方を続けると、年数に見合った立場を得られないまま時間が過ぎます。同じ期間を過ごしても、到達する場所が変わってしまうのはここに理由があります。

IT土方から抜け出すための具体的な4つの方法

ここまで構造の問題を見てきましたが、構造が変わるのを待つ必要はありません。今いる場所でできることと、環境そのものを変える選択肢の両方があります。

取り組みやすい順に、次の4つを解説します。

1. 今の現場で上流工程の経験を取りに行く
2. 市場価値の高い技術領域を学ぶ
3. 資格で経験の不足を客観的に補う
4. 商流の浅い企業へ転職する

それでは、順に見ていきましょう。

今の現場で設計・要件定義の経験を取りに行く

まず取り組めるのが、現在の常駐先で上流工程に近づく動き方です。転職の準備としても、この経験の有無が結果を左右します。

現実的な進め方は、担当範囲の一歩外側に手を伸ばすことです。仕様書を渡されたときに、なぜその仕様になったのかを設計担当者に確認するだけでも、決定の背景が見えてくるでしょう。

設計レビューへの同席を願い出る、テスト設計を自分で組み立てるといった行動も、実装以降に閉じていた範囲を広げる糸口になります。

得られた経験は、その都度メモに残しておきましょう。担当した工程と、自分が判断した内容を記録しておくと、そのまま職務経歴書の材料になります。参画した現場を離れてからでは思い出せません。

ただし、この方法には限界もあります。契約が実装工程に限定されている場合、範囲外の業務を任せてもらえない場面は出てくるでしょう。半年ほど働きかけても状況が動かないなら、環境側の問題として切り分けて考えましょう。

クラウドやAI活用など市場価値の高い領域を学ぶ

次に効果が大きいのが、需要の伸びている領域へ技術の軸を移す取り組みです。学ぶ対象を選ぶ基準は、求人でどれだけ評価されているかに置きましょう。

エンジニア特化の転職エージェント「テックゴー」が保有する求人データで職種ごとの平均年収を見ると、領域による差がはっきり表れています。

経済産業省の試算では、2030年に先端IT人材が55万人不足する一方、従来型IT人材は供給が需要を上回る見通しが示されました。不足している側へ移ることが、そのまま評価の上がる方向と重なります。

学習の進め方としては、業務で使っている技術と地続きの領域から始めると定着しやすいです。サーバーの運用保守を担当しているならクラウド基盤の構築へ、テスト工程が中心なら自動化ツールの扱いへと広げていく形が現実的でしょう。

参考：経済産業省「IT人材需給に関する調査（概要）」

資格で経験の不足を客観的に補う

3つ目は、資格の取得です。上流工程の実務経験が積めない状況でも、知識を持っていることを書類で示せます。

資格が有効なのは、経歴で伝わらない部分を埋められるからです。実装とテストの経験しか書けない場合でも、設計や管理の知識を学んだ事実は残せます。選考では、意欲を裏付ける材料としても扱われます。

目指す方向に応じて、次のような資格が候補になります。

• 基本情報技術者試験
• 応用情報技術者試験
• システムアーキテクト試験
• プロジェクトマネージャ試験
• AWS認定ソリューションアーキテクト

情報処理技術者試験は、2026年度から応用情報技術者試験と高度試験もCBT方式へ移行しました。全区分がコンピュータで受験する形になり、受験の機会が増えています。

ただし、資格だけで評価が決まるわけではありません。実務と結び付けて話せる状態にしておくと、面接での説得力が変わります。

商流の浅い企業（自社開発・プライム）へ転職する

最後が、環境そのものを変える選択です。担当できる工程は商流の位置で決まるため、位置を変えると任される仕事も変わります。

移り先としては、次の3つが有力な候補になります。

また、年収の面でも差が出ます。エンジニア特化の転職エージェント「テックゴー」の求人データでは、要件定義や設計を含むシステムエンジニアの平均年収が698万円、プロジェクトリーダーが763万円、プロジェクトマネージャーが890万円でした。

運用保守の646万円と比べると、工程の違いがそのまま金額に表れています。

気になる企業がある場合は、転職エージェントに相談してみるのがおすすめです。転職エージェントは各企業とのつながりがあるため、発注元と直接契約している案件の比率など、求人票には載らないデータも保有しています。

IT土方から抜け出した人のキャリアパス

抜け出す方法がわかっても、その先にどんな仕事が待っているかは見えにくいものです。実際には、これまでの経験を土台にして進める道がいくつもあります。

エンジニア特化の転職エージェント「テックゴー」で転職したエンジニアの方によく選ばれているのは、以下の4つのルートです。

• テスト中心の経験からインフラ・クラウド領域へ移る
• 詳細設計の経験を足がかりに上流工程へ進む
• 現場で得た業務知識を武器にコンサルティング側へ移る
• 客先常駐から自社開発企業のエンジニアになる

それぞれのルートを確認していきます。

テスト中心のSEからインフラ・クラウドエンジニアへ移る

テストや運用保守を長く担当してきた場合、インフラ領域は移りやすい方向です。システムの動作を確認してきた経験が、そのまま基盤を扱う仕事につながります。

現場で障害対応をしていた人であれば、ログを読んで原因を切り分ける力がすでに身についています。サーバーやネットワークの構成を把握する場面も多く、インフラの知識に触れる機会は下流工程のなかでも比較的多いです。

そこからクラウドへ広げると、評価は大きく変わります。テックゴーの求人データでは、運用保守の平均年収が646万円である一方、クラウドエンジニアは743万円、SREは875万円でした。同じ基盤を扱う仕事でも、構築や改善まで担うかどうかで水準が動きます。

進め方としては、クラウドの認定資格を取得しながら、現在の現場でクラウド環境に触れる業務を探す形が現実的でしょう。

詳細設計の経験を足がかりに上流SE・PMへ進む

実装だけでなく詳細設計を任された経験があるなら、上流工程への道が開けています。設計は要件と実装をつなぐ位置にあり、要件定義に近い考え方を求められる工程だからです。

このルートの利点は、段階を踏んで進める点です。詳細設計から基本設計へ、そして要件定義へと担当範囲を広げ、その先にプロジェクトリーダーやプロジェクトマネージャーが見えてきます。一足飛びに管理職を目指す必要はありません。

求人データで見ると、年収は段階ごとに上がっていきます。

このように、上流へ進むほど、経験が金額に反映されやすくなります。

業務知識を強みにITコンサルタントへ転身する

意外に思われるかもしれませんが、客先常駐の経験がコンサルティング領域で評価される場合があります。金融や製造といった特定の業界の現場に長く入っていた人ほど、その傾向は強いです。

理由は、業務の中身を知っている人が限られているからです。システムを作る力があっても、金融機関の事務手続きや製造現場の在庫管理がどう回っているかまでは、外から見てもわかりません。

常駐先で仕様書を読み込み、担当者と会話を重ねてきた経験は、そのまま業界知識として蓄積されています。

また、ITコンサルタントは年収の水準も高い領域です。テックゴーの求人データでは、ITコンサルタントの平均年収が997万円、セキュリティコンサルタントが1,036万円でした。

ITコンサルタントは技術力ではなく、業務を理解している点が評価の対象になります。同じ業界の案件を複数経験しているなら、その経歴は職務経歴書の中心に据えましょう。

SESから自社開発企業のエンジニアへ移る

最後は、自社でサービスを開発する企業へ移るルートです。客先常駐との違いが最も大きく、働き方そのものが変わります。

変わる点は、次の3つに整理できます。

• 発注元ではなく自社の判断で開発を進められる
• 企画から運用まで一貫して関われる
• 現場が変わらないため経験が積み上がる

とくに3つ目の影響は大きいです。常駐先が変わるたびに立場を作り直す働き方から離れ、同じプロダクトに向き合い続けられます。担当領域が深まり、改善の結果を自分で確かめられる環境です。

選考では、実装の経験に加えて、なぜその技術を選んだかを説明できるかが見られます。指示どおりに作った話ではなく、自分で考えた部分を伝えられるかが分かれ目になります。

現在の現場でも、判断した内容を記録しておくと準備が進めやすいでしょう。

キャリアアップをするための転職ならテックゴー

下流工程から抜け出す転職では、求人票を見ただけでは判断がつきません。職種名が同じでも、商流の位置によって任される工程はまったく違います。

テックゴーは、エンジニアとITコンサルタント領域に特化した転職エージェントとして、上流工程を担う求人を多数保有しています。元エンジニア出身のアドバイザーが在籍しており、これまでの経験のどこが評価されるのかを整理したうえで、応募先を提案します。

• エンジニア・ITコンサル領域に特化し、上流案件の求人を多数保有している
• 平均年収アップ金額は144万円と、収入が上がった実績が豊富にある
• 年収アップの成功率は86%で、交渉はすべて代行してもらえる
• アドバイザーは元エンジニア・ITコンサル出身者が多く、現場を知ったうえで助言をもらえる
• 面接対策は回数無制限で、選考の通過まで支援を受けられる

相談したからといって、転職を決めなければならないわけではありません。今の経験がどこまで評価されるのかを確かめるところから始めてみましょう。

まとめ

この記事では、IT土方という言葉の意味と由来、そして下流工程に固定される原因と抜け出す方法を解説しました。この言葉が指しているのは個人の能力ではなく、元請けから何層にも再委託が重なる産業構造です。公正取引委員会の調査でも、商流の深い位置にいるほど不必要な中抜きを実感する割合が高いことが示されています。

一方で、構造が変わるのを待っているあいだにも時間は進みます。厚生労働省のデータでは、下流工程が中心の職種は経験15年以上でも平均年収578.06万円にとどまり、上流工程を担う職種の860.58万円との差は開いたままです。生成AIの普及によって下流工程の単価は下落しており、待つほど選択肢は減っていくでしょう。

今の現場で設計や要件定義に近づく努力から始めて、状況が動かないなら商流の浅い企業へ移る。この順番で考えると、無理のない形でキャリアを動かせます。

上流工程への転向や年収アップを考えているなら、テックゴーへの相談がおすすめです。上流案件やITコンサル領域に強く、元エンジニア出身のアドバイザーが、これまでの経験をどう評価につなげるかを一緒に整理します。