システム開発の契約書は、金額と納期だけでなく、工程、成果物、変更手続き、確認方法を対応させて読むことが大切です。何を依頼し、どの状態を確認して次へ進むかを、仕様書や見積書と合わせて整理しましょう。
モデル契約は確認項目を整理する資料
IPAは、受託開発や保守運用などを対象とする「情報システム・モデル取引・契約書(第二版)」を公開しています。仕様、プロジェクト管理、検収方法について、発注者と受注者の共通理解を深めるための資料です。IPA 第二版の公開ページ
モデルをそのまま貼り付ければ個別案件に合うとは限りません。公開ページにも、参照法規は公表当時の内容に基づき、利用時には改正等を確認するよう注意があります。本記事は契約を読むための整理で、個別案件の法的判断や条項の完成例を示すものではありません。
工程と契約対象を対応させる
まず、今回の契約がどこまでを対象とするか確認します。要件整理から運用まで一括なのか、工程ごとに別の合意なのかで、成果物や確認の節目が変わります。
| 観点 | 契約・関連資料で確認すること |
|---|---|
| 対象工程 | 要件整理、設計、実装、テスト、移行、運用の範囲 |
| 成果物 | プログラム、設計資料、手順書などの対象と形式 |
| 発注側の対応 | 資料提供、仕様判断、環境準備、確認の担当と期限 |
| 確認方法 | 誰が、何を、どの期間に確認するか |
| 対象外 | 別途費用や追加合意が必要な作業 |
たとえば「一式」という記載だけでは、データ移行や利用者教育が含まれるか判断しにくくなります。曖昧な箇所は、具体的な作業と成果物へ置き換えて確認します。
開発手法と契約類型を同じものと考えない
IPAのアジャイル開発版は、機能や優先順位の変更に対応する開発を想定し、専門家としての業務遂行に対価を支払う準委任契約を前提としています。IPA アジャイル開発版
これは当該モデルの前提であり、「アジャイルなら必ずこの契約」「準委任なら成果物を確認しなくてよい」という結論にはなりません。何を委託するのか、どう報告し、何を確認し、何に対して支払うかを個別の条件として読む必要があります。
開発手法の名前だけで責任範囲を判断せず、契約文と実際の進め方が対応しているかを、契約担当や専門家と確認してください。
変更時の扱いを先に読む
要件の追加や変更が起きたとき、誰が依頼し、影響をどう見積もり、誰が合意するかを確認します。費用と期限だけでなく、確認済みの設計やテストに戻る必要があるかも論点です。
仮の例として、帳票へ項目を追加する場合を考えます。帳票の表示変更だけで済むのか、入力画面や保存データ、外部連携も変えるのかによって対象が変わります。変更前の合意と変更後の内容を残し、最新版を双方で識別できるようにします。
納品後と契約終了時まで確認する
受入の基準と期間、不具合が見つかった場合の連絡・対応、保守の範囲を読みます。また、秘密情報や個人情報の扱い、成果物の権利、第三者ソフトウェアの利用条件、再委託、終了時の返却・削除や引継ぎも確認候補です。
これらの条項は、短い一文だけで有利不利を判断しにくい場合があります。損害賠償や解除などの法的効果を含む条件は、案件の内容と現行法に照らした専門家の確認が必要です。
読み合わせでは未決事項を残す
契約書、仕様書、見積書で対象や版が一致するかを確かめます。読み合わせの結果は「合意済み」「修正する」「確認待ち」に分け、確認待ちには担当と期限を付けましょう。重要な条件を曖昧にしたまま着手しないための記録になります。
システム開発の対象範囲や進め方の整理は、お問い合わせからご相談いただけます。契約条件の法的判断は、必要に応じて専門家へ確認してください。