システム開発に関する契約書作成 ― 請負型契約の注意点とは ―

システム開発契約を「請負」で組む。

一見するとシンプルですが、ここに落とし穴が詰まっています。

なぜなら、請負契約とは

「仕事の完成」に対して報酬が発生する契約だからです。

つまり――

完成しなければ、お金はもらえない。

この一点だけで、契約の重さが一気に変わります。

請負契約とは何か（システム開発における意味）

民法上の請負契約は、

成果物の完成が義務

完成しなければ報酬請求不可

これをシステム開発に当てはめるとどうなるか。

「仕様どおりのシステムを完成させる責任を負う」

という構造になります。

ここで問題になるのが――

そもそも仕様が固まっていない案件が多すぎるという現実です。

最大のリスクは「仕様の曖昧さ」

請負契約で最も危険なのはこれです。

「思っていたのと違う」

この一言で、すべてが崩れます。

注意点①：仕様書を“契約の中心”に据える

請負契約では、契約書よりもむしろ

仕様書の精度が命

です。

最低限、ここは押さえたい

機能一覧（やらないことも明記）

画面遷移

入出力仕様

外部連携の範囲

パフォーマンス要件

そして重要なのは――

「本仕様書に記載のない事項は対象外とする」

この一文。

これがあるかないかで、戦場が変わります。

注意点②：検収の仕組みを設計する

請負契約では「完成＝検収合格」です。

ここを曖昧にすると、永遠に終わりません。

よくある失敗

検収期間の定めなし

基準が抽象的

修正回数無制限

これを避けるために

検収期間（例：納品後10日）

検収基準（仕様書適合性）

軽微な不具合の扱い（検収合格とみなすか）

を明確にする必要があります。

注意点③：仕様変更＝別契約と切り分ける

開発現場ではほぼ確実に起きます。

「やっぱりこれも追加したい」

これを飲み続けるとどうなるか。

工数増加

納期遅延

追加報酬なし

つまり、ただの消耗戦です。

したがって

仕様変更は書面で合意

追加費用・納期を明記

合意なき変更は対応義務なし

ここを冷たく切ることが、むしろ関係維持につながります。

注意点④：瑕疵担保（契約不適合責任）の範囲

請負契約では避けて通れません。

ポイントは

期間（例：検収後3ヶ月）

対応内容（無償修補の範囲）

責任上限（報酬額を上限とする）

これを入れないとどうなるか。

 青天井で責任を負う可能性

があります。

注意点⑤：準委任との使い分けを意識する

ここはプロの分岐点です。

実務的には

要件定義・設計 → 準委任

実装 → 請負

と分けるケースが多いです。

理由はシンプルで、

曖昧なフェーズを請負にすると事故る

からです。

まとめ：請負契約は“強い契約”である

請負契約は、発注者にとっては安心です。

しかし受注者にとっては――

かなりリスクの高い契約形態

です。

だからこそ、

仕様を詰める

検収を設計する

変更を遮断する

責任範囲を限定する

この4点を外すと、簡単に赤字案件になります。

最後に

システム開発契約は、

単なる「契約書作成」ではありません。

プロジェクトの設計図そのものです。

雛形をコピペして済ませるか、

実務に耐える契約にするか。

その差は、数十万円ではなく

事業そのものの損益に跳ね返ってきます。

南本町行政書士事務所 代表 特定行政書士 西本