請負契約でシステム開発を依頼して失敗する3つのパターン｜契約前に確認すべきこと

請負契約でシステム開発を依頼して失敗する3つのパターン

「請負契約なら安心」と思っていませんか？

「請負契約で発注したのに、できあがったシステムがまったく使えなかった」

中小工務店や設計事務所の経営者から、こうした相談が増えています。

• 「300万円で請け負ってもらったのに、追加費用を含めたら倍以上になった」
• 「納品されたシステムが現場のオペレーションにまったく合わない」
• 「仕様変更をお願いしたら"契約外です"と言われて、にっちもさっちもいかない」
• 「検収で"仕様通りです"と言い張られ、使えないシステムを受け取るしかなかった」
• 「結局、Excelの方がマシだったという結論になった」

建設業界で生きてきた方なら、請負契約は馴染み深い契約形態でしょう。設計図を渡して、完成品を受け取る。建物もシステムも同じだろう——そう考えるのは自然なことです。

しかし実際には、建物の請負とシステムの請負では、失敗のリスクがまったく異なります。建物には建築基準法という明確な「正解」がありますが、システム開発には**「こう作れば正解」という絶対的な基準が存在しない**のです。

この記事では、請負契約でシステム開発を依頼して失敗する典型的な3つのパターンと、契約前に必ず確認すべきチェックポイントを解説します。

同じ「請負」なのに、なぜシステム開発だけ失敗するのか

「うちは建設の請負で何十年もやってきた。契約の仕組みはわかっている」

この自信が、システム開発では裏目に出ることがあります。

建設業の請負契約がうまくいくのは、発注者と受注者の間で「完成形」のイメージが一致しているからです。図面がある。仕様書がある。建築基準法がある。「何をもって完成とするか」が客観的に判断できます。

ところがシステム開発では、「完成形」を言語化すること自体が難しいのです。

たとえば「顧客管理システムを作ってほしい」と依頼したとします。発注者の頭の中には「こんな感じ」というイメージがありますが、そのイメージを100ページの要件定義書に落とし込んでも、認識のズレは必ず残ります。

建物なら「窓の位置が図面と違う」と一目でわかりますが、システムの「使いにくい」は主観的で、仕様書のどこにも書かれていないことがほとんどです。

この構造的な違いを理解しないまま請負契約を結ぶと、発注者・受注者の双方が不幸になる結果を招きます。

この記事で解決できること

この記事を読むことで、以下のことがわかります。

• 請負契約でシステム開発を依頼したとき、なぜ失敗するのかの構造
• よくある3つの失敗パターンと、それぞれの原因
• 契約前に確認すべき具体的なチェックリスト
• 失敗を避けるための契約の組み立て方

「次こそは失敗したくない」「これから初めてシステム開発を外注する」という方は、ぜひ最後まで読んでください。

請負契約の失敗パターンを解決する

失敗パターン1：「要件定義があいまいなまま請負契約を締結してしまう」

これが最も多い失敗です

請負契約の本質は、**「あらかじめ決めた仕様通りのものを納品する」**という約束です。つまり、契約時点で「何を作るか」が明確でなければ、契約として成立しないのです。

ところが実際には、こんなケースが頻発します。

• **「大体こんな感じで」**という口頭の説明だけで発注
• 要件定義書はあるが、画面遷移や例外処理が書かれていない
• 「細かいところは作りながら決めましょう」と開発会社に言われてそのまま契約

建設業に置き換えると、「なんとなくこんな家が欲しい」で工事請負契約を結ぶようなものです。設計図もなく着工すれば、完成後に「こんなはずじゃなかった」となるのは当然です。

なぜこうなるのか

理由は明確で、発注側にシステムの「完成形」をイメージする経験がないからです。

工務店の社長が「顧客管理システムが欲しい」と言うとき、頭の中にあるのは**「今Excelでやっている作業を楽にしたい」**という漠然とした願望です。それを具体的な画面設計、データベース構造、業務フローに落とし込むには、IT側の専門知識が不可欠です。

しかし請負契約では、仕様を決めるのは原則として発注者の責任です。開発会社は「言われた通りに作る」のが仕事であり、「何を作るべきか一緒に考える」義務は契約上ありません。

どうすればよかったのか

要件定義フェーズを請負契約から切り離すことが鉄則です。

具体的には、以下の手順が有効です。

1. 要件定義は準委任契約（またはコンサルティング契約）で別途依頼する
2. 要件定義の成果物（要件定義書、画面モック、業務フロー図）を発注者が理解・承認する
3. 成果物を基に、開発フェーズのみ請負契約を締結する

この「要件定義と開発を分ける」という考え方は、大手SIerでは常識ですが、中小企業への説明が不十分なまま一括請負で進められてしまうケースが非常に多いのです。

失敗パターン2：「仕様変更に対応できず、使えないシステムが納品される」

作り始めてから「違う」と気づく問題

請負契約の2つ目の落とし穴は、開発中の仕様変更への対応です。

システム開発では、実際に動くものを見て初めて「ここが違う」と気づくことが日常的に起こります。

• 「この画面、現場のスタッフには項目が多すぎる」
• 「入力順序が実際の業務フローと逆だ」
• 「この機能より、先にこっちの機能が必要だった」

建設業でも、施工中に施主から変更依頼が入ることはあります。しかし建設の場合、変更の影響範囲が物理的に見えるため、追加費用と工期の見積もりが比較的容易です。

一方、システム開発の仕様変更は、見た目は小さな変更でも内部構造に大きな影響を与えることがあります。「ボタンを1つ追加する」だけで、データベース設計からやり直しになるケースも珍しくありません。

請負契約が仕様変更を阻む構造

請負契約では、**契約時に合意した仕様が「正」**です。仕様変更は「契約外」の追加作業となり、別途見積もり・別途契約が必要になります。

このため、以下のような状況が起こります。

• 開発会社は仕様変更を嫌がる（利益が減るため）
• 変更のたびに追加費用の交渉が発生し、関係が悪化する
• 結果として、**「仕様通りだけど使えないシステム」**が納品される
• 発注者は**「もう変更を言い出せない雰囲気」**になり、妥協する

最終的に「仕様書通りです」と言われれば、法的にはそれ以上追及できません。契約上は正しいのに、ビジネス上は大失敗——これが請負契約の構造的な問題です。

どうすればよかったのか

仕様変更が起きる前提で契約を設計することが重要です。

• プロトタイプ（試作品）フェーズを設け、実際に触れる段階で仕様を確定させる
• 仕様変更の手続きと費用算定ルールを契約書に明記しておく
• 変更が多発しそうなプロジェクトでは、アジャイル型の準委任契約を検討する

特に中小工務店や設計事務所のように初めてのシステム開発というケースでは、仕様変更は避けられません。「変更が起きない契約」ではなく、**「変更に対応できる契約」**を選ぶべきなのです。

失敗パターン3：「検収基準があいまいで、トラブルが泥沼化する」

「完成」の定義が食い違う悲劇

請負契約の3つ目の失敗パターンは、検収（受け入れテスト）でのトラブルです。

請負契約では、発注者が成果物を「検収」して初めて報酬が確定します。しかし、「何をもって検収合格とするか」が契約書に明記されていないケースが驚くほど多いのです。

こうなると、納品時にこんなやり取りが発生します。

発注者： 「この機能、思ったのと違うんですけど」

開発会社： 「仕様書通りに作っています。検収してください」

発注者： 「でも、現場で使えないんです」

開発会社： 「仕様書に書かれていない要件は契約外です」

発注者： 「じゃあ、検収できません」

開発会社： 「検収拒否は契約違反です。支払いをお願いします」

こうなると、弁護士を入れた交渉に発展することもあります。数百万円のシステム開発で、さらに弁護士費用まで発生する——中小企業にとっては致命的な負担です。

なぜ検収でもめるのか

根本的な原因は、検収基準が「仕様書通りであること」としか定義されていない点にあります。

建設業なら、建築基準法や設計図面という客観的な基準がありますが、システム開発の「仕様書通り」は解釈の幅が広いのです。

たとえば、「顧客一覧画面を表示する」という仕様があったとします。

• 表示速度は何秒以内か？
• 一度に何件表示するか？
• 検索機能は必要か？
• スマートフォンでも表示できるか？

こうした**非機能要件（性能、操作性、対応デバイスなど）**が仕様書に書かれていなければ、開発会社は「最低限動くもの」を作って「仕様通りです」と言えてしまいます。

どうすればよかったのか

検収基準を契約書に具体的に明記することが不可欠です。

具体的には、以下の項目を契約前に合意しておくべきです。

「そこまで細かく決めるのは大変だ」と感じるかもしれません。しかし、ここを省略したツケは、必ず検収時に回ってきます。

契約前に確認すべきチェックポイント

契約前に確認すべき5つのチェックポイント

ここまでの3つの失敗パターンを踏まえて、契約前に必ず確認すべきチェックポイントをまとめます。

チェック1：要件定義は完了しているか

• 画面モック（実際の画面イメージ）が作成されている
• 業務フロー図で「誰が・いつ・何をするか」が明確になっている
• 例外処理（エラー時の動作）が定義されている
• 発注者側の担当者が要件定義書の内容を理解し、承認している

もし要件定義が不十分なら、請負契約を結ぶのは時期尚早です。

チェック2：仕様変更のルールが明記されているか

• 仕様変更が発生した場合の手続き（書面での変更依頼など）が決まっている
• 変更に伴う追加費用の算定方法が明記されている
• 変更による納期への影響の取り扱いが合意されている
• 軽微な修正と仕様変更の線引きが明確になっている

チェック3：検収基準が具体的か

• 検収テストのシナリオが用意されている
• 非機能要件（速度、対応デバイスなど）が数値で定義されている
• 検収期間と、期間内に不合格とする場合の手続きが決まっている
• 検収後の不具合対応（瑕疵担保・契約不適合責任）の範囲と期間が明記されている

チェック4：開発プロセスの可視性があるか

• 開発中の進捗報告の頻度と方法が決まっている
• 中間成果物（設計書、テスト結果など）の提出タイミングが合意されている
• 発注者が開発中のシステムを途中で確認できる機会がある

チェック5：開発会社の実績と体制を確認したか

• 同業種（建設・不動産業界）での開発実績があるか
• プロジェクトマネージャーが明確に任命されているか
• 開発チームの体制（人数、役割分担）が提示されているか
• トラブル時の連絡先とエスカレーションルートが決まっているか

これらのチェック項目に「NO」が3つ以上あるなら、契約を急ぐべきではありません。

こんな方はぜひ契約前に立ち止まってください

• 初めてシステム開発を外注しようとしている中小工務店・設計事務所の経営者
• 過去にシステム開発で失敗した経験があり、次こそは成功させたい方
• 開発会社から提示された契約書の内容に不安を感じている方
• 「請負契約だから安心」と思い込んでいたことに気づいた方
• 要件定義と開発の違いがよくわからないまま契約しようとしている方

システム開発の失敗は、数百万円〜数千万円の損失に直結します。建設業のように「やり直せばいい」というわけにはいきません。デジタルの世界では、間違った基盤の上に建てたシステムは、基礎からやり直すしかないのです。

「まだ契約していない」なら、今がまさに最後の確認ポイントです。

まとめ

請負契約の失敗を防ぐために

請負契約でシステム開発を依頼して失敗する3つのパターンを振り返ります。

1. 要件定義があいまいなまま契約してしまう → 「何を作るか」が決まっていないのに「完成」を約束させている
2. 仕様変更に対応できない → 開発中の気づきを反映できず、「仕様通りだけど使えない」システムが完成する
3. 検収基準があいまい → 「完成」の定義が食い違い、納品時にトラブルが泥沼化する

いずれの失敗も、契約を結ぶ「前」の段階で防げるものです。

特に中小工務店や設計事務所がシステム開発を外注する際は、建設業の請負契約の感覚をそのまま持ち込まないことが最も重要です。建物とシステムでは、「完成形の見える化」の難易度がまったく違います。

「要件定義を分離する」「仕様変更のルールを決める」「検収基準を具体化する」——この3つを契約前に押さえるだけで、失敗リスクは大幅に下がります。

しかし正直なところ、これらを自社だけで判断するのは簡単ではありません。ITの専門知識がない中で、開発会社が提示する契約書の妥当性を評価するのは、建設の素人が設計図面をチェックするようなものです。

もし「契約前に第三者の目でチェックしてほしい」「そもそも要件定義から伴走してほしい」とお考えなら、アトリエ・バイナリのコンサルティングサービスにご相談ください。建設・不動産業界のレガシーな業務課題を理解した上で、契約設計から開発プロセスまで、発注者側の立場でサポートいたします。

まずは「今検討している案件の契約書を見てほしい」——そんな気軽なご相談からで構いません。