このユニットの結論
同じ「外部に頼む」でも、契約の形が違えば、誰が何に責任を持つかが変わります。
完成に責任を持つ契約、作業に責任を持つ契約、サービスを利用する契約では、指示できること・確かめるべきこと・失敗したときの扱いが違います。形を知らずに頼むと、「できていない」と言ったときに、どちらの責任かでもめます。
1. 何の話か
このユニットは、外部に仕事を頼むときの契約の形と、それによって責任がどう変わるかの話です。
02-05 契約で何を決めるのか では、契約に何を書くかを学びました。ここでは、その前提となる「契約の形」を扱います。一般的な形は 3 つです。決めたものを完成させることに責任を持つ形（請負型）、決めた体制で作業を行うことに責任を持つ形（準委任型）、提供されているサービスを利用する形（サービス利用型）です。
2. なぜ必要か
契約の形を意識せずに進めると、
- 作業に責任を持つ契約なのに、完成しなかったことをベンダーの責任だと主張してしまう
- 完成に責任を持つ契約なのに、発注側が細かく作業の指示を出し、責任の所在があいまいになる
- 外部サービスの仕様が変わったとき、「変えないでほしい」と言える立場にないことに気づく
ということが起きます。マルチベンダーの案件では、会社ごとに契約の形が違うことも普通です。
3. このユニットで分かること
- 3 つの契約の形と、責任の違い
- 形ごとに、発注側が確かめるべきこと
- 境目の仕事（どの会社の責任か分かりにくい仕事）の扱い
4. 3 つの形と責任の違い
| 観点 | 完成に責任（請負型） | 作業に責任（準委任型） | サービス利用型 |
|---|---|---|---|
| 相手が約束すること | 決めたものを決めた期日に完成させる | 決めた体制・技能で、作業を適切に行う | 決めた水準でサービスを提供し続ける |
| 発注側ができること | 完成したものを確かめ、受け入れる・受け入れないを決める | 作業の内容を相談し、優先順位を伝える | 提供条件の範囲で使う。仕様の変更は求めにくい |
| 発注側がしてはいけないこと | 相手の作業者に直接細かく指示する（責任が移る） | 完成しなかったことだけを理由に責任を問う | サービスの中身を自分の都合で変えさせる |
| 要件が途中で変わったら | 変更の合意と、費用・期日の見直しが要る | 作業の範囲で吸収しやすいが、完成は約束されない | 提供元の仕様に合わせて業務を変えることが多い |
| 失敗したとき | 完成していなければ相手の責任を問える | 作業が適切だったかが論点になる | 提供条件（水準）を下回ったかが論点になる |
どの形が良い・悪いではありません。決まっているものを作らせるなら完成に責任を持つ形、決めながら進めるなら作業に責任を持つ形、作らずに済むならサービス利用という向き不向きがあります。
5. 境目の仕事をどう扱うか
複数の会社が関わると、どの会社の責任か分かりにくい仕事が必ず生まれます。システム同士の連携のテスト、全体の性能の確認、障害の原因の切り分けなどです。
一般的には、次を契約と役割分担表に書いておきます。
- 境目の仕事を一覧にし、主担当と協力する会社を決める
- 原因が分からない問題は、原因が分かるまで誰が調べるかを先に決める（原因が分かってから責任を決める）
- 発注側（アステリア側）が最後に責任を持つ範囲を明記する。責任は外部に出し切れない
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の契約の相手に関する記載
- マルチベンダー。Vendor A ネクサスシステムズ — 新基幹アプリケーション、Vendor B クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視、Vendor C ファイナンスシステムサービス — FIN-CORE、会計連携、Vendor D タイムリンク — 勤怠・工数管理SaaS
- SYS-03 勤怠・工数管理SaaS は外部のサービス
- P-007 松本 健太 — 営業・契約業務リーダー、P-003 西村 俊介 — プログラムマネージャー
各ベンダーとの契約がどの形（完成・作業・サービス利用）だったか、契約に何が書かれていたかは、正本に記録がありません。記録なし 担当範囲の記載は「何を担当するか」であり、契約の形を示すものではありません。
6. THINK — 「作業で頼んでいるが、完成しなければ責任を問う」
要件を決めながら進めたいという理由で、ある領域を作業に責任を持つ形で頼みました。数か月後、PMO の会議で次の発言がありました。
「要件が固まらなかったのは事実だが、期日までに完成しなかったのだから、ベンダーの責任で作り直してもらう。」
問題
この主張は通るでしょうか。何を確かめるべきでしょうか。
判断例を開く
判断
作業に責任を持つ形では、相手が約束しているのは「適切に作業すること」であって、完成ではありません。
確認すること:
- 契約の形は何か。完成の約束が契約に書かれているか
- 要件が固まらなかった原因は、発注側の決めの遅れか、相手の作業の問題か
- 相手の作業が適切だったか（体制、技能、報告）を示す記録があるか
- 完成を求めたいなら、要件を固めたうえで、完成に責任を持つ形に切り替える合意ができるか
「決めながら進める」を選んだ時点で、完成の責任は発注側に大きく残ります。形の選択と、責任の主張は一致していなければなりません。
7. よくある失敗
- 契約の形を意識せず、すべての会社に同じ責任を期待する
- 完成に責任を持つ契約なのに、発注側が作業者に直接指示を出し、責任があいまいになる
- 外部サービスの仕様変更を「契約違反」と捉え、業務を変える準備をしていない
- 境目の仕事の主担当を決めず、問題が起きてから責任の押し付け合いになる
8. 成果物との接続
- BUS-005 提案依頼書（RFP）：どの形で頼むかは、提案を求める段階で示す。形が決まっていないと、比べられる提案が集まらない
- PRG-004 役割・責任分担表：契約の形で決まった責任を、仕事ごとの役割に落とす。境目の仕事の主担当もここに書く
9. AI WORKFLOW — 契約の形と役割分担の食い違いを探させる
AIは、契約の条項と役割分担表を読み比べ、契約の形と合わない役割（作業に責任を持つ相手に完成を求めている など）を探す下書きに役立ちます。
指示例:
「次の契約の抜粋と役割分担表を読み比べ、仕事ごとに『契約上の責任の形（完成・作業・サービス利用）』と『役割分担表で求めている責任』を並べ、合っていない可能性のある箇所を示してください。法的な判断はせず、食い違いの箇所だけを示してください。」
10. REVIEW — AIの指摘を確認する
- AIが読み取った「契約の形」が、契約の条項から正しく読めるか（法務に確かめる）
- 食い違いとされた箇所が、実際の合意と違っていないか
- 契約書を AI に渡してよいか（守秘の扱い）を事前に確かめたか
11. 人間が判断すること
- 領域ごとに、どの形で頼むか
- 境目の仕事の主担当と、原因が分かるまで調べる会社
- 発注側が最後に持つ責任の範囲
12. 判断演習
「約36本のシステム連携のテスト」を、どの会社がどの形で担当すべきか考えてください。
連携の両端が別の会社であるとき、テストの主担当、失敗したときに原因を調べる会社、発注側が持つ責任を書いてください。契約の形（完成・作業・サービス利用）がそれぞれの判断にどう影響するかも書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
契約の形で責任が変わる。完成に責任・作業に責任・サービス利用の違いを知り、境目の仕事の主担当を先に決める。責任は外部に出し切れない。