システム開発契約で失敗しないための実践ガイド【契約書作成から交渉まで】
システム開発プロジェクトの成否を左右する要素は数多くありますが、その中でも契約書の内容は最も重要な要素の一つです。実際、システム開発における紛争の多くは、契約時の認識のズレや契約書の不備に起因しています。
この記事では、システム開発契約の基礎知識から実務で使える具体的なポイントまで、発注者・受注者双方の視点で詳しく解説します。契約形態の選び方、契約書に盛り込むべき条項、そして実際の交渉で注意すべき点まで、15年以上IT法務に携わってきた経験を踏まえてお伝えします。
システム開発契約とは何か
システム開発契約は、ソフトウェアやアプリケーション、業務システムなどの開発を委託する際に締結される契約です。発注者（ユーザー企業）と受注者（ベンダー、開発会社）の間で、開発内容、納期、費用、責任範囲などを明確に定めることで、プロジェクトの円滑な進行と後のトラブル防止を図ります。
なぜ契約書が重要なのか
システム開発は無形のサービスであり、物品の売買のように「完成品」が明確に定義しづらいという特徴があります。そのため、何を持って「完成」とするのか、仕様変更はどこまで許容されるのか、バグが見つかった場合の対応はどうするのかなど、曖昧になりがちな点を契約書で明確にしておく必要があります。
実務では、口頭での合意やメールのやり取りだけで開発を進めてしまい、後になって「言った・言わない」の水掛け論になるケースが少なくありません。こうした事態を避けるためにも、最初の段階できちんとした契約書を交わすことが不可欠です。
一般的な契約の流れ
システム開発契約を締結するまでの典型的な流れを見ていきましょう。
まず、プロジェクトの初期段階では秘密保持契約（NDA）を締結します。これは、商談段階で機密情報をやり取りする際に必要となるものです。次に、発注者側から提案依頼書（RFP）を作成し、複数のベンダーに送付します。
各ベンダーから提案書が提出されたら、技術力、実績、費用などを比較検討して優先交渉先を選定します。選定後は、基本契約書と個別契約書のドラフトについて協議を重ね、法務チェックを経て正式に締結する、という流れになります。
実際のプロジェクトでは、この基本契約をベースに、個別の開発案件ごとに個別契約（発注書や注文書と呼ばれることもあります）を締結していくのが一般的です。
契約形態の種類と選び方
システム開発契約には大きく分けて請負契約と準委任契約の2種類があり、プロジェクトの性質や開発手法によってどちらを選ぶかが変わってきます。この選択を誤ると、後々大きなトラブルに発展する可能性があるため、それぞれの特徴をしっかり理解しておきましょう。
請負契約の特徴とメリット・デメリット
請負契約は、「仕事の完成」に対して報酬を支払う契約形態です。民法第632条に基づき、受注者は約束した成果物を完成させる義務を負い、発注者は完成した成果物に対して報酬を支払う義務を負います。
請負契約の最大の特徴は、受注者が完成責任を負うという点です。つまり、どれだけ時間や費用がかかろうとも、約束した成果物を完成させなければ報酬を請求できません。逆に言えば、発注者にとっては「完成しなければお金を払わなくてよい」という安心感があります。
ただし、この安心感には落とし穴もあります。何を持って「完成」とするかが曖昧だと、受注者が「これで完成です」と主張しても、発注者が「これでは要件を満たしていない」と反論し、延々と修正作業が続くという事態になりかねません。
請負契約が適しているのは、要件が明確に定義できるウォーターフォール型の開発です。最初の段階で詳細な仕様書を作成し、その通りに開発を進めていくプロジェクトであれば、請負契約のメリットを最大限に活かせます。
一方、アジャイル開発のように要件が流動的で、開発しながら仕様を固めていくタイプのプロジェクトには不向きです。なぜなら、「完成」の定義が常に変化してしまい、請負契約の前提が崩れてしまうためです。
準委任契約の特徴とメリット・デメリット
準委任契約は、「一定の業務を行うこと」に対して報酬を支払う契約形態です。民法第656条に基づき、受注者は善良な管理者の注意義務（善管注意義務）をもって業務を遂行する義務を負いますが、成果物の完成までは約束していません。
準委任契約では、受注者は「一生懸命やること」が求められますが、必ずしも成果物を完成させる義務はありません。そのため、報酬の支払いは通常、稼働時間や人月（人×月）を基準に計算されます。
この契約形態が適しているのは、アジャイル開発や保守運用業務など、成果物の完成よりもプロセスや継続的な改善が重視されるプロジェクトです。要件が流動的で、開発しながら仕様を固めていくような場合、準委任契約の方が柔軟に対応できます。
ただし、発注者にとってのリスクもあります。準委任契約では「やるだけやったけど完成しませんでした」という事態が起こり得るため、プロジェクト管理をしっかり行わないと、費用だけかさんで成果が出ないという状況に陥る可能性があります。
実務での使い分け
実際のプロジェクトでは、フェーズごとに契約形態を使い分けるのが賢明です。例えば、要件定義フェーズは準委任契約で行い、要件が固まった後の設計・開発フェーズは請負契約で行う、といった形です。
また、最近では準委任契約でありながら成果完成型の条項を盛り込んだハイブリッド型の契約も増えています。これは、準委任契約の柔軟性を保ちながら、一定の成果物の納入を約束するという形態で、両者の良いとこ取りを狙ったものです。
ただし、こうしたハイブリッド型は法的な位置づけが曖昧になりがちなため、契約書の文言には特に注意が必要です。弁護士などの専門家に相談しながら進めることをお勧めします。
開発手法による契約の違い
システム開発の手法は、プロジェクトの性質や規模、納期などによって使い分けられます。主にウォーターフォール型とアジャイル型の2つがあり、それぞれ適した契約形態や契約書の内容が異なります。
ウォーターフォール型開発の契約
ウォーターフォール型は、要件定義→設計→開発→テスト→リリースという順序で、一方向に進んでいく開発手法です。各工程が完了してから次の工程に進むため、後戻りが困難という特徴があります。
この手法に適しているのは請負契約です。最初の要件定義で仕様を固め、その通りに開発を進めていくため、「完成」の定義が比較的明確になります。契約書には、各工程の成果物（要件定義書、設計書、ソースコード、テスト仕様書など）を具体的に列挙し、それぞれの検収基準を明記します。
ウォーターフォール型の契約で重要なのは、仕様変更の取り扱いです。発注者の都合で仕様を変更する場合、それが軽微な変更なのか、工数が大幅に増える変更なのかによって、追加費用の有無や納期の延長が発生します。契約書には、どの程度の変更まで無償で対応するのか、追加費用の計算方法、変更管理のプロセスなどを明確に定めておく必要があります。
実務では、仕様変更が発生するたびに「変更管理票」を作成し、双方が合意した上で署名するというプロセスを踏むのが一般的です。この変更管理票は契約書の一部として機能するため、しっかり管理しましょう。
アジャイル型開発の契約
アジャイル型は、短いサイクル（スプリント）で開発と検証を繰り返し、少しずつ機能を追加していく開発手法です。要件は固定せず、開発しながら調整していくため、柔軟性が高い一方で、最終的な成果物が事前に確定しないという特徴があります。
この手法には準委任契約が適しています。各スプリントで「何を開発するか」は決めますが、プロジェクト全体としての「完成」は流動的です。報酬も、スプリントごとの工数や人月を基準に計算するのが一般的です。
アジャイル開発の契約で難しいのは、プロジェクトの終了時期と総費用が見えにくいという点です。発注者としては「いつまで、いくらかかるのか」が不明確なまま進めるのは不安でしょう。そのため、契約書には以下のような工夫が必要です。
予算の上限設定: 総額でこの金額を超えない、という上限を設ける
中止条項: 一定の条件下で発注者がプロジェクトを中止できる権利を定める
定期的なレビュー: 数スプリントごとに進捗と予算を見直し、継続可否を判断する機会を設ける
また、独立行政法人情報処理推進機構（IPA）が公開している「アジャイル開発向けモデル契約」は、アジャイル開発に特化した契約のひな形として参考になります。実際の契約書作成時には、このモデル契約をベースにカスタマイズするのが効率的でしょう。
複合型（多段階契約）のアプローチ
実際のプロジェクトでは、ウォーターフォール型とアジャイル型を組み合わせた多段階契約が採用されることも増えています。
典型的なパターンは、まず要件定義フェーズを準委任契約で行い、要件が固まった段階で設計・開発フェーズを請負契約で進める、というものです。こうすることで、初期段階の不確実性に対応しながら、本格開発では成果物の完成を約束できます。
多段階契約を採用する場合、基本契約と個別契約の2階建て構造にするのが一般的です。基本契約では共通的な条件（秘密保持、知的財産権の取り扱い、紛争解決方法など）を定め、個別契約では各フェーズの具体的な内容（成果物、納期、報酬など）を定めます。
この方式のメリットは、プロジェクトの進行に合わせて柔軟に契約内容を調整できる点です。ただし、契約書の管理が煩雑になるため、どの契約がどのフェーズに適用されるのかを明確にしておく必要があります。
契約書に必ず盛り込むべき重要条項
システム開発契約書には、プロジェクトの成否を左右する重要な条項が多数あります。ここでは、実務で特にトラブルになりやすい条項を中心に、具体的な記載内容と注意点を解説します。
契約の目的と適用範囲
契約書の冒頭では、この契約が何のためのものかを明確に記載します。「発注者が運営するECサイトのリニューアルに伴うシステム開発」といった具合に、具体的に書くことで、後の解釈の余地を減らせます。
適用範囲も重要です。この契約がカバーする業務の範囲を明確にし、「この範囲外の作業は別途見積もりが必要」という理解を双方で共有しておきます。曖昧にすると、発注者は「この作業も含まれているはず」と考え、受注者は「それは範囲外です」と主張して、トラブルになります。
用語の定義
システム開発契約では専門用語が多く使われるため、用語の定義をしっかり定めておくことが重要です。例えば、「成果物」「検収」「仕様書」「バグ」「重大な欠陥」など、契約書で使用する用語の意味を明確にします。
特に「バグ」と「仕様変更」の境界線は曖昧になりがちです。「仕様書に書かれていない動作をする」のはバグなのか、仕様の不備なのか。契約書では、こうしたグレーゾーンをできるだけ減らすような定義を心がけます。
成果物の定義と納品方法
何を納品するのかを具体的に列挙します。ソースコード、実行ファイル、設計書、操作マニュアル、データベース設計書など、納品物を一つ一つ明記しましょう。
納品方法も重要です。物理メディア（CD-ROMなど）での納品なのか、オンラインでのデータ転送なのか、GitHubなどのリポジトリを使うのか。また、納品時のファイル形式やディレクトリ構成なども定めておくと、後のトラブルを防げます。
実務では、納品物のリストを別紙として添付し、「別紙1記載の成果物を納品する」という形にすることが多いです。こうすることで、成果物が増減した場合も、別紙を差し替えるだけで対応できます。
仕様の確定と変更管理
システム開発で最もトラブルになりやすいのが仕様変更です。発注者は「こんな機能も欲しい」と追加要望を出しがちですが、受注者にとっては工数が増えることになります。
契約書では、仕様変更の手続きを明確に定めます。変更要望が出た場合、まず見積もりを作成し、双方が合意した上で変更を実施する、というプロセスを踏むことが重要です。
また、軽微な変更の範囲も定めておきましょう。「画面上の文言を5文字以内で修正する」といった小さな変更まで、いちいち見積もりを出していては効率が悪いため、「〇〇人日以内の工数で対応できる変更は無償で対応する」といった条項を入れることもあります。
ただし、この「軽微な変更」の定義が曖昧だと、発注者が何度も小さな変更を要求し、積もり積もって大きな負担になる、という事態も起こり得ます。実務では、「軽微な変更は月に〇回まで」といった制限を設けることも検討しましょう。
検収と検収基準
検収は、納品された成果物が契約の要件を満たしているかを確認する重要なプロセスです。検収が完了して初めて、受注者は報酬を請求できます（請負契約の場合）。
契約書では、検収期間と検収基準を明確に定めます。例えば、「納品から14日以内に検収を完了する」「検収基準は別紙の要件定義書に準拠する」といった形です。
検収基準が曖昧だと、発注者が「イメージと違う」という理由で検収を拒否し続ける、という事態になりかねません。そのため、検収基準はできるだけ客観的で測定可能なものにする必要があります。
✕ 「使いやすいUIであること」（主観的で測定不可能）
◯ 「〇〇の操作が3クリック以内で完了すること」（客観的で測定可能）
また、検収期間内に発注者が何も連絡しなかった場合、自動的に検収完了とみなすみなし検収条項を入れることもあります。これにより、発注者が検収作業を放置して、いつまでも支払いが行われない、という事態を防げます。
契約不適合責任（旧:瑕疵担保責任）
2020年4月の民法改正により、「瑕疵担保責任」は「契約不適合責任」に変わりました。納品された成果物が契約の内容に適合しない場合、発注者は受注者に対して修補、代金減額、損害賠償などを請求できます。
契約書では、この責任の範囲と期間を明確にします。「納品後〇ヶ月以内に発見された不具合については無償で修正する」「ただし、発注者の環境に起因する不具合は除く」といった形です。
実務では、不具合の重大度によって対応期間を変えることもあります。例えば、システムが全く動作しないような重大な不具合は即座に対応するが、表示が少しずれているような軽微な不具合は次回のアップデート時にまとめて対応する、といった具合です。
知的財産権の帰属
システム開発で作成されたソフトウェアの著作権は、原則として作成者（受注者）に帰属します。これは著作権法の原則です。ただし、契約書で別段の定めをすることで、著作権を発注者に譲渡することも可能です。
実務では、以下のようなパターンがあります。
パターン1: 著作権を発注者に譲渡 受注者は開発したソフトウェアの著作権を発注者に譲渡し、発注者が自由に使用・改変できるようにします。この場合、譲渡の対価を報酬に含めるか、別途支払うかを明確にする必要があります。
パターン2: 著作権は受注者に留保し、使用許諾を与える 著作権は受注者が保持したまま、発注者に対して使用を許諾します。この場合、発注者が第三者にシステムを販売したり、改変したりすることは原則としてできません。
パターン3: 共有著作権 著作権を発注者と受注者で共有します。ただし、共有著作権は管理が複雑になるため、実務ではあまり推奨されません。
どのパターンを選ぶかは、プロジェクトの性質によります。受注者が同じようなシステムを他の顧客にも提供したい場合はパターン2が適していますし、発注者が独自のシステムとして自由に改変・展開したい場合はパターン1が適しています。
また、オープンソースソフトウェア（OSS）を使用する場合の取り扱いも重要です。OSSには様々なライセンスがあり、中には「このOSSを使って開発したソフトウェアもオープンソースにしなければならない」というコピーレフト型のライセンスもあります。契約書では、どのOSSを使用するか、そのライセンスは何か、を明記しておく必要があります。
再委託の可否
受注者が開発業務の一部または全部を第三者に委託（再委託）できるかどうかを定めます。大規模プロジェクトでは、受注者がすべての作業を自社で行うのは現実的でないため、再委託を認めることが一般的です。
ただし、再委託を無制限に認めると、品質管理や情報セキュリティの面でリスクがあります。そのため、契約書では以下のような制限を設けることが多いです。
再委託には発注者の事前承認が必要
再委託先の選定基準を定める（実績、セキュリティ体制など）
再委託先にも契約書と同等の義務を課す
再委託先の行為についても受注者が責任を負う
実務では、想定される再委託先をあらかじめリスト化し、「別紙記載の企業への再委託は承認されたものとみなす」という条項を入れることもあります。
機密保持と個人情報の取り扱い
システム開発では、発注者の機密情報や個人情報を扱うことが多いため、機密保持条項は必須です。受注者は、開発過程で知り得た情報を第三者に漏らしてはならず、目的外に使用してはなりません。
個人情報を取り扱う場合は、個人情報保護法に基づく適切な管理が求められます。契約書では、個人情報の取り扱い方法、セキュリティ対策、漏洩時の対応などを詳細に定めます。
近年では、GDPR（EU一般データ保護規則）など、海外の個人情報保護規制も意識する必要があります。EU圏のユーザーのデータを扱う場合、GDPRに準拠した契約条項が必要になるため、専門家に相談することをお勧めします。
報酬と支払条件
報酬額と支払いのタイミング、方法を明確に定めます。
固定報酬型（一括払い） 請負契約でよく使われる方式で、プロジェクト全体で〇〇万円、という形で報酬を確定します。支払いは、契約時に〇%、中間検収時に〇%、最終検収時に〇%、という分割払いにすることが多いです。
タイムアンドマテリアル型（工数精算） 準委任契約でよく使われる方式で、実際の作業時間に応じて報酬を支払います。「シニアエンジニア: 月単価〇〇万円」「ジュニアエンジニア: 月単価〇〇万円」といった形で単価を定め、実績に基づいて精算します。
支払条件も重要です。検収完了後〇日以内に振込、といった形で明確にします。また、消費税の取り扱い、振込手数料の負担なども定めておきましょう。
損害賠償と責任の制限
システム開発で問題が発生した場合の損害賠償について定めます。ただし、無制限の賠償責任を認めると、受注者にとってリスクが大きすぎるため、責任の上限を設けることが一般的です。
例えば、「受注者の責任は、契約金額を上限とする」といった形です。ただし、受注者に故意または重大な過失がある場合は、この上限を適用しないという条項を入れることもあります。
また、間接損害の免責も重要です。システムの不具合により発注者が得られるはずだった利益を失った（逸失利益）場合、その全額を賠償するとなると莫大な金額になる可能性があります。そのため、「間接損害、特別損害、逸失利益については責任を負わない」という条項を入れることが多いです。
プロジェクト管理と協力義務
システム開発は、受注者だけでなく発注者の協力も不可欠です。契約書では、双方の協力義務を明確にします。
発注者の義務としては、以下のようなものがあります。
必要な情報やデータの提供
質問への回答（〇営業日以内など期限を設ける）
検収作業の実施
開発環境の提供（必要な場合）
受注者の義務としては、以下のようなものがあります。
定期的な進捗報告
問題が発生した場合の速やかな報告
プロジェクトマネージャーの配置
実務では、定例会議の開催を契約書に盛り込むことも多いです。「週に1回、進捗確認のための会議を開催する」といった形です。
契約の解除
契約を中途で解除できる条件を定めます。一般的な解除事由としては、以下のようなものがあります。
相手方が契約に違反し、催告後も是正しない場合
相手方が破産手続きなどを開始した場合
天災などにより契約の履行が困難になった場合
発注者側としては、受注者の開発が著しく遅れている場合や、品質が基準を満たさない場合に解除できる条項も検討すべきでしょう。
また、解除時の精算方法も定めておく必要があります。解除時点までの作業に対する報酬の支払い、納品済みの成果物の取り扱いなどを明確にします。
紛争解決
万が一、契約について紛争が発生した場合の解決方法を定めます。
裁判管轄 どこの裁判所で争うかを定めます。「東京地方裁判所を第一審の専属的合意管轄裁判所とする」といった形です。発注者と受注者が地理的に離れている場合、どちらの地域の裁判所にするかは重要な問題です。
準拠法 契約の解釈について、どこの国の法律を適用するかを定めます。国内取引であれば「日本法を準拠法とする」となりますが、国際取引の場合は慎重に検討する必要があります。
ADR（裁判外紛争解決） 裁判ではなく、調停や仲裁で解決することも検討できます。裁判よりも迅速で費用も抑えられる場合がありますが、仲裁の場合は判断に不服があっても上訴できないという点に注意が必要です。
IPAモデル契約書の活用方法
独立行政法人情報処理推進機構（IPA）は、システム開発契約のひな形としてモデル取引・契約書を公開しています。これは、経済産業省の委託により作成された信頼性の高いひな形で、実務でも広く活用されています。
IPAモデル契約書の構成
IPAのモデル契約書は、開発手法やフェーズに応じて複数のバージョンが用意されています。
ウォーターフォール型開発向け: 要件定義、設計、開発、テストの各フェーズごとの契約書
アジャイル型開発向け: スプリント単位での契約書
保守運用向け: システムの保守・運用に関する契約書
各契約書には、逐条解説も付属しており、なぜその条項が必要なのか、どのように記載すべきかが詳しく説明されています。初めてシステム開発契約書を作成する場合でも、この解説を読めば理解しやすいでしょう。
モデル契約書を使う際の注意点
IPAのモデル契約書は非常に有用ですが、あくまでひな形であり、そのまま使えるわけではありません。自社のプロジェクトに合わせてカスタマイズする必要があります。
まず、[ ]で囲まれた部分は、具体的な内容を記入する必要があります。例えば、「報酬は[金額]円とする」となっている部分は、実際の金額を入れます。
次に、選択的な条項は、プロジェクトの性質に応じて採用・不採用を判断します。モデル契約書には「この条項は〇〇の場合に採用する」という注記がついているので、それを参考にしましょう。
また、モデル契約書には含まれていない条項でも、プロジェクトに必要な条項は追加すべきです。例えば、特殊な業界特有の要件や、発注者固有のセキュリティポリシーなどは、モデル契約書には含まれていないため、自分で追加する必要があります。
実際の活用事例
ある中堅企業が社内の業務システムを刷新する際、IPAのモデル契約書を活用した事例を紹介します。
このプロジェクトは、要件定義から運用まで約2年かかる大規模なものでした。当初、同社は自社で契約書を一から作成しようとしていましたが、法務担当者がシステム開発の知識に乏しく、何を盛り込むべきか分からないという状況でした。
そこでIPAのモデル契約書を参考にすることにしました。まず、ウォーターフォール型の要件定義フェーズのモデル契約書をベースに、自社の要件を追加していきました。特に、業界特有のコンプライアンス要件や、既存システムとの連携に関する条項を追加しました。
結果として、契約書の作成期間を大幅に短縮でき、かつ必要な条項を漏れなく盛り込むことができました。プロジェクトは無事に完了し、契約書のおかげで大きなトラブルもなく進行したとのことです。
実務でよくあるトラブルと対策
どれだけ綿密に契約書を作成しても、実際のプロジェクトではトラブルが発生することがあります。ここでは、実務でよく見られるトラブルのパターンと、その対策を紹介します。
「言った・言わない」問題
最も多いトラブルが、口頭での合意やメールでのやり取りを巡る認識の齟齬です。発注者は「あの時こう言ったはずだ」と主張し、受注者は「そんなことは聞いていない」と反論する、というパターンです。
対策: すべての重要な合意事項は書面化し、双方が署名する習慣をつけましょう。メールでのやり取りも重要な証拠になりますが、メールは後から「そういう意味ではなかった」と言われる可能性があるため、正式な合意は必ず書面で残します。
実務では、議事録を作成し、会議の内容を記録するのが効果的です。議事録には、誰が何を発言したか、何が決定されたか、次回までの宿題は何か、などを明記し、参加者全員に共有します。異議がなければ、その議事録の内容が合意事項とみなされます。
仕様変更の無限ループ
発注者が次々と仕様変更を要求し、プロジェクトが一向に完成しない、というトラブルも頻発します。発注者としては「より良いものにしたい」という思いがありますが、受注者にとっては工数が膨れ上がり、採算が取れなくなります。
対策: 契約書で変更管理のプロセスを明確に定めます。変更要求が出た場合、まず影響分析を行い、工数・費用・納期への影響を見積もります。その上で、発注者が変更するかどうかを判断する、というプロセスを踏むことで、安易な変更要求を抑制できます。
また、仕様凍結日を設定するのも有効です。「〇月〇日以降の仕様変更は、次のバージョンでの対応とする」と決めることで、いつまでも仕様が固まらない、という事態を防げます。
検収の長期化
納品したのに、発注者がなかなか検収してくれない、というトラブルも多いです。発注者の担当者が忙しくて検収作業を後回しにしてしまったり、社内の承認プロセスに時間がかかったりすることが原因です。
対策: 契約書に検収期間とみなし検収条項を盛り込みます。「納品から14日以内に検収結果を通知しない場合、検収完了とみなす」という条項があれば、発注者も期限内に対応せざるを得なくなります。
また、検収作業をスムーズに進めるため、検収チェックリストを事前に作成し、発注者と共有しておくのも効果的です。何を確認すればよいかが明確になるため、検収作業の負担が軽減されます。
著作権・知的財産権を巡る紛争
システム開発で作成したソフトウェアの著作権が誰に帰属するか、という点で後からトラブルになることがあります。発注者は「お金を払ったのだから著作権は自分のものだ」と思い込み、受注者は「著作権は作成者である自分に帰属する」と主張する、というパターンです。
対策: 契約書で著作権の帰属を明確に定めます。著作権を発注者に譲渡するのか、受注者に留保するのか、使用許諾の範囲はどこまでか、を具体的に記載します。
また、開発したシステムに第三者の知的財産権が含まれる場合（OSSやライブラリなど）の取り扱いも明確にします。特に、コピーレフト型のOSSを使用する場合、そのライセンス条件が発注者のビジネスに影響を与える可能性があるため、事前に確認が必要です。
プロジェクトマネジメントの不全
受注者のプロジェクトマネジメントが不十分で、進捗が大幅に遅れたり、品質が著しく低かったりするケースもあります。一方、発注者側の協力が得られず、必要な情報提供が遅れることもあります。
対策: 契約書で双方のプロジェクトマネジメント体制を定めます。受注者はプロジェクトマネージャーを配置し、定期的に進捗報告を行う義務を負います。発注者も、質問に対する回答期限や、承認作業の期限を設けることで、プロジェクトがスムーズに進むようにします。
また、マイルストーンを設定し、重要な節目ごとに進捗を確認するのも効果的です。マイルストーンに遅れが出た場合は、早期に原因を分析し、リカバリープランを立てることで、プロジェクト全体の遅延を防げます。
下請法違反のリスク
発注者が資本金1,000万円超の法人で、受注者が個人事業主または資本金1,000万円以下の法人の場合、下請代金支払遅延等防止法（下請法）が適用される可能性があります。
下請法では、発注者に対して様々な義務が課されています。例えば、発注時に書面を交付する義務、代金を60日以内に支払う義務、一方的な減額の禁止などです。これらに違反すると、公正取引委員会から勧告を受けたり、罰則が科されたりする可能性があります。
対策: 下請法が適用される可能性がある場合、契約書の内容が下請法に準拠しているかを確認します。特に、支払期限、減額の禁止、発注書面の交付などに注意が必要です。不安な場合は、弁護士や公正取引委員会に相談することをお勧めします。
契約交渉のポイント
契約書の内容について、発注者と受注者の間で交渉が必要になることがあります。ここでは、交渉を進める際のポイントを、それぞれの立場から解説します。
発注者側の交渉ポイント
発注者としては、リスクを最小化することが目標です。以下のような点を重視して交渉しましょう。
完成責任の明確化 請負契約の場合、受注者に完成責任があることを明確にします。「ベストエフォート」「商業的に合理的な努力」といった曖昧な表現は避け、「約束した機能をすべて実装する」という明確な義務を課します。
検収基準の具体化 何を持って検収合格とするか、できるだけ客観的で測定可能な基準を設定します。「使いやすい」「美しい」といった主観的な基準は避け、「〇〇の処理が〇秒以内に完了する」といった定量的な基準にします。
損害賠償の範囲 受注者の責任制限条項については、慎重に検討します。契約金額を上限とする責任制限が提案されることが多いですが、発注者としては、少なくとも重大な過失や故意による損害については、上限を設けないという交渉も検討すべきです。
知的財産権の確保 開発したシステムの著作権を発注者に譲渡してもらうか、少なくとも独占的な使用権を確保します。将来的にシステムを改修したり、第三者に販売したりする可能性がある場合、著作権の帰属は非常に重要です。
受注者側の交渉ポイント
受注者としては、適正な利益を確保しつつ、過度なリスクを避けることが目標です。
責任範囲の限定 発注者の環境や、発注者が提供する情報の誤りに起因する問題については、受注者は責任を負わないという条項を入れます。また、不可抗力（天災、戦争、パンデミックなど）による遅延についても免責されることを明確にします。
変更管理の徹底 仕様変更があった場合、必ず見積もりを行い、発注者の承認を得てから作業を開始するというプロセスを徹底します。口頭での指示や、メールでの軽い依頼に対して、安易に対応してしまうと、後で「それは契約外だ」と主張しても認められにくくなります。
支払条件の改善 検収完了後すぐに支払いを受けられるよう、支払期限を短く設定します。また、プロジェクトが長期にわたる場合は、中間金を受け取れるようにすることで、キャッシュフローを改善できます。
再利用権の確保 開発したシステムの一部（汎用的なモジュールやライブラリなど）を、他のプロジェクトでも再利用できるようにしておくと、開発効率が上がります。契約書では、発注者向けにカスタマイズした部分は譲渡するが、汎用的な部分は受注者に留保する、という条項を検討します。
Win-Winの関係を築く
契約交渉は、どちらか一方が得をして、もう一方が損をする、というゼロサムゲームではありません。双方にとってメリットのある契約を目指すべきです。
例えば、受注者が品質の高いシステムを納品し、発注者がそれに対して適正な報酬を支払う。発注者は完成したシステムでビジネスを拡大し、受注者はその実績を活かして新たな案件を獲得する。こうしたWin-Winの関係を築くことが、長期的には双方にとって最も利益になります。
契約書は、相手を縛るためのものではなく、双方の権利と義務を明確にし、信頼関係を構築するためのツールです。この視点を忘れずに、建設的な交渉を進めましょう。
契約後のプロジェクト管理
契約書を締結したら終わり、ではありません。契約書の内容を遵守しながら、プロジェクトを適切に管理していくことが重要です。
キックオフミーティングの重要性
契約締結後、できるだけ早くキックオフミーティングを開催しましょう。このミーティングでは、以下のような内容を確認します。
プロジェクトの目的とゴールの共有
体制図の確認（誰が何を担当するか）
コミュニケーション方法の確認（定例会議の頻度、連絡手段など）
マイルストーンとスケジュールの確認
課題管理の方法（どのツールを使うか、エスカレーションルールなど）
キックオフミーティングで認識を合わせることで、プロジェクトがスムーズにスタートします。
定期的なコミュニケーション
プロジェクト期間中は、定期的なコミュニケーションが欠かせません。週次や隔週でステータス会議を開催し、進捗状況、課題、次のステップを確認します。
会議だけでなく、日常的な報告・連絡・相談（ホウレンソウ）も重要です。問題が発生したら、すぐに相手に伝える。判断に迷ったら、相談する。こうした基本的なコミュニケーションが、トラブルの早期発見・早期対応につながります。
変更管理の徹底
プロジェクトの途中で仕様変更が発生することは珍しくありません。重要なのは、すべての変更を記録し、承認を得ることです。
変更要求が出たら、まず変更管理票（Change Request）を作成します。変更内容、理由、影響（工数、費用、納期への影響）、対応案を記載し、発注者と受注者の双方が承認します。承認後、この変更管理票を契約書の一部として管理します。
こうすることで、「この変更は承認されたのか、されていないのか」「追加費用は発生するのか、しないのか」といった曖昧さがなくなります。
リスク管理
プロジェクトには常にリスクが潜んでいます。技術的なリスク、人的リスク、外部環境のリスクなど、様々なリスクを想定し、対策を講じておく必要があります。
リスク管理では、まずリスクを洗い出し、それぞれのリスクの発生確率と影響度を評価します。発生確率が高く、影響度も大きいリスクについては、優先的に対策を講じます。
例えば、「キーパーソンが退職するリスク」に対しては、知識の共有やドキュメント化を進めることで、影響を最小化できます。「技術的な難易度が高く、実現できないリスク」に対しては、早期にプロトタイプを作成して検証することで、リスクを早期に顕在化させます。
契約書の見直し
長期にわたるプロジェクトでは、途中で契約内容を見直す必要が出てくることもあります。例えば、プロジェクトの規模が当初の想定より大きくなった場合、納期を延長したり、予算を増額したりする必要があるかもしれません。
こうした場合、契約の変更合意書を作成します。元の契約書の第〇条を以下のように変更する、という形で、変更内容を明確に記載し、双方が署名します。
口頭やメールだけで合意すると、後で「合意した・していない」という争いになる可能性があるため、必ず書面で残しましょう。
契約締結前のチェックリスト
契約書に署名する前に、以下の項目をチェックしましょう。
基本事項の確認
[ ] 契約当事者の名称、住所が正確に記載されているか
[ ] 契約の目的が明確に記載されているか
[ ] 契約期間が適切に設定されているか
[ ] 成果物が具体的に列挙されているか
費用・支払条件の確認
[ ] 報酬額が明確に記載されているか
[ ] 支払時期とタイミングが明確か
[ ] 消費税の取り扱いが明確か
[ ] 振込手数料の負担が明確か
[ ] 仕様変更時の追加費用の計算方法が明確か
責任範囲の確認
[ ] 請負契約か準委任契約か、契約形態が明確か
[ ] 完成責任の有無が明確か（請負契約の場合）
[ ] 契約不適合責任の範囲と期間が明確か
[ ] 損害賠償の範囲と上限が明確か
[ ] 免責事項が明確か
知的財産権の確認
[ ] 著作権の帰属が明確か
[ ] 使用許諾の範囲が明確か（著作権を譲渡しない場合）
[ ] 第三者の知的財産権の取り扱いが明確か
[ ] OSSの使用に関する条項があるか
プロジェクト管理の確認
[ ] 納期が現実的か
[ ] マイルストーンが設定されているか
[ ] 検収の方法と基準が明確か
[ ] 仕様変更の手続きが明確か
[ ] 定例会議などコミュニケーション方法が定められているか
終了・解除の確認
[ ] 契約終了時の成果物の取り扱いが明確か
[ ] 契約解除の条件が明確か
[ ] 解除時の精算方法が明確か
その他
[ ] 秘密保持条項があるか
[ ] 個人情報の取り扱いが適切か
[ ] 再委託の条件が明確か
[ ] 準拠法と裁判管轄が明確か
[ ] 下請法に抵触していないか（該当する場合）
これらの項目をすべてチェックし、不明な点や懸念がある場合は、署名前に相手方と協議するか、弁護士などの専門家に相談しましょう。
まとめ
システム開発契約は、プロジェクトの成否を左右する重要な要素です。適切な契約形態を選び、必要な条項をすべて盛り込んだ契約書を作成することで、後のトラブルを大幅に減らすことができます。
契約書の作成にあたっては、IPAのモデル契約書を活用するのが効率的ですが、あくまでひな形であるため、自社のプロジェクトに合わせてカスタマイズすることが不可欠です。
また、契約書を締結したら終わりではなく、契約内容を遵守しながら、適切なプロジェクト管理を行うことが重要です。定期的なコミュニケーション、変更管理の徹底、リスク管理などを通じて、プロジェクトを成功に導きましょう。
システム開発契約は複雑で、法律の専門知識も必要になるため、重要なプロジェクトでは弁護士などの専門家に相談することをお勧めします。特に、高額なプロジェクトや、新しい技術を使うプロジェクト、国際的な要素が絡むプロジェクトでは、専門家のアドバイスが不可欠です。
適切な契約書と良好な協力関係があれば、発注者と受注者の双方がWin-Winの関係を築き、プロジェクトを成功させることができます。この記事で紹介した知識とポイントを活用して、皆さんのプロジェクトが成功することを願っています。
