システム開発における多段階契約とはなにか　推奨される理由も踏まえた解説

システム開発プロジェクトでは、多段階契約というやり方で契約実務が進められる場合が多いものです。本記事では、システム開発における多段階契約について、それが推奨される理由なども踏まえて解説していきます。

多段階契約とは

一般的に契約を締結するための実務は、契約書を介して行われるものです。すなわち、報酬を支払う側（システム開発であればユーザー）が、報酬の支払いを義務として引き受け、仕事を受ける側（システム開発であればベンダー）が対応するサービスを提供することを書面上で約束するということです。このようにして、両当事者が、自らの引き受ける義務を約束することが契約の本質です。

各工程の性質に応じた契約を締結し、作業を完了させる

しかしシステム開発プロジェクトの場合、プロジェクトの内容自体もいくつもの工程を経て進んでいくものであり、その内容も複雑になりがちです。こうした業務の性質を考えると、契約も複数回に分けて進める方が適切である場合も考えられます。つまり、プロジェクト全体を取り仕切る契約書自体も、構造的にアイデアをまとめて作成していくほうがよいということです。たとえば、各工程ごとに逐一契約を締結し直すという手法が実務上は非常に好まれます。こうした契約のやり方は多段階契約とも呼ばれるものです。経産省が提供するモデル契約も、こうした多段階契約に基づくものとなっています。

各プロジェクトにおいて締結される契約の種類

システム開発でよく用いられる契約は、請負契約と準委任契約の二種類ですが、各工程の性質に応じて、この二つを使い分けながら全体を取り仕切っていくというわけです。システム開発の全工程のうち、たとえば、詳細設計、プログラムの実装、単体テストなどは、請負契約が用いられるのが一般的です。こうした工程が請負契約によく馴染む理由は、請負契約が「仕事の完成」という結果を債務の履行要件として重視するものであるところ、工程の性質としても「完成」の要件を具体化しやすいことにあります。なお、請負契約における「仕事の完成」については、以下の記事にて詳細に解説を行なっています。

一方、システム開発の前段階における企画や、要件定義といった段階は、準委任契約がよく用いられる傾向があります。こうした工程の特徴は、「仕事の完成」の要件を明確化するのが容易でない場合が多く、両当事者の信頼関係が契約の基礎となっていることが多い点です。基本設計・結合テストなどの工程では、プロジェクトの性質に応じて、準委任・請負いずれも用いられます。こうした工程でどちらの契約を選択すべきかについては、ユーザーの協力がどの程度必要となるかがひとつポイントとなります。

ベンダー側に一方的に「仕事の完成」を債務として求められる性質のものであれば、請負契約を選択するのが簡便であると考えられます。しかし実際問題ユーザーとベンダーの共同作業にならざるを得ないのであれば、そうした両当事者の信頼に基づく関係性のほうに法的保護を与えるほうが現実的な場合もあるのだと理解しましょう。なお、請負契約と準委任契約の違いについては、以下の記事に詳細に解説しています。

本記事では、プログラムの実装など、成果物の姿が具体的に特定しやすいものは請負契約が用いられる傾向が強く、そうした傾向が小さいものほど準委任契約が用いられる傾向が強くなることを説明しています。こうして、複数にわたって締結される請負契約・準委任契約の総体として一連のプロジェクトを捉えていくのが、多段階契約に基づく契約実務です。また、何度も同様の記載を繰り返さなくてもようように共通する事項をまとめて抽出したものが「基本契約書」だといえます。ちょうど、プログラムの実装で、共通する要素をクラスや関数としてひとまとまりにしておくのともよく似ています。

基本契約書にひとまとめに書いておくことの多い事項としては、たとえば、

• 何度も繰り返し用いる用語の定義
• 個別契約を締結する際の、手続きのやり方
• 実現すべき仕様を事後で変更する際の、その方法
• 各工程ごとの成果物の納入・検収のやり方
• 秘密保持のあり方

などがあります。これらの特徴は、たとえ段階別に契約が別個に分かれていたとしても、一連のプロジェクトであることからすれば通常工程によって区別する必要はなく、一貫して同じ内容となることです。このように、より一般性が高く、汎用性の高い取り決めを基本契約として抽出し、各工程ごとに区別して個別に取り決めをすべきところは個別契約として基本契約の下位に置くというのが多段階契約の特徴です。多段階契約はシステム開発に限らず、規模の大きさや複雑さを特徴とする商取引ではよく用いられるものでもあります。なお、こうした複雑な構造をもつ多段階契約の反対概念は、一括契約です。もし題材がシステム開発ではなく、オーダーメイドのスーツの発注であれば、契約は通常一括で十分でしょう。

多段階契約のメリットとは

では、あえてこうした多段階契約というやりかたを採用するメリットはなんでしょうか。もう少し具体的に整理していくなら、以下のようなメリットを挙げることができます。

多段階契約のメリット１：開発プロジェクトの流動性に対処しやすい

多段階契約のメリットのひとつは、開発プロジェクトの流動性への対処が比較的容易であることが挙げられます。通常一連のシステム開発プロジェクトは、たしかに原則としては、事前に定義された要件に沿って、設計・プログラムの実装などへと進んでいき、手順にも前後や手戻りを挟まずに一気に進めていくものです。しかし、制作物の複雑さゆえに工期も相応の期間にわたるのが通常であり、実現すべき仕様の内容は事後で変わる場合も決して珍しくありません。なお、こうした事後の仕様の変更リクエストに対し、変更管理を適切に行う方法については以下の記事で詳細に解説しています。

すなわち、プロジェクトの開始時点では、最終的な目標が必ずしも明確にはなっていないのです。こうした不確定な要素を含んだプロジェクトであるなら特に、契約締結時点で一括にすべての義務を相互に約束しあうのは困難になりがちです。各工程に分割するほうが、双方にとって無用なリスクを引き受けずにすみ、またスムーズに商取引を進めやすくもなります。

多段階契約のメリット２：見積もりを正確に行いやすい

また上記の、「不明確なものについてあえて確約せずに済ませることができる」というメリットは、見積もり金額を正確にすることができるという点にもつながっていきます。そもそも事後で仕様変更がなされたのであれば、見積もりも事後で変更しなければならなくなることが大いにありえます。こうした際の見積もりの再計算のやり方に関しては、以下の記事にて詳細に解説しています。

事後の仕様変更に伴う見積りの変更に関する考え方は上記記事のとおりですが、そもそも事後でこうした変更に対処することは、ユーザー・ベンダー両者にとってもあまり望ましいことではないでしょう。修正が必要になるような見積りであれば最初から行わず、正確に一回で完了することがベストです。多段階契約であれば各工程ごとに分割して契約する分、見積りが正確に行いやすいこと、事後の見積り変更を起きにくくすることなどが期待できます。

多段階契約のメリット３：報酬を支払う側からみても金額の妥当性が理解しやすい

さらに、各工程に分割して見積りを行うということからは、プロジェクト全体にかかる報酬について、報酬を支払うユーザーからみても金額の妥当性を納得しやすいということもいえます。先述の通り、一連のプロジェクトに完璧な意味での計画性をもって臨むことは決して簡単ではありません。そのためむしろ様々な変更を経て、さらには当初の見積りにも変更が行われつつ進んでいくことが多いものです。こうした点につき、一括契約では見積り金額の説明機会が最初の契約締結時だけとなってしまうことが想定されます。ユーザーにとって、支払い段階で当初の見積りと実際の支払い金額に相違が生じた理由が理解しづらいものとなるということです。こうした点を踏まえると、多段階契約はユーザーにとっても一定もメリットがあるといえます。

まとめ

多段階契約は、公平かつ明確なかたちで両者の合意を形成していくのに適しており、後々のトラブルの予防にも効果があります。もっとも、「逆に多段階契約にもなにかしらのデメリットがあり、むしろ個別契約のほうがよい場合もあるのではないか」と考えた人もいるのではないでしょうか。この点については、強いて言うなら、毎回契約を締結しなおす手間がかさむため、小規模ですぐに業務が終わることが自明なら一括契約でよいという考えは成り立ちえます。しかし、多段階契約のごく限られたデメリットを意識するよりは、正確かつ変更に強い多段階契約という手法のメリットを十分理解しておくことのほうが大切でしょう。一定以上の規模のプロジェクトであれば、当然のものとしてこうした手法を用いるようにしましょう。