法律と契約について：システム開発における契約の注意点

はじめてシステム開発を発注する担当者にとって、最大の不安は「ちゃんと完成するのか」「追加費用で揉めないか」「納期が守られるのか」ではないでしょうか。実は、こうした不安の多くは技術の難しさよりも、システム開発 契約（システム開発契約／開発契約）の決め方・運用の仕方で大きく変わります。プロジェクトが炎上する典型は、契約書が薄い、または“雛形のまま”で、要件定義・検収・変更・支払いが曖昧な状態で走り出すことです。

この記事では、ITに詳しくない発注側でも現場で使えるように、請負と準委任契約の選び方、変更管理の作り方、検収と契約不適合責任（旧：瑕疵担保責任）をどう扱うか、知財や個人情報までを一気通貫で整理します。読み終えた頃には、見積や契約書を前に「どこを確認すべきか」「何を先に決めるべきか」が具体的に見えてくるはずです。

1. システム開発契約で揉めるのはなぜ？「よくある失敗」を先に潰す

システム開発で起きる対立は、発注側が悪い・受託側が悪いという単純な話ではありません。多くは期待のズレです。発注側は「この要望は当然やってくれる」と思い、受託側は「契約や見積の範囲外なので追加」と考える。ここに、システム開発 契約の設計不足が重なると、揉め事が“構造化”されます。

たとえば見積書に「一式」と書かれていても、実際は前提条件が大量にあります。画面数、権限の段階、外部サービス連携の数、データ移行の量、運用保守の範囲、セキュリティ要件などが少し変わるだけで工数は増減します。ところが、契約書・議事録・要件定義書に前提が残っていないと、後から「言った／言わない」になり、開発契約そのものが機能しなくなります。

また、プロジェクトでは意思決定が遅れることも珍しくありません。社内稟議、部門間調整、現場ヒアリングの都合で、発注側の回答が遅れ、その結果として納期がずれる。ここでも、システム開発契約に協力義務や承認期限、遅延時の扱いが書かれていないと、受託側だけが責められて関係が悪化します。契約は“相手を縛る”道具というより、現場の判断を迷わせないための設計図だと捉えると、必要な条項が見えてきます。

現場で起きがちな7つの衝突点：①追加要望の扱い（無料/有料の境界）、②要件定義の未確定、③検収条件の曖昧さ、④支払い条件と成果物の不整合、⑤バグと仕様の線引き、⑥知財の帰属、⑦個人情報・秘密情報の取り扱い。これらはすべてシステム開発 契約で“先に”整理できます。

2. 請負と準委任契約：契約形態を合わせるだけでトラブルは激減する

発注側がまず理解したいのが、システム開発契約の土台となる契約形態です。ざっくり言うと、請負は「成果物を完成させる約束」、準委任契約は「業務を遂行する約束」です。請負は完成がゴールなので、検収・納品・支払いが“成果物中心”になりやすい。準委任契約は時間や役割が中心になり、プロセスを丁寧に回す代わりに、発注側が成果の定義と優先順位を握る必要が出てきます。

よくある失敗は、仕様が固まっていないのに請負で固定価格にしてしまうことです。発注側は安心したつもりでも、途中で要望が増えた瞬間に「追加費用」「納期延長」が発生し、結局、契約書の外で揉め始めます。逆に、成果物を求めているのに準委任契約で進めると、担当者としては「お金を払っているのに完成が見えない」状態になり、社内説明が苦しくなります。

実務的には、要件定義フェーズは準委任契約で進め、仕様が固まった段階で実装〜納品を請負（または成果物ベース）で握る、という“フェーズ分割”が相性が良いことが多いです。アジャイル開発の場合は、スプリントごとに成果物が出るため、準委任契約にしつつも、受入基準（何をもってOKか）を明文化して、発注側の不安を減らす設計が有効です。いずれにせよ、システム開発 契約の形を、プロジェクトの現実（要件が変わるか、納期固定か、社内意思決定の速度）に合わせることが第一歩です。

3. 要件定義と変更管理：仕様追加が“地獄化”しない運用を契約に落とす

発注側にとって最も効くのが、要件定義と変更管理を“書面化”することです。ここでいう要件定義は、単に「こんな機能が欲しい」を並べることではありません。誰が、何を、どの画面で、どのデータを扱い、どんな例外があり、どこまで自動化するかを、運用まで含めて決めていく作業です。要件定義が甘いと、後からバグと仕様の区別がつかず、検収が伸び、契約不適合責任の議論も空中戦になります。

具体的に、要件定義で“契約に紐づけたい”成果物は、要件定義書、画面一覧・遷移図、データ項目定義、権限設計、外部連携一覧、通知や帳票の要件、そして非機能要件（性能・セキュリティ・可用性・監査ログなど）です。準委任契約で要件定義を伴走してもらうなら、これらを成果物として納品してもらう設計にすると、次工程の請負に繋げやすくなります。

次に重要なのが変更管理です。変更は起きます。むしろ、業務を理解するほど要望は出ます。大切なのは、追加を止めるのではなく、追加を“事故”にしないことです。おすすめは、変更要求（CR）を「受付→影響調査→再見積→優先順位調整→承認→反映」の流れで固定することです。ここで承認者（誰が決めるか）と承認期限（何日以内か）を決めておくと、現場が止まりにくくなります。小さな変更でも、合意の証跡（議事録・チケット・メール）を残し、開発契約の範囲を更新していく、という運用を徹底しましょう。

事例：「CSV取り込みを追加したい」という要望は、画面を1つ増やすだけに見えて、権限、入力チェック、エラー処理、履歴、再実行、運用手順、監査ログまで波及することがあります。変更管理がないと“ついでに”積み上がり、納期も品質も崩れます。変更を悪者にせず、手続きで守るのがシステム開発 契約の役割です。

4. 見積・支払い・納期：社内説明できる「お金とスケジュール」の作り方

見積で見るべきは金額よりも、内訳と前提条件です。システム開発 契約（開発契約）では、見積の根拠がブラックボックスだと、追加費用が出たときに社内説明が破綻します。発注側が押さえるべき内訳は、要件定義、設計、実装、テスト、PM（進行管理）、移行、教育、保守運用です。特にPMとテストは削られやすい一方、削ると事故の確率が上がるため、必要性を理解しておくと判断がブレません。

固定価格（請負）で進めるなら、前提条件が外れたときに再見積するルールをシステム開発契約に書きます。たとえば「画面数がXを超える」「権限段階が追加される」「外部連携が増える」「データ移行が想定より増える」など、追加費用が出やすい条件を明文化します。準委任契約で進めるなら、月次上限・スプリント上限を置き、成果レビューの頻度を決めることで、費用のコントロール感が生まれます。

支払い条件は、発注側のリスクと受託側のキャッシュフローのバランスです。検収後一括は分かりやすいですが、プロジェクトが長いと受託側の負担が増え、条件が悪いと良いパートナーが見つからないこともあります。実務では、要件定義完了、設計完了、β版、リリースなど、マイルストーン払いにすると双方が安定します。納期についても、発注側の資料提出遅れ・承認遅れが影響することは多いので、協力義務と遅延時の扱いを開発契約に置き、プロジェクト全体の“止まりどころ”を作るとトラブルが減ります。

5. 品質・検収・契約不適合責任：バグの責任境界を“言語化”する

品質トラブルは「バグが出ること」自体よりも、「バグの扱いが決まっていないこと」から起きます。そのため、システム開発 契約では検収（受入）と契約不適合責任の設計が重要です。検収は、受託側の納品と発注側の受入を一致させる仕組みで、支払い条件とも直結します。検収期間（例：納品後10営業日）、合否基準（受入テスト項目で判定）、不合格時の再提出、そして“みなし検収”（期間内に通知がなければ合格）を定めると、プロジェクトが終わらない事故を防げます。

次に、契約不適合責任（旧：瑕疵担保責任）は「契約内容に適合しない」場合の責任を扱います。ここで肝になるのは、契約内容＝合意済み仕様が明確であることです。だからこそ、要件定義と変更管理が前提になります。実務では、無償で修正する期間（例：検収後30日）、対象とする不具合（重大度S1〜S3など）、対象外（軽微な表示差、運用ルール違反、第三者サービス起因）を整理します。準委任契約の場合でも、品質保証を曖昧にせず、受入基準と改修優先度を合意し、保守運用契約（SLA）に繋げていく設計が現実的です。

よくある誤解：「準委任契約なら品質は保証されない」「請負なら何でも無償で直してもらえる」という理解は危険です。準委任契約でも受入基準と成果物を明文化すれば品質は上げられますし、請負でも契約範囲外まで無償対応が続くと、結果として納期・品質が落ちます。契約不適合責任を“怖い条文”にせず、現場運用に落とすのがポイントです。

6. 知財・秘密・個人情報：後戻りできない論点を「契約＋運用」で守る

知財・秘密・個人情報は、後から揉めると最も修復が難しい領域です。まず知財では、成果物（ソースコード、設計書、画面デザイン、ドキュメント）の利用範囲と帰属を整理します。発注側としては、将来の改修や内製化を見据え、自社で改変できる権利や、ドキュメント・ソースの提供条件をシステム開発契約に書いておくと安心です。OSSや外部ライブラリを使う場合は、ライセンス条件を確認し、利用制約がないかを整理します。

秘密保持（NDA）は“契約を結んだだけで安全になる”ものではありません。再委託（下請け）を許可するか、許可する場合はどの範囲まで情報を渡すか、アクセス権限をどう管理するか、ログや監査をどうするか、退職者・委託終了後のデータ削除をどう担保するか、といった運用まで落とすと事故が減ります。個人情報を扱う場合はさらに重要で、取り扱うデータの種類、保存場所（クラウド/オンプレ）、暗号化、持ち出し禁止、インシデント時の連絡手順などを契約と運用ルールの両方で整えます。

もし契約書を前にして「どこから手をつけるべきか分からない」「自社の状況に合わせると何を優先すべきか迷う」という場合は、契約書だけを眺めるより、発注前の整理（目的・業務フロー・リスク・優先順位）から一緒に設計してしまう方が早いことがあります。たとえば、要件定義を準委任契約で伴走し、見積の前提条件を固め、検収と契約不適合責任を現場運用に落とす、という流れで進めると、社内説明もしやすく、パートナー選定もスムーズです。

まとめ：契約は「守るための道具」—はじめての発注でも揉めないために

システム開発は、最初から完璧な要件を作るのが難しいからこそ、システム開発 契約の設計が重要です。請負と準委任契約をプロジェクトの実態に合わせ、要件定義と変更管理を手続き化し、検収と契約不適合責任を“言語化”して現場運用に落とす。さらに、知財・秘密・個人情報を契約と運用で守る。これだけで、発注側の不安は大きく減り、受託側との関係も健全になります。

契約書は法律文書ですが、ゴールは条文の暗記ではありません。プロジェクトが止まらないためのルール作りです。もし「自社の状況だと請負と準委任契約のどちらが良いか」「要件定義の成果物をどう決めるべきか」「契約不適合責任の範囲をどう整理すべきか」などで迷ったら、早めに第三者の目線で整理するのが近道です。

この段階で、条文の細部よりも「実務で何が起きるか」を想像するのがコツです。たとえば、追加要望が出たらシステム開発 契約の変更手続きに乗せ、受入が伸びそうならシステム開発 契約の検収条件を見直し、バグ対応は契約不適合責任の範囲と保守の範囲を切り分けます。要件が流動的なら準委任契約の運用（レビュー頻度・成果物・上限）まで決めておくと、社内説明もプロジェクト管理も格段に楽になります。