執筆：弁護士 森田 芳玄（AI・データ（個人情報等）チーム）
『連載:システム開発紛争の基本問題（１） 請負契約と準委任契約の区別の判断要素について（前編）』はこちらから
『連載:システム開発紛争の基本問題（２） 請負契約と準委任契約の区別の判断基準について（後編）』はこちらから
『連載:システム開発紛争の基本問題（３） 仕様の重要性について』はこちらから
『連載:システム開発紛争の基本問題（４） プロジェクトマネジメント義務』はこちらから
『連載:システム開発紛争の基本問題（５） 準委任契約について』はこちらから
『連載:システム開発紛争の基本問題（６） 損害賠償請求について』はこちらから
１．はじめに
システム開発業務を委託/受託するに際してトラブルに巻き込まれてしまうことは意外にあるものです。そのようなときに後悔しないように、本連載では事前に対処するべき事項や、実際にトラブルになってしまった際の対処法などをできる限りやさしく解説してゆくことを目的としています。
第７回目は、段階的契約の問題について考えてみたいと思います。
２．システム開発における段階的契約とは
（１）なぜ段階的契約が必要となるか
そもそも段階的契約とはどのようなことかといいますと、システム開発業務の工程ごとに契約を締結することを意味します。
業務委託契約の場合、当事者間のどの案件にも共通する基本的な事項については基本契約で取り決め、案件ごとの個別的な内容については個別契約で取り決める、というように基本契約と個別契約に分けることはよく見かけます。しかしながら、段階的契約とは、一つの案件の工程ごとに契約を分けるものです。
なぜそのようなことが必要とされるのでしょうか。それは、システム開発業務は他の委託業務とは異なる性質を有していることが挙げられます。
すなわち、システム開発業務は、一般的には「要件定義」、「設計」、「プログラミング」、「テスト」、完成後の「保守・運用」などというような段階に分かれており、その段階ごとに性質が分かれているといわれています。たとえば、要件定義の工程においては、基本的にはそのシステムの発注者である委託者（ユーザー）側が主導して行い、受託者（ベンダー）側はそのサポートを行うものという理解であるのに対して、プログラミングの工程においてはまさに受託者側が行うべき業務ということになります。
なお、上記の工程の最後の保守・運用は、正確にはシステム開発業務というよりもステムが完成した後の業務であり、システム開発契約とは別に保守・運用契約を締結する例が多いかと思います。これは両者の業務の性質の違いに着目して契約を分けているという点で、広い意味では段階的契約といえるかと思います。
必要性に関するもう一つの理由としては、システム開発業務の場合、開発の対象となるシステムの内容が流動的で、開発の当初の段階では完成までの姿が見通せない場合があり得るということです。当然のことながら委託者のある目的のためにシステム開発を行うわけですが、その時々の対内的・対外的な状況の変化に応じて、システムに求める内容も変化し、それを反映させる必要が生じてきます。このため、システムの最終的な完成までの正確な見積りを出すことが困難な場合もあり得ます。そのような場合に、段階的契約として開発の段階ごとに見積もりを出すことで、見込み違いをなくすことが可能となるわけです。
（２）参考となる裁判例
直接的に段階的契約に言及したものではありませんが、以下のような裁判例は一つの参考になります。
【裁判例】東京地裁平成２０年４月２４日判決
「本件システムの開発で採用されたウォーターフォールモデルでは、通常、設計段階（要求仕様、基本設計の確認まで）においては、その開発内容を決定する発注者側が主導的な役割を果たし、基本設計が確認された後の制作段階においては、上記開発内容を専門技術を活かして成果物を作成する受注者側が主導的な役割を果たすものとされていること」から、「本件システムの開発に必要な設計書を作成する事務の遂行」段階については準委任契約であったと認定。
上記の裁判例は、ある工程の業務について請負契約であったか準委任契約であったかが争点となった事案でありますが、裁判所においても設計段階までと制作段階以降において業務の性質が異なり得ること、それに基づいて契約内容も異なることがあり得ることを認めたものとして参考になるかと思います。
３．段階的契約のメリット・デメリット
（１）メリットその１～工程ごとに契約の種類を変えることが可能～
それでは、段階的契約のメリットとしては、どのようなことが考えられるのでしょうか。まず１点目としては、工程ごとの契約の性質の違いに対応することができることが挙げられます。
すなわち、委託者側があまり意識していない場合もあるのですが、システム開発において最初の要件定義と設計段階の一部については、上記裁判例でも指摘されているように、どのようなシステムを開発するかという意思決定の場面になるため、委託者側で主導的な役割を担い、受託者はそのサポートを行うというのが本来的な役割分担になります。そうすると、受託者の方において「完成」が求められる請負契約はその性質にそぐわず、準委任契約の方が親和的であるということが考えられます。
他方で、開発段階については、まさに事前に確定した設計通りに制作するという意味では「完成」が求められている部分になるため、請負契約の方が親和的ということになります。
このように、段階的契約とすることにより、工程ごとの性質に応じた契約が可能である点があります。これはシステム開発案件の全体を請負契約とするか、準委任契約とするかという、委託者側と受託者側の間での最も利害対立の生じる事項についての折衷案的な解決策になりうるかもしれません。
（２）メリットその２～開発の対象ごとの契約が可能～
２点目としては、上記２で述べた必要性の２点目に対応することですが、開発の開始当初の段階で最終的な完成までの見通しが立てづらい場合において、システム開発自体をいくつかの段階に分けて、その段階ごとの契約を締結する、ということも考えられます。たとえば、開発自体を３つの工程に分けて、その工程ごとにそれぞれ契約を締結するというような方法です。
この場合、それぞれの開発工程において費用を見積もることができるため、正確な費用を算出することが可能になるというメリットが生じます。また、委託者・受託者どちらにもいえることですが、開発が途中で思うように進捗しない場合に、開発途中の段階でも費用の精算などの観点からも契約の終了が容易に可能になる、ということもあります。
（３）デメリット
段階的契約のデメリットとしては、当然のことながら、何度も契約を締結することになるため、その法務コストが生じてしまうことが挙げられます。
また、委託者側としては、契約を段階的にすることによって、トータルの開発コストが上昇してしまう懸念が存在します。ただこれに関しては、段階的契約としない場合には受託者側が案件の全体を見通せない結果、高めの見積りを出すことも考えられるため、段階的契約とすることにより常に高くなるとは限りません。
他方、受託者側としては、段階的にすることにより次の段階の開発を失注してしまう懸念もあり得ることになります（実際には、別業者への引継ぎのコストが発生するためベンダーの安易な切り替えは発生しないと思われますが。）。
しかしながら、本来委託者が負担すべき開発コストを委託者が負担しないとか、受託者が不十分な業務を行っているにもかかわらず、別のベンダーに切り替えられないで業務が進行し続けられてしまうということは、事態が進行すればするほど深刻な問題になり、最終的には訴訟に発展しかねなません。
それを避けるために事前に段階的契約としておくことは、トータルのコストを下げる保険的な意味でも十分に検討に値すると思います。
４．段階的契約の実践方法
それでは、段階的契約はどのように行えばよいのでしょうか。上記の段階的契約を確実にするためには、やはり段階ごとに契約書を締結するのが望ましいと思います。
しかしながら、実際のところは、契約書自体を複数にしなくても上記のメリットをある程度実現できる場合があり得ると思います。すなわち、一つの契約書の中で、要件定義部分は準委任、開発部分は請負、というように異なる性質を定めておき、それぞれの性質に対応する条項を盛り込めば、契約書自体が一通でも段階的な契約とすることが実現可能であると考えます。
また、開発業務の中でもいくつかの工程に分け、Ａ工程は○○○万円、それが完成したら次にＢ工程を行いその金額は○○○万円というように、工程ごとに納品・検収を行い、その工程に対応する報酬を支払うことを定める、とすることも考えられます。
このような契約書上の工夫をすることにより、完全に契約書自体を分けた場合のような明確さは劣るものの、従来型の一般的な業務委託契約とすることによるリスクをある程度は解消できるのではないかと考えます。
５．まとめ
現状では、システム開発案件全体を１つの契約とし、請負契約または準委任契約で行われている事例が圧倒的な多数なのではないかと思います。その場合は現場でどのようにしているかと考えますと、当初請負契約で定めた報酬以上の費用が生じてしまっているものの、その後に保守・運用契約が締結されることを見込んでやりくりするとか（受託者側の不満）、全体を準委任契約で締結してしまったために受託者が完成まで責任を持ってくれない（委託者側の不満）、などという事態が頻繁に発生しているのではないかと思われます。
そのような事態を事前に回避するためにも、上記のような段階的契約を検討していただければと思います。
以上
