先日、転職を考えているエンジニアの方と話していて、こんな言葉が出てきました。「前の現場、入ってみたら聞いてた話と違ったんです」。面談のときに説明された内容と、実際の働き方がずれていた、と言うのです。残業の指示が誰から飛んでくるのか、自分の仕事が何で評価されるのか、そのあたりが曖昧なまま現場に入ってしまった、と。

話を聞きながら、私はその「ずれ」の多くが、契約の形を知らないまま働き始めたことから来ているように感じました。同じようにコードを書く仕事でも、どんな契約で現場に入っているかで、働き方も、責任の重さも、評価のされ方も変わります。ここを知っているかどうかで、会社選びの見え方はかなり変わると思っています。

今日は、エンジニアにあまり丁寧に説明されないまま流されがちな「準委任」と「請負」という二つの契約について、創業して1年、SESと受託開発の両方を見てきた立場から書いてみます。少し地味なテーマですが、知っておくと損のない話です。

2026年になって、社内に開発を取り戻す内製化の動きや、受託で外に任せる動きが、どちらも活発になってきました。エンジニア一人ひとりにとっても、自分がどの立場で開発に関わっているのかを意識する場面が増えています。だからこそ、契約の話を一度きちんとしておきたいと思いました。

「準委任」と「請負」は、約束しているものが違う

ざっくり言うと、準委任は「働く時間と労力」を提供する契約で、請負は「完成したもの」を提供する契約です。約束しているものが、そもそも違います。

準委任は、決められた期間や時間のなかで、エンジニアとして力を尽くすことに対して対価が支払われます。客先に常駐するタイプのSES契約は、多くがこの形です。成果物そのものの完成を約束しているわけではないので、「最後まで一人で作りきる責任」が個人に重くのしかかることは、本来はありません。求められているのは、その期間しっかり手を動かして貢献することです。

一方の請負は、「このシステムを、この条件で、いつまでに完成させます」という約束です。受託開発の多くがこの形になります。完成して初めて対価が発生するので、途中で何が起きても、決めた期日までに動くものを納める責任がチーム側にあります。作りきって、はじめてお金になる。そういう契約です。

料理にたとえると、準委任は「厨房に入って、その時間しっかり腕をふるう」働き方で、請負は「一皿を完成させて出す」働き方に近いかもしれません。どちらも料理人の仕事ですが、約束しているものが時間なのか一皿なのかで、求められる動き方は変わります。

ひとつ注意したいのは、準委任が楽で請負がきつい、という単純な話ではないことです。準委任でも責任感を持って深く関わる人はいますし、請負でも無理のないスケジュールで気持ちよく作れる現場はあります。契約はあくまで枠組みで、そのなかをどう過ごすかは、会社と現場の運用次第です。だから枠組みだけで決めつけず、実際の運用とセットで見てほしいのです。

この違いは、紙の上だけの話に見えて、実は日々の働き方に直結しています。順番に見ていきます。

「この残業、誰のため？」も、契約をたどると説明がつく

準委任で現場に入っている場合、エンジニアへの指揮命令が契約上どこにあるのかは、本来きちんと整理されているはずのものです。誰の指示で動くのか、勤務時間は誰が管理するのか。ここが曖昧なまま、常駐先の都合で残業が当たり前になっていたり、指示の出どころがはっきりしないまま遅くまで働かされていたりすると、それは契約と実態がずれているサインかもしれません。

たとえば、定時の少し前に常駐先の担当者から「これ今日中にお願い」と直接振られる。自社の誰にも相談できず、断る理由も見つからないまま、気づけば毎晩遅くなっている。よく聞く話です。このとき「この残業、そもそも誰のために、どの契約に基づいてやっているんだろう」と立ち止まれるかどうかで、その後の消耗の仕方が変わってきます。

自分がどんな契約で現場にいるのかを知っていると、もやもやの正体が見えてきます。逆に何も知らないと、なんとなく断れない空気のなかで、ただ削られてしまう。知識は、こういうときの小さな盾になります。

請負の場合は、そもそも成果物に対しての契約なので、「何時間働くか」より「いつまでに何を納めるか」が中心になります。だから、納期が近づくと負荷が高まりやすいという別の特徴があります。完成責任があるぶん、スケジュールが厳しければ自分たちで巻き取らないといけない場面も出てくる。ここはきれいごとを言っても始まらないので、正直に書いておきます。

誤解してほしくないのは、準委任の現場が悪いという話ではないことです。指揮命令の所在がはっきりしていて、残業も無理なく管理され、何を任されているかが明確な準委任の現場は、たくさんあります。腰を据えて技術を磨くには、むしろ良い環境にもなります。問題なのは契約そのものではなく、契約と実態がずれたまま放置されることのほうです。

どちらが良い悪いではなく、性格が違うのだと思います。決まった範囲で安定して力を出す働き方が合う人もいれば、最後まで作りきる手応えを求める人もいます。自分がどちらに向いているかを知らないまま、たまたま入った現場の契約形態に合わせて消耗してしまうのは、もったいない。

評価される基準も、契約によってずれていく

見落とされがちなのですが、何で評価されるかも契約によって変わります。

準委任の現場では、目の前のタスクをどれだけ丁寧に、安定してこなせるかが見られやすい。決められた範囲のなかで信頼を積み上げることが、次の継続や次の話につながっていきます。ただ、「自分はもっと上流から関わりたい」「設計の段階から考えたい」と思っても、契約で任されている範囲の外だと、なかなか手を出しづらいこともあります。やる気はあるのに、契約の壁で止まる。これがしんどい人もいます。

実際、ある現場で「もっと提案したいのに、言われた範囲しかやらせてもらえない」と感じていたエンジニアが、別の請負のプロジェクトに移ったとたん、設計の議論から関わって生き生きと働き出した、という話があります。本人の能力は何も変わっていません。変わったのは、関われる範囲を決めていた契約のほうでした。

請負だと、評価の軸が変わります。問われるのは成果物の品質と、チームとして完成までたどり着けたか。個人がどれだけ速くコードを書いたかよりも、全体が納まったかどうかが大事になります。だから、ひとりで抱え込むより、周りと連携して全体を前に進める動き方のほうが効いてくる。同じエンジニアでも、評価されるポイントがまるで違うのです。

転職を考えるとき、スキルや条件の前に「自分はどう評価されたいのか」を一度言葉にしておくと、目の前の現場の契約形態と、自分の望む働き方が噛み合っているかを確かめやすくなります。ここがずれていると、どれだけ頑張っても「評価されていない気がする」という感覚が残りがちです。

「言われたことを安定してこなすのが得意」なのか、「ゴールから逆算して全体を動かすのが好き」なのか。どちらが上というものではなく、自分の効きどころがどちらにあるかです。それが分かっていると、契約の話を聞いたときに、この現場は自分に合いそうかどうかが、肌感覚で判断できるようになります。

線引きが曖昧な現場は、なぜ生まれてしまうのか

ここまで整理して書くと、契約はきれいに分かれているように見えます。でも現実には、線引きが曖昧になっている現場もあります。

たとえば、準委任のはずなのに、常駐先から直接こまかい指示が飛んでくる。勤怠も実質的には常駐先が握っていて、自社の影は薄い。こうなると、誰に従えばいいのか分からないまま、責任だけがなんとなく重くのしかかる状態に近づいていきます。世間で「偽装請負」と呼ばれるのは、おおよそこういう、契約の建て付けと現場の実態がずれた状況のことです。

こうしたグレーは、必ずしも誰かの強い悪意から生まれるわけではありません。下請けの構造が何層にもなっていくほど、間に入る会社が増え、現場の実態と契約の建て付けがずれていきやすい。そして、いちばん末端にいるエンジニアが、その曖昧さを引き受けることになりがちです。本人は何も悪くないのに、居心地の悪さだけを背負わされる。

私自身がエンジニアとして、そして経営する側として現場を見てきたなかでも、契約と実態を誠実にそろえている会社と、そこが緩い会社の差は、確かにありました。これは制度の立派さというより、姿勢の問題だと感じています。きれいに整える手間をかけているかどうか。そこに会社の素が出ます。

契約を知っていると、会社選びの解像度が上がる

ここまで読んでくださった方に、いちばん伝えたいことを書きます。契約形態は、会社を見極めるためのもう一つの目になります。

カジュアル面談や条件提示のときに、こう聞いてみてください。今回は準委任なのか請負なのか。指揮命令はどこにあるのか。残業はどう扱われるのか。常駐先と自社の役割分担はどうなっているのか。具体的に、淀みなく答えが返ってくる会社は、自社のエンジニアがどんな契約でどう働いているかを、ちゃんと把握しています。逆に、ここで言葉が濁ったり、はぐらかされたりする会社は、入ってから「聞いてた話と違う」が起きやすい。私はそう見ています。

スキルや条件はみんな確認します。でも、その仕事を「どんな契約で、誰の指揮命令のもとで」やるのかは、案外そのまま流されてしまう。実は、入社後の働き心地を左右するものが、そこに隠れています。質問してみて返ってくる答えの具体度に、その会社の誠実さが出ます。難しい用語で武装する必要はありません。素朴に聞いて、相手がどう答えるかを見るだけで十分です。

もちろん、契約形態だけで会社の良し悪しが決まるわけではありません。準委任の現場で大きく成長する人もいれば、請負だからといって全部がうまくいくわけでもない。大事なのは、自分がどんな働き方をしたいのかを持ったうえで、それと現場の枠組みが噛み合っているかを確かめることです。契約は、その確認をするための共通言語のようなものだと思っています。

私たちが、最初に契約の話をする理由

Codenceは、SESと、立ち上げ中の受託開発の両方をやっています。だからこそ、準委任の現場に入ってもらうときも、請負で一緒に作るときも、「これはどういう契約で、あなたはどこまで任されて、何で評価されるのか」を、最初にできるだけ正直に話すようにしています。良い面だけでなく、しんどくなりがちなところも含めて。

創業して１年、まだ小さな会社です。立派な制度がすべてそろっているわけではありません。それでも、契約と実態をそろえること、聞かれたことに濁さず答えること。ここは、規模に関係なくやれることだと思っています。むしろ、そこを曖昧にしたままエンジニアに無理をさせる会社にだけは、なりたくないのです。創業期だからこそ、最初の一人ひとりとの向き合い方に、後々の会社の色が出ると感じています。

もしあなたが、次の現場では「聞いてた話と違う」を起こしたくないと感じているなら、一度カジュアルに話せたらうれしいです。準委任の現場での働き方も、請負で成果物を作りきる経験も、どちらの話もできます。受託開発をゼロから一緒に立ち上げていく仲間も探しているので、よければ下の募集ものぞいてみてください。お互いの「聞いてた話」と「実際」がそろう相手と出会えたら、それがいちばんいいと思っています。