システム開発の契約書は、専門用語が多く、つい読み飛ばしてしまいがちである。しかし、トラブルが起きたときに立ち返るのはこの契約書であり、ここに何が書かれているかが、責任の所在や費用負担を左右する。読み込むのが難しくても、「どこを確認すべきか」という観点を持っていれば、要点は押さえられる。
本記事は、システム開発の契約書で確認しておきたい項目を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門である。法律の専門家でなくても、スコープ・納期・検収・責任・権利・保守という観点で見れば、確認すべき箇所が見えてくる。なお、契約書の条項の解釈や、自社にとっての有利不利の判断には個別の事情が関わるため、最終的な判断は弁護士など専門家への確認を前提としていただきたい。
結論：六つの観点で契約書を読み解く
契約書を一から読み解くのは難しいが、確認の観点を絞れば要点は押さえられる。GXOが発注者にすすめるのは、次の3点である。
- スコープ・納期・検収・責任・権利・保守という六つの観点で確認する
- 専門用語が分からないところは、開発会社に意味を説明してもらう
- 自社にとって重要な条項は、弁護士など専門家にも確認する
契約書は、署名する前に確認するものである。開発が始まってから「そんな取り決めだったのか」と気づくのでは遅い。確認の観点を持って、不明な点は遠慮なく質問したい。
なぜ契約書の確認が重要か
契約書は、開発が順調なときには意識されないが、認識のずれやトラブルが起きたときに、責任と費用負担を判断する基準になる。ここが曖昧だと、双方が自分に都合よく解釈し、対立が深まりやすい。
契約書の確認が不十分だと、次のような問題につながりやすい。
- スコープが明確でなく、追加作業の費用負担をめぐって揉める
- 検収の基準がなく、いつ完了とみなすかで対立する
- 責任分担が曖昧で、不具合が起きたときの対応が決まらない
契約書は、開発全体のルールブックである。要件定義の準備や契約形態の理解とあわせて確認したい。契約形態の違いは請負契約と準委任契約の違いで扱っている。
六つの確認観点
契約書を読むときは、次の六つの観点を意識すると、確認すべき箇所が整理しやすい。
| 観点 | 確認したいこと |
|---|---|
| スコープ | 何を作り、何を作らないかの範囲が明確か |
| 納期 | 完成・納品の期日と、遅れたときの取り扱い |
| 検収 | 何をもって完了とするか、確認の手順 |
| 責任 | 不具合や障害が起きたときの責任分担 |
| 権利 | 成果物の権利が誰に帰属するか |
| 保守 | リリース後の対応範囲と費用 |
それぞれの観点について、契約書に該当する記載があるかを確認したい。記載がない、あるいは曖昧な場合は、その点が後のトラブルの種になりやすい。
スコープ・納期・検収を確認する
スコープ（範囲）
最もトラブルになりやすいのがスコープである。何を作るかだけでなく、「何を作らないか」も書かれているかを確認したい。範囲が曖昧だと、追加作業の費用負担をめぐって認識がずれる。仕様変更の扱いは仕様変更・追加要件の扱いも参考になる。
納期
納期が記載されているか、そして遅れた場合の取り扱いが定められているかを確認したい。遅延や中止に関わる取り決めは納期遅延・中止時の取り扱いで扱っている。
検収
検収は、何をもって完了とするか、どんな手順で確認するかを定める項目である。基準が曖昧だと、完了の判断で対立しやすい。検収と不具合対応については検収・契約不適合責任で詳しく扱っている。
責任・権利・保守を確認する
責任分担
不具合や障害が起きたとき、誰がどこまで責任を負うのかを確認したい。発注者側の協力義務や、責任の上限についても記載されることがある。
権利の帰属
成果物の著作権などの権利が、誰に帰属するのかは重要な確認点である。権利の整理は知的財産権・成果物の権利で詳しく扱っている。
保守の範囲
リリース後の保守について、対応範囲や費用が定められているかを確認したい。開発と保守が別契約になることも多い。詳しくは保守・運用の契約を参照されたい。
契約書の確認でよくある失敗
契約書の確認では、次のような失敗が起きやすい。いずれも、署名前に確認しておけば避けられる。
- スコープを読み飛ばす：範囲が曖昧なまま署名し、追加作業で揉める。
- 専門用語を確認しない：意味が分からない条項をそのままにし、後で不利な内容だと気づく。
- 検収基準を決めない：完了の判断基準がなく、いつまでも検収が終わらない。
- 専門家に相談しない：重要な契約を社内だけで判断し、見落としに気づけない。
契約書は、分からないところを質問してよいものである。不明な点を残したまま署名しないことが、トラブル回避の基本になる。
契約書の確認チェックリスト
契約書に目を通すときは、次の項目が記載されているか、そして自社にとって不利でないかを確認したい。記載がない項目は、後で揉めやすい箇所である。
- 何を作り、何を作らないかの範囲（スコープ）が明確か
- 納期と、遅れたときの取り扱いが定められているか
- 検収の基準と手順、確認の期間が記載されているか
- 不具合や障害が起きたときの責任分担が明確か
- 成果物の権利が誰に帰属するかが定められているか
- リリース後の保守の範囲と費用が記載されているか
- 仕様変更が出たときの扱いが定められているか
- 分からない専門用語を、説明してもらって理解したか
すべての項目が完璧に書かれている契約書ばかりではない。記載がない、あるいは曖昧な項目があれば、その点を開発会社に確認し、必要に応じて追記や修正を相談したい。
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| この契約で「完成」とは何を指しますか | 完了の基準 |
| スコープに含まれない作業は何ですか | 範囲の境界 |
| 納期が遅れた場合はどうなりますか | 遅延時の取り扱い |
| 検収はどんな手順で行いますか | 検収の進め方 |
| 納品後の不具合は、いつまで対応してもらえますか | 不具合対応の範囲と期間 |
| 成果物の権利は誰に帰属しますか | 権利の所在 |
これらの質問への答えがはっきりしない場合、その箇所が後のトラブルの種になりやすい。曖昧な回答を放置せず、契約書に明記してもらうことを相談したい。開発会社の選び方の観点はAI開発のベンダー選定基準も参考になる。
関連記事
よくある質問
Q1. 契約書の専門用語が分からないときはどうすればよいですか
分からない用語は、開発会社に意味を説明してもらってよい。説明を求めることは失礼ではなく、認識をそろえるために必要な手順である。説明を聞いても自社にとっての有利不利が判断できない場合は、弁護士など専門家に確認するとよい。
Q2. 開発会社が用意した契約書を、そのまま受け入れてよいですか
開発会社の契約書は、開発会社側の立場で作られていることがある。そのまま受け入れるのではなく、スコープや責任分担など、自社にとって重要な点を確認したい。修正を提案することも、契約交渉の一部である。
Q3. 小規模な開発でも契約書は必要ですか
規模にかかわらず、何を作り、いくらで、いつまでに、という基本は文書に残しておきたい。口頭の合意だけでは、認識がずれたときに立ち返る基準がない。簡潔な契約書でも、要点が押さえられていれば役に立つ。
システム開発の契約書を、署名前に一緒に確認しませんか
GXOでは、システム開発の契約に入る前に、スコープ、納期、検収、責任分担などの確認観点を整理し、後のトラブルを避けるための準備をご支援します。専門的な法務判断は専門家と連携しながら進めます。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。