開発案件で契約体系についてしっかり把握すべきと感じているので備忘録として記載。
用語定義
ユーザー
システム開発費用を捻出し、システム開発を依頼する開発依頼元(発注元)。
ベンダー
ユーザーからシステム開発の依頼を請けるシステム開発会社(受託開発会社)。ユーザーの立場からは委託先にあたる。
請負契約
ある期間からある期間の間、システム開発をベンダーに依頼。システム開発した結果、期日までに「納品」をし、納品物を「検収」し、不備がない事を確認。検収完了したことを示す「検収書」を提出。開発元は検収が行われた事を確認し「請求」を実施。
請負契約で進める場合の書類各種
| 順番 | 書類 | 提出側 | 備考 |
|---|---|---|---|
| 1 | 見積書 | ベンダー | 依頼内容に対する見積 |
| 2 | 注文書 | ユーザー | 依頼内容に対する注文 |
| 3 | 請書 | ベンダー | 注文に対して正式に請ける旨を示したもの |
| 4 | 納品書 | ベンダー | 注文内容に関して納品した旨を示したもの |
| 5 | 受領書 | ユーザー | 注文内容を受け取った旨を示したもの |
| 6 | 検収書 | ユーザー | 注文内容に対して検査を行なったことを示したもの |
| 7 | 請求書 | ベンダー | 注文に対しての請求 |
注意すべきポイント
- いつ注文したのか。
- いくらで注文したのか
- 会社として正式な手続きを行った上で書面を提出したか
- 日付が前後していないか
準委任契約
ある期間からある期間の間、作業を行なったことに対して報酬を支払う形になる。これは成果物が完成に至ってなくても支払う必要がある。請負と大きくことなるのが評価に軸が「成果物なのか」「業務を行ったことなのか」になる。
| 順番 | 書類 | 提出側 |
|---|---|---|
| 1 | 見積書 | ベンダー |
| 2 | 注文書 | ユーザー |
| 3 | 請書 | ベンダー |
| 4 | 作業報告書 | ベンダー |
| 5 | 作業確認書 | ユーザー |
| 6 | 請求書 | ベンダー |
落とし穴支払サイト(日数足りない問題)
注文書、または請求書に「支払期日は作業完了翌月末締め翌月支払」なんて事を記載している場合が多い。 作業が完了してすぐに検収や作業内容の確認ができるわけないし、そもそも書類を提出するにしても、社内承認が必要となってくる場合が多い。 そのため可能であれば「検収書提出の翌月末日支払(これは提出元が怠れば期日が延びる内容になるため難しいが)」または「作業完了月の翌々月末日支払」とした方が安全。
下請け法(支払期日)
納品から60日の決まりがある。ただしこれは「しっかりと依頼した内容が納品されていることが前提」にある。注文して全く異なるものが出てきたら作り直すのと一緒。
そのため「いつ納品したのか」「いつ検収が完了したのか」がポイントになる。
ただ、こんなことで揉めるようなベンダーは信用できないから、付き合いはやめたほうがいい。単純に注文内容を納品してくれれば良いが注文者側もしっかりと提案依頼書を書いてないとトラブルになる。
- 提案依頼書にスケジュールの記載はあるか
- 提案依頼書に対応範囲についての記載はあるか
- 提案依頼書に概算予算に関する記載はあるか
- 提案依頼書に依頼背景の記載はあるか
- 提案依頼書に目的の記載はあるか
注文書に余計な事を書くな
業務を委託する場合、必ず基本契約を締結させる必要がある。これは法務担当が出てきて内容を確認し最終的にお互いが内容に合意した上で締結…と言う流れになる。注文書は基本契約があることを前提に期間や金額や対応内容を記載する。多くは基本契約に書いてあることから変更がある場合は別途個別進める流れになるため、個別契約、注文書が上書きされるような形で優先される。そう考えた場合、基本契約を一生懸命考慮して締結しても個別契約、注文書に余計なことが書いてあると有効になる。
代表者印 / 会社角印
代表者印
