システム開発で準委任契約を選ぶべき場面とは？請負契約との使い分けを事例で解説

システム開発で準委任契約を選ぶべき場面とは？

「うちの案件、準委任と請負どっちが正解なの？」

「見積もりをもらったら"準委任契約"と書いてあった。請負じゃダメなんですか？」

中小工務店や設計事務所の経営者が、初めてシステム開発を外注するときにぶつかる壁がこれです。

• 「前回のIT会社は請負だったのに、今回の会社は準委任だと言ってきた。何が違う？」
• 「準委任だと成果物保証がないと聞いた。それなら請負一択じゃないのか？」
• 「アジャイル開発だから準委任ですと言われたが、そもそもアジャイルが何かわからない」
• 「DXコンサルは準委任、開発は請負と言われた。なぜ分ける必要がある？」
• 「要件定義は準委任が一般的と聞いたが、成果物なしでどうやって進捗を確認する？」

建設業界にいると、仕事＝「完成させて納品する」が当たり前です。設計図を描いて渡す。建物を建てて引き渡す。すべて請負契約の世界です。

だからこそ、**「成果物の完成を約束しない契約」**と聞くと違和感を覚えるのは当然のこと。「それってお金だけ取られるんじゃないの？」という不安が生まれます。

しかし結論から言えば、すべてのシステム開発を請負契約で進めるのは、むしろ危険です。場面によっては、準委任契約の方が発注側にとって圧倒的に有利なケースがあるのです。

建設業の常識がIT契約では通用しない理由

この不安の根底には、建設業とIT業界の「仕事の進め方」の根本的な違いがあります。

建設業では、設計図が先にあり、その通りに施工すれば完成形が見えます。ゴールが最初から明確だからこそ、請負契約が成立します。

ところがシステム開発では、作り始めてから「こうじゃなかった」と気づくことが日常茶飯事です。

• 「使ってみたら操作が面倒だった」
• 「現場のスタッフに見せたら、必要な機能が足りなかった」
• 「法改正があって仕様を変えなければならなくなった」

こうした変更が発生するたびに、請負契約では追加費用と納期延長の交渉が必要になります。「最初の見積もりは300万円だったのに、最終的に800万円になった」——こんな話は珍しくありません。

ゴールが見えない段階で「完成」を約束させること自体に無理がある。この構造を理解すると、準委任契約の存在意義が見えてきます。

中小工務店や設計事務所の方にとっても、実は身近な感覚のはずです。たとえば、施主との打ち合わせ段階を思い出してください。「どんな家を建てたいか」をヒアリングしている最中に、「この設計図で請負契約を結んでください」とは言いませんよね。要望が固まるまでは、伴走しながら一緒に考える段階が必要です。

システム開発における準委任契約は、まさにこの「一緒に考える段階」に使う契約なのです。

この記事を読めば「どの場面でどちらの契約を選ぶか」が判断できます

契約の使い分けを理解する

この記事では、システム開発における準委任契約と請負契約の使い分けを、中小工務店・設計事務所で実際にある事例をもとに解説します。

「準委任契約とは何か」「メリット・デメリットは何か」といった基礎知識は、前回の記事で詳しく解説しました。今回は実践編として、「じゃあ具体的にどの場面でどちらを選べばいいのか」にフォーカスします。

読み終えるころには、ITベンダーから提案された契約形態が妥当かどうかを自分で判断できる力が身についているはずです。

【事例で学ぶ】準委任契約を選ぶべき5つの場面

場面1：要件が固まっていない段階の「要件定義」

事例：A工務店（従業員15名）のケース

A工務店は、紙の台帳で管理していた顧客情報と工事履歴をデジタル化したいと考えていました。しかし、「どんなシステムが必要か」を具体的に言語化できない状態でした。

• 顧客情報はExcelと紙が混在
• 工事履歴は担当者の記憶頼り
• 見積書のフォーマットが人によってバラバラ

この状態で「完成品を納品してください」と請負契約を結ぶとどうなるか。ITベンダー側が想像で要件を決めてしまい、できあがったシステムが現場の実態とかけ離れたものになるリスクが極めて高くなります。

正解は、要件定義フェーズを準委任契約で切り出すことです。

ITベンダーのエンジニアが現場に入り、業務フローを観察し、スタッフにヒアリングし、「本当に必要な機能は何か」を一緒に洗い出す。この工程は**「作業時間に対して報酬を支払う」準委任契約が最も適している**のです。

建設業に置き換えると： 施主の要望をヒアリングして基本設計をまとめる段階。この段階を「建物の完成」まで含めた請負契約に入れてしまうと、設計変更のたびに揉めることになります。

場面2：段階的に機能を追加していく「アジャイル開発」

事例：B設計事務所（従業員8名）のケース

B設計事務所は、施主向けのプロジェクト進捗共有ツールを開発することにしました。しかし、「最終的にどこまでの機能が必要か」は使いながら判断したいという希望がありました。

• まずは工事写真の共有機能だけ作る
• 施主の反応を見て、コメント機能を追加するか判断
• 好評であれば、スケジュール共有機能も追加

こうした**「作りながら方向性を決める」開発スタイル**では、最初に全体のゴールを定義できません。請負契約で「全機能を○月○日までに納品」と決めてしまうと、途中で方向転換ができなくなります。

準委任契約であれば、2週間ごとに成果を確認し、次に何を作るかをその都度判断できます。不要だと分かった機能に無駄なコストをかけずに済むのです。

場面3：既存システムの「保守・運用」

事例：C工務店（従業員25名）のケース

C工務店は、3年前に導入した工事管理システムの保守を外部に委託していました。

• 月に数回のバグ修正
• WindowsやブラウザのアップデートへのOS対応
• ユーザーからの問い合わせ対応

保守・運用は、毎月どれだけの作業が発生するか予測できません。ある月はバグが3件、翌月はゼロ、その翌月はセキュリティパッチの適用で丸1日——こうした作業を毎回請負契約で発注するのは現実的ではありません。

月額固定の準委任契約で「月○時間まで対応」と決めておくのが一般的です。建設業でいえば、ビルのメンテナンス契約に近い感覚です。

場面4：技術選定やIT戦略の「コンサルティング」

事例：D設計事務所（従業員12名）のケース

D設計事務所は、BIMソフトの導入を検討していましたが、どの製品を選ぶべきか、社内のワークフローをどう変えるべきかが分からず、ITコンサルタントに相談しました。

• Revit、ArchiCAD、Vectorworksの比較検討
• 既存の2D CADワークフローとの並行運用計画
• スタッフの研修プラン策定

これは**「完成品を納品する」仕事ではありません**。調査・分析・提案という知的作業に対して報酬を支払う、典型的な準委任契約の場面です。

ただし注意点があります。「調査レポートを納品する」という形にすれば請負契約にもできます。コンサルティングの場合、「いつまでに何を納品するか」を明確にできるなら請負、継続的に伴走しながらアドバイスがほしいなら準委任、という判断基準になります。

場面5：社内にITがわかる人材がいない場合の「技術顧問」

事例：E工務店（従業員10名）のケース

E工務店には、IT担当者がいませんでした。年に数回、パソコンの買い替えやソフトウェアの更新で困るたびに、知り合いのIT会社に都度相談していましたが、対応が遅く不満を抱えていました。

そこで、月額固定で「ITの相談相手」を確保する準委任契約を結びました。

• 月2回のオンライン相談
• ソフトウェア選定のアドバイス
• セキュリティ対策の簡易チェック

「何かあったときにすぐ聞ける人がいる」という安心感は、中小企業にとって大きな価値です。これもまた、成果物ではなく「専門家の時間と知識」に対して支払う準委任契約の典型例です。

【事例で学ぶ】請負契約を選ぶべき3つの場面

請負契約と準委任契約の使い分けステップ

準委任契約が有効な場面がある一方、請負契約の方が適切な場面も確実に存在します。

場面1：要件が明確で、ゴールが定義できる開発

要件定義が完了し、「何を作るか」が画面設計書や機能一覧として文書化されている状態であれば、請負契約が適しています。

たとえば、「この設計書通りのWebサイトを制作してください」「この仕様書通りの見積もりシステムを開発してください」といったケースです。

建設業に置き換えれば、設計図が完成した後の施工段階。ここは請負契約で「いつまでに、いくらで完成させる」と約束してもらうのが合理的です。

場面2：パッケージ導入・カスタマイズ

すでに完成しているパッケージソフト（kintone、Salesforceなど）を導入し、自社の業務に合わせてカスタマイズする場合も、ゴールが比較的明確です。

「この3つの帳票を出力できるようにする」「この業務フローに合わせて画面を変更する」——こうした要件が具体的に列挙できるなら、請負契約でスコープを固めることができます。

場面3：成果物が明確なデザイン・制作案件

ホームページ制作、ロゴデザイン、パンフレットのデジタル化など、「何が完成品か」がはっきりしている案件は請負契約が適しています。

ページ数、デザインカンプの承認プロセス、納品形式——これらが事前に決められるからです。

最適な契約を選ぶための判断フローチャート

実際のプロジェクトでは、「全体を1つの契約形態で進める」のではなく、フェーズごとに契約を分けるのがベストプラクティスです。

ステップ1：要件は固まっているか？

• 固まっている → 請負契約を検討
• 固まっていない → ステップ2へ

ステップ2：ゴール（完成物）を定義できるか？

• 定義できる → 請負契約を検討
• 定義できない → 準委任契約を検討

ステップ3：期間中に方向転換の可能性があるか？

• ある → 準委任契約が安全
• ない → 請負契約が有利

ステップ4：複数フェーズに分割できるか？

• できる → フェーズごとに最適な契約形態を選択

この判断基準を持っておくだけで、ITベンダーから提案された契約形態が妥当かどうかを自分の頭で判断できるようになります。

実際のプロジェクトでの組み合わせ例

多くのシステム開発プロジェクトでは、**準委任と請負を組み合わせて進める「多段階契約」**が採用されています。

たとえば、先ほどのA工務店のケースでは、最終的にこのような契約構成になりました。

1. 要件定義（準委任・2ヶ月）： 現場ヒアリング、業務フロー整理、必要機能の洗い出し → 成果物として要件定義書を作成
2. 設計・開発（請負・4ヶ月）： 要件定義書に基づきシステムを構築 → 完成したシステムを納品
3. 保守運用（準委任・月額）： バグ修正、問い合わせ対応、小規模改修

「準委任で方向性を固め、請負で確実に作り、準委任で維持する」——この流れが、多くのプロジェクトで最もリスクが低い契約戦略です。

契約形態を間違えるとどうなるか——失敗事例

失敗事例1：全工程を請負にしたF工務店

F工務店は、勤怠管理システムの開発を**全工程一括の請負契約（500万円）**で発注しました。

要件定義も含めて請負にしたため、ITベンダーは「最初にヒアリングした内容」だけで仕様を確定。しかし、開発が進むにつれて現場から「この機能がない」「この画面では使いにくい」という声が続出。

結果：

• 追加開発の見積もりがさらに300万円
• 納期は3ヶ月遅延
• 最終的に「使いにくい」という理由で現場に定着せず

要件定義を準委任で分離していれば、現場の実態に合ったシステムを設計でき、手戻りコストを大幅に削減できたはずです。

失敗事例2：全工程を準委任にしたG設計事務所

逆のパターンもあります。G設計事務所は、ホームページリニューアルを**全工程準委任契約（月額30万円）**で発注しました。

「柔軟に進めたい」という理由で準委任を選びましたが、完成イメージは最初からほぼ固まっていました。結果的に、制作期間が当初想定の2ヶ月から5ヶ月に延長。

結果：

• 総額150万円（請負なら80万円で済んだ見積もり）
• 「いつ終わるのか」が常に不透明
• 完成物のクオリティに対する責任の所在が曖昧

ゴールが明確な案件を準委任にすると、ダラダラと期間が延び、コストが膨らむ典型例です。

契約交渉で使える3つのチェックポイント

ITベンダーから契約形態を提案されたとき、以下の3点を確認しましょう。

チェック1：「なぜこの契約形態なのか」の説明を求める

「準委任が一般的ですので」「業界標準です」——こうした説明しかできないベンダーは要注意です。なぜこのプロジェクトにこの契約形態が最適なのかを、発注側が納得できるように説明できるベンダーを選びましょう。

チェック2：フェーズ分割を提案しているか

全工程を1つの契約形態で提案してくるベンダーよりも、「要件定義は準委任、開発は請負で分けましょう」と提案してくるベンダーの方が信頼できます。フェーズごとにリスクが異なることを理解している証拠だからです。

チェック3：準委任契約に「成果物」の定義があるか

準委任契約でも、「各月の成果物（報告書、設計書、プロトタイプなど）」を定義しておくことは可能であり、推奨されます。「毎月何を受け取れるのか」が曖昧な準委任契約は、後からトラブルになりやすいです。

こんな方は今すぐ契約の見直しを

• 初めてシステム開発を外注しようとしていて、契約形態に迷っている方
• 過去にIT外注で「想定以上の費用がかかった」経験がある方
• ITベンダーに言われるまま契約形態を決めてしまっている方
• 社内にIT契約に詳しい人材がおらず、判断基準が欲しい方
• DX推進を検討しているが、何から始めればいいかわからない方

建設業界のDX化は年々加速しています。BIM義務化の流れ、電子帳簿保存法への対応、インボイス制度——ITへの投資は避けて通れない時代です。

だからこそ、「お金の使い方」を間違えない知識が経営を守ります。契約形態の選択は、その第一歩です。

「次のIT投資で同じ失敗を繰り返したくない」と少しでも感じているなら、今が見直しのタイミングです。

まとめ

まとめ：契約形態の使い分け

システム開発の契約形態選びは、「準委任か請負か」の二者択一ではなく、場面に応じた使い分けがポイントです。

• 要件が不明確・変更可能性がある → 準委任契約
• ゴールが明確・成果物を定義できる → 請負契約
• 多くのプロジェクト → フェーズごとに組み合わせるのが最適

この判断基準を持っているだけで、ITベンダーとの交渉において対等な立場で話ができるようになります。

建設業界の皆さんは、建物を建てるプロです。しかし、IT契約のプロである必要はありません。必要なのは、正しい判断基準と、信頼できる相談相手です。

「うちの場合、どの契約形態が最適なのか具体的に知りたい」「今進めているプロジェクトの契約を見直したい」——そうしたお悩みがあれば、私たちアトリエ・バイナリにお気軽にご相談ください。建設業界のIT課題に精通した専門家が、御社の状況に合わせた最適な契約戦略を一緒に考えます。

まずは現状の契約内容を整理するところから始めてみませんか？