お問い合せ(メールフォーム24時間対応)
TEL:03-6435-9560(平日休日問わず9時から21時まで対応)
このボタンで電話
初回相談は無料です実績豊富な弁護士が今すぐあなたのお力になります
i@atlaw.jp 直接メールでのお問い合せも承ります

システム開発を含むIT法務について,定期的に無料電話法律相談を行っています。
くわしくはこちらをご覧下さい。 

システム(ソフトウェア)開発契約とは

システム開発契約とは,その依頼内容も種類も複雑で多数ありますので,これがシステム開発契約と提示することは困難です。

ここでは,依頼者(ユーザーといいます。)の依頼に応じて,業者(ベンダーといいます。)が,ユーザーの要求に合致したソフトウェアを開発することを請け負うという典型的な例を想定します。

システム開発契約の法的性質

これも,そもそもあまり有益な議論ではないですし,一般の方にとっても無益な議論だと思いますので,あまり議論しません。

システムという成果物の制作を求めるという請負契約か,それともそれに向けての種々の役務をある程度広い裁量で遂行するので,準委任契約か,という問題がありますが,混合契約ないし無名契約と解するのが素直でないかと思います。

システム開発契約における双方の役割

システム開発契約においては,概ね,ベンダーの仕事は,仕様の確定,要件定義,設計を経て実際に製造を行い,ユーザーに納品して検品を得るという流れになります。

一方で,ユーザー側にも,お金を払う以外に仕事があり,自己の要求,たとえば,どういう機能がほしいかということを,そのコストについても相談しながら,開発に協力をするぎむがあると考えられています。

システム開発契約というのは,ある意味,ユーザーとベンダーの共同作業の契約といってもよいでしょう。

もっとも,裁判例によれば,ベンダーには,ユーザーが無茶な提案に固執して,開発を頓挫させないようにする,プロジェクトマネジメント義務があるとされています(平成24年3月29日東京地方裁判所判決,スルガ銀行対日本IBM損害賠償請求事件 判例集未登載)。

ですから,ユーザーとベンダーは,双方がやるべき事を確認して,できれば覚え書き等を作成しておいた方がよいでしょう。万全を期するなら,打ち合わせの度に,双方の押印のある議事録を作成しておくのが適当ではないかと思われます。

システム開発契約においては,双方が,任せっぱなしにせず,任されっぱなしにもしないという意識が重要であるといえましょう。

「仕様変更」はどこまで認められるか

「仕様変更」とは,ここでは大きく,ユーザーの注文内容が契約後に変化することをいいます。

あくまで原則論でいえば,契約は,ユーザーの当初の注文内容で確定して成立したのであり,その内容を途中で変更できないのが原則です。これは,たとえば,ビールを一ケース頼んでおいて,途中で自由に発泡酒に変えられるのか?というような問題です。

もちろん,相手方が同意すれば自由に変更はできるのですが,通常はコストが発生しますので,そうそううまくいきません。

また,システム開発契約においては,ユーザーとベンダーが協力をして仕様を固めていくという側面があります。

そうすると,果たして「すでに確定した仕様を変更するのか」,それとも「未だ確定していない仕様を確定させる(つまり変更ではない)のか」が争いになる可能性があります。

前者であれば,自由にできない(追加費用が発生する。)ということになるでしょうが,後者であれば問題が無いのが原則となります。そうすると,それまでの両者の協議経過が決定的に重要になります。

この争いは,お互い立証が困難ですので,紛争に至った場合にはお互いハイコストな争いとなりかねません。

これを防ぐためには,契約の当初からある程度仕様を確定させてしまうのがよいのですが,最初から確定できる場合ばかりではありません。

ですから,契約の時点において確定できない場合は,その後の進行にしたがって確定させること,確定させるときは書面によるべき事を定めて,仕様が確定する度に書面を作成するのが好ましいです。

法的紛争は別にしても,仕様変更でトラブルになると,取引先を失う結果にもなりかねません。そこで,特にベンダーとしては,仕様確定・変更の難しさについてよく説明すると共に,当初から一定額を仕様変更の作業費として設定してしまうことも検討した方がよいかもしれません。

開発の進捗・完成未完成の紛争を防ぐには

契約を中途で解約する場合の出来高払いのとき,あるいは,納品後の完成の有無が争われるケースがあります。

まず,出来高の算定ですが,予め契約で定めておけばいいのですが,そうでない場合や,そうであっても算定困難なケースがままあります。

最初に,当事者の方に知っておきたいのは,検収,つまり,ユーザー側の方で納品されたシステムを確認して異議を申し立てないと,原則として完成が推定されてしまうことです。さらに,ユーザーがシステムを受領してそれを実際に運用してしまっても同様です。

もちろん,完成・未完成の判断は,契約とシステムの内容そのものから判断すべきものですが,実際には,運営の事情などのいわば「状況証拠」も重視されますので,よくよく注意が必要です。

このような紛争を起こさないためにも,ユーザーがニーズを的確にベンダーに伝えておくことが必要です。

ソフトウェアの開発は,乱暴にいえば,要するにソースコード(ソフトウェアの設計図のようなものです。)の作成なわけですから,ユーザーとしては,進捗におうじて,ソースコードを受け取れる様にしておくことも重要です。内容が分析できなくても,将来の紛争に備えることができますし,ユーザーが注意を払っているというポーズを示すことができれば,ベンダーにおいてもしっかりとユーザーが納得のいく作業・説明を心がけるようになるはずです。

ベンダーとしては,ユーザーのニーズをしっかりとつかんでいくほか,作業状況についてしっかりと進捗管理をし,画面デザイン,機能なども項目毎にしっかりと同意を取り付けていくことが重要です。これは,前述した議事録の作成が効果的です。

システム開発紛争の法的処理の困難性

システム開発紛争においては,専門用語が飛び交い,それらについて逐一,訴外交渉であれば相手方代理人弁護士,訴訟であれば裁判所に説明をする必要があること,その説明は法律家が行うことから,非常に処理が困難となります。

すなわち,紛争発生後は,紛争の交渉や訴訟活動のコストには,交渉や訴訟そのもののコストのみならず,現状・ソースコード等の分析のコスト,そして,それを法律に再構成するコストが重くのしかかります。

ですから,紛争額が小さい場合は費用倒れになることが多く,また時間もかかりがちです。

紛争額が大きい場合でも,訴訟や交渉の趨勢が読めず,大きなリスクを負担することにもなりかねません。

上記の注意点によく配慮して,予防法務を十分に行うことが,なによりも重要です。

「プロジェクトマネージメント義務」という特殊性

裁判例は,

被告は、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、被告は、注文者である原告国保のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない原告国保によって開発作業を阻害する行為がされることのないよう原告国保に働きかける義務(以下、これらの義務を「プロジェクトマネメント義務」という。)を負っていたというべきである(平成16年3月10日東京地裁判決)。

と述べています。

これはどういうことかというと,そもそもシステム開発においてはベンダーは専門家である一方,ユーザーは専門家ではないことがほとんどです。

一方で,何が欲しいのか,何が必要なのか,どうしたいのかを一番よく知っているのはユーザーです。ですが全ての要求を取り入れていると,納期や予算を超過してしまいます。これに対してどういう要求にどういう時間や費用がかかるのか知っているのは,ベンダーとなります。

通常の,それもシンプルな請負契約であれば,注文主が何々を作って欲しいと依頼し,請負人がそれをその通りに完成させるということになります。

しかし,システム開発契約においては,そもそも複雑であること,ニーズの理解が困難であること,さらに予算・納期の制約などからそもそもの注文内容は,両当事者の協力により確定していくという性質をもつことになります。

ここで,ベンダーがユーザーの要求をそのまま聞き入れていたら,予算や納期を超過する事になってしまいますし,かといってユーザーのニーズを全く無視するわけにもいきません。

そこで,ベンダーとしては,ユーザーのニーズを聞き取り,理解して,それを実現するように心がける一方で,その内容が予算や納期などの制約で無理な注文であった場合には,代案を提案するなどしてプロジェクトを頓挫させず成功に導くべき義務がある,ということになります。これを,裁判例はプロジェクトマネージメント義務と呼んでいます

上記の裁判所の指摘で重要なのは,ユーザーの不適切な行為により,プロジェクトが頓挫しないように配慮する義務が,ベンダーにはある,といっていることです。

つまりベンダーとしては,たとえ,ユーザーが不適当な無理な注文をしたとしても,それだけでその後のプロジェクト失敗の責任が回避できるわけではなく,どうして無理なのかを説明し,プロジェクト頓挫を回避できるよう,十分に説得する義務があると思います。

要するに,「今回,このプロジェクトは迷走しそうだけど,クライアント(ユーザー)が無茶なことを言ったせいだ」とは直ちにいえない,ということです(もっとも,そのことについて十分危険を説明すれば,責任はユーザーにうつる余地があります。)。

ただ,説得しようにも営業時点での約束や契約内容などから「それくらいやってくれると思った。営業・担当者が言っていたじゃないか。」ということになる可能性もあります。そういう意味で,プロジェクトを完成にもっていくためのベンダーの義務は,契約後からではなく,契約前の打ち合わせ段階から始まっているというべきでしょう。契約がある程度具体化した段階から弁護士等の関与を求めたり,すくなくとも契約条項について自分側の技術者からの意見を求めたり,その程度の配慮は必要であると思います

IT法務.jpでは,システム開発紛争について,ご相談を承っています。紛争額が小さいなど,弁護士費用にご不安のあるケースでは,従量制や書面作成代行のみでお請けするなど,合理的な報酬を提案しますので,まずはお問い合わせ下さい

(平成24年9月8日,最終更新 平成25年2月2日 弁護士 深澤諭史-なお,免責事項もお読み下さい