プロジェクトの契約って難しいですよね。
よく分からないから営業さんや法務の方に任せてる？
はい、その気持ちよく分かります。
しかし、プロジェクトの最前線で活動するプロジェクトマネージャーが契約を理解しておくことは、
顧客折衝において大きな力になります。
この記事では、主要な契約の種類とその選び方を学んでみましょう！
- プロジェクトで扱う契約の種別は主に２つ
- 契約の種別とベンダーの責任の重さの違い
- どういうときに、どの契約を選べば良いのか
- クライアントに責任をきちんと説明しよう
プロジェクトで扱う契約の種別は主に２つ
まずは下の表を見てみましょう。
この表は、プロジェクト自体やその工程ごとに、どの契約が適しているかを簡単に取りまとめたものです。
| 項番 | 大分類 | 小分類 | ＜選択基準A＞ 成果物の明確さ／納品の約束の有無 | ＜選択基準B＞ ベンダーの努力が成果の達成に関与する割合 | 契約不適合責任の有無 | 債務不履行の要件 | 契約解除時の報酬の取り扱い | クライアントに対する損害賠償責任 | ウォーターフォール型プロジェクトの場合の、各工程の推奨契約 |
|---|---|---|---|---|---|---|---|---|---|
| １ | 準委任契約 | 履行割合型 | 不明確／納品の約束無し | 小さい | 規定無し（ただし善管注意義務違反を問われる場合がある） | 善管注意義務に違反したとき（民法644条） | 既にした履行の割合に応じて報酬を請求できる（民法648条3項） | 善管注意義務に違反した場合に負う（民法652条によって準用される民法620条） | ・要件定義（外部設計含む） ・システムテスト（外部システムを含む場合） ・受入れテスト ・導入支援 ・運用保守 |
| ２ | 成果完成型 | 明確／納品の約束有り | 中程度 | 負う（民法559条 | 既にした可分な仕事のうち、注文者が利益を受ける部分の報酬を請求できる（民法634条） | ・あまり使われない | |||
| ３ | 請負契約 | – | 大きい | 仕事を完成できなかったとき | 負う | ・設計（内部設計以降） ・実装 ・システムテスト（外部システムを含まない場合） |
読みづらくてごめんなさい。エクセル版もどうぞ。
この記事では、項番１と３、選択基準AとBを主に説明していきます。
さて、プロジェクトの契約で少しややこしいのは、
一つのプロジェクトの契約が、項番１と３の契約の組み合わせで成り立っている、というところです。
例えばウォーターフォール型のプロジェクトの場合、以下のようにすることが推奨されています。
| プロジェクトの工程 | 使用する契約種別 |
|---|---|
| 要件定義 | 準委任契約（履行割合型） |
| 設計、実装 | 請負契約 |
| 単体テストからシステムテスト | 請負契約 |
| 受入れテスト（ユーザーテスト） | 準委任契約（履行割合型） |
| リリース | 請負契約 |
| 導入支援 | 準委任契約（履行割合型） |
なぜこんな面倒なことをするのかと言えば、
各工程ごとにベンダーが負うことのできる責任の重さが異なるからです。
どういうことなのか分かりづらいですね。
それでは次章で、契約種別とベンダーの責任の重さの関連を見てみましょう。
契約の種別とベンダーの責任の重さの違い
結論から言うと、項番１の「準委任契約（履行割合型）」が最もベンダーの責任が軽く、
逆に項番３の「請負契約」が最も責任の重い契約となります。
これがどういうことなのか、具体的にベンダーが報酬をもらえる条件を見てみましょう。
（項番２は割愛します）
| 項番 | 契約種別 | ベンダーが報酬を貰える条件 |
|---|---|---|
| １ | 準委任契約（履行割合型） | 成果の有無にかかわらず、働いた時間分だけ報酬がもらえる。 ※ただし善管注意義務に違反しないこと。 |
| ３ | 請負契約 | 成果物が完成したときに、報酬がもらえる。 |
つまり、項番１の準委任契約（履行割合型）は、
「何の成果も出ていなくても、提供した労働の分はお金を貰う権利が発生するよ！」
という、ベンダーにとって超有利な契約ということです。
「え、じゃあ全部の契約を準委任契約（履行割合型）にしてしまった方が良くない？」
と、思われるかもしれませんが、そう簡単な話でもありません。
まず、「責任」とは移動することはあっても無くなることはありません。
ベンダー側の責任が軽いということは、クライアント側の責任が重くなる、ということです。
「責任」は「リスク」と読み替えても問題ありません。
片方ばかりが不利になる契約なんて、普通は合意できません。
また、準委任契約（項番１と２）もベンダー側に完全有利というわけではなく、
「善管注意義務（ぜんかんちゅういぎむ）」という責任が存在します。
「善管注意義務」とは、「善良なる管理者の注意義務」の略で、
「その業務のプロフェッショナルらしく、クライアントを含めてちゃんと業務を管理、処理してね」という意味になります。
（これまたきちんと定義しておかないと危険）
なので、「クライアントに言われた通りやってれば良い」くらいに考えて、受け身でプロジェクトを進行していると、
業務の結果が芳しくないときに、善管注意義務違反と見なされて報酬を受け取れない場合があります。
そんなわけで、片方ばかりが完全に有利な契約というものも存在しません。（当然っちゃ当然）
契約を使い分けて、両者の間で「責任」の分散が図られることになります。
どういうときに、どの契約を選べば良いのか
では、いよいよ契約の選び方を考えてみましょう。
ベンダー目線で見たときに、以下の（A）または（B）、あるいはその両方に該当する場合、
準委任契約（履行割合型）を選択すべき、となります。
（A）成果物が不明確な場合
（B）ベンダーが成果の達成をコントロールできる割合が少ない場合
※記事の冒頭の表の「選択基準AとB」に関連づいています
実際のプロジェクトに照らして、それぞれの具体的な例を見てみましょう。
（A）成果物が不明確な場合
「成果物が不明確」な状態とは、例えば「予算は確保したが、何を作るかはこれから考える」というケースです。
プロジェクト開始直後の企画、要求定義、要件定義などの作業がまさにそれで、
ぼんやりした課題や構想はあるが、それらが整理できていない状態です。
要件定義の場合、「要件定義書を作る、整理する」というゴール自体はありますが、
プロジェクトの方針が定まっていない状態で、作成する資料は決めづらいですよね。
アジャイル型の開発なんかも成果物が不明確（変化していく）なことが多いため、この（A）に該当します。
ベンダーとしては、
「何をするかがちゃんと決まっていないプロジェクトの責任は負えないよ」
ということになります。
（B）ベンダーが成果の達成をどの程度コントロールできるか
これは、「作業者が、作業管理者の統治下（指揮命令系統内）にいない」というケースです。
（A）でも取り上げた要件定義や、受入れテスト（ユーザーテスト）がそれに該当します。
要件定義は、プロジェクトの最初期ということで議論が発散しやすく、期間が伸びやすいという性質を持ちます。
（信頼関係の構築や、クライアント社内の意思決定に時間を要することが多い。）
受入れテストは、テストに必要な情報やその観点はベンダーが取りまとめますが、
テストする内容の決定や、テスト作業そのものはクライアントが行います。
テスト作業自体がクライアントによる作業であるため、ベンダーはその成果（精度や網羅性など）に責任を負えません。
またクライアントは、受入れテストで初めて製品全体を触ることになるため、
仕様変更や追加要求が発生しやすく、その見通しを立てづらいこという背景もあり、
準委任契約（履行割合型）の選択が推奨されます。
ベンダーとしては、
「サポートはするけど、あなたたち（クライアント）の作業の割合が多いから、成果の責任は負えないよ。」
ということになります。
まとめると、
（Ａ）と（Ｂ）のいずれにも該当しないときに、ベンダーが成果物に責任を負う項番３の請負契約を選択できる、
というわけですね。
クライアントに責任をきちんと説明しよう
適切な契約種別の選択は、クライアントとベンダー双方の利益を守るための大切な工程です。
重要なのは、選択した契約によって双方にどのような責任が発生するのかを、
ベンダーがきちんとクライアントに説明することです。
システム開発の段取りや契約に明るいクライアントは多くありません。
そのため、その筋の専門家であるベンダーが、クライアントにきちんと情報を伝え、エスコートしていく必要があります。
これはベンダーの立派な責務の一つです。
クライアントも、自社の役割とその責任を正しく認識すれば、それを果たすべく動いてくれます。
（サボれば、その代償として無用な出費が発生しますからね・・・。）
このときクライアントに伝える「責任、リスク、それに伴って発生するタスク」は、
各工程ごとに、できるだけ詳細に説明してあげると喜ばれます。
プロジェクトとは、ベンダーとクライアントの双方で作り上げ、成功させるものです。
片方のみが責任を負うような契約のプロジェクトは上手く進みませんし、
また、それを強要する相手と仕事をするべきではありません。
（十分な追加費用を貰って、ベンダーがリスクを負うこともありますが。）
まとめ
いかがでしたでしょうか。
当記事を読まれたあなたは、プロジェクトに最適な契約を選択できるようになりました。
迷ったときは、記事の冒頭の表を読み返してみてください。
選択基準のAとBが、契約選択のポイントです。
また、当記事を書くにあたって参考にしたサイトを紹介させていただきます。
より深く理解したい方は、以下のページを次のステップにすると良いと思います。
以上、あなたのプロジェクト運営の一助になれば幸いです。
当記事のステップアップ図書
成功するシステム開発は裁判に学べ!
過去の判例から、「こういう進め方をしてると揉めますよ」という事例を集めた良書です。
各分野を広く浅く取り扱っており、気を付けるべきポイントを効率よく学ぶことができます。
当記事の関連記事
準備中このブログは、日本のプロジェクトマネージャーの仕事のレベルを底上げし、
本人とそのチームの人々の人生を幸福にすることを目的に、プロジェクトマネージャーの仕事に関する記事を書いています。
私自身も道半ばゆえ、至らぬ点も多々あるかと思いますが、記事の感想やリクエストをいただければ
できるだけ記事にしてお応えしますので、皆様の忌憚のないご意見をいただけますと幸いです。
コメント