ソフトウェア開発（システム開発）の種類
ソフトウェア開発には、大きく分けてアジャイル型とウォーターフォール型の2つが存在します。選択を誤るとコストや品質に影響するので、基本概念を押さえて判断材料にしてください。
アジャイル型
アジャイル開発は、短い反復を重ねながら優先度の高い機能から実装を進める手法です。
初期段階で詳細仕様を固めず、動く成果を出しつつ方向修正を繰り返します。仕様変更に強く市場変化への即応力が得られ、早期リリースによるフィードバックを経済的価値に結び付けられます。
チーム全体で進捗と課題を共有し、成果物の品質を高める点も強みです。一方、計画が流動的になるため、予算や納期の管理には継続的な合意形成が欠かせません。
対話重視のスクラムを用いれば役割とイベントが整理され、進行が円滑になります。
ウォーターフォール型
ウォーターフォール開発は、要件定義からテストまでを段階的に進め、各工程を完了してから次へ移行する手法です。
初期に仕様を詳細まで確定するため進捗管理が行いやすく、ドキュメント中心の管理で品質基準を明示できます。計画通りに進めば予算と納期の見通しが立ち、契約条項にも落とし込みやすい点が特長です。
ただし途中変更への適応力が低く、後半で仕様を修正すると手戻りが発生します。市場や要求が動きやすい案件では、慎重な適用判断が必要です。
プロジェクト規模が大きくメンバーが多い場合にも、手順の明確さが統制力を助けます。
ソフトウェア開発（システム開発）における「委託契約」とは
ソフトウェア開発で用いられる委託契約は、発注者が社外の専門家に業務を任せ、完成責任や成果物の有無に応じて請負契約・準委任契約へ細分されます。
請負型では納品物が完成した時点で報酬が支払われ、準委任型では作業時間や達成割合に基づき対価が発生します。双方は雇用関係を伴わず、発注者が直接指揮命令を行えない点が特徴です。
そのため、業務範囲や成果基準、報酬算定方法を契約書に明記し、責任分担や知財帰属を明確化しましょう。外部人材活用で固定費を抑え技術を得られますが、ノウハウ蓄積は限定的です。
委託契約の法的根拠
委託契約の根拠は、民法に定められた2つの条文にあります。仕事の完成を伴う場合は第632条が適用され、成果物の引き渡しと報酬支払が契約成立の条件となります。
- （請負）第六百三十二条 請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
対して法律行為そのものを任せるケースでは第643条が基盤となり、受任者の承諾時点で効力が発生します。
- （委任）第六百四十三条 委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。
さらに、法律行為に当たらない事務を委ねる準委任（656条）は委任規定を準用して処理されます。
- （準委任）第六百五十六条 この節の規定は、法律行為でない事務の委託について準用する。
開発委託では条文の組合せで責任範囲・成果基準・報酬計算を明示し、紛争を防止することが実務上不可欠です。
委託契約の種類と各種契約の違い
契約類型：業務の中心：報酬が確定するタイミング：指揮命令の所在完成責任：瑕疵責任：印紙・その他の留意点
請負契約：成果物の完成を伴う仕事（例：システムの本番環境への納品）：仕事が完成し検収を通過したあと：ベンダー側が自律的に管理：成果物が仕様に適合しない場合、ベンダーが契約不適合責任を負う：契約金額に応じた収入印紙が必要になる場合がある
委任契約：法律行為など限定的な業務（例：登記申請代行）：業務遂行そのものに対して発生：ベンダーが手順を決定：成果物の完成義務を負わないが善管注意義務あり：一般に印紙の貼付は不要（長期の継続基本契約は除外）
準委任契約：コンサルティングや要件定義など、成果物を特定しにくい事務：実働時間・工数または達成割合に応じて発生：ベンダーが工程を管理：完成責任はなく、作業遂行に対する注意義務を負う：基本的に印紙不要、長期基本契約は4,000円の印紙が必要
派遣契約：受託者の従業員を発注者の現場に配置し日常業務を行う：作業時間に応じて発生：発注者が現場で直接指揮命令：発注者が成果管理を行うため、派遣元の完成責任は限定的：労働者派遣法の対象となり、契約条項・期間規制に注意
上記のとおり、委託契約は「成果物が必要か」「誰が指揮命令を行うか」「責任の帰属はどこか」で性質が分かれます。
業務内容や管理方法に合った契約形態を選定し、条項を明文化することで後のトラブルを防止できます。
委託契約のメリット・デメリット
＜メリット＞
- 必要なときだけ外部人材へ発注できるため、固定人件費や設備投資を抑えられる
- 高度な技術や業界特有のノウハウを即座に取り込み、開発スピードを上げられる
- 設計・プログラミングを外部へ任せることで、社内はコア業務に専念できる
- 案件単位で費用を把握しやすく、プロジェクト採算を判断しやすい
＜デメリット＞
- 外部完結型のため、運用や改善に必要な知識が社内へ蓄積しにくい
- 発注者は直接指揮命令できず、成果物の品質やスケジュールを管理しづらくなる
- 外部業者に機密を共有するため、契約条項やセキュリティ体制の確認が不可欠
- 仕様変更や機能追加のたびに別途コストが生じ、予算が膨らみやすくなる
委託契約は、柔軟な外部リソース活用によりコストとスピードを両立できます。一方で、社内知見や品質統制をどう補完するかが成功において重視される要因です。
ソフトウェア開発（システム開発）委託契約書とは
ソフトウェア開発委託契約書は、ソフトウェアやシステムの構築を外部に依頼する際に、委託側と受託側が取り交わす文書です。社内基盤システムの構築を外部企業へ頼む場合や、顧客向けに販売するパッケージの開発を依頼する場合に用いられます。
契約形態は、大きく準委任型と請負型の2種類に分かれます。準委任型は開発作業そのものを中心に依頼する形で、請負型は完成したシステムの納品を主目的とする形です。
開発規模や期間などの条件により最適な形態が決まり、ウォーターフォール開発を採用する場面では、工程を段階的に区分して検討します。
参考：「IPA情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」（P.14）より一部改変
基本契約書と個別契約書
ソフトウェア開発を外部に委託する場合、基本契約書と個別契約書を分けて締結する形が一般的です。
基本契約書では、損害賠償や解除条項、代金の支払方法や裁判管轄など、取引全体に共通する事項を規定します。
個別契約書には、フェーズごとの委託範囲や報酬額など、プロジェクト固有の条件を詳細に盛り込みます。
2種類の契約書に矛盾が生じたときの優先順位も、基本契約書で定めておくことが欠かせません。多くの事例で個別契約の内容を上位に置きますが、契約本数が増えて管理が煩雑になる恐れがある場合は、基本契約を優先させる方式も有効でしょう。
なお、小規模案件では、両契約の要素を一本にまとめた単一の契約書で対応する選択肢もあります。
ソフトウェア開発（システム開発）委託契約締結までのステップ
システム開発委託契約は、要件整理からキックオフまで十段階で進行します。流れを把握すれば漏れなく交渉と契約管理ができ、プロジェクト成功率が高まるでしょう。
ここでは、各工程の要点と注意点を簡潔に整理します。
1.事業目的・開発範囲の整理
事業目標と想定効果を共有し、機能要件と非機能要件を区分したうえで要件定義書へ落とし込みましょう。IPAの要求策定ガイドでは、ヒアリング議事録を確認書式に転記し、品質特性チェックリストで漏れを点検する方法が示されています。
責任者を視点別に割り当てれば進捗が可視化され、手戻りも抑制できます。合意内容を版管理表に登録すると、更新履歴の追跡も容易です。
2.NDA（秘密保持契約）の締結
要件書や設計図を外部へ開示する前に、まずNDAを締結して情報管理体制を固めます。秘密保持契約では以下を明記し、双務契約とすることで公平性が保たれます。
- 情報範囲
- 目的外使用の禁止
- 返却義務
期間や存続条項を設定すると、終了後の漏えいリスクも抑制できます。印紙要否や電子契約の適用可否を確認し、運用に合う形態を選びましょう。
3.RFP（提案依頼書）の作成と送付
NDAで保護された情報を基にRFPを整備し、候補ベンダーへ提示しましょう。提案依頼書には以下を詳細に記載し、見積と開発計画を期限付きで求めます。
- 開発目標
- 期待成果物
- 評価観点
採点項目と重み付けを事前共有すれば交渉根拠が明朗になり、信頼構築にも寄与します。
4.提案書の比較・優先交渉先の選定
提出された提案書を同一尺度で比較し、優先交渉先を決定しましょう。
議事録と決裁状況を保存すれば、後日の意思決定検証が容易です。決定根拠を可視化する文化が、組織の信頼を高めます。
5.基本契約（マスター）ドラフト協議
長期間共通となる以下の条項を整理します。
- 再委託
- 知的財産の帰属
- 瑕疵対応
- 損害賠償範囲
準拠法や裁判管轄を明文化すると、国際案件でも適用関係が明瞭です。価格改定条項を設ければ、長期契約の費用変動へ柔軟に対応できます。
6.個別契約（開発委託契約）ドラフト協議
続いて、以下を詳細化しましょう。
- 成果物範囲
- マイルストーン
- 検収方法
- 支払条件
- 変更管理手順
基本契約との差分を条文で特定し、優先関係を明示すると責任区分が明確になります。成果物一覧表を添付すれば齟齬が減少し、品質トラブルの対応も円滑になるでしょう。
7.法令・リスクチェック
草案が固まったら、法令適合性とリスクを確認します。下請法・個人情報保護・セキュリティ指針を照合し、不備があれば条文を修正しましょう。
内部監査部門と連携しリスク一覧を整備すると意思決定が加速し、外部監査への説明も容易です。
8.リーガルレビューと社内承認
リーガルレビュー後に、社内稟議を進めます。外部弁護士の見解を加えると条項解釈の偏りが排除され、経営層の承認も得られます。
承認プロセスを電子化すると進行状況が可視化され、遅延が抑制されるでしょう。
9.正式締結（押印・電子契約）
合意内容が確定したら、電子署名または押印で正式に締結しましょう。クラウドサインなどを利用すれば、タイムスタンプ付きで改ざん防止が可能です。
保存期間とアクセス権限を設定すれば漏えいリスクが低減し、更新履歴の自動取得も有効です。
10.キックオフミーティングの開催
契約発効後は、キックオフミーティングで担当者・連絡フロー・成果物提出形式を共有しましょう。
役割分担と報告サイクルを定義すれば、責任境界が明瞭になります。リスク一覧を配布し対応方針を協議すると序盤の不安が軽減され、進捗報告も効率化されるでしょう。
ソフトウェア開発委託契約書の作成に際し参考にできるモデル契約書
ソフトウェア開発委託契約書を作成する際は、独立行政法人情報処理推進機構（IPA）が公開するモデル契約書が有用な手引きになります。ただし、雛型をそのまま流用せず、取引の実情に合わせて条項を調整する配慮が欠かせません。
独立行政法人情報処理推進機構のモデル契約書
独立行政法人情報処理推進機構（IPA）は、経済産業省がかつて公表したモデル契約書を再検討し、改訂版として提供しています。IPAは経済産業省のIT政策実行機関として、IT動向や情報セキュリティの社会的課題を調査し、施策を企画する専門組織です。
公開中のモデル契約書は2020年民法改正に対応しており、ウォーターフォール方式向け「情報システム・モデル取引・契約書」第二版と、アジャイル方式向け「情報システム・モデル取引・契約書（アジャイル開発版）」を収録しています。
アジャイル開発を検討する際は、当該ひな型と解説資料が有益な参考資料となります。
情報システム・モデル取引・契約書（https://www.ipa.go.jp/digital/model/index.html）
ソフトウェア開発委託契約書の主な条項
ソフトウェア開発を外部企業へ委託する契約を結ぶ際には、あらかじめ明文化しておくべき必須条項が存在します。
開発手法は、アジャイル型とウォーターフォール型の2種類に大別されます。アジャイル型は機能単位で実装を進めつつ、必要に応じて前段階へ戻る柔軟性を持つ手法です。一方、ウォーターフォール型は「要件定義→外部設計→内部設計→実装→テスト」のように工程を一連に進め、前段階へ戻らない前提で管理します。
契約書を作成する際は、どちらの開発方式を採用するかを最初に明確化し、プロジェクトの内容や作業範囲を具体的に記載する姿勢が不可欠です。
以下で、ソフトウェア開発委託契約書に盛り込むべき条項を順に解説します。
契約の目的
ソフトウェア開発委託契約に限らず、あらゆる契約では目的条項の設定が欠かせません。目的を明示すれば条文の意図が透過し、紛争発生リスクを抑えやすくなります。
ソフトウェア開発の場合は、想定する最終利用者や利用シーンを具体的に盛り込む配慮が望ましいでしょう。
さらに、債務不履行などの法的責任を判断するとき、目的条項は重要な評価材料になります。責任範囲を巡る議論を防ぐためにも、目的を詳細に記述する姿勢が求められます。
【基本契約書の記載例】
本契約は、甲が、甲社内で利用する営業推進顧客管理システムのコンピュータソフトウェアの開発に関する業務（以下「本件業務」という。）を乙に委託し、乙がこれを受託することに関する基本的な契約事項を定めることを目的とする
用語の定義
ソフトウェア開発委託契約書では、専門用語が頻繁に登場します。そこで、契約書内で使用する語句の意味をあらかじめ定める「定義条項」を設けることが欠かせません。
用語の解釈が当事者間で食い違えば、業務遂行時のコミュニケーションに齟齬が生じ、紛争へ発展する恐れがあります。
定義条項を作成するときは語句の内容が正確かどうかに加え、契約書内でその語句が使われる箇所との整合性や追加修正の要否まで検証する姿勢が重要です。
【基本契約書の記載例】
本契約で用いる用語の定義は、次のとおりとする。
① 本件ソフトウェア本契約及び個別契約に基づき開発されるソフトウェアであって、プログラム、コンテンツ、データベース類及び関連資料など個別契約において定めるもの
② 要件定義書本件ソフトウェアの機能要件（甲の要求を満足するために、ソフトウェアが実現しなければならない機能に係る要件。システム機能及びデータにより定義される。）及び非機能要件（機能要件以外のすべての要素に係る要件。業務内容及びソフトウェアの機能と直接的な関連性を有さない品質要件、技術要件、移行要件、運用要件及び付帯作業等から成り、それぞれに対する目標値及び具体的事項により定義される。）をとりまとめた文書
③ ………
適用範囲
ウォーターフォール型で工程ごとに個別契約を取り交わす構成を採る場合、まず基本契約書に「どの範囲に基本条項を適用するか」を明示します。
さらに各工程が請負に当たるのか準委任に該当するのかによって、準拠条文を切り分けるケースもあります。その際は「個別契約Ａには基本契約書の第○条と第○条を適用する」といった形で対応関係を具体的に記載し、内容の妥当性を確認しましょう。
一方、アジャイル開発では多くの場合が準委任型のため、適用範囲を細かく区分する条項を置かずに済むケースが目立ちます。
【基本契約書の記載例】
1. 本件業務は、第〇条の要件定義作成支援業務、第〇条の外部設計書作成支援業務、第〇条のソフトウェア開発業務、第〇条のソフトウェア運用準備･移行支援業務から構成され、本件業務の個々の業務（以下｢個別業務｣という。）には本契約のほか、次条に基づき締結される当該個別業務に関する契約（以下「個別契約」という。）が適用される。
2. 甲及び乙は、個別契約において本契約の一部の適用を排除し、又は本契約と異なる事項を定めることができる。この場合、個別契約の条項が本契約に優先するものとする。
個別契約
前述のとおり、ウォーターフォール開発では、フェーズ単位で個別契約を取り交わす形式が一般的です。個別契約では担当作業や成果物を細部まで記載し、実務内容を具体化します。
加えて、基本契約に主要な取引条件を例示しておけば、当事者の見通しが立ちやすく交渉も円滑に進みます。
さらに、個別契約の成立手続きと成立時点を基本契約で定義しておくと安全です。成立の有無が後日に争点となるリスクを抑えられるためです。
【基本契約書の記載例】
1. 甲及び乙は、個別業務に着手する前に、提案依頼書、提案書及び見積書に基づいて、当該個別業務について以下の各号のうち必要となる取引条件を定め、個別契約を締結する。 ①具体的作業内容（範囲、仕様等） ②作業期間又は納期 ③甲乙の役割分担 ④………
2. 個別契約は、甲乙間で個別契約に署名捺印した場合又は甲が乙に対し発注書を交付し、乙が発注請書を提出した場合に成立するものとする。
委託料と支払い方法
委託契約書には、委託料について定める条項も欠かせません。ウォーターフォール方式では工程ごとに報酬が発生する例が多く、計算式がフェーズ別に変わる場合も見受けられます。
報酬額や算出手順は、個別契約で細かく規定するのが一般的です。実費の取り扱いについても整理が必要です。対象となる費用や負担先をあらかじめ明記すれば、後日争点になりにくくなります。
なお、下請代金支払遅延等防止法の適用を受ける契約では、業務完了または納品から六十日以内に支払う義務が課されますので注意しましょう。
【基本契約書の記載例】
1. 甲は乙に対し、本件業務の対価として、各個別契約で定めた委託料を当該個別契約で定めた方法で支払う。2. 本件業務の遂行に際して必要な実費については、個別契約でその負担について定める場合は個別契約で定めた内容に従う。個別契約で定めがない場合は、甲乙間で別途合意した場合を除き、乙の負担とする。
作業期間または納期
ソフトウェア開発契約では、作業期間と納期の明示が欠かせません。
ウォーターフォール方式を採用する場合、各工程ごとに個別契約を結び、工程別に期間や納品日を設定する形が一般的です。アジャイル開発でも、準委任契約なら作業期間を、請負契約なら納期を定義します。
加えて、計画どおりに進行しない場面を想定し、双方が再協議できる条項を設ける事例も見受けられます。
【基本契約書の記載例】
各個別契約の業務期間又は納期は、当該個別業務にかかる個別契約において定める。
再委託
ソフトウェア開発の現場では、受託者が業務を完全または部分的に別企業へ再委託する事例が珍しくありません。
ただし、委託者の立場からすると、了承なしに作業工程が外部へ移ると品質や進行状況への懸念が生じます。そのため、契約書では再委託の可否、可とする場合の事前通知義務などを明示する必要があります。
一般的には「再委託原則禁止、ただし書面による承諾があるときのみ許可」という方式を採用しますが、受託者の裁量で再委託先の選定を認める形も見受けられるでしょう。いずれの場合でも、再委託先に関する責任は受託者が負うと定めておくと、責任範囲が明確になり紛争リスクを抑制できます。
【基本契約書の記載例】
1. 乙は、事前に書面による甲の承諾を得た場合に、各個別業務の全部又は一部を第三者に再委託することができる。
2. 乙は、前項の規定により再委託した場合、再委託先の行為及び結果について、責任を負うものとする。
システムの仕様と変更
ウォーターフォール型の契約では、上流工程で要件を固めた時点でシステム仕様も確定するため、途中段階からの変更は原則として想定しません。
一方、アジャイル契約では後戻りを許容しながら幅を持たせて開発を進めるため、途中で仕様を更新する場面が生じやすいでしょう。変更が起きた際の手順と、変更後の仕様確定方法を条文化しておく姿勢が欠かせません。
【基本契約書の記載例】
1. 甲と乙は、本契約又は別途作成した仕様書に記載された内容について変更の必要が生じた場合には、その変更の具体的内容及び理由を示した書面を相手方に交付して、変更の協議（以下「変更協議」という。）の開催を要請することができる。
2. 甲と乙は、相手方より前項の要請があったときは、速やかに協議に応じなければならない。
3. 変更協議の結果、本契約の内容を変更することが合意された場合には、変更内容が記載された変更合意書を作成し、甲乙双方が当該合意書に記名押印する。
ソフトウェアの検収
ソフトウェア開発委託契約では、完成したプログラムやシステムを受託者が納品した時点で、委託者は契約書に示された仕様へ適合しているかを確認します。納品後の検査を「検収」と呼びます。
検収条項に明示するのは、以下の項目です。
- 検査手順・期間
- 不合格時の修正対応と
プログラムやシステムの契約では、試験方法や合格判定基準をあらかじめ設定しておく姿勢が欠かせません。合意した内容は契約書や仕様書へ盛り込み、両当事者が共通認識を持てるよう文書化する配慮も必要です。
【基本契約書の記載例】
1. 甲は、本件ソフトウェアを受領後、納入を受けた日から個別契約に定める期間内に、本契約及び別途定める仕様書に合致するか否かを検査しなければならない。
2. 甲は、本件ソフトウェアが前項の検査に適合する場合、検査合格書に記名押印の上、乙に交付するものとする。また、甲は、本件ソフトウェアが前項の検査に合格しない場合、乙に対し不合格となった具体的な理由を明示した書面を速やかに交付し、修正又は追完を求める。乙は、甲乙間で協議の上定めた期限内に無償で修正して甲に納入する。この場合の検査は前項の規定による。
3. 検査合格をもって、本件ソフトウェアの検収完了とする。
契約不適合責任
請負型契約では、納品済みの成果物が種類・品質の両面で契約内容に適合しない場合、受託者に契約不適合責任が生じます。
民法により、不適合を把握した日から1年以内に委託者へ通知すれば責任が発生するため、比較的長期間にわたり義務を負う可能性があります。
当事者が株式会社などの商人である場合は商法が適用され、契約不適合を確認した時点で速やかな通知が求められ、発見が難しいケースでも引渡し後6か月以内の連絡が必要です。したがって、受託者側は通知期間を短縮する条項を検討すると有利です。
一方、委託者は民法上、まず補修や追完を請求しますが、修補を経ずに代金を減額できる条項を設ける選択肢もあります。ソフトウェア開発委託契約では、当該条項が最も修正協議の対象になりやすい事項といえます。
【基本契約書の記載例】
1. 〇条の検収完了後、成果物について本契約又は仕様書との不一致（バグも含む。以下本条において「契約不適合」という。）が発見された場合、甲は乙に対して当該契約不適合の補修又は追完を請求することができ、乙は当該請求に従い補修又は追完するものとする。但し、乙がかかる責任を負うのは、〇条の検収完了後〇ヶ月以内に甲から書面により通知された場合に限るものとする。
2. 前項にかかわらず、契約不適合が軽微であって、甲の業務に実質的な影響を及ぼすものではなく、かつ成果物の補修又は追完に過分の費用を要する場合には、乙は前項所定の責任を負わないものとする。
3. 第1項の規定は、契約不適合が甲の提供した資料等又は甲の与えた指示によって生じたときは適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。
知的財産権の帰属・侵害の責任
開発済みのソフトウェアやシステムについて、特許権・著作権をどちらの当事者が保有するかを明確に取り決めます。委託者が不特定多数へ販売する製品を開発するケースでは、知的財産権を委託者へ帰属させたほうが適切です。
反対に、受託者が保有する特許や著作物を中心に活用して開発を進めた場合、受託者は「使用許諾までは認めても権利譲渡には応じたくない」といった意向を示すことがあります。
さらに、完成物が第三者の知的財産権を侵害した際の責任分担も条項に盛り込みます。この場面では、受託者に対し「開発物は第三者の権利を侵害していない」と表明保証を求める例が見受けられます。
【基本契約書の記載例】
1．本件業務遂行の過程で新たに生じた発明その他の知的財産又はノウハウ等（以下、あわせて「発明等」という。）に係る特許権その他の知的財産権（特許その他の知的財産権を受ける権利を含む。但し、著作権は除く。）、ノウハウ等に関する権利（以下、特許権その他の知的財産権、ノウハウ等に関する権利を総称して「特許権等」という。）は、当該発明等を行った者が属する当事者に帰属する。
2. 本件業務遂行の過程で乙が新たに作成した著作物に関する著作権（著作権法第27条及び第28条の権利を含む。以下同じ。）は、甲に帰属する。乙から甲への著作権移転の対価は、委託料に含まれるものとする。
3. 乙は、本件成果物が、第三者の知的財産等を侵害しないことを表明保証する。
4. 甲が本件成果物に関し第三者から著作権又は特許権等の侵害の申立を受けたときは、速やかに乙にその事実及び内容を通知する。5. 乙は、前項の申立がなされた場合、乙が責任と費用をもって、当該紛争を処理するものとする。
業務の終了確認
準委任型の開発契約では、委託内容が「業務の遂行」であり、成果物を納品する義務は発生しません。そのため、作業が適切に実施されたかを判定する仕組みを契約条項として整備する必要があります。
一般的な運用例として、受託者が業務完了報告書を作成・提出し、委託者が内容を精査したうえで承認する流れが採用されています。
【基本契約書の記載例】
1. 乙は、本件業務の終了後〇営業日以内に、業務終了報告書を作成し、甲に提出する。
2. 甲は、前項の業務終了報告書を受領してから〇営業日以内に、当該業務終了報告書を点検し、その内容に疑義がない場合、業務終了確認書に記名押印の上、乙に交付する。当該書類が交付された時点で、本件業務の終了を確認するものとする。
3. 前項記載の期間に甲から異議がない場合には、前項記載の期間の満了をもって、業務の終了を確認したものとみなす。
失敗事例から学ぶソフトウェア開発（システム開発）委託契約の注意点
最後に、経済産業省が開示している「情報システム・ソフトウェア取引トラブル事例集」から、ソフトウェア開発（システム開発）委託契約に関する注意点を押さえていきましょう。
- 正式契約書を締結していないのに作業を開始してしまうことが多い
キックオフ前後の口頭合意だけでベンダがプログラムを書き始め、あとから費用清算を巡る紛争に発展するケースです。文書化された発注が無ければ、着手時点で責任範囲も支払条件も不明確になります。したがって、有償作業へ移る前に「対象業務・成果物・金額・納期」を明文化した個別契約を結びましょう。着手承認は書面や電子署名で残すと安心です。
- 作業にあっていない契約形態になっていることが多い
仕様未確定なのに一括請負で予算を確定したため、要件定義の途中で工数が膨張し訴訟になった例も紹介されています。成果物が見えない段階では請負より準委任を使い、要件確定後にフェーズごとの請負へ切り替える二段階方式が有効です。契約類型を工程に合わせて組み合わせれば、追加費用の根拠も示しやすくなります。
参考：経済産業省｜情報システム・ソフトウェア取引トラブル事例集
最新の法改正情報に対応し、弁護士監修のひな形を多数提供する「LegalOn Cloud」
LegalOn Cloud「テンプレート」は、様々な類型・立場の契約書や、規約、社内書式など2000点を超えるひな形を収録。契約書作成業務の負担軽減と品質向上を支援します。
【新任～若手法務の方へ】そもそも契約とは何か、なぜ契約書を作成するのか、正しく答えられますか？以下の無料資料をダウンロードして、契約の基本を網羅的に理解しましょう。
