© 2016-2019 ILRI

Please reload

最新記事

ITエンジニアが裁判例から学べる教訓 第4回「ベンダーはユーザー業務を知っているべき?」​

July 24, 2017

1/4
Please reload

特集記事

ITエンジニアが裁判例から学べる教訓 第4回「ベンダーはユーザー業務を知っているべき?」​

July 24, 2017

弁護士・ITストラテジスト

仕様変更の話が続きましたが、そもそも、仕様変更があるべき機能がないと主張されてしまった(ユーザーからすると当然あるべき機能がない)場合にどのように考えるべきか、裁判例をみてみましょう

 

■東京地判平成16年6月23日公刊物未登載(West Law Japan)

 

旅行業等を行うユーザーが、自己の既存のウェブサイトに航空券の申込みや決済などの機能を追加することを目的として、ベンダーに開発を委託しました。

しかし、このシステムには「遠隔操作機能」という重要な機能が欠けていました。この「遠隔操作機能」というのは、判決からはやや読み取りにくいのですが、航空券の価格などのサーバーに保存されているデータをユーザーが遠隔で変更する機能のようです。航空券の値段などは、日々刻々と変動するものですから、価格などのデータを変更できる機能というのは、航空券のオンライン販売をするのであれば不可欠なものといえます。

 

この「遠隔操作機能」は仕様書に記載がなかったのですが、裁判所は、上記のように、遠隔操作機能がユーザーの業務に不可欠なものであること、契約締結に先立って、遠隔操作機能が不可欠なものであることがベンダーに伝えられ、了解されていたこと、システムの構成図等のプロジェクト資料にも遠隔操作機能を示す記載がされていることを挙げて、遠隔操作機能を開発するとの合意が口頭で成立していたとしました。

 

このシステムは、オンライン決済の機能がしばしばフリーズし、過去1年間の「決済成功率」が32.5%(89件中29件)(!)でした。裁判所は、このように決済機能が十分機能しないことや、上記のように遠隔操作機能がないことから、このようなシステムでは、ユーザーは契約の目的を達したことにはならず、本システムは、欠陥が著しいものであり、未だ完成したものとはいえないとして、ベンダーに対して、既払報酬をユーザーに返還するよう命じました。

 

 

10年以上前のプロジェクトとはいえ、非常に問題が多いシステムだったようです(なお、拡張性の問題で、遠隔操作機能を追加することもできなかったと認定されています)。

ただ、仕様書に記載がないにもかかわらず、遠隔操作機能が仕様に含まれるとされたこと、さらに、もちろんそれだけが理由ではないものの、遠隔操作機能がないことをもって、システムの完成が否定されたというのは、ベンダーにとってはなかなか厳しい判断といえます。このような判断は、ベンダーはユーザーの業務を理解しているべきということを前提にしているように考えられます。

 

次に、逆に、ユーザーが重要な機能がないと主張したにもかかわらず、システムの完成を認めた事例をご紹介します。

 

■東京地判平成28年4月1日公刊物未登載(West Law Japan)

 

このケースは、ユーザーが弁護士で、ベンダーである被告に対して、「集団訴訟管理システム」というシステムの開発を委託しました。ベンダーが、システムを納入したところ、ユーザーは、「係属裁判所」(訴訟を審理している裁判所)や「事件番号」(訴訟の事件ごとに振られる番号)の入力項目がなく、これらによって事件を検索する機能がない、文書のひな形のダウンロード機能がないなどとして、システムは未完成であると主張しました(具体的には既払報酬についての損害賠償等を請求しました)。

 

裁判所は、「『集団訴訟(管理)システム』というだけで、必然的に係属裁判所、事件番号等の入力項目が導かれるものではない」とした上で、「日頃、裁判実務に携わっている者には自明のことであっても、そうではない被告らにとって、このようにいえるとは解されない。要するに、本件契約の内容として、係属裁判所、事件番号等の入力項目を設け、これらにより事件を検索する機能を持たせるようにするためには、原告がその旨を明確に指摘し、被告法人と協議したことが必要であると解されるところ、このような事実があったことを認めるに足りる証拠はない。」としました。

 

口頭でのやり取りがあったことも認定されていないという点で、先ほどの事件とも異なりますが、この判決は、ユーザーが明確に指摘しなければ検索機能を開発するとの合意があったとは認められないとしており、少し判断の仕方が異なっています。航空券等のウェブ予約という先ほどの事例と比べて、「訴訟の管理」という業務が一般的なものではないことが影響しているように思います。

 

ユーザーの業務は本来的にユーザーにしか分からないものであり、「注文者側がどのような内容のソフトウェアの開発を望んでいるかを提示又は説明する責任は、注文者側にそのような能力がないことが前提になっているなどの事情がない限り、注文者側にあると考えられるので(東京地判平成22年7月22日判例時報2096号80頁、本コラム第2回参照)、ベンダーはユーザー業務を知っている必要はないというのが原則であるはずです。ただ、その機能がなければ業務が回らないことが明らかなケースでは、仕様書にその機能が記載されていないとしても構築義務がある(記載漏れはベンダーが責任を持つ)という議論も十分成り立つと思います。特に、ベンダーが特定業界でのシステム構築について経験を持っており、ユーザー業務に精通していることが期待されている場合には、ベンダーが責任を負うべきとされる可能性は高くなると考えられます(もちろん、ユーザーの力量やユーザーがどのような資料を出していたかといった事情にも左右されます)。

 

 

業務あってのシステムですから、ベンダーもユーザーも、このシステムで業務は回るのかを考える必要があるということです。たとえベンダーが作成した仕様書であっても、プロジェクト・オーナーであるユーザーの責任で確認し、承(否)認すべきといえます。

 

 

参考文献 「裁判例から考えるシステム開発紛争の法律実務」(共著)(商事法務、2017)

*今回取り上げた東京地判平成16年6月23日については、参考文献の142頁にて取り上げています。

 

 

 

 

 

Share on Facebook
Share on Twitter
Please reload

ソーシャルメディア
Please reload

タグから検索
Please reload

アーカイブ
  • Facebook Basic Square