受託開発における訴訟リスク対策と弁護士との付き合い方〜【前編】知っておくべきトラブルの争点と、契約時に注意すべきこと

近年、システム開発に関するトラブルや訴訟が増えているらしい。そこで、The board Media 第二弾企画では、受託開発における訴訟リスク対策と弁護士事務所との付き合い方について、GVA法律事務所の弁護士の藤江さんとセッションを行いました。




＊発言者は、F：藤江さん、T：田向

（T）受託開発会社において、クライアントとの契約は基本的に、請負契約と、準委任契約という形態、また委任契約があるとおもうのですが、それについてまず簡単に教えていただけますか。

（F）はい。一般的に請負契約と呼ばれるものは、請負人が仕事を完成させ，注文者がそれに対して報酬を支払うという契約です。これに対して（有償の）準委任契約は、受託者が頼まれた事務を遂行し、委託者がそれに対して報酬を支払う契約です。似ているようですが、準委任契約の場合は、仕事を完成させる義務がなく、作業そのものに報酬が発生するという点に大きな違いがあります。

（T）なるほど。そうすると、準委任契約の場合の訴訟の争点は決められた時間稼働しない、などということになるんでしょうか。

（F）報酬の支払いで争いになった場合、稼働時間が争点になるという場合もありますが、実は、そもそもの前提として「この契約は、準委任なのか、請負契約なのか」ということが争点になることが多いんです。

（T）なるほど。それって最初の段階できちんと合意が出来てなかったということですか。

（T）それが大きいですね。IT業界では、そもそもこの契約の性質は何か？という部分が争点となるケースがよく見られます。もし、それが準委任契約となれば、定められた時間分を稼働していないとか、作業遂行上のミスがあったとかの争点はあるとしても、決められた作業を遂行していれば、その部分については報酬が発生するという話になります。でも、その契約が請負契約となれば、仕事を完成させなければ報酬がもらえませんので、報酬額が0になる場合も出てくることになります。なので、契約の性質を徹底的に争うんですね。

（T）なるほど。受注側は準委任契約だと思って業務を行っていたけれど、支払い側は請負契約だと思っていた、ということが争点になるんですね。
最近、IT業界でトラブルや訴訟が増えているという話を聞くんですが、実際どうなんですか。

（F）はい。おっしゃるとおり近年、システム開発に関する紛争は増えています。その理由を簡単に言えば「IT業界の契約そのものが難しい」ということになりますが、受託開発の契約で、トラブルを招くケースとしては、この3つのパターンが挙げられます。

1. 契約締結前に、作業を開始した（契約書を交わすのを後回しにしてしまうケースです）
2. 契約内容自体があいまいになっている
3. 作業形態に合っていない契約書を交わした（これは先ほどの話と連動しています）

「作業形態に合っていない契約書」の典型事例は、契約書の使い回しをしているケースです。契約書が難しいので、みなさん他社から出てきた契約書などの雛形を転用されるんですね。でも、先ほど申し上げたように、請負契約か準委任契約かというポイントは、争点になるくらいに線引きが難しいものなんです。それなのに契約書をよく確認せずに転用してしまうと、準委任の形で話をすすめていたのに、契約書は請負契約になっていたということが発生したり、作業内容に合っていない契約になっていることが多い。

（T）そうなんですか。「完成しなかった」「仕様が違う」といったケースが主というイメージでいたんですが、契約そもそもの性質が争点になるんですね。

（F）はい。また、契約の性質という話からは逸れますが、「完成しなかった」ということが争点になるときも実は契約書に不備がある場合が多いと思います。その場合の契約不備の最大のポイントは、要件定義、仕様が書面上で固まっていないことです。先ほどのパターンでいえば、2のパターンになります。

（T）要件定義書を作成して、それに対して発注書をかわすだけだとだめですか？あまり重くない案件だと、発注書を交わすだけで終わらせてしまったりするのですが、それは、問題ですか？

（F）そうですね、発注書の内容にもよるのですが、発注書を受け取って仕事を受注した、というケースでは、何をどういうレベルでやってもらうか、という点は何も決められていない場合がほとんどです。一番問題なのは、開発対象が明確に記載されていないことで、発注書でいえば、「●●に対するシステム開発」という一行だけしか記載されていないもの。

（T）はい…（苦笑）

（F）すると、書かれている内容が抽象的なので、発注者としては要望を追加しやすくなりますし、受注側は本来追加報酬を請求できる事項でも、曖昧なままに当初の開発スコープの中に組み込まれてしまって、追加報酬の請求に関して交渉が難しくなったりします。

（T）機能が多いときはなかなか全部なんてかけないから、一行はないかもしれないですが、大きな固まりで数行にわたって発注書に書いたりしてしまいますね。
「●月●日付けの要件定義書を元にします」と記載しておくだけでもだめですか？

（F）発注書に要件定義書を添付しておけば、状況的にかなりクリアーになってきます。要件定義書の内容がはっきりしていれば、そこに記載のない事項は追加で報酬を請求することができる、また記載されている事項は完遂する義務がある、ということになりますからね。

（T）なるほど。ちなみに発注書と個別契約書ってどう違うんですか？
 
（F）個別契約書と発注書は、単に名称の違いだけで、法律的にみればイコールに扱われることが多いです。システム開発では、通常、開発着手前に基本契約が交わされると思うのですが、基本契約というのは、システム開発全体での共通事項を定めているものです。これに対して個別契約は、基本契約に従いながら、個々の案件の詳細を定めましょうというものです。実務上使用されている発注書は、そういう個々の案件を記入していることが多いですよね。

（T）内容として必要なことが定められていたら、発注書でも問題ないということですか。

（F）はい。名目はどちらでもかまいません。

（T）何をやるのかがきちんと定義されていて、残っている、ということが非常に重要ということですね。お客様と要件定義書をメールでやりとりするだけでは、足りないんでしょうか。

（F）想定される状況にいろいろなバリエーションがあるので、答えるのが難しいところなんですけれど、大事なことは、個別契約や発注をかけている段階で、開発対象とその範囲がはっきりしているということです。なので、開発着手段階で、要件定義書が確定されたという旨のメールのやり取りが残っていれば、それは大事な証拠になります。逆に、要件定義書がなかったり、曖昧な内容にしかになっていない場合、その明確になっていない部分を推測するためにメールのやり取りを見ることはよくあります。ですが、あくまで推測できるといった程度であって、はっきりした定義書が残っていて欲しいなと思うところです。

（T）なるほど。やはり原則は、個別契約書と要件定義書がセットである状態であるべき、ということですね。知り合いの会社で、過去のメールを頑張って探していたということは聞いたこともあります（笑）


（T）仕様を決定して、契約するのは、ウォーターフォールで開発するときはやりやすいと思うのですが、アジャイルのときは開発範囲が大まかに決まっているものの、明確な詳細事項は定まっていないですよね。今のお話からすると受注側としては、リスクが大きいと思うのですが、その場合は請負契約を結ぶことが多いんでしょうか。

（F）アジャイル契約に関しては、実は、実務上の運用も必ずしも一定に定まっているわけではありません。ただ、ベンダーとユーザーのやり取りが非常に多岐にわたっており、その中で要件が決まっていくという性質があるので、一定程度の段階を経たら要件が確定する、その確定するため条件を契約書に明記しておくことになります。ですので、基本契約を最初にまいて、あとで個別契約をまきます。これはウォーターフォールとほとんど変わりません。ただ、たとえば特定の機能群を開発するための個別契約を締結する時期は、その開発スコープが確定した時期ということになります。

（T）へぇ！じゃぁ、開発の前段階でどういう要件にするか、という話をしているときは、開発するための個別契約の締結前ということですか？

（F）はい。前になります。その場合は、準委任契約を合わせて適用するケースもけっこうあります。開発スコープが確定すれば仕様が確定するので、その範囲に対して、請負の適用が可能です。それ以外の、ただ仕様を決めていく作業、一緒にクリエイトしてく作業については、はじめから成果物を確定して、それを提供することができない。ですから、報酬形態が作業ベースになりますね。それは性質上、準委任契約としておく方がよいでしょう。要するに、フェーズごとに、請負契約と準委任契約を使い分けられるようにしておくことが実態に合わせやすいと思います。

（T）なるほど。分ければいいんですね！！それいいですね。
アジャイルの契約条件の設定は、いつも非常にむずかしくて、見積もりもしっかりできないので、結局「人数を確保しておきます」という話になったり、発注側も予算がとりにくかったりしていました。金額の話は双方が納得したとしても、どっからどこまでが請負なんだろう、ということがいつもひっかかっていて…
非常にクリアーになりました！これから、そうしたいと思います。


（後編を読む）