はじめに ― 契約書の一文で「揉め方」が変わる
先代からシステムや基幹業務まわりのIT発注を引き継いだとき、多くの後継社長が最初にぶつかる壁は「見積もり」でも「要件」でもなく、契約書に書かれた契約類型です。開発会社から届く契約書のタイトルや条文の中に、「請負」と書かれているか「準委任」と書かれているかで、トラブルが起きたときの結果はまったく違うものになります。
先代の時代から付き合いのある開発会社であれば、「昔からこの内容でやっているから」という理由だけで、深く考えずに契約を継続しているケースも珍しくありません。しかし、経営を引き継いだ以上、契約内容を理解しないまま押印を続けるのはリスクです。特に、システムが完成しなかったとき、動かなかったとき、追加費用を請求されたときに「そもそもこの契約ではどちらの責任なのか」を判断できないと、経営者として不利な立場に立たされます。
さらに厄介なのは、多くの後継社長が「契約書は総務や先代が管理していたもので、自分は中身をきちんと読んだことがない」という状態で経営を引き継いでいる点です。先代の経営スタイルによっては、「昔からの付き合いだから」「向こうを信頼しているから」という理由で、契約書自体がほとんど更新されず、口約束や継続発注の積み重ねだけでシステム保守が続いているケースすらあります。これは決して珍しい話ではなく、中小企業のIT発注の現場ではむしろよくある状況です。
しかし、事業承継のタイミングは、こうした「なんとなく続いてきた契約」を見直す絶好の機会でもあります。新しい経営者として一度立ち止まり、「この契約は請負なのか準委任なのか」「今の取引実態にその契約類型は合っているのか」を確認しておくことは、将来のトラブルを未然に防ぐだけでなく、開発会社との対等な関係を築く第一歩にもなります。
この記事では、IT発注における2つの代表的な契約類型「請負契約」と「準委任契約」について、法律的な建前だけでなく、実務でどう違いが表れるか、後継社長が契約書のどこを見ればよいかを具体的に解説します。専門用語を極力かみ砕きながら、実際に起こりがちな失敗パターンや、契約書チェックの実践的なポイントまで、順を追って説明していきます。契約を結ぶ前段階として、そもそも何を決めておくべきかは刷新を開発会社に相談する前に、決めておきたい3つのことで扱っている。
請負契約と準委任契約、法律上の定義
まず前提となる法律の条文を確認しておきます。日本の民法では、請負と委任（準委任）はそれぞれ別の条文で定義されている、性格の異なる契約類型です。
請負契約とは
民法632条は、請負契約を「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる」と定義しています。
ポイントは「仕事の完成」を約束する契約だという点です。発注者から見れば、「動くシステムを納品してもらう」ことを契約の目的にできる、非常にわかりやすい契約形態です。仕事が完成しなければ、原則として報酬を請求する権利が発生しません（もっとも2020年の民法改正で、途中終了時の割合的な報酬請求が認められる場合があるなど細かい修正は入っています）。
この「完成義務」を負う契約類型を、つぎてなびでは請負契約と呼んでいます。ITシステム開発の文脈で「請負」という言葉が出てきたら、まずはこの「完成させる責任が開発会社側にある」という一点を思い出してください。
なお、ここで注意したいのは、「完成」の意味は必ずしも「発注者が満足する出来栄えになっていること」ではないという点です。法律上の「完成」は、あくまで契約で定めた仕様・作業範囲を満たしていることを指します。つまり、契約時点で「何をもって完成とするか」を具体的に定義しておかなければ、後になって「これは完成と言えるのか、言えないのか」で発注者と開発会社の間に深刻な認識のズレが生じます。中小企業のIT発注トラブルの多くは、実はこの「完成の定義があいまいだった」ことに起因しています。
準委任契約とは
一方、民法656条は準委任契約について、「法律行為でない事務の委託については、委任に関する規定を準用する」と定めています。委任・準委任の受託者が負う義務は、民法644条に定める「善良な管理者の注意をもって、委任事務を処理する義務」（善管注意義務）です。
つまり準委任契約は、「仕事の完成」ではなく「一定の水準で業務を遂行すること」を約束する契約です。発注者から見れば、「専門的な技術者が、真摯に、専門家としての注意義務を尽くして作業してくれること」を契約の目的にする形になります。成果物が完成するかどうかは契約上の直接の義務ではありません。
システム開発の現場で準委任契約が使われる典型例は、要件定義工程、運用保守、技術顧問、常駐型のSES（システムエンジニアリングサービス）契約などです。
準委任契約には、報告義務の有無によって「履行割合型」と「成果完成型」の2種類があることも押さえておくとよいでしょう。履行割合型は、稼働した時間や工数に応じて報酬が発生する、いわゆる一般的な準委任契約です。成果完成型は、2020年施行の改正民法648条の2で新たに整理された類型で、業務の遂行によって得られる成果に対して報酬を支払う定めをする準委任契約を指します。成果完成型は請負契約に近い性質を持ちますが、あくまで「完成義務」ではなく「成果に対する報酬支払いの合意」である点で法的性質が異なります。契約書に「成果完成型準委任」といった記載がある場合は、通常の準委任契約とは報酬発生の条件が異なるため、個別に確認が必要です。
何がどう違うのか ― 5つの観点で比較する
抽象的な条文の説明だけではピンと来ないと思いますので、後継社長が実務で気にすべき5つの観点に分けて比較します。
観点1：完成義務があるかどうか
- 請負契約：仕事を完成させる義務がある。完成しなければ報酬は原則発生しない（一部の出来高部分を除く）。
- 準委任契約：完成義務はない。契約で定めた時間・工数の分、誠実に業務を遂行すれば、成果物が未完成でも報酬は発生する。
これが最大の違いです。「お金を払ったのにシステムが完成しない」という後継社長のよくある不満は、実は「請負だと思っていたら準委任契約だった」というケースが多くあります。契約書の表題や条文をよく確認してください。
観点2：契約不適合責任（旧・瑕疵担保責任）の有無
- 請負契約：納品後、契約内容と異なる不具合（契約不適合）が見つかった場合、発注者は開発会社に対して修補請求、代金減額請求、損害賠償請求、契約解除を求めることができます（民法562条〜564条、636条）。
- 準委任契約：完成物を前提とした契約ではないため、契約不適合責任の規定は原則として適用されません。業務の遂行に善管注意義務違反があった場合に、債務不履行として損害賠償を請求できるにとどまります。
つまり、納品後にバグが出た場合、請負契約なら「直してください」と当然に言えますが、準委任契約では「善管注意義務を怠っていた」ことを発注者側が立証しなければ、追加の修正を無償で求める根拠が弱くなります。
ここで多くの後継社長が誤解しやすいのが、「バグ」と「契約不適合」は必ずしもイコールではないという点です。契約不適合責任が発生するのは、あくまで契約書や仕様書で合意した内容と、実際の納品物が異なっている場合です。仕様書に明記されていなかった機能や、契約後に口頭で「あったらいいな」と伝えただけの要望が実装されていなくても、それは契約不適合には当たりません。この点でも、契約前に仕様をどこまで具体的に文書化できているかが、後々の交渉力を大きく左右します。
観点3：検収の位置づけ
請負契約では、成果物の完成を発注者が確認する「検収」という手続きが契約上の重要な区切りになります。検収に合格して初めて、開発会社の完成義務が履行されたことになり、報酬支払い義務が確定するのが一般的な契約実務です。検収書にサインをする、あるいは検収期間内に異議を申し立てなければ自動的に検収完了とみなす、といった条項が入っていることが多く、この検収条項の内容次第で発注者の権利義務が大きく変わります。
一方、準委任契約には本来「検収」という概念がありません。月次の稼働報告や作業報告書の確認はあっても、それは「仕事の完成」を承認する手続きではなく、あくまで「その期間、業務が遂行されたこと」の確認に過ぎません。それにもかかわらず、準委任契約の契約書に「検収」という言葉が紛れ込んでいることがあり、これは契約類型と条文の中身が矛盾している危険なサインです。契約書を見るときは、「請負」と書いてあるのに検収条項がない、逆に「準委任」と書いてあるのに検収条項がある、といったちぐはぐな契約書に注意してください。
検収は、発注者にとって「これで完成として受け入れます」という意思表示であると同時に、開発会社にとっては「これ以降の追加要望は別料金です」という区切りの意味も持ちます。検収前であれば、契約範囲内の不具合修正や調整は無償で対応してもらえるのが通常ですが、検収後に「やっぱりここも直してほしい」と依頼すると、それは追加の有償対応として扱われることが多くなります。後継社長としては、検収作業を「形式的なサイン業務」と軽視せず、実際に画面を動かし、業務フローに沿って一通り操作確認をしてから検収に応じる、という姿勢が重要です。特に、現場の従業員に実際の操作を試してもらい、フィードバックを集めてから検収するという手順を社内ルールとして定めておくと、検収後に「使ってみたら思っていたのと違った」というトラブルを防ぎやすくなります。
観点4：指揮命令関係と偽装請負のリスク
請負契約・準委任契約のいずれであっても、発注者が受注側の技術者に対して直接、業務の遂行方法や労働時間について具体的な指揮命令を行うことは、労働者派遣法上の「偽装請負」に該当するおそれがあります。特に、開発会社の技術者が発注者のオフィスに常駐して作業する場合には注意が必要です。
後継社長が特に誤解しやすいのは、「準委任契約なら、常駐させて細かく指示を出してもよい」という思い込みです。準委任契約であっても、指揮命令権は受託会社側にあり、発注者が直接技術者に指示を出す運用を続けると、実態は労働者派遣に近くなり、偽装請負と判断されるリスクがあります。指示を出したい場合は、受託会社の責任者（プロジェクトマネージャーなど）を窓口にする体制を整えることが重要です。
偽装請負と判断された場合、労働者派遣法・職業安定法違反として、発注者側にも行政指導や是正勧告の対象になり得るという点は見落とされがちです。「うちは発注しているだけで、雇っているわけではないから関係ない」と考えるのは危険です。実務的には、次のような運用になっていないか確認してください。
- 発注者の社員が、常駐している開発会社の技術者に対して、始業・終業時刻や休憩時間を直接指定している
- 発注者の社員が、その日の作業内容や作業順序を直接技術者に指示している
- 技術者の勤怠管理（有給申請や欠勤連絡）を発注者側で行っている
- 技術者を、発注者の組織図上の一員であるかのように扱い、社内会議で直接評価やフィードバックを行っている
これらに心当たりがある場合は、指揮命令の窓口を受託会社側の責任者に一本化する、あるいは常駐ではなくリモートでの成果物ベースのやり取りに切り替えるなど、契約と実態を一致させる見直しが必要です。
観点5：報酬の決め方（固定額か、精算型か）
- 請負契約：完成という結果に対して報酬を支払うため、多くの場合、契約時点で総額が固定されます（固定額請負）。仕様変更や追加要望が発生すると、追加の見積もり・追加契約が必要になるのが原則です。
- 準委任契約：稼働した時間・人数（工数）に応じて精算されることが多く（時間単価×稼働時間、いわゆる「準委任型・精算型」）、仕様の変更や試行錯誤があっても契約変更なしに柔軟に対応できます。ただし、稼働時間が伸びれば伸びるほど費用も増えていくため、青天井になりやすいという弱点もあります。
具体的な数字でイメージしてみましょう。仮に技術者の時間単価が8,000円、月の稼働時間が140時間程度だとすると、準委任契約での月額はおおよそ112万円前後になります。これが3ヶ月続けば336万円、6ヶ月続けば672万円という規模になります。要件定義フェーズであれば1〜2ヶ月程度で収まることが多いですが、「仕様が固まらないまま」ずるずると準委任契約を延長し続けると、当初の想定を大きく超える費用になることがあります。後継社長としては、準委任契約で発注する際は「いつまでに、何を確定させるフェーズなのか」というゴールと期限をあらかじめ開発会社とすり合わせておくことが、費用の青天井化を防ぐ実務上のコツです。
実務ではどう使い分けられているか
システム開発プロジェクトは、通常いくつかの工程に分かれます。工程ごとに向いている契約類型は異なり、実務では1つのプロジェクトの中で契約類型を使い分けるのが一般的です。
要件定義・設計フェーズ ― 準委任契約が向いている
プロジェクトの最初にある「何を作るか」を固める要件定義工程は、まだ仕様が固まっておらず「完成」の定義自体が定まっていません。このフェーズを無理に請負契約にすると、開発会社側は「何をもって完成とするか分からない」リスクを負うことになり、見積もりに過大な安全マージンを載せてくることがあります。そのため、要件定義フェーズは準委任契約で契約し、双方が協力しながら仕様を固めていくのが実務上一般的です。
つぎてなびの別記事で解説していますが、要件定義フェーズを乗り切るには、発注者側が「何を実現したいか」を整理した文書、いわゆる要件定義の土台をあらかじめ用意しておくと、準委任契約であっても稼働時間の見通しが立てやすくなり、費用が青天井になるリスクを抑えられます。
開発・実装フェーズ ― 請負契約が向いている
要件定義・設計が固まり、「何を作るか」が明確になった段階では、請負契約で「完成させて納品する」ことを約束してもらうのが発注者にとって有利です。仕様が固まっているため、開発会社側も見積もりを立てやすく、双方にとって合理的な契約形態です。
運用・保守フェーズ ― 準委任契約が向いている
システムが稼働した後の保守・運用は、「何を完成させるか」という性質の業務ではなく、日々のトラブル対応や軽微な改修、監視業務など、継続的な役務提供が中心になります。このフェーズは準委任契約（あるいは業務委託契約のなかで保守を準委任的に位置づける形）で契約するのが一般的です。
経済産業省のモデル契約書に見る「工程別契約」の考え方
「請負と準委任のどちらを選ぶべきか、業界標準の考え方はないのか」と疑問に思う後継社長も多いと思います。実は、経済産業省（旧・情報処理推進機構との連携事業を含む）は、ソフトウェア開発における取引の適正化を目的として、モデル取引・契約書を公表しています。これは法的な強制力を持つものではありませんが、システム開発業界における契約実務の「標準的な考え方」を示すものとして、発注者・開発会社の双方が参照する資料になっています。
このモデル契約書の大きな特徴は、システム開発を単一の契約でひとまとめにするのではなく、工程ごとに契約を分割し、それぞれの工程の性質に応じて請負・準委任を使い分けることを前提にしている点です。具体的には、おおむね次のような整理がなされています。
- 企画・要件定義：発注者と開発会社が共同で仕様を作り上げていく工程であり、成果物の完成を一方的に約束できる性質のものではないため、準委任契約が想定されています。
- 外部設計・内部設計：要件を技術的な設計に落とし込む工程で、要件定義同様に協働作業の色が強いため、準委任契約が想定されることが多いですが、要件が確定していれば請負契約とすることもあります。
- プログラミング・単体テスト・結合テスト：仕様がすでに確定しており、「完成」の基準を明確に定義しやすい工程のため、請負契約が想定されています。
- システムテスト・導入・受入支援：発注者側の業務に即した最終確認を行う工程であり、性質に応じて請負・準委任のいずれかが選ばれます。
- 運用・保守：継続的な役務提供の性質が強いため、準委任契約が想定されています。
後継社長が新しく開発会社と契約を結ぶ際、あるいは既存の契約を見直す際には、こうした工程別の考え方を知っているだけで、開発会社からの提案が業界標準に沿ったものかどうかを自分なりに判断できるようになります。逆に、要件定義から納品まで、性質の異なる全工程を一本の請負契約でひとまとめにしている契約書を提示された場合は、なぜそのような契約構成になっているのか、開発会社に理由を確認してみることをおすすめします。
下請法との関係にも注意する
自社の資本金規模によっては、開発会社との取引に「下請代金支払遅延等防止法」（下請法）が適用される場合があります。下請法は、発注者（親事業者）が下請事業者に対して優越的な立場を利用し、不当な代金減額や支払遅延、受領拒否などを行うことを禁止する法律です。
IT開発の委託は、下請法上の「情報成果物作成委託」に該当することがあり、自社の資本金が一定額を超え、開発会社の資本金がそれより小さい場合には、下請法の適用対象になり得ます。契約類型が請負であっても準委任であっても、下請法の適用可否は資本金要件で判断されるため、この点は契約類型の話とは別に確認しておく必要があります。
後継社長として気をつけたいのは、自社が発注者側の優位な立場にあるとき、無意識のうちに「検収を長期間保留する」「一方的に代金を減額する」「発注書面を交付しない」といった、下請法違反に該当し得る対応をしてしまわないようにすることです。先代の代からの取引先である開発会社に対しては、特に立場の非対称性を意識し、公正な取引慣行を保つことが、長期的に良好なパートナーシップを維持するうえでも重要です。先代から引き継いだ保守契約自体の点検方法は先代から引き継いだ保守契約、内容を確認せず放置していませんかでも取り上げている。
後継社長が契約書で確認すべき7つのチェックポイント
先代から引き継いだ契約書や、新たに提示された契約書を確認するときに見るべきポイントをリストにしました。
- 契約書のタイトルと条文の整合性を確認する：「業務委託契約書」というタイトルだけでは請負か準委任か分かりません。本文の条文（「甲は乙に対し、本件仕事の完成を委託し」なら請負寄り、「甲は乙に対し、本件業務の遂行を委託し」なら準委任寄り）を必ず確認してください。
- 報酬の定め方を確認する：固定総額か、時間単価×工数の精算型か。精算型の場合、上限（想定工数の上限）が定められているか確認してください。
- 検収条項の有無と内容を確認する：検収の期間、検収不合格時の対応（再修補の回数、期限）が明記されているか確認してください。検収期間が短すぎたり、「〇日以内に異議がなければ検収完了とみなす」という、みなし検収条項が発注者に不利な内容になっていないか注意が必要です。
- 契約不適合責任の期間を確認する：民法上のデフォルトは原則1年ですが、契約書で短縮・免責されているケースがあります。あまりに短い期間（例：検収後1ヶ月のみ）になっていないか確認してください。
- SOW（作業範囲記述書）や仕様書が契約に添付されているか確認する：請負契約であれば、何をもって「完成」とするかの基準になる作業範囲や仕様の記述が、契約書の別紙として添付されているべきです。これがないまま「一式」で契約している場合、完成の基準があいまいになり、後々のトラブルの火種になります。
- 偽装請負のリスクがある常駐契約になっていないか確認する：技術者が自社に常駐する契約の場合、指揮命令系統が受託会社側にあるかどうかを確認し、自社の従業員が直接技術者に細かい指示を出す運用になっていないか点検してください。
- 契約変更・追加費用のルールを確認する：仕様変更が発生した場合の見積もり・承認フローが明記されているか。ここがあいまいだと、「言った・言わない」の追加費用トラブルに発展しやすくなります。
これらの7項目は、法務の専門知識がなくても、契約書を読みながら1つずつ照らし合わせて確認できる内容です。すべての項目を一度に完璧にチェックしようとする必要はありません。まずは自社にとって特にリスクが大きいと感じる項目（多くの場合、報酬の定め方と検収条項です）から重点的に確認し、疑問点が残る場合は開発会社に直接質問するか、顧問弁護士や中小企業診断士などの専門家に相談することをおすすめします。特に、金額の大きいプロジェクトや、基幹業務に関わるシステムの契約については、契約締結前に専門家のレビューを一度挟んでおくと安心です。
よくある失敗パターン
失敗パターン1：「請負だと思っていたら準委任だった」
先代の代から続く開発会社との契約を、内容を精査せずに更新し続けていたところ、新しいシステムの追加開発を依頼した際に「今回のご依頼分は稼働時間分のご請求になります」と言われ、初めて準委任契約だったことに気づいた、というケースは少なくありません。「発注すれば完成品が納品される」という思い込みだけで契約を続けると、想定外の請求や、未完成のまま費用だけがかさむ事態を招きます。
失敗パターン2：要件定義前に無理やり請負契約で総額固定にしてしまう
逆に、「金額が青天井になるのが怖いから」という理由で、要件が固まっていない段階から無理に請負契約・総額固定で契約してしまうケースもあります。この場合、開発会社側は不確実性を見積もりに織り込むため、当初から割高な金額を提示してくることがあります。また、後から仕様変更が発生するたびに追加契約・追加費用の交渉が発生し、結果的に当初の想定より費用も期間も膨らむことがあります。
失敗パターン3：みなし検収条項に気づかず、不具合を見逃す
検収期間が「納品後5営業日以内に書面で異議を述べない場合は検収完了とみなす」という条項になっているケースで、繁忙期と重なり確認が遅れ、検収完了とみなされてしまった結果、後から見つかった不具合の修補を有償対応と言われてしまった、という失敗もあります。検収期間は自社の業務サイクルに照らして現実的な日数になっているか、契約前に必ず確認しておく必要があります。
失敗パターン4：準委任契約なのに完成責任を求めてしまい関係が悪化する
準委任契約で契約しているにもかかわらず、「お金を払っているのだから完成させるのが当然」という認識のまま開発会社に強く完成を迫り、関係が悪化してしまうケースもあります。契約類型ごとに、発注者が主張できる権利の範囲は法律で決まっています。準委任契約で完成責任を求めたい場合は、そもそも契約類型の見直しから交渉する必要があります。
このパターンは、特に事業承継の直後に起こりやすいという特徴があります。先代の時代は、開発会社の担当者と長年の信頼関係があり、「多少あいまいな契約でも、これまで通りやってくれるだろう」という暗黙の了解が機能していました。しかし、経営者が交代したことで、開発会社側も「新しい社長には、契約書に書いてある範囲できちんと対応方針を説明しよう」という姿勢に変わることがあります。これは開発会社が不誠実になったわけではなく、むしろ真っ当な対応です。後継社長としては、先代時代の「暗黙の了解」に頼るのではなく、契約書に立ち返って交渉する姿勢に切り替える必要があります。
失敗パターン5：契約変更の記録を残さず、後から言った・言わないになる
プロジェクトの途中で「やっぱりこの機能も追加してほしい」「この画面のデザインを変えてほしい」といった変更依頼は、どのプロジェクトでも一定数発生します。問題は、こうした変更依頼を口頭やチャットでのやり取りだけで済ませてしまい、正式な変更契約や覚書を残さないまま進めてしまうケースです。
請負契約の場合、当初の契約範囲を超える変更は、本来であれば追加の見積もり・追加契約が必要です。これを省略して進めてしまうと、納品段階になって「この機能は契約範囲外なので追加費用がかかります」と言われたり、逆に開発会社側が「言われた通りに無償で対応したはずなのに、今さら契約書にないと言われても困る」というトラブルになったりします。変更が発生するたびに、簡単でよいので書面（メールやチャットでも、内容と双方の承認が残っていれば実務上は有効な証跡になります）で記録を残す習慣をつけることが重要です。
失敗パターン6：契約書のひな形を先代の代から一度も見直していない
先代が契約した時点のひな形を、内容を精査せずにそのまま使い続けているケースもよく見られます。法律は民法改正をはじめ随時変わっており、古いひな形のままだと、現行法に合わない条文（旧・瑕疵担保責任の表現がそのまま残っている、消滅時効の期間が古い規定のままになっているなど）が残っている可能性があります。事業承継のタイミングで、顧問弁護士や中小企業診断士などの専門家に、現在使っている契約ひな形が最新の法制度に沿っているか、一度確認してもらうことをおすすめします。
発注時にどちらを選ぶべきか、判断の目安
後継社長が新規にIT発注をする際、どちらの契約類型を選ぶべきか迷ったときの目安は次の通りです。
- 仕様が明確に固まっている／固められる場合 → 請負契約を検討する。完成責任を負ってもらえるため、発注者にとって安心感がある。
- 仕様がまだ固まっていない、あるいは試行錯誤しながら進めたい場合 → 準委任契約を検討する。無理に請負契約にすると割高な見積もりになりやすい。
- まずは小さく試してみたい場合 → MVP（実用最小限の製品）的なアプローチで、小規模な範囲を先に請負契約で発注し、その後の拡張フェーズで契約類型を見直す、という段階的な進め方も有効です。いきなり全社基幹システムを一括で請負発注するのではなく、まず一部の業務・一部の部署だけで動く最小限の仕組みを作り、実際に使ってみてから本格開発に進むことで、仕様の手戻りや契約変更のリスクを抑えられます。
- 開発会社から提案依頼書への回答として見積もりを受け取る場合 → RFP（提案依頼書）の中で、どの工程をどちらの契約類型で進めたいかをあらかじめ明記しておくと、開発会社側も想定に沿った見積もりを出しやすくなります。RFPの段階で契約類型の希望を伝えておくことで、開発会社ごとに提示してくる見積もりの前提条件がバラバラになることを防ぎ、複数社を横並びで比較しやすくなるという副次的なメリットもあります。
- 国や自治体の補助金を活用して発注する場合 → IT導入補助金などの制度を利用する場合、対象経費として認められる契約形態や証憑の要件が細かく定められていることがあります。あらかじめ制度の要綱を確認し、契約書の形式が補助金の要件を満たしているか確認しておくことが重要です。特に、既製のパッケージ製品を使わずゼロから独自開発する場合は開発費用が大きくなりがちなため、対象経費の範囲や上限額を事前に確認しておくと安心です。
事業承継のタイミングだからこそ、契約を棚卸しする
ここまで、請負契約と準委任契約の違いと、実務上の注意点を解説してきました。最後に、後継社長という立場ならではの視点を補足します。
先代から会社を引き継いだ直後は、決算や税務、金融機関との関係、取引先への挨拶回りなど、優先すべき業務が山積みで、IT契約の見直しは後回しになりがちです。しかし、IT契約は一度放置すると、次に問題が表面化するのは「システムが止まった」「大きな追加費用を請求された」といった、経営に直接影響するタイミングになることが少なくありません。
事業承継のタイミングで契約を棚卸しすることには、次のようなメリットがあります。
- 既存の契約書を一覧化し、契約類型を分類できる：どの契約が請負で、どの契約が準委任なのかを一覧表にまとめておくだけで、自社がどこにどれだけの完成責任・費用リスクを負っているのかを可視化できます。
- 開発会社との関係を「先代との関係」から「自社との関係」に切り替えるきっかけになる：契約内容を確認する過程で開発会社の担当者と対話する機会が生まれ、新しい経営者として自社の考え方を伝える良い機会になります。
- 不要な契約や、実態と合わなくなった契約を整理できる：先代の時代に導入したものの、すでに使われていないシステムの保守契約が惰性で更新され続けている、というケースは中小企業では意外と多く見られます。棚卸しを機に、契約の要否そのものを見直すこともできます。
契約書の棚卸しは、法務の専門家でなくても、まずは「タイトル」「契約類型（請負か準委任か）」「契約期間」「金額」「自動更新の有無」を一覧表にするだけでも十分に価値があります。その一覧表をもとに、疑問点がある契約だけを弁護士や顧問の専門家に確認してもらうという進め方が、コストと手間のバランスが取れた現実的な方法です。
契約交渉に臨む前の心構え
最後に、後継社長が開発会社との契約交渉に臨む際の心構えについても触れておきます。契約類型の知識を身につけたからといって、それをそのまま開発会社にぶつけて一方的に契約変更を迫るのは得策ではありません。開発会社にも、それぞれの契約類型を選んでいる合理的な理由があることがほとんどです。
大切なのは、「なぜその契約類型になっているのか」を対等な立場で質問し、双方が納得できる契約条件を一緒に作り上げていく姿勢です。たとえば、「この工程を準委任契約にしているのはなぜですか」「検収期間をもう少し長くすることはできますか」といった具体的な質問を投げかけることで、開発会社側も誠実に説明してくれるはずです。逆に、契約類型について質問しても曖昧な返答しか返ってこない、あるいは契約内容の変更提案に一切応じない開発会社であれば、今後の付き合い方そのものを見直す判断材料にもなります。
契約は、発注者と開発会社のどちらか一方が有利になるように結ぶものではなく、双方がリスクと責任を適切に分担し合うための取り決めです。後継社長として契約類型の基本を理解しておくことは、開発会社と対等に議論できる土台を作り、長期的に信頼できるパートナーシップを築くための第一歩になります。
FAQ
Q1. 契約書に「業務委託契約」としか書かれていません。請負なのか準委任なのか、どこで判断すればよいですか。
A. タイトルではなく本文の条文で判断します。「仕事の完成」「納品」「検収」という言葉が中心に使われていれば請負契約の性格が強く、「業務の遂行」「善良な管理者の注意をもって」「稼働時間」「工数」という言葉が中心であれば準委任契約の性格が強いといえます。判断に迷う場合は、開発会社に「これは請負契約ですか、準委任契約ですか」と直接確認することをおすすめします。契約類型を尋ねられて明確に答えられない開発会社であれば、契約管理の意識自体を疑ったほうがよいかもしれません。
Q2. 先代の代から続く契約を、今のタイミングで請負から準委任に変更してもらうことは可能ですか。
A. 可能です。契約は双方の合意があればいつでも見直せます。ただし、開発会社側にもそれぞれの契約類型を選ぶ理由（保守フェーズは業務量が読みにくいため準委任にしている、など）があることが多いので、一方的に変更を求めるのではなく、なぜ契約類型を見直したいのか（例えば、完成責任を明確にしたい、費用の見通しを立てやすくしたいなど）を伝えた上で協議することをおすすめします。
Q3. 準委任契約で発注していますが、追加費用なしで直してもらう方法はありませんか。
A. 準委任契約では、成果物の契約不適合責任という枠組みでの無償修補は原則として求められません。ただし、開発会社の作業が善管注意義務を欠いていた（明らかな手抜き、専門家として通常求められる注意を払っていなかった等）ことを具体的に指摘できる場合は、債務不履行として無償対応や損害賠償を求められる余地があります。まずは契約書上の義務内容と、実際に何が起きたのかを照らし合わせ、必要であれば弁護士に相談することをおすすめします。なお、そもそも「追加費用なしで直してほしい」と感じる場面が頻発するようであれば、契約類型そのものが今のプロジェクトの実態に合っていない可能性もあります。仕様が固まっているのであれば、次期契約から請負契約への切り替えを検討する価値があります。
Q4. 1つのプロジェクトの中で、要件定義は準委任、開発は請負というように契約を分けるのは普通のことですか。
A. はい、システム開発業界では一般的な進め方です。経済産業省のモデル取引・契約書でも、要件定義や設計工程は準委任、開発・製造工程は請負という工程別の契約形態が例示されています。むしろ、要件が固まっていない段階から最初から最後まで一括で請負契約にしてしまうほうが、双方にとってリスクの高い契約の組み方だといえます。工程ごとに契約書を分けると事務手続きが増えるように感じるかもしれませんが、その分、各工程で誰がどこまでの責任を負うのかが明確になり、後々のトラブルを未然に防ぐ効果があります。後継社長としては、契約書が1本にまとまっているかどうかよりも、各工程の性質に応じた契約内容になっているかどうかを確認する視点を持つことが大切です。
契約形態の理解を踏まえて、発注前に確認すべき項目を一覧にしたのが先代の代からのシステム発注、契約・権利・データはここを確認するだ。
まとめ ― 契約類型は「誰がどこまで責任を負うか」の設計図
請負契約と準委任契約の違いは、単なる法律用語の違いではありません。「完成しなければお金を払わなくてよいのか」「不具合が出たら無償で直してもらえるのか」「費用は固定なのか、青天井になり得るのか」という、経営者にとって極めて実務的な問いに直結します。
この違いを一言で表すなら、請負契約は「結果に対してお金を払う契約」であり、準委任契約は「専門家の努力・時間に対してお金を払う契約」だということです。どちらが優れているというものではなく、プロジェクトのどの工程で、どのようなリスクを誰が負うのが合理的かによって、適した契約類型は変わります。仕様が固まっていない段階で無理に完成を約束させようとしても、開発会社は不確実性を見積もりに上乗せせざるを得ませんし、逆に仕様が固まっている段階で漫然と時間単価の契約を続ければ、費用は際限なく膨らんでいきます。
先代から契約を引き継いだ後継社長にとって大切なのは、既存の契約を「昔からこうだから」と思考停止で継続するのではなく、一度立ち止まって契約書の条文を読み、どちらの契約類型なのか、それが今のプロジェクトの実態に合っているのかを確認することです。契約類型の理解は、開発会社と対等な立場で交渉するための、最も基本的で、最も費用対効果の高い自己防衛策だといえます。
今日からできる最初の一歩は難しいことではありません。手元にある契約書を1通取り出し、本文の条文を読んで「これは仕事の完成を約束しているか、それとも業務の遂行を約束しているか」を確認してみることです。その一手間が、将来の大きなトラブルを避ける最も確実な備えになります。契約書を自分で読むべきか顧問に確認してもらうべきか迷う場合は、承継1年目、システムの契約書は自分で読むか顧問に確認してもらうかも参考になる。
そして、もし確認した結果、契約類型と実態がずれている、あるいは条文があいまいで判断できないと感じたら、それは決して珍しいことではありません。多くの中小企業で同じような契約書がそのまま使われ続けています。大切なのは、気づいたときに開発会社と対話し、必要であれば契約書を現状に合わせて更新していく姿勢です。後継社長としての最初の一歩を、契約書の見直しから始めてみてはいかがでしょうか。
