受託開発はやめとけって本当？つらいと言われる理由と、やめとけが当たる会社・当たらない会社の見分け方！

受託開発について調べると、やめとけ、きつい、スキルが身につかない、といった声がすぐに見つかります。実際、そう言いたくなる職場があるのは事実です。ただ、受託開発という業態そのものに原因があるケースは思ったより少なく、多くは会社の受け方と回し方の問題です。

受託開発で「やめとけ」が当たるかどうかは、次の3点でほぼ決まります。

①商流の深さ（元請け・二次請けか、三次請け以下か）
②契約と変更管理の仕組み（追加要望を追加工数として扱えるか）
③見積もりとPMの質（無理な納期を現場の残業で吸収していないか）

3つがそろって悪い会社なら、迷わず離れてかまいません。反対に、この3点が健全な受託会社は、要件定義からリリースまでを一通り経験でき、金融や物流といった業界知識も身につく良い修行先です。

例外は、一つのサービスをリリース後も長く育てたい人と、特定の技術を何年も深掘りしたい人です。この2タイプは、会社がどれだけ健全でも受託という働き方そのものとかみ合いません。

この記事では、受託開発がつらいと言われる理由を仕組みから分解し、やめとけが当たる会社の見分け方、辞める前の判断基準、受託の経験が活きる転職先まで順に解説していきます。

なお、商流や仕様変更の扱いは求人票にまず書かれません。転職を考え始めているなら、企業の内情を把握しているレバテックキャリア、テックゴー、ギークリーといったIT特化型のエージェントに聞くのが手っ取り早い方法です。3社の違いは記事の後半で紹介します。

受託開発はやめとけは本当？先に結論を整理

同じ受託開発でも、会社によってまったく別の仕事になる

受託開発という言葉は、かなり幅の広い働き方をひとまとめにしています。

たとえば、エンドユーザーの企業から直接相談を受け、業務のヒアリングから要件定義、開発、リリース後の保守まで自社で持つ会社があります。ここで働くエンジニアは、顧客がなぜそのシステムを必要としているのかを理解したうえで設計に関われます。

同じ受託開発でも、大手SIerからさらに別の会社を経由して仕事が回ってくる会社だと、手元に届くのは完成した仕様書と納期だけです。担当はテストや一部機能の実装に限られ、仕様に疑問があっても顧客に直接確認することすらできません。

ネット上の受託開発はやめとけという声の多くは、後者の環境から出ています。前者と後者を同じ受託として評価すると、判断を誤ります。

受託開発とは｜SESや自社開発との違いを30秒で

受託開発は、クライアントからシステムやアプリの開発を請け負うビジネスです。契約は主に請負と準委任の2種類で、請負は成果物を完成させて納品する責任を負い、準委任は決められた作業を遂行することに対して報酬が支払われます。

注意したいのは、受託開発という言葉が契約上かなりあいまいに使われている点です。求人票に受託開発と書いてあっても、実態は準委任で顧客先に常駐し、人月単価で稼働する、SESに近い働き方の会社もあります。社内で開発するのか、顧客先に行くのか。ここが受託会社を見分ける最初のチェックポイントです。

また、受託開発にはWebサイトやスマホアプリを作るWeb系の受託と、企業の基幹システムや業務システムを作るSIer系の受託があります。扱う技術も開発の進め方もかなり違うため、同じ受託経験でも次のキャリアの選び方は変わってきます。

自社開発との違いをスキル・年収・働き方まで比べたい人は、自社開発と受託開発の働き方の違いとは？メリット・デメリットなど現役エンジニアが徹底開発！で詳しく比較しています。

受託開発がやめとけ・つらいと言われる理由

納期が固定され、遅れのしわ寄せが現場に来る

受託開発の納期は、開発会社の都合ではなく顧客の事業計画で決まります。新サービスの開始日、店舗のオープン日、税制改正や法改正の施行日。こうした日付はずらしようがなく、システムが間に合わなければ顧客の事業そのものが止まります。

請負契約では、完成して納品するまで報酬が確定しません。開発途中で要件の抜け漏れが見つかったり、外部システムとの連携で想定外の不具合が出たりしても、納期を動かすのは簡単ではないわけです。本来は機能を削る、人を増やす、リリースを段階に分けるといった調整をプロジェクト全体で行うべきところを、マネジメントが弱い会社は現場の残業と休日出勤で埋めようとします。

厚生労働省の職業情報提供サイト（job tag）でも、受託開発のシステムエンジニアは納期が迫ると休日や夜間に働くことがあり、仕事の山を越えたところでまとめて休みを取る働き方がよく行われていると説明されています（出典：job tag システムエンジニア（受託開発））。

つまり、繁閑の波があること自体は受託開発の性質です。問題にすべきなのは、案件が変わっても毎回同じように炎上し、山を越えても休めない状態が続いている場合で、こちらは業態ではなく会社のプロジェクト管理の問題です。

仕様変更が増えても、追加費用や納期変更につながらない

開発途中の仕様変更は、受託開発では避けられません。動く画面を見て初めて顧客の要望がはっきりすることもありますし、顧客社内の別部署の意見で仕様がひっくり返ることもあります。

健全な会社は、変更が出た時点で影響範囲と追加工数を見積もり直し、追加費用か納期延長か、あるいは別の機能を削るかを顧客と交渉します。危ないのは、一括請負で契約しているのに変更管理のルールがなく、お客様の要望だからと無償で受け続ける会社です。

一件ごとの追加要望は半日程度の作業に見えても、10件積み重なれば数週間分の工数になります。契約金額も納期も変わらない以上、その数週間は誰かの時間外労働でしか吸収できません。受託開発のつらさの大部分は、実はこの変更管理の欠如から生まれています。

下請けの階層が深いほど、裁量も給与も削られる

元請けが受けた案件を二次請けへ、二次請けがさらに三次請けへと流す多重下請けの構造では、階層を一つ下るごとに間に入った会社が利益を確保します。下流の会社ほど受注単価が下がり、それがそのままエンジニアの給与や人員の余裕に響きます。

お金以上に厄介なのが、情報の伝言ゲームです。エンドユーザーが何に困っているのか、どこまでなら仕様を変えられるのかが、上位の会社を経由するたびに薄まって届きます。下流のエンジニアが仕様の矛盾に気づいても、確認の連絡は何社も経由するため、回答が来る前に納期が来てしまう。結果として、疑問を抱えたまま仕様書どおりに作るしかなくなります。

三次請け以下になると、担当工程がテストや保守、既存機能の小改修に寄っていくのも見逃せません。これが何年も続くと、設計や要件定義の経験がないまま年次だけが上がり、転職市場で説明できる実績が残りません。

ただし、二次請けでも上流から任される会社はありますし、元請けでも社内の分業が細かくて担当範囲が狭い会社もあります。会社の立ち位置はあくまで目安で、最終的に見るべきは自分が担当できる工程です。

見積もりの甘さが、そのまま残業になる

受託開発の残業は、開発者の作業スピードよりも受注時点の見積もりで決まっている部分が大きいです。営業が案件を取りたいあまりに安い金額と短い工期で契約してしまえば、開発が始まった時点で負けが決まっています。

ここで差がつくのがPMの存在です。現場を守るPMは、無理な納期には根拠を示して押し返し、仕様変更があれば機能・納期・費用のどれを動かすかを顧客と決めます。見積もりの段階から実際に手を動かすエンジニアを呼び、工数の根拠を一緒に作る会社もあります。

同じような案件を扱っていても、こうしたPMがいるチームといないチームでは、月末の残業時間がまるで違います。会社を見るときは、残業の有無より、炎上しかけたときに誰がどう止めているのかを確認したほうが実態に近づけます。

使う技術を自分たちで選べない

受託開発の技術選定には、顧客側の事情が入ります。既存システムとの互換性、納品後に顧客の情報システム部門が保守できるかどうか、社内のセキュリティ規定。こうした条件が優先されるため、エンジニアが使いたい技術をそのまま採用できる場面は限られます。

とくに長年稼働している業務システムの改修案件では、古い言語やフレームワークを使い続けることになります。モダンな技術を追いかけたい人にとって、これがストレスになるのは当然です。

とはいえ、受託開発だから古い技術しか触れないというのは言い過ぎです。新規サービスの立ち上げ、クラウド移行、レガシーシステムの刷新といった案件では、顧客側から新しい技術を指定されることもあります。古いシステムと新しい技術の両方が分かるエンジニアは、刷新案件ではむしろ重宝されます。求人を見るときは、会社紹介にあるモダンな開発環境という言葉より、直近1〜2年でどんな案件を何の技術で作ったかを聞いたほうが確実です。

作ったものがどう使われたのか分からないまま終わる

受託開発では、納品と検収が一つの区切りです。保守まで同じ会社が担当すればまだ追えますが、別の会社に引き継がれると、自分たちが作ったシステムが現場でどう使われているのか、どの機能が役に立ってどの機能が使われていないのかは、ほとんど分からなくなります。

ユーザーの利用データを見て機能を改善したい、問い合わせの内容から次の仕様を考えたい。そういう働き方を望むエンジニアにとって、この物足りなさは会社を変えても埋まりません。受託という業態そのものの性質だからです。

反対に、毎回違う顧客の課題を聞き、システムとして作り切って渡すことに面白さを感じる人にとっては、デメリットというより受託の醍醐味になります。

案件ごとに知識がリセットされ、少人数だと技術の天井が低い

受託開発では、案件が変わると顧客も業界も変わります。金融の次は物流、その次は医療というように、せっかく覚えた業務知識が次の案件ではほとんど使えないことも起こります。幅広い経験として前向きに捉えられる人もいますが、一つの業界を深く理解したい人にはもどかしいはずです。

もう一つ見落とされやすいのが、少人数の受託会社で起きやすい技術の天井です。社内に5〜6人しかエンジニアがいない会社では、そのメンバーが知っている範囲がそのまま会社の技術の上限になります。コードレビューが形だけだったり、設計を相談できる先輩がいなかったりする環境では、案件数をこなしても伸び方に限界があります。

受託開発はオワコン？内製化・ノーコード・AIの影響

受託開発はオワコンという意見の背景には、ユーザー企業の内製化、ノーコード・ローコードツールの普及、生成AIによるコード生成があります。これらによって、仕様書に書かれた内容をそのまま実装するだけの仕事は確実に減っていきます。

ただ、受託開発そのものがなくなるとは考えていません。内製化を進めたい企業でもエンジニアを十分に採用できるわけではなく、業務の整理から設計、既存システムとの連携、セキュリティや運用設計まで含めて任せられる外部パートナーはこれからも必要です。社内にIT部門を持たない中小企業や、業界特有の知識が求められる領域ではなおさらでしょう。

今後起きるのは、受託の消滅ではなく二極化です。顧客の課題を聞いて何をどう作るべきかまで提案できる受託会社は価値が上がり、下請けで実装作業だけを請けている会社は単価と仕事量の両方で苦しくなります。受託会社を選ぶなら、どちら側の会社なのかをこれまで以上に厳しく見る必要があります。

やめとけが当たる受託会社・当たらない受託会社の見分け方

受託会社の良し悪しは、求人票に並ぶ上流工程から携われます、お客様と直接やり取りできます、といった言葉だけでは判断できません。会社サイトで仮説を立て、面接で確かめ、可能なら第三者から裏を取る。この順番で情報を集めると、外れの会社をかなりの確率で避けられます。

取引先一覧と会社案内から商流を読む

最初に見たいのは、会社サイトの主要取引先一覧です。メーカー、小売、医療法人といったIT以外の事業会社が並んでいれば、エンドユーザーから直接受けている元請けの可能性が高いと見ていいでしょう。名の知れた大手SIerやITベンダーが中心なら二次請け、聞き慣れないシステム会社や受託開発会社が並んでいるなら三次請け以下の可能性を疑います。

もちろん取引先一覧だけで断定はできません。大手企業の名前があっても案件によっては別会社を経由していますし、二次請けで上流から入っている会社もあります。あくまで面接で確かめるための仮説として使ってください。

会社案内に労働者派遣事業の許可番号が載っている、あるいは常駐先の実績を前面に出している場合は、受託とSESが混在している可能性があります。その場合は、受託案件と常駐案件の比率を必ず確認しておきましょう。

逆に、従業員が数十人規模の地方の受託会社で、地元企業からの直接受注だけで回しているような会社は、規模が小さくても良い修行先になります。顧客との距離が近く、若手でも要件のヒアリングから関われるからです。

「自社サービスあり」だけで優良企業と判断しない

受託会社の中には自社サービスも持っている会社があり、求人ではここが魅力として打ち出されます。ただ、自社サービスがあることと、エンジニアがそこに集中できることは別の話です。

注意したいのは、自社サービスの売上がまだ小さく、受託で稼いだお金で開発を続けている会社です。このタイプは受託案件の納期が最優先で、自社サービスの開発は空いた時間に回されます。エンジニアは受託と自社サービスの両方を求められ、どちらも中途半端なまま板挟みになるのがよくある結末です。

面接では、自社サービス開発に専任チームがあるのか、受託とのかけ持ちなのかを聞いてください。それだけでかなり実態が見えます。

要件定義から保守まで、どこまで自社で持っているか

要件定義から保守まで一貫して受けている会社なら、上流工程の経験とリリース後の手応えの両方が得られます。ここで確認したいのは、会社として受けている範囲と、自分が担当する範囲が一致しているかどうかです。

会社案内では要件定義から対応と書いてあっても、要件定義はPMと営業だけで行い、エンジニアは詳細設計から参加するという分業の会社もあります。今回募集しているポジションがどの工程から入るのかは、面接で具体的に聞かないと分かりません。

取引先が特定の1社に偏っていないか

長く付き合っている顧客がいること自体は、安定した取引基盤の証拠でもあります。問題になるのは、売上の大半が1社に集中しているケースです。その顧客から仕事が切れると会社が傾くため、無理な納期や無償の追加対応を断れなくなります。前の章で触れた変更管理の欠如は、この依存関係から生まれていることがよくあります。

面接で主要取引先の数や、売上に占める上位顧客の割合を聞くのは失礼にはあたりません。答えを濁す会社は、それ自体が一つの情報です。

面接で聞いておきたい質問

商流、変更管理、見積もりの3点を面接で確かめるなら、次のような質問が使えます。

答えの中身以上に注目したいのは、具体的に説明できるかどうかです。安心材料になる回答と注意したい回答の目安を整理すると、次のようになります。

一つの回答だけで合否を決める必要はありません。ただ、どの質問にも抽象的な答えしか返ってこない会社は、社内でも整理されていないと考えたほうが安全です。

正直なところ、面接で聞いても建前の答えが返ってくることはあります。実際にその会社へ人を紹介してきた転職エージェントなら、入社した人がどの案件に配属され、どのくらい残業しているかまで把握していることがあります。レバテックキャリア、テックゴー、ギークリーのようなIT専門のエージェントに、応募前にこの会社の実際の商流はどうなっているのかと聞いてしまうのが一番早い確認方法です。

受託をやめて自社開発企業に移ることも考えているなら、「自社開発企業への転職に強いエージェント・サイト9選―未経験OKや社内SE向けも！」で各社の強みを比較しています。

自社開発企業への転職に強いエージェント・サイト9選―未経験OKや社内SE向けも！

受託開発で身につく経験は、次のキャリアの武器になる

受託開発に大変な面があるのは確かです。ただ、受託出身だから転職市場で不利になるということはありません。採用側が書類や面接で見ているのは、受託にいたかどうかではなく、そこで何を任され、何を作り切ったかです。

0から作り切って納品した経験

受託開発では、決められた期限までに動くシステムとして完成させ、顧客に受け入れてもらうところまでがエンジニアの仕事です。要件の整理、設計、実装、テスト、リリースを一通り経験していれば、システム全体を見渡す力が身についています。

採用の現場では、担当した機能の話しかできない人と、プロジェクト全体の中で自分が何を作り、どんな問題をどう解決したかまで話せる人とで、評価がはっきり分かれます。受託で作り切った経験は、後者の話をするための材料になります。

顧客の曖昧な要望を仕様に落とす力

顧客は、最初からこの画面にこの機能を、と具体的に依頼してくるわけではありません。多くは、この業務をもっと楽にしたい、という漠然とした相談から始まります。

そこから業務の流れを聞き取り、システムでできることとできないことを説明し、優先順位をつけて仕様として合意する。この一連の作業は、技術書を読むだけでは身につきません。自社開発企業でも、企画職や営業から上がってくる曖昧な要望を仕様に変換する場面は日常的にあり、受託でこれを鍛えてきた人は即戦力として見られます。

納品後に顧客の現場を見に行き、想定とまったく違う使われ方をしているのを目の当たりにしてユーザー視点に目覚めた、という受託出身のエンジニアもいます。顧客と向き合った経験は、プロダクト開発に移ってからも活きる土台です。

業界の業務知識は、そのまま専門性になる

特定業界の案件を長く担当してきたなら、それは立派な専門性です。金融なら決済や口座管理、物流なら在庫や配送、医療なら診療報酬やデータ連携など、業界ごとに独特の業務ルールがあり、これを理解しているエンジニアはそう多くありません。

書類選考では、Javaを5年使いました、よりも、物流システムで在庫引当や配送ルートの業務要件を理解しながら開発してきました、のほうが、入社後に任せられる仕事を具体的に想像できます。同じ業界の事業会社や、その業界向けにサービスを作っている自社開発企業へ移るときには、この知識が技術力と同じくらいの武器になります。

受託開発をやめとけが当てはまる人・向いている人

向き不向きは性格診断で決めるより、受託の日常で起きる場面にどう反応するかで考えたほうが外れません。

やめておいたほうがいい人

まず、作ったものをリリース後も育て続けたい人です。受託は納品で区切りがつく仕事なので、ユーザーの反応を見ながら同じサービスを何年も改善する働き方とは根本的に違います。会社を変えても埋まらない部分なので、ここに強いこだわりがあるなら最初から自社開発を目指したほうが遠回りになりません。

次に、一つの技術や領域を長期間掘り下げたい人です。受託では案件ごとに技術も業界も変わり、自分で選べる範囲も限られます。Goでバックエンドを極めたい、といった明確な方向性がある人ほど、案件に振り回されるストレスは大きくなります。

そして、顧客との調整そのものが強い負担になる人です。受託では、要望を聞き、できないことを説明し、ときには納期について交渉する場面がコードを書く時間と同じくらいあります。技術だけに集中したい気持ちが強いなら、受託会社の中で居場所を探すより、業態ごと変えたほうが満足度は上がります。

受託開発が向いている人・残る価値がある人

案件ごとに違う業界や技術に触れることを面白いと感じられる人は、受託開発に向いています。数年で複数業界の業務を見られる環境は、自社開発ではなかなか得られません。

将来PMやITコンサルタントを目指す人にとっても、受託の経験は直結します。見積もり、要件定義、顧客折衝、進行管理といったPMの仕事を、エンジニアの立場から間近で見て、少しずつ任せてもらえるからです。フリーランスを視野に入れている人も同様で、案件を受けて条件を詰め、納品まで責任を持つという流れは独立後の仕事そのものです。

未経験や経験1〜2年目で、まずは実務でシステムを作り切る経験を積みたい人にも受託は合っています。ただしこれは、元請けか二次請けで、教育やコードレビューの体制がある会社に限った話です。三次請け以下でテスト作業だけを回される環境に入ると、受託のメリットはほとんど得られません。

今の受託会社がつらい人へ｜辞める前の判断基準

受託開発がつらいと感じたとき、最初に切り分けたいのは、つらさの原因が今の会社にあるのか、受託という業態にあるのかです。ここを取り違えると、転職しても同じ悩みを繰り返します。

原因が会社なら商流を変え、業態なら転職先の業態を変える

つらさの中身が、三次請けでテストばかり、仕様変更の無償対応、営業が取ってきた無理な納期、といったものなら原因は会社にあります。冒頭で挙げた3つの基準が健全な会社、つまり元請けや二次請けで変更管理と見積もりが機能している受託会社に移れば、同じ受託開発でも働き方は大きく変わります。受託を辞めるのではなく、受託会社を変えるという判断です。

反対に、納品して終わる働き方が物足りない、使う技術を自分で選びたい、というつらさは業態から来ています。この場合はどれだけ優良な受託会社に移っても解決しないので、自社開発や社内SEといった別の業態を目指すことになります。

離れることを考えたいサイン

次のような状態が1年以上続いているなら、転職活動を始めていい段階です。

一つの目安になるのが、job tagで示されている受託開発SEの成長の流れです。最初は開発の一部を担当し、3年目頃には一人で詳細設計を書けるようになり、5年目頃には基本設計を含めて開発全体を担えるようになるのが一般的な歩みとされています（出典：job tag システムエンジニア（受託開発））。3年目を過ぎても設計に触れる機会がまったくないなら、本人の努力より環境の問題を疑ったほうがいいでしょう。

もちろん、一時的に忙しいだけなら転職理由にする必要はありません。次の案件では上流から入れてもらえる、今回の炎上を受けて見積もりのやり方を変える、といった具体的な改善が会社から示されているなら、残る意味は十分あります。同じ問題が何年も手つかずなら、個人の頑張りで変えられる範囲を超えています。

残って経験を積むなら、1年後に話せる実績を決めておく

まだ今の会社で吸収できることがあるなら、漫然と残るのではなく、1年後に職務経歴書へ書ける実績を先に決めておくことをおすすめします。

実装中心だった人なら、次の案件で要件定義の打ち合わせに同席させてもらい、議事録と要件一覧の作成を引き受ける。特定業界の案件が続いているなら、その業界の業務フローを自分で図にまとめられるくらいまで理解を深める。見積もりに関わる機会があれば、自分の担当機能の工数見積もりから手を挙げてみる。

受託開発では、何年いたかより、何を任されるようになったかがそのまま市場価値になります。1年後に顧客と仕様を詰めて設計まで担当したと言える状態になっていれば、残った時間は無駄になりません。

受託開発から移るなら｜経験が活きる転職先

受託を離れる場合も、これまでの経験はリセットされません。どの工程まで経験してきたかによって、選べる転職先が変わります。

自社開発企業｜作ったものを育てたい人の本命

納品して終わりではなく、一つのサービスを長く育てたいなら、自社開発企業が本命です。受託で鍛えた要件整理の力と、顧客に納品できる品質で作り切る感覚は、プロダクトの仕様づくりやリリース判断の場面でそのまま活きます。

ただし、自社開発に移れば受託の悩みがすべて消えるわけではありません。事業の数字に対する責任や、長く運用されてきたコードの負債といった、自社開発ならではの大変さがあります。移る前に「自社開発エンジニアはやめとけ？そう言われる理由と転職前に知っておきたい現実」で現実を確認しておくと、入社後のギャップを減らせます。

自社開発企業の多くはWebサービスを扱っているため、Webエンジニアという仕事そのもののきつさも知っておいて損はありません。業態ごとにどこできつさが出るのかは、「Webエンジニアはやめとけって本当？きついと言われる理由と、後悔しない職場の見極め方を解説！」で整理しています。

社内SE｜受注する側から発注する側へ

顧客との要件調整を経験してきた人なら、社内SEも相性のよい転職先です。受託開発では依頼を受ける側でしたが、社内SEは自社の業務部門から要望を聞き、外部ベンダーに発注する側に回ります。

受託会社の見積もりがどう作られ、仕様変更がどこで揉めるのかを内側から知っている人は、ベンダーの提案が妥当かどうかを見抜けます。この視点は受託出身者ならではの強みとして評価されやすい部分です。社内SEの転職事情は「社内SEへの転職は難しい？転職難易度が高い理由と受かるための対策」、開発経験の活かし方は「開発エンジニアから社内SEへ転職｜コードは書き続けられる？違い・後悔しない求人の選び方」で詳しく解説しています。

元請け中心の受託会社｜受託の働き方は好きな人

受託開発の仕事自体は好きで、つらいのは今の会社の商流やマネジメントだけという人は、業態を変えずに商流だけを上げる道があります。会社の見分け方は前述のとおりで、配属される案件の立ち位置まで確認するのが前提です。

請負の一括契約ではなく、準委任で顧客と一緒にアジャイル開発を進める受託会社もあります。仕様を最初に固めきらず、短い期間で動くものを見せながら優先順位を調整していく進め方なので、仕様変更が即残業につながる構造から抜けやすいのが特徴です。受託のまま働き方を変えたい人は、こうした会社も候補に入れてみてください。

SIer出身ならWeb系という選択肢も

SIer系の受託で業務システムを経験してきた人なら、Web系企業への転職も現実的です。設計書を書いてきた経験や業務理解はWeb系でも評価されますが、開発スピードや技術選定の考え方の違いに合わせた準備が必要になります。タイプ別の準備や経験の伝え方は「SIerからWeb系への転職は難しい？評価される経験・年収の変化・タイプ別の準備を徹底解説！」にまとめています。

フリーランス｜受託の経験がそのまま商売になる

要件整理、見積もり、顧客との調整、納品まで一通り経験しているなら、その流れはフリーランスの仕事そのものです。会社員時代は営業やPMが担っていた条件交渉や契約まわりも自分の責任になりますが、受託で顧客対応まで経験している人ほど立ち上がりは早くなります。独立のリスクや会社員との違いは「フリーランスエンジニアやめとけは本当？会社員を辞める前に知っておきたいこと」で確認しておきましょう。

受託開発のやめとけに関するよくある質問

未経験の最初の1社が受託開発会社なのはあり？

ありです。元請けか二次請けで、新人の教育やコードレビューの体制がある受託会社なら、実務でシステムを作り切る経験を早い段階で積めます。

避けたいのは、研修後は案件に配属としか書かれておらず、配属先の商流も担当工程も説明されない会社です。面接では、新人が最初に担当する仕事と、コードレビューを誰がどう行うのかまで聞いておきましょう。未経験可の求人の見極め方は未経験OKのエンジニア求人が怪しい？元エンジニアが見極め方を伝授も参考になります。

SESと受託開発なら、どちらがまし？

契約の名前だけでは決まりません。受託開発を名乗っていても実態は準委任で顧客先に常駐する会社がありますし、SESでも技術力の高いチームに入って幅広い工程を経験できる現場はあります。

比べるべきなのは、どこで働くのか、誰から仕事を受けるのか、どの工程を担当するのかの3つです。社内で開発し、元請けか二次請けの立場で、設計から関われる受託会社であれば、一般的な常駐型のSESより経験の幅は広がります。

受託開発でも残業が少ない会社はある？

あります。見積もりにエンジニアが関わり、仕様変更を追加工数として扱えている会社は、納期前の繁忙期があっても慢性的な長時間労働にはなりにくいです。

面接で平均残業時間を聞く場合は、年間平均だけでなく、納期前の月にどのくらい増えるのか、そのあと休みは取れているのかまで聞くと、数字の裏にある働き方が見えてきます。

受託開発の経験は、自社開発の選考で不利になる？

不利になるのは経験そのものではなく、伝え方です。受託で3年間Javaを書きました、だけでは、どこまで任せられる人なのか採用側には分かりません。

物流会社向けのシステムで要件整理から参加し、在庫管理機能の設計から実装、テストまで担当した、と工程と業務まで具体的に話せれば、受託出身であることはむしろプラスに働きます。自社開発企業の選考で落ちる原因と対策は「自社開発企業に受からないのはなぜ？厳しいと言われる理由と選考段階別の対処法」で詳しく解説しています。

まとめ

受託開発はやめとけ、という言葉は、受託という業態全体への評価としては半分外れています。当たるのは、商流が深く、仕様変更を無償で飲み込み、無理な見積もりを現場の残業で埋めている会社です。

今の職場について判断するなら、まず取引先と担当工程から自社の立ち位置を確かめ、次に仕様変更と見積もりの扱いを振り返ってみてください。そこに問題があるなら、変えるべきは会社です。元請けや二次請けで変更管理が機能している受託会社に移れば、受託のまま働き方を立て直せます。

作ったものを育てたい、技術を自分で選びたいという気持ちがつらさの正体なら、話は別です。変えるべきは業態で、自社開発企業や社内SEへの転職を考える段階に来ています。

どちらの道を選ぶにしても、商流や開発体制は外から見えにくい情報です。求人票と面接だけで判断せず、企業の内情を知っている第三者に確認しながら進めるのが、受託からの転職で失敗しないための近道になります。

もう一度「受託開発はやめとけって本当？つらいと言われる理由と、やめとけが当たる会社・当たらない会社の見分け方！」を読む ↑

受託開発からの転職を相談できる転職エージェント3選

受託開発から転職するときにやっかいなのは、元請け案件が多い、上流工程から携われる、と書かれた求人の実態を外から確かめにくいことです。ここで紹介する3社はいずれもIT・Web領域に特化しており、求人票に出てこない商流や開発体制について相談しやすいエージェントです。1社だけに頼らず、2社ほどに登録して同じ企業の情報を突き合わせると精度が上がります。

レバテックキャリア

レバテックキャリアは、ITエンジニアとクリエイターの転職支援に特化したエージェントです。担当者が企業の開発現場の情報をよく把握しており、技術スタックや開発体制といった踏み込んだ話が通じやすいのが強みです。

受託で2〜3年以上の実務経験があり、次は自社開発企業や元請け寄りの会社に移りたい人と相性がいいでしょう。面談では、三次請けは避けたい、要件定義から関われる環境に移りたいと、今の不満を具体的に伝えると紹介される求人の精度が変わります。気になる求人があれば、配属先チームの受託比率や、入社した人が実際に担当している工程まで聞いてみてください。

レバテックキャリアの詳細はこちら
レバテックキャリアの評判・口コミはこちら

テックゴー

テックゴーは、経験者エンジニアの転職支援に強みを持つエージェントで、面接対策の手厚さに定評があります。

受託出身者がつまずきやすいのは、実際には要件定義や顧客折衝まで経験しているのに、職務経歴書や面接では開発・テスト担当としか伝えられていないケースです。テックゴーでは模擬面接を重ねながら、受託で積んだ経験を自社開発企業の面接官に伝わる言葉へ置き換える練習ができます。受託経験をどう語ればいいか分からない人ほど、使う価値があるサービスです。

テックゴーの詳細はこちら
テックゴーの評判・口コミはこちら

ギークリー

ギークリーは、IT・Web・ゲーム業界に特化した転職エージェントです。自社サービス企業から受託寄りの企業まで、同じ業界内の求人を幅広く比較できるのが特徴です。

受託を続けるか、自社開発に行くか、社内SEも視野に入れるか。まだ方向性が固まっていない段階で相談するのに向いています。同じバックエンドエンジニアでも、要件定義の経験があるのか、特定業界の知識があるのかで狙える求人は変わるため、自分の経験がどのタイプの企業で評価されるのかを確かめながら転職先を絞り込めます。

ギークリーの詳細はこちら
ギークリーの評判・口コミはこちら

自社開発企業に強いエージェントをほかにも比較したい人は、自社開発企業への転職に強いエージェント・サイト9選―未経験OKや社内SE向けも！で各社の特徴とメリット・デメリットをまとめています。