SIerはやめとけと言われる理由と企業選びの基準

SIerの定義と、メーカー系・ユーザー系・独立系の違い

SIer（システムインテグレーター）は、顧客企業の情報システムを、企画・要件定義から設計・開発・テスト・運用保守まで請け負う会社です。自社のサービスを開発する会社と違い、仕事の起点は顧客の発注で、納期・予算・仕様は顧客との契約で決まります。

SIerは成り立ちで3つに分けられ、どこから仕事が来るかと、技術の選び方の自由度が分かれます。

種類	成り立ち	仕事の出どころと特徴
メーカー系	電機・通信機器メーカーの情報システム部門や子会社から独立	親会社の製品・ハードウェアと組み合わせた案件が多い
ユーザー系	金融・商社・製造などの事業会社の情報システム部門が分社化	親会社グループの基幹システムの案件が多い
独立系	特定の親会社を持たない	顧客・製品を選ばず幅広く請け負う。会社ごとの差が大きい

もう1つの軸が商流の位置です。顧客から直接受注する元請（一次請け）の下に、二次請け・三次請けの会社が連なる多重下請けの構造があり、「やめとけ」と言われる理由の多くはこの階層の下の側で起きます。

SIerはやめとけと言われる4つの理由

SIerがやめとけと言われる理由は、多重下請けの下の階層ほど条件が厳しくなること、納期と仕様変更のしわ寄せで残業が増えやすいこと、管理の比重が上がってコードを書く時間が減ること、顧客の既存システムに合わせるため技術を選ぶ幅が狭いことの4つです。前の2つは商流の位置で、後の2つは担当する工程と案件の種類で程度が変わります。

多重下請けの下の階層ほど単価と裁量が削られる

多重下請けでは、発注額が階層を下るごとに各社の取り分を差し引かれて流れるため、下の階層の会社ほど1人あたりの単価が低く、仕様を決める場にも入りにくくなります。この構造の問題を、資本金3億円以下のソフトウェア業者2万1000社へのアンケートと、関係事業者・団体へのヒアリングで確かめたのが、公正取引委員会の調査です。

公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書（概要）」（令和4年6月）は、エンドユーザーや上流の発注者からの買いたたき・減額・支払遅延といった違反行為が多重下請けの流れの上を連鎖する「下請代金にまつわる下流しわ寄せ型の問題」があったとし、「多くの事業者が不必要な「中抜き」事業者の存在を感じている」とも記しています。

同じ調査で、違反行為に該当すると考えられる経験があると答えた事業者は、買いたたきが15.7%（回答数2,611）、不当な給付内容の変更が14.2%（回答数2,649）でした。

下の階層では、元請が決めた設計書をもとに開発・テストを担うことが多く、顧客と直接話す機会も限られます。年収が上がりにくい、要件定義の経験が積めないという不満の出どころは、多くがこの位置です。

納期と仕様変更のしわ寄せで残業が増えやすい

SIerの案件は納期と予算が契約で先に決まるため、途中で仕様が変わっても納期が動かず、その差を現場の残業で埋める形になりやすいのが、長時間労働の印象が残る理由です。同じ公正取引委員会の報告書は、成果物について当事者間で正確な共通認識を形成しづらいソフトウェア制作の特性が、不当な給付内容の変更・やり直しを誘引するとも指摘しています。

産業ごとの平均では、所定外労働時間は情報通信業のほうが長く、総実労働時間はほぼ同じです。厚生労働省「毎月勤労統計調査令和6年分結果確報」第2表によると、事業所規模5人以上の一般労働者の月間の所定外労働時間は、情報通信業が16.5時間で、調査産業計の13.5時間を3.0時間上回ります。総実労働時間は情報通信業が161.3時間、調査産業計が162.2時間で、ほぼ同じです。

情報通信業にはSIerのほか通信・放送・Webサービスの会社も入るため、この値はSIerだけの平均ではありません。月平均の統計なので、会社と案件ごとの差や、リリース前・トラブル対応の時期の偏りまでは表しません。

管理の比重が上がりコードを書く時間が減る

SIerでは経験年数が上がるほど、設計・開発の担当からプロジェクトリーダー、プロジェクトマネージャーへと役割が移り、進捗・品質・予算の管理と、顧客・協力会社との調整が仕事の中心になります。開発を協力会社に任せる元請の大手ほど、この傾向が強くなるのが一般的です。

マネジメントの経験は転職でも評価される一方、実装を続けたい人にとっては、手を動かす機会が年々減っていくことが「やめとけ」の理由になります。

顧客の既存システムに合わせるため技術を選ぶ幅が狭い

SIerの案件では、顧客がすでに使っている言語・ミドルウェア・運用ルールに合わせて開発するのが前提になり、新しい技術を採用するかどうかは、顧客の承認と保守の体制で決まります。金融や公共の基幹システムでは、安定稼働を優先して長く同じ構成を使い続けることも珍しくありません。

クラウドや新しいフレームワークを業務で使いたい人は、配属される案件の顧客と業界で経験が左右されることを前提に、会社を選ぶ必要があります。

「やめとけ」が当てはまるかは会社と立ち位置で決まる

SIerがやめとけかどうかは、業態ではなく、商流の位置・担当する工程・案件の種類と、本人が何を伸ばしたいかの組み合わせ次第です。上流工程とマネジメントを伸ばしたい人には元請のSIerは経験を積みやすい場所で、実装を突き詰めたい人には合わない場面が増えます。

観点	SIerが合いやすい人	SIerが合いにくい人
伸ばしたい力	要件定義・設計・プロジェクト管理・顧客との調整	実装の深さ・新しい技術の検証
仕事の進め方	契約・仕様・手順に沿って大人数で進める	小さく作って早く直すことを繰り返す
関わりたい相手	顧客企業の業務担当者・協力会社	プロダクトの利用者・社内のチーム
働き方	繁忙期の偏りを受け入れられる	毎月の稼働を一定に保ちたい

同じSIerの中でも、元請で上流を担う部署と、下請けで開発・テストを担う部署では日々の仕事がまったく違います。今の不満が業態から来ているのか、今いる会社の位置や案件から来ているのかを分けて考えるのが、残るか、同じSIerの中で移るか、業態ごと変えるかを決める近道です。

年収の目安は、担う工程で開きます。厚生労働省「令和7年賃金構造基本統計調査」職種（小分類）第1表（企業規模10人以上・男女計）をもとにした年収換算では、要件定義やプロジェクト管理を担うシステムコンサルタント・設計者が889.0万円、仕様決定・設計・プログラミングを担うソフトウェア作成者が578.5万円です（きまって支給する現金給与額×12＋年間賞与その他特別給与額で Offers 編集部が換算）。上流の工程に近い区分のほうが年収換算は高く、SIerで何を伸ばすかを決める材料の1つです。

職種としてのシステムエンジニアが「やめとけ」と言われる理由と年収は、システムエンジニアはやめとけと言われる理由と年収で扱っています。

避けたいSIerを見分ける5つの確認点

避けたいSIerを見分けるには、商流の位置、客先常駐の割合、顧客と案件の偏り、技術と人への投資、残業と評価の実績の5つを、求人票と面接で確かめます。どれも外から見えにくいので、面接で具体的に聞くのが確実です。

確認点	避けたい状態	面接で聞くこと
商流の位置	二次請け・三次請けの案件がほとんどで、顧客と直接話す機会が無い	元請（顧客と直接契約）の案件の割合、要件定義から関われる案件の有無
客先常駐の割合	配属先が案件ごとに変わり、自社の評価者が仕事を見ていない	常駐と自社内の開発の割合、常駐中の評価の仕方
顧客と案件の偏り	親会社や特定の1社の案件に売上が集中している	売上上位の顧客の構成、新規の顧客・案件の増え方
技術と人への投資	研修・資格の支援が無く、新しい技術を試す案件が無い	直近で採用した技術、研修・資格取得の支援の中身
残業と評価の実績	残業の実績を答えられない、評価の基準が文書で無い	部署ごとの月の残業時間の実績、評価の基準と昇給の決まり方

商流の位置と客先常駐の割合は、エンジニアが積める経験の中身を直接決めます。顧客の偏りは、親会社や主要な顧客の方針が変わったときに案件ごと失われるリスクで、技術と人への投資は、5年後に転職市場で語れる経験が残るかどうかを左右する点です。

SIerで働くメリット

SIerで働くメリットは、社会の基盤になる大規模なシステムに関われること、要件定義からテスト・移行までの全工程を経験できること、顧客の業務知識が身につくこと、継続的な保守の契約で仕事が安定しやすいことです。どれも、転職の場面で経験として説明しやすい強みになります。

メリット	中身
大規模なシステムに関われる	金融・公共・製造などの基幹システムは、数十人から数百人の体制で数年かけて作られる。規模の大きい開発で品質と進捗を守る経験を積める
全工程を経験できる	要件定義・基本設計・詳細設計・開発・テスト・移行・運用保守を工程として分けて進めるため、システムを作る流れ全体を説明できるようになる
業務知識が身につく	会計・物流・金融などの顧客の業務を理解してシステムに落とす経験は、その業界の事業会社やSaaSの会社への転職でも活かせる
仕事が安定しやすい	基幹システムは導入後も保守・改修の契約が続くことが多く、案件が続きやすい

SIerの将来性と、公正取引委員会の令和4年の提言

SIerの仕事は、基幹システムの保守・刷新とクラウドへの移行がある限り続きます。多重下請けの構造には公正取引委員会が令和4年の報告書で見直しを促しており、中間で仕様を受け渡すだけの階層は減っていく方向というのが編集部の見立てです。将来性は業態全体よりも、元請に近い位置と顧客との直接の取引を持つ会社かどうかで分かれます。

公正取引委員会は先に挙げた令和4年6月の報告書の提言で、「中抜き」事業者の存在が多重下請構造の多層化を深めるおそれがあるとして、業界全体でサプライチェーンのスリム化に向けた取組を進めていくことが期待されるとし、独占禁止法・下請法の執行を強化するとしました。エンドユーザーと元請には、契約内容の明確化を求めました。

商流が短くなれば、中間の階層で仕様を受け渡すだけの役割は減り、顧客と直接話して要件を決められる会社と人に仕事が集まります。SIerに残るにしても移るにしても、上流の工程に近づく経験を積めるかが、これからの判断の軸になります。

SIerで積んだ経験を求人の応募条件はどう書いているか

Offers に掲載された正社員の求人で、応募条件の欄で SIer に触れるものは38件あり、書き方は「Sier出身者」「SIerでの業務経験」とだけ書くものから、要件定義・プロジェクトマネジメント・設計・開発といった工程まで名指しするものまで幅があります（Offers（株式会社overflow）調べ・応募条件の欄で SIer に触れる正社員求人 n=38・2023年11月〜2026年8月公開）。

工程まで名指しする求人の応募条件の欄の書き方は、例えば次のとおりです。

求人の職種	応募条件の欄の文言
CTO候補	「SIerまたは大手企業の情報システム部門での大規模プロジェクトマネジメント経験」
ソリューションアーキテクト	「SI(システムインテグレーター)での設計、開発経験」
コーポレートIT	「SIerや内製開発でのシステム開発業務経験(言語不問)」
プロダクトマネージャー	「SIerやシステム部での要件定義」
PdM・PM候補（自社開発の会計SaaS）	「SIerにてPMの経験がある方」
テクニカルプロダクトマネージャー	「SIerでの大企業向けのシステム開発、スタートアップでのサービス開発双方の経験」

この6件では、CTO候補の求人が大規模プロジェクトのマネジメントを、ソリューションアーキテクトの求人が設計・開発の経験を、コーポレートITの求人がシステム開発の経験を、プロダクトマネージャーの求人が要件定義を挙げています。

SIerにいる間に、担当した工程・体制の人数・自分が決めたことを、こうした応募条件の言葉に合わせて説明できるようにしておくと、転職先の選択肢が広がります。

Offers で SIer の経験を活かせる転職先を探す

SIerからの転職先と、それぞれで活きる経験

SIerからの主な転職先は、元請や大手のSIer、自社サービスを開発する会社のエンジニア、プロダクトマネージャー・プロジェクトマネージャー、事業会社の社内SE（社内システムエンジニア）、ITコンサルティングの5つです。どこを選ぶかは、SIerで伸ばした経験と、次に伸ばしたいことで決まります。

転職先	活きるSIerの経験	移ると変わること
元請・大手のSIer	設計・開発・テストの経験、業界の業務知識	要件定義など上流の工程と、顧客と直接話す機会が増える
自社サービスの会社のエンジニア	設計・開発の経験、品質を守る進め方	技術を選ぶ幅が広がり、利用者の反応を見て改善を続ける仕事になる
プロダクトマネージャー・プロジェクトマネージャー	要件定義、プロジェクト管理、顧客との調整	受けた仕様を作る側から、何を作るかを決める側に回る
事業会社の社内SE・コーポレートIT	要件定義、ベンダーとの調整、システム導入	発注する側に立ち、自社の業務の改善に長く関わる
ITコンサルティング	上流工程、業務知識、プロジェクト管理	IT戦略や業務改革の提案から関わる

同じSIerでも、元請に移れば上流の経験を積みながら業態は変えずに済みます。業態ごと変えるなら、自社サービスの会社は実装を続けたい人に、プロダクトマネージャーや社内SEは要件定義と調整の経験を軸にしたい人に向いている道です。社内SEで仕事の重さが職場によって変わる点を扱うのが、社内SEはやめとけと言われる理由と職場の選び方の記事です。

SIerと働き方が近いSES（システムエンジニアリングサービス）との違いと、SESが「やめとけ」と言われる理由はSESはやめとけと言われる理由と実態・転職先の要件、SESの年収はSESの年収、社内SEの仕事と年収は社内SEの年収、プロジェクト管理の経験を軸にするPMO（プロジェクトマネジメントオフィス）の道はPMOの年収で整理しています。

SIerから転職するときの進め方

SIerからの転職は、担当した工程と体制の棚卸し、職務経歴書での成果の書き分け、求人の応募条件との照合、面接での確認の4段階で進めると、SIerの経験を相手の言葉で伝えられます。

工程と体制を棚卸しする。案件ごとに、業界・システムの種類・担当した工程・チームの人数・自分の役割を書き出します。下請けの位置で上流に関われなかった場合も、設計書を読み解いて実装した範囲と、品質を守るために工夫したことは、経験として書ける材料です
職務経歴書で成果を書き分ける。「何人の体制で、どの工程を、どの期間で、どう終えたか」を数字で書きます。プロジェクトマネジメントの書き方を詳しく扱っているのは、プロジェクトマネージャーの職務経歴書の書き方の記事です
求人の応募条件と照合する。応募したい職種の必須要件・歓迎要件に、自分の経験のどれが当たるかを1行ずつ確かめます。前の節の求人のように、SIerでの要件定義や大規模プロジェクトの経験を名指しで求める求人は、照合しやすい相手です
面接で働き方を確かめる。避けたいSIerの確認点と同じく、開発体制・技術を選ぶ決まり方・残業の実績を、面接で具体的に聞きます

自分のスキルと希望の条件を登録しておくと、経験に関心を持った企業から声がかかる形で、転職先の候補を広げられます。

Offers でハイクラスのエンジニア転職を始める