はじめに
プロジェクトマネジメントにおいて、契約書のレビューは法務や調達部門だけの仕事ではありません。契約書はプロジェクトのスコープ、スケジュール、コスト、リスクの前提条件となり、実務では契約内容の読み違いがそのままプロジェクトの失敗につながります。本記事では、プロジェクトマネジメントの観点から、プロジェクト・マネジャー（PM）が必ず確認すべき契約書レビューのポイントについて、私の経験上のノウハウを整理します。
文末では、実務的なチェックリストがダウンロードできます。
本投稿の前提としてはIT分野のプロジェクトマネジメント視点から記載しております。従いまして、業界が異なるプロジェクトや各社のポリシー、行政のポリシーなどにより内容が異なる場合がありますので、あらかじめご了承ください。
皆様の業務の参考になれば幸いです。また、皆様の業界での状況をコメントでお聞かせいただけると学びになります。
なぜプロジェクトマネージャは契約書をレビューすべきなのか
契約書はプロジェクトの公式ベースラインとみなされます。
提案書や見積もり、WBSより契約書の効力が上位にあり、契約と計画が矛盾すると後から修正できない状況に陥ります。
PMが契約をレビューすべき理由は次のとおりです。
- 契約はスコープ・納期・コストの基準になる
- 契約に書かれていない事項は、原則として提供義務がない
- 提案書と契約書の齟齬が炎上の原因になる
- リスク分析の内容が契約に反映されているか確認する必要がある
- PM責任の範囲が過剰に広がっていないか把握する必要がある
法務は合法性・会社経営のガバナンスを見る役割ですが、PMは実行可能性とリスクを見る立場です。
プロジェクトマネージャが押さえておくべき契約書の種類
本記事では契約書自体の法的説明には踏み込みませんが、PMが関与する代表的な契約は以下のとおりです。
顧客との契約
- 基本契約
- 請負・委任契約
- 保守契約
- サービスアグリーメント（SLA含む）
外注・サードパーティ契約
- 下請契約
- 再委託契約
ライセンス・知財関連契約
- ソフトウェアライセンス
- 知財利用・共同開発契約
社内調達・工場・部門間の取り決め
- 部品供給ルール
- 変更管理ルール
- 品質保証条件
（※これが後述の重要ポイント）
契約の詳細よりも、どの契約がプロジェクトに影響するのかを把握、理解することがPMの仕事です。疑問点、不明点がある場合は法務部門へ相談します。
プロジェクトマネージャが契約書で必ず確認すべき重要ポイント（外部契約編）
ベースライン（Scope・Cost・Schedule）と契約内容の整合性
契約書はプロジェクトの最上位文書のため、以下との整合が必須です。
- 見積もり
- WBS
- 提案書・SOW
- スケジュール
曖昧な表現や包括表現には注意します。
例：
- 必要に応じて追加作業を実施する
- 関連する作業も範囲に含む
これはスコープが無限に広がる典型です。
前提条件（Assumptions）と制約条件（Constraints）の明記
見積もり時に置いた前提条件が契約に反映されていない場合、後にPMの責任になります。
例：
- 顧客が環境を準備する前提
- 顧客レビューは◯日以内
- データ準備は顧客側
- 仕様確定前に契約だけ先行させる
アジャイルやAIプロジェクトでは特に重要です。
契約書の内容をよく理解していない顧客の担当者もいらっしゃいますので、期限のある顧客のアクションについてもPMは管理が必要です。
リスク分析（Risk Register）の反映状況
プロジェクト開始前に洗い出したリスクを契約に反映することは、PMの核心的な役割です。
- 技術的不確実性
- データ品質リスク
- 外部依存
- 損害賠償上限（Liability Cap）
- NDA (Non-Discloser Agreement) 機密保持契約
損害賠償上限が契約に書かれていない場合、リスクは青天井になります。
また、配送遅延、納期遅延、瑕疵担保に関する記述からリスクを読み取り、見積もったリスクと一致しているか確認が必要です。ハードウェアが成果物に含まれている場合、大規模なプロジェクトであれば着荷不良は必ず発生しますので、発生する確率をもとに、リカバリコスト（予備品を買っておくのか？工場から借りるのか？）や発生時の対応フローをあらかじめ作成しておく必要があります。
機密保持契約はパートナー契約など上位の契約内で結ばれることがい多いですが、プロジェクト個別に結ぶケースもあります。内容は顧客から提示される場合もありますし、自社のテンプレートを使用する場合両方のケースがあります。
どちらのケースにおいても、必ず法務部門の確認が必要となります。PMとしては、プロジェクト内で働く派遣社員、業務委託社員にも及ぶのか、及ぶのであれば、個別にNDAのサインが必要であるのか？など法務部門と調整が必要です。
成果物と受入基準（Definition of Done）の明確化
成果物が曖昧だと、認識違いが必ず発生します。
確認項目は次のとおりです。
- 成果物一覧の明確さ
- UAT条件（受け入れテスト環境の準備、実施責任範囲など、顧客によっては自分でやらない場合もある）
- ドキュメント範囲
- 納品物の形式（PDF、ソースコード、設計書など）
成果物のドキュメントなどは、要求レベルの粒度、深度によって作業量が爆増しますので、事前に十分な認識合わせが必要です。これを見逃すと、納期も作業量も大幅に見積もりを超えます。
最近は少なくなりましたが、成果物を印刷、冊子で提供、データはDVDで提供することもあります。
作成作業に時間が見込まれる成果物も、見積もりのコストに含まれているのか確認が必要です。
役割分担（R&R）と再委託ルールの確認
PMは自社・顧客双方の役割を明確に把握する必要があります。
- 顧客責任（資料提供、環境準備など）が明記されているか
- 自社の作業範囲が絞られているか
- 再委託の可否
- 再委託時の品質責任の所在
RACIチャートとの整合が鍵です。問題が発生してから顧客に対して、これは「お客様がやることです。」と説明しても炎上を招く恐れがありますので、問題が発生していない平和なときに顧客に説明をして、理解いただくことことが大切です。
そして必ず議事録に落とし込んで、顧客と共有しておくのを忘れないでください。
MUST / SHOULD / BEST EFFORT の責任文言の違い
契約書における単語は、責任の重さそのものです。
- MUST：義務。不履行は契約違反
- SHOULD：努力義務。必ずしも違反ではない
- REASONABLE BEST EFFORT：合理的な努力。結果よりプロセスが評価される
海外企業との契約ではBEST EFFORTは頻発します。
国際契約・大企業契約でPMが特に注意すべき条項
紛争解決・準拠法・裁判所の指定（指定裁判所問題）
海外企業との契約では、指定裁判所が海外になっているケースがあります。
しかし、これは実務的に次の理由でほぼ裁判不能です。
- 費用が膨大
- 移動・証言が困難
- 現地法律の壁
- 言語の壁
可能な限り、日本の地方裁判所を指定することが望ましいです。
反社会勢力排除条項（暴排条項）
コンプライアンス上重要ですが、大企業側はこの条文を嫌がることがあります。
理由：
- 従業員数万人の中に、遠い親族・知人で関わる者がいる可能性がある
- 組織全体の統制が難しいため、契約上のリスクになる
表現の仕方は慎重さが必要です。この条文は法務の専門家が主に対応すべき内容となりますが、最後まで平行線になりやすい条文ですので、契約締結まのでスケジュールリスクのある項目であると認識しておいたほうが良いかも知れません。
汚職防止条項（Anti-Bribery / Anti-Corruption）
海外契約では必須です。
注意点：
- 接待・贈答の制限
- サードパーティを経由した贈収賄
- FCPA（米国海外腐敗行為防止法）リスク
- 通報義務や監査義務の扱い
外注管理計画とも密接に関連する項目です。
これも原則法務部門がアカウンタビリティをもつ項目となりますが、PMとして業務上守らなければならない条項ですので、プロジェクトメンバーを含めて理解をしておかなければなりません。
特に顧客との会食、ランチミーティングの費用負担など会社によって処理が厳格なところもあります。また、会社としても予算の上限もあり管理されていますので、管理プロセスについてもPMとして知らなければなりません。
社内調達・工場・部門間の契約／取り決めも確認すべき理由（内部契約編）
外部契約のチェックだけでは不十分であり、PMは社内契約や工場ルール、部門間取り決めも確認する必要があります。
顧客契約の義務が社内の仕組みで実行可能かを確認する
製造業やハードウェア系プロジェクトでは典型的に次のギャップがあります。
顧客は「部品変更時の事前通知」を要求
→ 社内工場は通知義務を負っていない
→ 顧客要件に沿わない可能性
顧客は「不具合発生時の原因分析レポート」を要求
→ 工場側契約に解析義務はない
→ 顧客要求に応えられない
これは、本来費用を見積もる段階で確認しておく内容ですが、契約書上での最終確認が必要です。主に工場や技術部門と外部サプライヤとのサードパーティ技術支援契約の内容になります。
さらにいうと、サードパーティの技術支援には時間がかかりますので、あらかじめ顧客との認識を合わせておくべきです。
緊急問題発生時の回答フローに入れてしまうと、スケジュールコントロールができなくなりますので、原状回復と暫定対処までは自社で完結できるような体制構築が望ましいです。
社内の責任範囲（R&R）が顧客要求と矛盾していないか
社内調達・製造・品質部門などが責任を負うべき事項が、
顧客契約の要求に一致しているかをチェックします。
例：
- 品質保証の範囲
- データ管理の範囲
- 変更履歴の保持範囲
もう少しわかりやすく言うと、顧客が望む製造、品質データのトラッキング情報を管理しており、さらに提出できるか？ということになります。
例えば、性能向上、コスト削減の一環で工場では部品を変更下とします。顧客にとっては、製造ベンダーが大丈夫であると確認したとしても、部品変更もリスクとなります。
従って、顧客からは部品変更時の連絡が欲しいと言われるケースもあります。しかしながら、都度部品変更の度に顧客にタイムリーな連絡を行い、なぜ部品変更したか、どのような確認をしたかなど説明をすることは実質日々の業務では不可能に近いです。
契約の中には、さらっと1行入っていることもありますので、注意が必要です。
この部分は、基本的には見積もりの段階で要求条件に沿って協議をおこない解決済みの内容だと思いますので、契約書ができた段階では、リスクは無いと思っていますが、最終的な確認は必要です。
社内 SLA・工場フローが顧客契約の要求基準を満たすか
特に以下は差分が発生しやすい項目です。
- 部品変更管理（ECOフロー）
- 変更通知のタイミング
- 不具合品解析の対応速度
- 再発防止策の提出義務
内部の仕組みが弱いと、顧客契約の要件を満たせません。これも前章と同じく、見積もりの段階で解決済みであるべき項目ですが、最終確認は必要です。
当然、サプライヤー、ベンダーの立場からいうと義務がない方がコストは低く見積もれます。
内部契約と外部契約のギャップをリスクとして管理する
差分を以下に反映します。
- RACIチャート
- リスク登録簿
- 内部SLAの更新
- 調達・工場への説明会
PMは外部・内部の両面を調整して、初めて契約を実行可能にできます。
社内は基本的には決まったフローで動くべきですので、特にフローに特別なアクションがない場合は、簡単な説明で良いと思います。
ただプロジェクトが始動すると、問い合わせが増えたり社内の稼働が多くなりますので、社内関係者へスケジュールなど連絡するコミュニケーションは必要です。
契約書レビュー内容をプロジェクト計画に落とし込む方法
- スコープ管理計画に反映
- スケジュール・WBSに反映
- リスク登録簿への追記
- ステークホルダー管理計画の更新
- 外注管理計画との整合
- RACIチャートの更新
契約を理解して計画に反映することで、プロジェクトの安定度が大きく上がります。
まとめ：契約を理解するPMがプロジェクトを成功に導く
契約はプロジェクトマネジメントにおける最強のリスク管理ツールです。
法務任せではなく、PMが自ら契約内容を理解し、外部契約・内部契約の双方から整合性を確認することで、プロジェクトは初めて健全な状態でスタートできます。
- 契約＝プロジェクトの設計図
- ベースラインとの整合が最重要
- 前提条件・責任範囲・文言の理解が必須
- 国際契約・暴排条項・汚職防止条項は実務インパクトが大きい
- 社内調達・工場との契約も確認しないと顧客要件を満たせない
契約書を読み解く力は、PMが持つべき“実務最強スキル”の一つです。
おまけ 契約書チェックシート
関連書籍
※本記事にはプロモーションを含みます。
コメント