小規模なWebアプリ開発では、どちらの契約が一般的ですか？

範囲と成果物が明確な小規模開発では、請負の考え方で契約することが多くあります。一方、要件を固めながら進める場合や、公開後の改善を継続的に依頼する場合は、準委任の考え方が合うこともあります。依頼先によって標準の契約形態が異なるため、事前に確認しましょう。

契約書がなく、見積書と発注書だけで進めても大丈夫ですか？

小規模な取引では見積書と発注書で進めることもありますが、修正対応の範囲、検収の方法、権利の帰属、支払い条件などが書かれていないと、後で認識がずれる原因になります。重要な条件は、何らかの書面で合意しておくことをおすすめします。

契約不適合責任とは何ですか？

納品されたものが契約の内容に適合しない場合に、発注者が修正などを求められる仕組みを指す言葉です。2020年4月に施行された改正民法で、従来の「瑕疵担保責任」に代わって整理されました。請求できる期間や範囲は契約で定められることも多いため、契約書の内容を確認してください。

システム開発の契約形態とは？請負と準委任の違いを発注者向けに解説

システム開発を外注するとき、見積もりの金額や納期には注目しても、契約の形まではあまり意識していなかった、という方も多いのではないでしょうか。しかし、契約の形によって、開発会社が何に責任を持つのか、どの時点で何に対して支払うのかが変わります。代表的な契約形態である請負と準委任の違いを、発注者の立場から解説します。

この記事は、システム開発の契約形態について一般的な考え方をまとめたもので、法的な助言ではありません。実際の権利や責任は、契約書の定めと個別の事情によって判断されます。契約条件は個別に確認し、必要に応じて弁護士などの専門家にご相談ください。

請負と準委任の基本的な違い

観点	請負契約	準委任契約
約束するもの	仕事の完成	業務を適切に行うこと（事務の遂行）
報酬の考え方	完成した成果物に対して支払う	行った業務（期間・工数など）に対して支払うことが多い
向いている作業	範囲と成果物が明確な開発	要件の整理、調査、継続的な改善・保守など
発注者が気をつけたいこと	何をもって「完成」とするかを明確にする	どの業務を、どの程度行うかを明確にする

大まかに言えば、請負は「決められたものを完成させる」契約、準委任は「決められた業務を行う」契約です。どちらが良い・悪いということではなく、作業の性質に合った形を選ぶことが大切です。

請負契約で確認したいこと

請負の考え方では、開発会社は合意した成果物を完成させる責任を負います。その分、「何が完成なのか」が曖昧だと、トラブルの原因になります。

成果物の範囲（画面・機能の一覧、納品物の種類）
検収の方法と期間（何を確認すれば検収とするか）
納品後の修正対応の範囲と期間
仕様の追加・変更が出たときの扱い
契約の内容に適合しない場合の対応（契約不適合責任の扱い）

2020年4月に施行された改正民法では、従来の「瑕疵担保責任」が「契約不適合責任」として整理されました。請求できる内容や期間は契約で定められることも多いため、契約書でどう書かれているかを確認しておきましょう。

準委任契約で確認したいこと

準委任の考え方では、開発会社は業務を適切に行う責任を負いますが、特定の成果物の完成までは約束しないのが基本です。要件を固めながら進める作業や、継続的な改善・保守に向いています。

依頼する業務の内容と範囲
報酬の計算方法（期間、工数、成果に応じた支払いなど）
作業の報告の方法と頻度
契約期間と、更新・終了の条件

なお、2020年の改正民法では、準委任の報酬について、業務を行った割合に応じて支払う形のほか、成果に対して支払う形についても規定が整理されました。どちらの形かによって、支払いの条件が変わります。

準委任でも、指示の出し方には注意

準委任契約は、発注者が開発会社の作業者を直接指揮命令する契約ではありません。作業者に対して社員のように細かく指示を出す運用は、契約の形によっては問題になる場合があります。作業の進め方は、開発会社の窓口を通じて相談するのが基本です。

工程ごとに契約を分ける方法

開発の工程によって性質が違うため、工程ごとに契約形態を分ける考え方もあります。

要件の整理：何を作るかを固める段階。範囲が決まっていないため、準委任の考え方が合いやすい
開発：範囲が決まった段階。成果物が明確なため、請負の考え方が合いやすい
公開後の保守・改善：継続的な業務のため、準委任の考え方が合いやすい

小規模な開発では、こうした分け方をせず一つの契約で進めることも多くあります。重要なのは形式より、各段階で何を約束し、何に対して支払うのかを双方が理解していることです。公的機関から、システム開発の取引の参考となるモデル契約が公表されている場合もあるため、契約書を検討する際の参考にできます。

契約形態にかかわらず確認したい項目

項目	確認したい内容
範囲	含まれる作業・成果物と、含まれないもの
変更の扱い	範囲を超える変更が出たときの相談と見積もりの方法
権利	ソースコードなどの権利の帰属と、利用できる範囲
アカウント・データ	サーバーや外部サービスの名義、データの扱い
支払い	金額、時期、方法、分割の有無
秘密保持	業務上の情報や個人情報の扱い
終了時	契約終了時の引き継ぎ、成果物とデータの扱い

権利やアカウントの扱いについては、外注したシステムを自社で持ち続けるためにで詳しく解説しています。見積もりの段階で比較する方法はシステム開発の相見積もりで比較すべきポイントをご覧ください。

契約書を読むときの確認の順番

開発会社から契約書の案を受け取ったら、次の順番で確認すると、重要な点を見落としにくくなります。

何を約束する契約か：成果物の完成か、業務の遂行か。契約の名前だけでなく中身を確認する
範囲：見積もりや要件の文書と、契約書に書かれた範囲が一致しているか
お金：金額、支払いの時期と条件、追加費用が発生する場合の扱い
完了と検収：何をもって完了とし、どのように確認するか
その後：修正対応、権利の帰属、保守、契約終了時の扱い

分からない言葉や、意図が読み取れない条項があれば、開発会社に説明を求めましょう。そのうえで、事業への影響が大きい契約は、専門家に確認してもらうことをおすすめします。

小規模な開発でも書面に残したいこと

小規模な開発では、正式な契約書を作らず、見積書と発注書だけで進めることもあります。その場合も、次の点は何らかの書面で合意しておくと、後のずれを防げます。

作るものの範囲（画面・機能の一覧）と、含まれないもの
初回納品後の修正対応の範囲と期間
範囲を超える変更が出た場合の扱い
ソースコードやアカウントの扱い
支払いの時期と方法

着手前に、範囲と条件を言葉にします

契約の形にかかわらず、Tailboneでは、制作範囲、初回納品後の修正の範囲、合意範囲を超える仕様追加の扱いを、着手前に文書で明確にしています。ソースコードやアカウントの扱いなど、気になる条件があれば最初のご相談の段階でお知らせください。契約条件は案件ごとに個別に確認のうえで決めていきます。