Contents
スポンサードリンク
1. 契約書構造 ― 基本契約＋個別SOW
| 階層 | 名称（例） | 主な役割 |
|---|---|---|
| ① | 基本契約書（マスタ） ※「システム開発委託基本契約書」 |
取引全体のルールを一元化。期間・支払方法・機密保持・知的財産権の枠組みなど、すべての案件で共通に適用できる条項を規定します。 |
| ② | 個別契約書（SOW） ※「システム開発委託作業指示書」 |
プロジェクトごとの業務範囲、成果物仕様、マイルストーン、報酬算出式など、実務に即した詳細を記載します。 |
- メリット
- 基本契約は1回だけ締結すれば済むため、取引開始のハンドリングが軽減。
- 個別SOWは案件ごとに差分だけを書き換えるだけで済み、変更管理が容易になる。
2. 主要7条項とカスタマイズ指針
| 条項 | カスタマイズ例（XYZ株式会社向け） | 実務上のチェックポイント |
|---|---|---|
| 1. 業務範囲 | 「要件定義フェーズは別途見積もり」と明記し、対象外業務は「システム保守・運用」等で列挙。 | ・曖昧な表現を排除 → 具体的な作業項目と除外項目を対照表にする。 |
| 2. 成果物・納品 | 納品形式＝「GitHub（プライベート）リポジトリ」＋「PDF版設計書」。受領確認は「検収チェックシート」に署名で完了。 | ・受領確認手順と再提出期限（例：5営業日以内）を必ず記載。 |
| 3. スケジュール・検収 | マイルストーンごとに 30% 支払 → 「第1フェーズ完了後10営業日以内に請求」 等具体化。 | ・遅延罰則は「納期超過1日につき契約金額の0.5％」と数値で示す。 |
| 4. 知的財産権 | 「開発完了後、著作権は貴社に譲渡」＋「第三者への再許諾は不可」と限定。 | ・ライセンス範囲（商用利用・改変可否）を明文化。 |
| 5. 機密保持 | NDA 有効期間＝契約終了後 3 年。例外は「法令に基づく開示」および「裁判所命令」。 | ・機密情報の定義（コード、設計書、顧客データ等）を列挙。 |
| 6. 保証・責任制限 | 「納品後 30 日間は不具合修正を無償」＋「賠償上限は契約金額の 2 倍」。 | ・免責条項が過度にならないよう、最低保証期間は必ず設定。 |
| 7. 解除条件 | 「重大な契約違反があった場合、30 日間の是正猶予後に書面で解除可能」 。精算は「未払金は全額返還、前払い金は実作業分を差し引く」。 | ・解除時の清算方法と残務処理手順を具体的に記載。 |
ポイント テンプレートそのままではリスクが残ります。上表のように「自社名・プロジェクト名」や「数値基準」を埋め込むだけで、曖昧さが大幅に減少します。
3. テンプレート入手先と最新版リンク
| 入手元 | フォーマット | 主な対象 | 推奨利用シーン |
|---|---|---|---|
| TemplateBank https://www.templatebank.com/category/software-development-agreement |
Word（.docx） | 基本契約・個別SOW・派遣契約等多数 | 豊富な検索機能で「開発委託」向けテンプレートを瞬時に取得。 |
| 経済産業省 標準様式 最新PDF（2024年版） https://www.meti.go.jp/policy/it_policy/standard_form/standard_contract_2024.pdf |
PDF／Word（ダウンロードページから変換可） | 「システム開発委託基本契約書」「個別作業指示書」等官公庁定めの標準形 | 公的案件や法令遵守が重要な企業に最適。 |
| MySign.jp https://mysign.jp/templates/software-development-individual-contract |
Word（.docx） | 個別SOW に特化したひな形 | チェックリスト付きで、導入直後の実務負荷が低い。 |
※「経済産業省 標準様式」のリンクは 2024 年 2 月に更新された最新版です。PDF の最下部に「改訂日：2024‑02‑15」と明記されていますので、必ず最新ファイルを使用してください。
4. カスタマイズ標準フロー（具体的手順）
- 要件定義シート作成
-
プロジェクト名、開始日・終了予定日、予算、関係者（PJリーダー・法務担当）を Excel/Google Sheet に記録。
-
テンプレート選択 & ダウンロード
- 基本契約は「経済産業省 標準様式」→PDF → Word 変換。
-
SOW は「MySign.jp」の個別ひな形をベースにする。
-
プレースホルダー置換
- 「株式会社○○」→「XYZ株式会社」
- 「所在地：東京都◯◯区」→実際の本社住所
-
期限・金額は要件定義シートから自動参照できるようにセルリンクさせても可。
-
条項カスタマイズ（上記表「カスタマイズ例」を参考）
-
各条項ごとに「変更理由」「担当者」欄を設け、レビューコメントを付与。
-
内部レビュー（3段階チェック）
- 一次レビュー（PJリーダー） – 業務範囲・スケジュールが現実的か確認。
- 二次レビュー（法務担当） – 用語統一、免責条項の妥当性、法令適合をチェック。
-
最終承認（経営層または取締役） – 契約金額・リスクが許容範囲か判断し、署名権限者が決定。
-
外部弁護士レビュー（必要時）
-
金額が 5,000 万円超、または新規技術（AI/ブロックチェーン等）を含む場合は必ず実務弁護士へ最終確認依頼。
-
署名・保存
- 電子契約ツール（DocuSign、Adobe Sign 等）で双方が署名。
- 署名済み PDF を「Contracts/2024/YYYY_MM_案件名」フォルダに格納し、Word の元ファイルは バージョン管理 用に別保存。
内部レビューの具体的チェックリスト（抜粋）
| 項目 | 確認ポイント | 担当 |
|---|---|---|
| 会社情報 | 社名・代表者・所在地が最新か | PJリーダー |
| 業務範囲 | SOW と基本契約の「業務範囲」条項が完全一致しているか | 法務担当 |
| 成果物受領手順 | 検収チェックシートと署名欄がセットになっているか | PJリーダー |
| 支払条件 | マイルストーン金額・支払期限が正確に反映されているか | 経理部門 |
| 知的財産権 | 権利帰属先・許諾範囲の文言が目的通りか | 法務担当 |
| 免責上限 | 金額が契約総額の 2 倍以内に収まっているか | 法務担当 |
| 解除手続き | 書面通知期間と是正猶予期間が明記されているか | PJリーダー |
5. 法的リスクと弁護士レビューのタイミング
| リスクシナリオ | 具体的問題点 | 推奨レビュー時期 |
|---|---|---|
| 業務範囲が曖昧 | 「追加作業は随時」だけでは費用算出不能。 | 基本契約草案段階で一次法務チェック、個別SOW 完成後に弁護士レビュー（金額 > 1,000 万円）。 |
| 免責条項が過大 | 「一切の損害賠償を負わない」→民法上無効リスク。 | SOW 最終ドラフトで外部弁護士に確認依頼。 |
| 知財権帰属未定義 | 著作権譲渡と利用許諾が混在し、後の権利争いの温床。 | 基本契約締結前に法務チームで一次検証、必要なら弁護士へ二次確認。 |
| 解除条件が不公平 | 委託者側だけが一方的に解除できる条項は、取引先からの訴訟リスク。 | 基本契約草案段階で法務レビュー、相手方と合意形成後に弁護士最終チェック。 |
| 法令遵守漏れ（下請法・個人情報保護） | 料金支払条件が下請代金支払遅延防止法に抵触。 | 契約締結前の総合レビューで必ず確認。 |
実務目安
- 基本契約は社内法務が一次チェック → リスクが高いと判断したら外部弁護士へ。
- 個別SOWは金額・期間が大きくなる案件（例：総額 5,000 万円超）では必ず弁護士の最終確認を取得。
6. 契約書の保管・バージョン管理ベストプラクティス
6‑1. フォルダ構造（推奨例）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
/Contracts ├─ /2024 │ ├─ /Master_Contract_XYZ株式会社 │ │ ├─ Master_v1.docx ← 法務一次レビュー版 │ │ ├─ Master_v2_LawyerReview.pdf ← 弁護士最終確認済み │ └─ /Project_A_NewSystem │ ├─ SOW_v1.docx │ ├─ SOW_v2_Final_Signed.pdf │ └─ Attachments/ │ ├─ RequirementSpec.pdf │ └─ AcceptanceCheckSheet.xlsx |
6‑2. アクセス権限
| ロール | 権限 |
|---|---|
| 法務部門長・担当者 | 閲覧＋編集（バージョン更新可） |
| プロジェクトマネージャー | 閲覧＋コメント追加 |
| 経営層（取締役等） | 閲覧のみ、署名権限は別途管理 |
| 社外ベンダー | 完全アクセス不可（必要なら閲覧用リンクを期限付きで発行） |
6‑3. バージョン管理手順
- Word の「変更履歴」 をオンにし、修正ごとにコメントを残す。
- 重要改訂（条項追加・金額変更）は PDF に変換して署名済み版 とし、
_Signed.pdfで保存。 - Git リポジトリ を社内利用可能なプライベートリポジトリに作成し、
contracts/2024/...配下で管理すると変更履歴が自動的に追跡できる（技術部門が慣れている場合）。
6‑4. バックアップ＆災害対策
- 二重保存：社内ファイルサーバー + Microsoft 365 / Google Workspace のクラウド。
- 年次アーカイブ：年度末に ISO イメージ（外付け HDD）へ丸ごとバックアップし、別拠点の保管庫に保管。
6‑5. 検索性向上
- ファイル名は
契約種別_案件名_YYYYMM（例：Master_XYZ株式会社_202404.pdf）形式で統一。 - メタデータタグを 「基本」「個別」「完了」 などで付与し、社内検索ツール（SharePoint, Google Drive）と連携。
まとめ 統一されたフォルダ・権限・バージョン管理を導入すれば、契約書の紛失や改ざんリスクが大幅に低減し、監査時にもスムーズに提示できます。
7. 企業実務での活用イメージ（XYZ株式会社ケーススタディ）
| フェーズ | 実施内容 |
|---|---|
| ① 受注前 | 経済産業省 標準様式の基本契約テンプレートをダウンロードし、社内標準条項に合わせてカスタマイズ。 |
| ② プロジェクト開始 | 個別SOW（MySign.jp）をベースに「AI データ分析モジュール」向けに業務範囲・納品物を具体化。 |
| ③ 内部レビュー | PJリーダーがスケジュールと金額シミュレーション、法務担当が免責条項と知財権のチェック、経営層が最終承認。 |
| ④ 弁護士確認 | 契約金額 8,000 万円（AI 開発）で外部弁護士に「免責上限」「知財譲渡」の妥当性をレビュー依頼。 |
| ⑤ 署名・保管 | DocuSign で電子署名、PDF を /Contracts/2024/Project_AI_Analytics に保存し、バージョン管理リポジトリにプッシュ。 |
| ⑥ 運用・変更 | プロジェクト途中で要件追加 → SOW の改訂版を作成し、同様のレビューフローを再実施。 |
この流れを社内マニュアル化すれば、新規案件ごとに「何を」「誰が」行うかが明確になり、契約リスクは最小限に抑えられます。
8. おわりに
- 重複排除：基本契約と個別SOW の役割分担をしっかり理解すれば、同じ条項を書き直す手間が省けます。
- 最新情報の活用：経済産業省 標準様式は 2024 年版を必ず参照し、リンクと改訂日を明記しておくこと。
- ブランド適合：XYZ株式会社のように自社名・業務内容で置き換えるだけで、どの企業でも即座に活用可能です。
- 具体的チェックリスト と 3段階内部レビュー により、抽象的な「内部レビュー」作業が実践的になります。
本ハンドブックをベースに、貴社独自の契約フローとテンプレートを整備し、受託開発プロジェクトの法務リスクを確実に低減させてください。
スポンサードリンク