このユニットの結論
契約は、ベンダーを選んだあとの「形式的な手続き」ではありません。
何を頼み、何をもって終わりとし、途中で変わったらどうし、お金をどう払うかを、発注する側と受ける側が同じ言葉で約束する場です。ただし、契約はプロジェクトの枠組みであり、日々の判断や取り決めのすべてを契約で決めきれるわけではありません。
1. 何の話か
このユニットは、システム開発の契約で決めることの話です。
ベンダーの評価（02-04・BUS-006）を終えて頼む会社が決まったら、契約を結びます。法律の細かい条文は法務の担当や専門家が確かめますが、何を約束するかの中身は、プロジェクトの側が決めなければなりません。
2. なぜ必要か
契約の中身があいまいだと、一般的に次のことが起きます。
- 「そこまでは頼まれていない」「頼んだはずだ」と、範囲の食い違いが起きる
- できあがったものを受け入れてよいかの基準がなく、支払いの判断ができない
- 途中で要件が変わったときの費用と期間の決め方がなく、話し合いが長引く
- 稼働後に見つかった不具合を、誰の負担で直すのかが決まらない
3. このユニットで分かること
- システム開発でよく使われる契約の形
- 契約で決めておく主な項目
- 契約の準備で、AIに任せてよいことと人間が決めること
4. 契約の主な形
システム開発では、一般的に次の2つの形がよく使われます（細かい意味は契約書の書き方によっても変わるため、実際には法務の担当と確かめます）。
| 形 | 何を約束するか | 向いている作業（一般的に） |
|---|---|---|
| 請負（うけおい） | 決められたものを完成させることを約束する。完成したものに対して支払う | 作るものがはっきり決まっている作業（設計が固まったあとの開発など） |
| 準委任（じゅんいにん） | 決められた作業を、専門家としてきちんと行うことを約束する。完成までは約束しない | 何を作るかを一緒に決めていく作業（要件をまとめる作業、稼働後の支援など） |
大規模な刷新では、工程ごとに契約を分けることがよくあります。たとえば、要件をまとめる工程は準委任、その結果をもとにした開発は請負、というように、その時点で何が決まっているかに合わせて形を選びます。
5. 契約で決めておく主な項目
| 項目 | 決めること |
|---|---|
| 範囲と成果物 | 何を頼むか。何を納めてもらうか（文書・プログラム・環境など）。頼まないものは何か |
| 期間と節目 | いつからいつまでか。途中の節目 |
| 受け入れの確認（検収） | 納められたものを、誰が、どの基準で確かめ、受け入れるか |
| 変更の扱い | 範囲や要件が変わったとき、費用と期間をどの手続きで見直すか |
| 支払い | いくらを、いつ、何と引き換えに払うか |
| 不具合への対応 | 受け入れのあとに見つかった不具合を、いつまで、誰の負担で直すか |
| 情報の扱い | 秘密の守り方。個人の情報の扱い。AIなどの道具にどの情報を渡してよいか |
| 権利 | 作ったプログラムや文書を、誰が、どこまで使えるか |
| 再委託 | 受けた会社が、さらに別の会社に作業を頼んでよいか |
| 終わり方 | 契約が終わるときの引継ぎ。途中でやめる場合の扱い |
どれも、選定のときに見つかった懸念（BUS-006 の「懸念とその扱い」）を、約束の形にする場所でもあります。
また、契約で決めきれない日々の作業の進め方は、契約とは別に、プロジェクトの中の取り決めとして管理します（05-06）。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- マルチベンダー。Vendor A〜D の4社（Vendor A / ネクサスシステムズ、Vendor B / クラウドブリッジ、Vendor C / ファイナンスシステムサービス、Vendor D / タイムリンク）
- 成果物に BUS-005 提案依頼書（RFP）、BUS-006 ベンダー評価表がある
- M0 正式キックオフ、M18 本番稼働
アステリア案件で各社とどの形の契約を結んだか、契約の期間・金額・受け入れの基準・変更の扱い・支払いの条件は、正本に記載がありません。未確定 上の表は一般的な項目の例で、アステリア案件の契約の内容ではありません。
6. THINK — 要件が決まる前の「完成の約束」
（教材上の例）ある会社で、これから要件をまとめる段階なのに、次の提案がありました。
「要件のとりまとめから稼働まで、全部を一つの金額で、完成を約束する契約にしましょう。金額が決まっていれば安心です。」
問題
この契約の形は、発注する側にとって本当に安心でしょうか。
判断例を開く
判断
一見、安心に見えますが、確かめることが多くあります。
確認すること:
- 何を作るかが決まっていない段階で、完成の中身をどう定めるのか
- 受ける側は、決まっていない部分の危険を、金額にどう上乗せしているか
- 要件がまとまったあとに範囲が変わったら、費用と期間をどう見直すのか
- 工程ごとに契約を分けて、要件がまとまってから開発の金額を決める方法と比べたか
その時点で何が決まっているかに合わせて、契約の形を選びます。
7. よくある失敗
- ひな形のまま、範囲と成果物を具体的に書かない
- 受け入れの確認の基準を決めず、支払いの判断ができない
- 変更の手続きを決めず、要件が変わるたびに費用の話し合いが止まる
- 選定のときの懸念を、契約に反映しない
- 契約さえ結べば、あとの管理は相手の会社に任せられると考える
8. 成果物との接続
- BUS-006 ベンダー評価表：選定のときの懸念を、契約の項目に引き継ぐ
- BUS-005 提案依頼書（RFP）：提案を求めた範囲と条件が、契約の範囲の出発点になる
- TST-006 利用者受入テスト・終了判定報告書：受け入れを判断する材料の1つになる
9. AI WORKFLOW — 契約の案と提案書の食い違いを探させる
AIは、長い契約の案と提案書を読み比べる下書きに役立ちます。
指示例:
「次の契約の案と提案書を比べ、範囲・成果物・期間・受け入れの確認・変更の扱い・支払いについて、①両方に書かれていて内容が合うもの、②内容が違うもの、③片方にしか書かれていないもの、を表にしてください。どちらの内容が正しいか、契約してよいかは判断しないでください。」
10. REVIEW — AIの比較を確認する
- 表の内容が、契約の案と提案書の元の文と合っているか
- AIが、法律上の意味を推測で断定していないか（法務の担当が確かめる）
- 契約の案を AI に渡してよいか（秘密の扱い）を、事前に確かめたか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 契約で決めきれないものの扱い
契約はすべてを書ききれない
数年にわたる開発で、起きうることをすべて契約に書くことはできません。世界で共有されている考え方では、これを「不完全契約」と呼びます。不完全であること自体は欠陥ではなく前提です。問題は、書ききれない部分をどう扱うかが決まっていないことです。契約には、中身の約束だけでなく、「決まっていないことが出てきたときの決め方」を書きます。
決め方を契約に書く
決め方として書くのは、たとえば次のものです（教材上の例）。
- 変更の手続き：誰が申請し、誰が影響を見積もり、誰が決め、何日以内に答えるか
- 判断の場：双方の責任者が定期的に集まる場と、そこで決めてよいことの範囲
- 上げる仕組み：現場で決まらないとき、どの順で誰に上げるか。上げてから答えるまでの期限
- 記録：決めたことをどこに残し、どちらが保管するか
これらがあれば、契約に書かれていない事態が起きても、止まらずに決められます。
関係を長く保つ契約
契約の条文で相手を縛るだけでなく、双方が同じ結果に向かう仕組みを入れる考え方があります。目標を共有し、達成したときの扱いと達成しなかったときの扱いを前もって決める形で、関係的契約と呼ばれることがあります。短い契約を工程ごとに重ねる場合、前の工程の評価を次の工程に引き継ぐ決まりも、この一種です。
測り方の例
- 契約に書かれていない事態で、話し合いに回った件数と、決まるまでの日数
- 変更の手続きの、申請から回答までの実際の日数
- 判断の場で決めたことのうち、記録に残っている割合
現場で確かめる問い
- 契約に、「決まっていないことが出てきたときの決め方」が書かれているか
- 変更の申請から回答までの期限は決まっているか。実際には何日かかっているか
- 現場で決まらないとき、誰に、どの順で上げるかが契約に書かれているか
- 決めたことの記録を、どちらが保管しているか。相手も同じものを見られるか
アステリア案件の契約に、決め方や上げる仕組みがどう書かれていたかは、正本に記録がありません。記録なし
11. 人間が判断すること
- 工程ごとに、どの契約の形を選ぶか
- 範囲・受け入れの基準・変更の扱いを、どう約束するか
- 契約を結ぶかどうか（法務の担当と、決める権限のある人が判断する）
12. 判断演習
あなたは、開発の工程の契約の案を点検する担当です。
契約の案の「受け入れの確認」の欄には、「発注者が確認する」とだけ書かれています。この欄を具体的にするために、決めておくべきことを3つ挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
契約では、範囲・終わりの判断・変更の扱い・支払いを、同じ言葉で約束します。
契約の形は、その時点で何が決まっているかに合わせて選びます。契約はプロジェクトの枠組みであり、日々の取り決めと管理は、契約とは別に続けていく必要があります。