ここから本文です

仕様書と通信方法が違うから、1銭も払いません!――全ベンダーが泣いた民法改正案を解説しよう その2

@IT 10/5(水) 11:52配信

 2017年に施行が見込まれる民法改正案がIT業界に与える影響について解説する3回シリーズ、第1回は「消える瑕疵担保責任という考え方」を解説した。

【あなたに発注したアプリ、アップルの審査を通らなかったので支払いを拒否します!(画像はイメージです)】

 前回も述べたが、本改正がIT開発契約に深く関連すると思われるのは、以下の3点だ。


1. 成果物の「瑕疵(かし)担保責任」という考え方がなくなる
2. 請負契約において、約束した成果物を納めなくても、請負人が支払いを受けられる場合が出てくる
3. 成果物の納品を前提とした準委任契約ができるようになる。

 今回は「2」の「請負契約の支払い」に関する条項を見ていく。「約束した成果物を全て納めなくても支払いを受けられる」とはどういうことだろうか。

関連リンク

 民法(債権関係)の改正に関する要綱案(法務省)

●成果物の一部納品でも費用を請求できるのか?

 まずは改正案を見てみよう。

---
第六百三十四条

次に掲げる場合において、請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成と見なす。この場合において、請負人は、注文者が受ける利益の割合に応じて報酬を請求することができる。

一 注文者の責めに帰することができない事由によって仕事を完成することができなくなったとき。

二 請負が仕事の完成前に解除されたとき。
---

 今までは、請負開発とは「完成した成果物を全て引き渡すことにより報酬を請求できる」というのが原則だった。

 もちろん実際の現場では、成果物に多少の欠落があっても、報酬の一部か全額かを支払われることはあったが、法律上は、約束した機能の99%を作り上げても、残り1%の未完成を理由にユーザーが支払いを拒むこともできたのである。

 以下のような判例も出ている。

●未完成のシステムの報酬に関する判例

---
●東京地方裁判所 平成26年10月28日判決から

あるアプリ開発会社が、iPhone用アプリ(本件アプリ)の開発を委託された。

アプリは、個人の年収や貯蓄金額を他者と比べて勝ち負けを競うゲームであり、それに加えて、ゲーム参加者の貯蓄や年収のランキングをインターネット上で表示するものであったが、参加者同士が、互いの情報を見られるようにBluetoothを使用した直接通信をすることも可能とする仕様だった。

しかし、Bluetooth付きの機能は、アップル社による審査に通らなかった。このため、委託企業とアプリ開発会社は、通信方式をインターネット経由に変更して開発を行い、App Storeからリリースされた。

ところが、委託者は、アプリ開発会社が見積もりに記載したBluetooth機能が実装されていないことを理由に請負代金168万円の支払いを拒み、開発会社が、その支払いを求めて訴訟になった。

※筆者注:Bluetooth通信は、開発中より委託者の懸念するところであった。しかしアプリ開発会社が、アップル社の審査に至るまでこの方式に拘泥し続けたという事実もある
---

 Bluetoothによる通信はできなかったものの、アプリ自体はリリースされている。私のようなベンダー出身者なら、「アプリは完成したと見なし、Bluetoothの部分だけ減額すればいいのでは」と考えてしまうだろう。

 しかし裁判所が下した判決は、次のようなものだった。

---
●東京地方裁判所 平成26年10月28日判決から(続き)

アプリ開発会社は、(中略)インターネット通信とBluetooth通信とが併記された本件見積書を提出しており、(中略)また、本件契約においても、本件アプリの対戦に関し、通信方法などについては、(中略)Bluetooth通信のみが例示として挙げられ、Bluetooth通信を本件アプリ上から起動するよう目指すことが合意されたものと認められる。
---

 裁判所は、「両者の合意(見積もりや契約)から鑑みるに、Bluetoothによる通信は必須であり、インターネット通信のみのアプリは成果物とは見られないので費用の請求はできない」と判断した。

 当然、アプリ開発会社は、使用可能なものを納品している。しかし、Bluetooth通信という一部の機能がないことで、全ての成果物を否定されてしまったのだ。

 裁判所の考え方の問題ではない。旧来の請負契約が「契約した成果物全て」の納品を前提としている以上、こうとしか判断できなかった、ということだ。

●改正で何が変わるのか

 アプリ開発会社の反省点は、「Bluetooth通信では審査が通らないと分かった時点で、インターネット経由の対戦を前提にしたアプリとするよう、契約と再見積もりを行うべきだった」ということになる。

 しかし、ベンダーが流した汗が全く認められない法律は、いささか酷ではないだろうか。今回の改正は、こうしたことも踏まえたものと推察される。

 改正法案では、たとえ一部の機能でも、それが「契約の目的」に照らして「ユーザーの利益に寄与する成果物」であると認められれば、その割合に応じて費用が請求できることになる。

 また、上流工程で作業が中止した場合も、それまでに作った画面設計書やデータベース設計書が、「他で流用可能」な程度に完成していれば、その分の費用を請求できることになるのだ。

 最初からプロジェクトの中断を前提に仕事をするベンダーはいないだろうが、もしものときのことを考えると、この改正はベンダーにとって「画期的」だ。

●確実に支払いを受けるために、ベンダーが心掛けるべきことポイント

 システム開発を請け負うベンダーが今後心掛けるべきは、1つ1つの成果物の完成度を高め、単体でも何らかの役に立つようにしておくことだ。

 プログラムであれば、なるべくプログラム同士の結合強度を弱くして、(カプセル化など)シンプルな引数のやりとりなどで第三者でも使える作りにしておくことだ。

 「Javadoc」のようなプログラムの説明やプログラム中のコメントも、他人から見て分かりやすいものを作っておきたい。途中で終わったプロジェクトを別のベンダーが引き継ぐようなときに、そのまま使えるプログラムであれば、立派な成果物となる。

 設計書や要件定義書は他人から見て分かりやすい物にしておく。ユーザーとベンダーの間で分かりきっているような事項もしっかりと書き込み、言葉の意味が第三者から分かるように「用語説明」を加える。作りかけのシステムや対象業務の理解を助ける「チャート」や「表」なども作っておきたい。

 これらを心掛け、誰もが理解できるような成果物を準備しておけば、今回の改正のメリットを十分に享受できるだろう。

 一方で、せっかく汗をかいてモノづくりを行っても、そして、それが非常に価値の高いものであっても、第三者が見て理解できないようなモノであれば成果物とは認められず、従来と同じように報酬の支払いを全く受けられない危険もある。

 「言葉は、話す人の口で生まれるのではなく、聞く人、読む人の心の中で初めて形作られる」――そんな意識を持って、開発に臨んでいただきたい。

編集部より:初出で判例の年月日を誤って記載しておりました。お詫びして修正いたします(2016/10/6)。
事実を鑑み、一部削除いたしました(2016/10/13)。

最終更新:10/13(木) 14:52

@IT

TEDカンファレンスのプレゼンテーション動画

「水中に潜む本当の危機」
インドガリアルとキングコブラはインドの象徴ともいえる爬虫類ですが、水質汚汚濁のために存亡が危ぶまれています。環境保護者のロミュラスウィトカーがこの素晴らしい動物たちの貴重な映像をお見せして、彼らのそして私達の生活を支えている川の保全を訴えます。