「言った通りに作ってもらえると思っていたのに、追加費用を請求された」「毎週の定例会議で進捗を聞いているはずなのに、納品されたものが想像と違う」。中小企業の経営者や情報システム担当者から、こうした声を聞くことは少なくありません。原因の多くは、エンジニアの技術力でも、担当者の説明不足でもなく、契約形態の選び方そのものにあります。
業務システムの開発を外部に発注するとき、必ず選ばなければならないのが「準委任契約」か「請負契約」かという二択です。この選択を、法務担当者に任せきりにしたり、開発会社のテンプレートをそのまま使ったりしていないでしょうか。実はこの契約形態の違いこそが、プロジェクトの半年後、一年後の関係性を決めてしまう、最も重要な意思決定のひとつです。
ある製造業の会社では、在庫管理システムの刷新を「まずは請負契約で、要件定義から納品まで一式お願いします」と発注しました。ところが現場の業務は複雑で、要件定義の段階では見えていなかった例外処理が次々と出てきます。開発会社は「契約範囲外の追加開発」として都度見積もりを出し、当初300万円だった予算は最終的に550万円まで膨らみました。逆に別のIT企業では、システムの根幹となる基盤部分を準委任契約のエンジニアに任せた結果、担当者が途中で離脱し、引き継ぎもないまま開発が止まってしまったケースもあります。どちらも契約自体が間違っていたわけではありません。自社のプロジェクトの性質と、契約形態が噛み合っていなかっただけなのです。
この記事では、準委任契約と請負契約の違いを、条文の言葉ではなく発注者の実感として理解できるように整理し、自社がどちらを選ぶべきかの判断軸まで踏み込んで解説します。決断を先延ばしにできない立場にいる、すべての発注担当者のための記事です。
準委任契約とは何か 発注者目線での実務感覚
準委任契約は、ひとことで言えば「特定の業務を、専門家として遂行することを約束する契約」です。成果物の完成そのものを約束するのではなく、決められた時間や期間の中で、専門知識と技術力を尽くして働くことを契約の対象とします。
発注者の感覚に置き換えると、準委任契約は「エンジニアやチームを、期間限定で自社の一員として迎え入れる」イメージに近いものです。毎週、あるいは毎日、進捗の相談をしながら一緒に開発を進めていく。要件が固まりきっていない段階からでも着手でき、走りながら仕様を詰めていくことができます。これは、事業のスピードを優先したい経営者にとって大きな利点です。市場の変化に合わせて仕様を変えたい、あるいは自社の業務自体がまだ言語化しきれていないという段階でも、準委任契約であれば「一緒に考えながら形にしていく」という進め方が可能になります。
一方で、準委任契約には「完成の保証がない」という側面もあります。契約上、開発会社が約束しているのは成果物の納品ではなく、専門家としての誠実な業務遂行です。そのため、プロジェクトの舵取りを発注者側がある程度担う覚悟が必要になります。エンジニアと二人三脚で走る以上、発注者自身が「今何を作っているのか」「次に何を決めるべきか」を把握し続ける責任を負うことになるのです。これは負担であると同時に、自社のシステムを自社の手でコントロールできるという安心感でもあります。
請負契約とは何か 発注者目線での実務感覚
請負契約は、「決められた成果物を、期日までに完成させて納品することを約束する契約」です。準委任契約が働き方を約束するのに対し、請負契約は結果を約束します。仕様書に書かれた機能が動くシステムとして納品されること、それ自体が契約の目的になります。
発注者の感覚で言えば、請負契約は「完成品を注文する」感覚に近いものです。オーダーメイドの家具を発注するときのように、こちらが望む仕様を明確に伝えれば、あとは職人であるエンジニアが責任を持って完成させてくれる。要件定義さえしっかりできていれば、発注後の日々の管理負担は準委任契約に比べて軽くなります。忙しい経営者や、専任の情報システム担当者を置けない中小企業にとって、これは大きな魅力です。
ただし、この安心感は「要件が最初から固まっていること」を前提にしています。仕様書に書かれていない要望は、原則として契約の範囲外です。プロジェクトが進む中で「やっぱりこの機能も欲しい」「この画面はこうしてほしい」という要望が出てくるのは自然なことですが、請負契約においてそれは追加契約、つまり追加費用の対象になります。契約時点でどこまで厳密に仕様を詰められるかが、プロジェクトの成否とコストを大きく左右します。
両者の違いを実務インパクトで比較する
言葉の定義だけを聞くと似たように感じられるかもしれませんが、実際にプロジェクトを進めるうえでの手触りはまったく異なります。発注担当者が現場で直面する具体的な場面ごとに比較してみます。
責任の所在
準委任契約では、成果物が完成しなかった場合でも、開発会社が誠実に業務を遂行していれば契約違反にはなりません。責任の所在は「プロジェクトを牽引した発注者」と「専門知識を提供したエンジニア」の双方に分散します。請負契約では、完成責任は開発会社にあります。納品されたものに不具合があれば、契約不適合責任として無償の修正を求めることができます。責任の重さで見れば請負契約の方が発注者に有利に見えますが、その分、仕様を明確に伝える責任は発注者側に重くのしかかります。
追加要望への対応
準委任契約であれば、追加の要望が出たときも、稼働時間の中で柔軟に対応してもらえる可能性が高くなります。もちろん時間が足りなくなればスケジュールの調整は必要ですが、契約変更の手続きを都度踏む必要はありません。請負契約では、仕様書にない要望はすべて追加見積もりの対象です。ここで発注者と開発会社の間に温度差が生まれ、トラブルに発展するケースが最も多い場面でもあります。「この程度の変更は当然含まれると思っていた」という発注者側の感覚と、「契約書に書かれていない以上、追加費用が発生する」という開発会社側の立場が正面からぶつかるのです。
費用の見積もり方
準委任契約は、多くの場合、エンジニアの稼働時間や期間に応じた費用体系になります。プロジェクトが長引けば費用は増え、早く終われば費用は抑えられます。予算の上限が読みにくい反面、無駄な機能を作り込まずに必要な分だけ発注するという柔軟な運用もできます。請負契約は、契約時点で総額が確定します。予算計画は立てやすい一方、その金額の中には「仕様変更のリスク分」が織り込まれていることも多く、当初提示される見積もりが準委任契約より高く感じられることがあります。
進捗管理の仕方
準委任契約では、発注者自身が定期的にプロジェクトの状況を確認し、時には方向性を示す必要があります。エンジニアと二人三脚で走る分、発注者側の関与度合いがプロジェクトの質に直結します。請負契約では、完成までのプロセスは基本的に開発会社に委ねられます。中間報告はあっても、発注者が細部まで管理する必要は薄く、その分、完成品を見るまでは不安を抱えたまま待つことになります。
自社はどちらを選ぶべきか 判断のための3つの軸
ここまでの違いを踏まえて、自社のプロジェクトに当てはめて考えてみましょう。判断軸は大きく三つあります。
- 要件がどれだけ固まっているか。業務フローが明確で、画面や機能の仕様を具体的に言語化できるなら請負契約が向いています。逆に、そもそも自社の業務自体が整理されておらず、開発を通じて業務プロセスを見直していきたいという段階であれば、準委任契約で走りながら固めていく方が現実的です。
- 並走したいか、任せきりにしたいか。自社に情報システム担当者がいて、日々の意思決定にコミットできる体制があるなら、準委任契約の柔軟さを活かせます。専任担当者を置く余裕がなく、発注したらできるだけ手離れさせたいのであれば、責任の所在が明確な請負契約の方が安心です。
- 予算の性質。総額を確定させて社内稟議を通したいなら請負契約、状況を見ながら投資額を調整していきたいなら準委任契約が適しています。
多くのプロジェクトでは、実はこの二つを組み合わせることが最も現実的な解になります。要件定義や業務分析のフェーズは準委任契約で、業務を熟知したエンジニアと一緒に本当に必要なものを見極める。仕様が固まった開発フェーズは請負契約に切り替えて、責任の所在を明確にしたうえで完成まで走ってもらう。この二段階の進め方は、決して器用貧乏な選択ではなく、システム開発の実務においてはむしろ王道と言えるやり方です。
よくある失敗パターン 契約形態のミスマッチが生む現場の混乱
ある地方の卸売業では、経営者が「早く形にしたい」という思いから、要件がほとんど固まっていない段階で請負契約を締結してしまいました。開発会社は限られた情報の中で仕様書を作成し、その通りにシステムを完成させます。ところが納品後、現場から「これでは実際の業務が回らない」という声が噴出しました。契約上は完成しているため、修正は追加契約扱いになり、当初500万円だった開発費に加えて200万円の追加費用が発生。経営者は「言った通りに作ってもらったはずなのに」と困惑し、開発会社は「仕様書通りに作った」と主張する、典型的なすれ違いが起きました。
逆のパターンもあります。あるサービス業の企業では、基幹システムの刷新を準委任契約で進めていましたが、発注者側に開発の進捗を管理する担当者がおらず、開発会社任せの状態が半年続きました。エンジニアは真面目に稼働していたものの、方向性を示す人がいないため、優先順位の低い機能ばかりが作り込まれ、肝心の在庫連携機能は着手すらされていませんでした。準委任契約は誠実な業務遂行を約束するものであって、成果物の完成を約束するものではないという前提を、発注者が理解していなかったために起きたトラブルです。
これらの失敗に共通しているのは、契約形態そのものが間違っていたのではなく、自社のプロジェクトの性質と契約形態の相性を見誤ったことです。要件が固まっていないのに請負契約を選べば、双方が疲弊する追加費用の応酬になります。並走する体制がないのに準委任契約を選べば、プロジェクトは漂流します。
まとめ 契約形態は、誰と、どう働きたいかの選択でもある
準委任契約と請負契約の違いは、単なる法律上の分類ではありません。それは、外部のエンジニアとどのような関係を築きながらシステムを作っていくかという、経営者自身の働き方の選択でもあります。すべてを任せて安心を得たいのか、それとも自らも汗をかきながら一緒に作り上げていきたいのか。どちらが正しいということはなく、自社の状況とプロジェクトの性質に合わせて選ぶことが唯一の正解です。
この選択に正面から向き合うことは、決して容易ではありません。日々の経営判断に追われながら、専門用語が並ぶ契約書と格闘し、社内の期待と外部パートナーの現実の間で調整を続ける。それでも、この一つひとつの決断の積み重ねが、会社の未来を支えるシステムを形にしていきます。壁を越えて挑む人には、いつも正解のない選択がついて回ります。だからこそ、その重みを正しく理解したうえで下す決断には、必ず価値があるのです。