ITシステム開発は、業務の効率化や新しいサービス導入のカギとなる重要な取引です。しかし、大きな費用がかかることともありますし、実際にできあがったものが事前にイメージしていたものと違うといったトラブルも発生します。このようなトラブルに対処するには、ITシステムの契約を理解し、事前に手当てしておくことが重要です。 そこで、今回のコラムでは、ITシステム開発の契約について、法的な問題となりやすい点を解説します。
第1部 ITシステム開発でトラブルが発生しやすい理由（5つ）
ITシステム開発は、トラブルが起きやすい取引です。その背景として、以下の5つが挙げられます。
①ユーザーが、出来上がりを事前にイメージするのが難しい
たとえば建物を作る場合であれば、設計図面や出来上がりの予想図で、ユーザーが事前に出来上がりをイメージできるでしょう。しかし、ITシステムはそのようなものがないので、ユーザーが事前に出来上がりをイメージするのが難しいといえます。このため、ユーザーが事前に想像していたものと、実際の出来上がりが違う、という事態が起きやすいです。
②ユーザー・ベンダーの両方が、相手方の領域について、十分な知識がない
ITシステムを作るには、ユーザーの業務上のニーズを理解して、それを解決するソフトウェアの形にしていく必要があります。 しかし、ユーザー側はソフトウェアについてあまり知識がありません。また、ベンダーがユーザーの業務について細かいところまで把握するのも簡単ではありません。このため、ユーザーの業務上のニーズにきちっとフィットしたソフトウェアを作るのは簡単ではありません。
③事前に工数の予測が立てづらい
ソフトウェア開発は、開発がある程度進まないと工数の見積もりが難しいため、実際に開発してみると、事前に予想していたよりだいぶ工数が多くかかってしまった、ということは珍しくありません。
④契約書を締結する前に作業がスタートしてしまうことが珍しくない
ユーザーは、競合他社との競争上、新サービスをできるだけ早く投入したいので、新システムをできるだけ早く完成させたいと考えるでしょう。しかし、システムを作るのにはどうしても時間がかかるので、早くサービスを開始したいのであれば、その分開発を早くスタートする必要があります。一方、契約書を締結するためには、契約書に書く取引条件を全て合意する必要がありますし、契約書の作成・交渉や、様々な社内調整で時間がかかることがあります。特に大企業であれば、それぞれの会社で契約書にどのような条項を置くかポリシーを持っていることが多いですので、その原則と違う内容の契約になってしまうと、締結するまでに、色々な部署に説明してOKをとらなければならないことも多いです。
このため、契約書の締結を後回しにして、開発作業だけ進行することがあります。開発作業がある程度進んだところでユーザーの方針が変わってやっぱりシステム開発をしない、ということになると、ベンダーは「すでに作業しているし、プロジェクトに人員が必要と聞いていたので、ユーザーの要請にあわせて今後の人員を確保するため、他の案件は断ってしまった。お金は払ってほしい」ということになり、ユーザーは「契約も締結していないのにお金は払えない」といったトラブルが生じます。
⑤開発作業中に仕様が変わってしまうことがある
細かいサービスの仕様、画面を完全に決める前に開発をスタートした場合や、開発スタート後に他の部署から指摘を受けたりして問題点に気づいた場合、「やっぱり少し仕様を変更したい」ということがあります。見た目がちょっとした変更だと、ユーザー側は、開発のスケジュールや予算には大した影響はないはずだと考えがちです。しかし、見た目ではちょっとした変更であっても、実際にはシステムの中の色々な部分を手直ししなければならず、時間やコストに大きな影響があることもあります。
このように、ITシステム開発はトラブルが生じやすい契約です。システム開発が遅れ、プロジェクトを最終的に中止せざるを得なくなって、ユーザーとベンダーとの間で裁判になるケースもあります。
第2部 ソフトウェア開発の流れ（ウォーターフォール開発）
法的な話ではないのですが、契約にも関係してくるため、ソフトウェア開発の流れについて触れておきます。
日本のソフトウェア開発では、「ウォーターフォール開発」というのが主流とされています。これは、次に書いた流れで開発していく方法です。
①要件定義工程・・・制作するソフトウェアの完成像をユーザーとベンダーですり合わせる工程です。具体的には、ソフトウェアの機能、予算、開発のスケジュールなどを決めます。
②基本設計工程・・・ソフトウェアの画面、周辺の情報システムとのインターフェイスなど、ユーザーや周辺の情報システムから見える部分の設計です。
③内部設計工程・・・基本設計工程で決めた機能を実現するため、ベンダーが、システム内部の動作や機能などを設計します。
④プログラミング工程・・・実際にプログラムを作成・実装します。
⑤単体テスト工程・・・各モジュールごとに、実装したプログラムが正しく機能するかをテストします。
⑥結合テスト工程・・・複数のプログラムを組み合わせ、正しく機能するかテストします。
⑦運用テスト工程・・・実際にシステムを稼働させて、ユーザーが操作した場合に問題がないかどうかを確認・検証します。
ウォーターフォール開発では、工程ごとに品質を管理するため、高い品質が確保できるメリットがあります。デメリットは、開発の途中で修正や仕様変更が発生し、前の工程に戻らざるを得なくなった場合に、工数や納期に大きな影響が出る点です。
「ウォーターフォール開発」以外で有名な開発の方法として、「アジャイル開発」という方法があります。これは、ビジネスの優先度に応じて、機能ごとに開発していく方法で、開発作業と並行して要件の明確化を進めていきます。開発中の仕様変更、修正に対応しやすいというメリットがある一方、プロジェクトの計画・管理が難しくなるというデメリットもあるといわれます。
第3部 ITシステム開発の法的なポイント（5つ）
１．一括契約方式か、多段階契約方式か（ウォーターフォール開発）
上に書いたように、ウォーターフォール開発では、要件定義工程が終わるまでソフトウェアの全貌が明らかにならないので、工数や期間の見積もりも難しく、契約条件を決めにくいという問題があります。そこで、最初は、開発プロジェクト全体に関係する一般的な条件だけ書いた基本契約と、要件定義工程の契約だけ締結し、そのあと、設計段階の契約、プログラミング段階の契約・・・と順々に締結していく方法（多段階契約方式）が、大規模な開発プロジェクトではよく使われています。ただ、この方法をとると、ユーザー側からみると、スタート前の見積もりでは全体で10億円と言われたのに、お金をかけて要件定義をしたら、全体で20億円と言われた・・・という事態も発生します。基本設計工程以後はまだ契約を締結していないのでプロジェクトを中止する、あるいは他のベンダーに乗り換えるという方法もありますが、ベンダーからの不合理な引き上げを防ぐため、最初に基本合意書のようなものを締結して、当初の見積もりより増加する場合はベンダーに説明義務を課す、といったことが考えられます。
他方、小さいプロジェクトでは、金額が小さいため、金額の振れ幅もそこまで大きくならず、ベンダーとしても契約にそこまで手間をかけることはない、ということで、全体を一括で請け負う形が多いようです（一括契約方式）。その場合は、全体の金額が最初から契約で決まっていることになります。
2．請負か準委任か
システム開発で使われる契約の類型として、「請負」と「準委任」があります。
「準委任」とは、コンサルティング契約などで使われる類型で、「善管注意義務を尽くして依頼された業務を遂行する」（＝プロとして当然果たすべきクオリティの仕事をやる）という契約類型です。これに対して、「請負」とは、仕事を完成させ、それに対して対価を払う、という契約類型です。「請負」は「完成」という言葉が出てきますので、何が「完成」なのかはっきりしていなければなりません。このため、「成果物」として何が求められるのか、事前にはっきり決められることが前提となります。上の多段階契約方式を使う場合、例えば、要件定義は準委任とするのが一般的であり、プログラミング工程は請負とするのが一般的です。
「請負」はユーザーの方に有利、「準委任」はベンダーの方に有利になる、と言われることがあります。これは民法上、請負契約は「完成」義務があるのに対して、準委任は完成義務を負わない（そもそも「完成」という概念がない）ため、請負の方がユーザー有利になる、ということのようです。確かにそのような面はありますが、請負で「完成」といえない場合は、準委任でも義務違反（善管注意義務違反）が認定されることが多いでしょうし、報酬についても、成果物の納入がないかぎり報酬は請求できないと契約に書いておけば、準委任でも成果物の納入がないのに報酬を払わなければならないことがなくなります。また、契約書で「準委任」「請負」とはっきり書いてあったとしても、それが決定的な意味を持つわけではなく、裁判になった場合は、契約書の実質的な内容、契約締結までの事情、作業の実態などをみて、裁判所が逆の類型（請負の場合は準委任）と判断することがある、という点には注意が必要です。結局、契約でベンダーが果たすべき義務がなんなのか、ということがポイントであり、契約書に「請負」と書くのか、「準委任」と書くのかが決定的な意味を持つものではないと思います。
3．契約書が締結されないままの開発進行
契約書が締結されないまま開発が進行し、途中でプロジェクトが中止された場合などに報酬を請求できるのか、という問題があります。
そもそも日本の法律上、契約は「契約書」がなくても、意思表示の合致があれば口頭でも成立します。ただ、企業の間の取引では「契約書」を締結するのが普通ですので、まだ契約書を締結していない、ということは、最終的な（正式な）意思表示はまだなされていないと考えるべきケースが多いでしょう。このため、企業の間で行うソフトウェア開発取引で、「契約書」が締結されていないにもかかわらず「契約」が成立したと裁判所が判断することは多くないと思われます。過去の裁判例でも、多くのケースでは契約の成立は否定されているようです。
ただ、ユーザーがベンダーに契約を締結してもらえると信じさせるような言動をして、ベンダーがそれを信じて開発作業に着手したのに、ユーザーの一方的な事情で契約が締結されなかった場合は、「契約締結上の過失」という法理により、ユーザーがベンダーに対して、ベンダーの損害（支出した人件費など）を賠償しなければならないことになります。契約が成立しているケースと何が違うかというと、①「契約締結上の過失」の場合は、あくまでベンダーの被った「損害」の賠償であって、プロジェクトが進行していたらベンダーが得たであろう利益分の請求はなかなか難しいと考えられるということ、②「契約締結上の過失」の場合は、過失相殺され、ベンダーが損害の一部しか請求できない可能性があること、が挙げられます。
また、ちょっと違うケースですが、ソフトウェア開発が進行した段階で、ユーザーがベンダーに対して仕様変更や機能追加を求め、ベンダーが（委託料の増額について合意することなく）応じて作業した場合に、ベンダーが追加請求できるのか、という問題があります。あらかじめ契約書にそのような場合の委託料の増額の条項があるのであればそれに従いますが、それもない場合にどうか、ということです。こちらはケースバイケースではありますが、もともとの委託料には含まれていないと考えられるような追加開発だとすると、商法512条という法律の条文を根拠に、追加の請求が認められる場合があります。
4．ソースコードの著作権
ソフトウェアのソースコードは「著作権」の対象になると考えられています。ユーザー側はお金を払ったので当然著作権ももらえるはずだと思われている方もいますが、「知的財産権」の一種である著作権（＝著作物をコピーしたり改変したりする権利）は、物としての成果物（ソフトウェア）そのものとは別なので、委託料を払ってソフトウェアを引き渡してもらったとしても、著作権が移転するわけではありません。例えば、本屋で小説の本を買っても、買った人に小説の著作権が移転するわけではないのと同じです。そのため、著作権を譲り受けるためには、契約書ではっきり書いておく必要があります。
ただ、ユーザーがソフトウェアを社内で使うだけであれば、著作権をもらわなくても、ソフトウェアを自社所有の媒体に保存しておくことが前提になりますが著作権法47条の3、47条の6第1項第2号という著作権法の条文に基づいて改変まで含めてできてしまう（あるいは、著作権をベンダーに残しても、社内利用に必要な範囲でライセンスを受けておければ十分なことが多い）ため、著作権をベンダーに残すケースも少なくないと思います。ユーザー側からすると、自分がお金を払っているのになぜ、という気持ちにもなると思いますが、ベンダー側からすると、著作権を渡してしまうと、そのソフトウェアのソースコードを改変して他の顧客向けに別のソフトウェアを開発する、ということもできなくなってしまい、ほかのソフトウェア制作に再利用できそうな汎用性のあるソースコードであれば、著作権を自分に残しておきたいというニーズがあるためです。
5．できあがったソフトウェアにバグがある場合
ユーザーからみると、成果物として納品されたソフトウェアにバグがあって使えないと困ってしまいます。その場合、ユーザーとしては何が言えるでしょうか。
最終的には契約書にどう書いてあるか次第ではありますが、当然、ベンダーにバグを直すよう求めることはできます。他方、バグがあるソフトウェアなんていらない、と思って、いきなり契約を解除してお金を返金してもらうことはできないと考えられています。バグがないソフトウェアはないので、バグが発見された場合、バグを速やかに直すなどの措置を取ってもらえばよいと考えられているからです。しかし、システムの使用に支障の出るバグについて、直すよう求めてもなかなか直してもらえない場合、あるいは、次から次へとバグが出てきてシステムの利用に支障が出る場合は、契約解除できることが多いと思います。最終的には契約書の書き方によって変わってくるので、契約を交渉する際の重要なポイントの一つになります。
［ディスクレイマー］ 本コラムは、お客様の参考として一般的な情報を提供するものであり、具体的な法的助言を意図したものではありません。また、分かりやすさを保つため、法的には厳密さを欠く表現にしている部分も多くあります。実際の事案を検討される際には、必要に応じて専門家にご相談ください。