© 2016-2019 ILRI

Please reload

最新記事

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

July 24, 2017

1/4
Please reload

特集記事

ITエンジニアが裁判例から学べる教訓 第2回「プロジェクト・マネジメント義務-ユーザーからの追加要望」​

March 10, 2017

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

前回(第1回)でご説明したベンダー側のプロジェクト・マネジメント義務とユーザー側の協力義務について、少し長いですが、以下の事例(裁判例)をもとに考えてみましょう。

 

■東京地判平成22年7月22日判例時報2096号80頁

 

人材派遣に関するマッチングサイトを運営している事業者(以下「ユーザー」)が、その運営サイトを改良することを企画し、あるベンダー(以下「ベンダー」)に対して依頼をしました。ユーザーとベンダーは十数回の打ち合わせを行い、その打ち合わせを踏まえて開発範囲を定めたシステム設計書が作成され、業務委託契約が締結されました。

このとき、ユーザーが、マッチング機能、シフト管理機能、勤怠評価機能、課金機能等を備えたものにしたいという要望をもっていたことをベンダーは理解していましたが、契約締結までの打ち合わせの内容から、本件プロジェクトで作成するシステムはマッチングサイトであり、シフト管理機能、勤怠評価機能、課金機能等については契約金額の範囲内に収まる程度のものにすれば足りるだろうと考えていました。

 

このようにして開発が開始されたのですが、ユーザーは、ベンダーから交付されたシステム設計書の内容は不十分であるなどとして、その承認を拒絶しました。また、ユーザーは、開発期間中も社内で新しいサイトを利用したビジネスモデルについての企画会議を重ねており、新しいビジネスモデルを考えつくたびに、ベンダーに要求事項を追加していきました。

 

このようなユーザーの追加要求を受け、ベンダーは、要求事項が確定した部分を「確認書」という形で書面化し、その部分についてプロトタイプを製作していくことで、開発すべきソフトウェアの仕様について合意ができるようにしようとしました。しかし、ユーザーはベンダーが作成した確認書では内容が不十分であるとして承認を拒絶しました。

 

このような開発状況のまま約2年が経過してしまい、要求事項は膨大なものとなりました。このプロジェクトは、当初の見積もりでは630万円でしたが、この段階では、外注先への外注費の見積もりだけでも約3400万円に上るものとなっていました。ベンダーは、工数・開発費の増加を吸収することはできないと判断し、ユーザーに対して追加費用の支払いについての申し入れをするとともに、システム機能の削減を提案しました。しかし、ユーザーの社長は、ベンダーの機能削減案について、「不要な機能はない」と述べ、追加費用案については、「金額(引用注:開発コスト)が増えたことは関係ない。どんなに金(引用注:開発コスト)が掛かろうがすべて本件契約の範囲内であるという認識なので、このままやるべき」と述べて、いずれの提案も拒絶しました。

 

これを受けて、ベンダーはユーザーに対して、ユーザーによる追加支払の拒絶や仕様確定の遅延は信義誠実の原則に反するなどとして、契約を解除すると通知し、プロジェクトは中止となりました。これに対して、ユーザーは、ベンダーが契約に基づく債務を履行しなかったと主張して、損害賠償を請求する訴訟を提起しました。

 

判決-ベンダーは過大な変更要求に応じる義務はない

 

以上のような事実関係のもとで、裁判所は以下のように述べて、ユーザーの請求を棄却しました(ベンダー勝訴)。

 

「ソフトウェアの開発は、注文者側と請負人側との間で開発すべきソフトウェアの性能、仕様、形態等に関する具体的なイメージを共有するため、注文者側の技術担当者と請負人側の技術担当者との間に密接な協力関係があることが必要不可欠であるところ、特に、開発の出発点である要件定義を確定する工程については、注文者の要求をまとめる工程であると定義されるとおり、注文者側の意向によってその内容が決せられることになるのであるから、注文者側がどのような内容のソフトウェアの開発を望んでいるかを提示又は説明する責任は、注文者側にそのような能力がないことが前提になっているなどの事情がない限り、注文者側にあるというべきである。・・・・また、一般に、要件定義が定まらない時点で締結されるシステム開発に係る契約については、開発規模それ自体の大きさなどを想定して契約金額が決められるのであるが、契約当事者間において開発内容を具体化していくその後の打合せにおいて、備えるべき新たな機能の追加など、当初の契約段階で客観的に想定されていた開発規模を超える内容のシステム構築を注文者が求めたような場合には、契約当事者の合意の基礎となった事情に変更が生じているのであるから、注文者は、上記内容のシステム開発を当初の契約金額の範囲で受注者に対して製作することを求めることはできないものと解すべきである。

・・・そうすると、本件契約が履行不能となったのは、原告(引用注:ユーザー)において、被告(引用注:ベンダー)との打合せのたびに新たな要求事項を追加するなどして、本件ソフトウェアの要件定義を確定させようとしなかった上、被告(引用注:ベンダー)からされた追加費用の負担の提案にも一切応じようとしなかったことに最大の原因があると考えられる。そうだとすれば、被告(引用注:ベンダー)に債務不履行(履行不能)の原因があるということはできないというべきである。」

 

裁判所は、要件定義工程において、仕様を提示または説明する責任は、注文者側(ユーザー側)にあると述べています。そして、ユーザーが当初の想定を超える開発を求めた場合には、合意の基礎となった事情に変更が生じているのだから、当初の金額の範囲内で開発を求めることはできず、ユーザーの求めるものを開発できなかったとしてもベンダーに帰責事由はないとしています。判決でも述べられているように、どのようなシステムを構築すべきかはユーザーの意向次第ですし、本件のユーザーの態度には問題があったといえますから、このような判断は妥当というべきでしょう。

 

膨大な要求を繰り返すユーザーに対してベンダーはどうすべきか

 

本件は、ユーザーが膨大な追加要求をした結果、開発規模は、少なくとも当初の想定の5~6倍以上にまで膨れあがりました。しかし、ユーザーの社長は、ベンダーの機能削減案について、「不要な機能はない」と述べていたということです。

 

このように開発規模が大きく膨れあがったとしても、ユーザーからは、全てが必要な機能であると主張されることがあります。実際のところ、システムがどのような機能を備えているべきかというのは、ユーザーの業務の内容に依存するもので、予算や開発スケジュールなどによって、優先順位を付けて開発の要否を検討していくものです。したがって、全ての機能が必要であるという主張はナンセンスであるといえます。

 

しかし、一方で、ユーザーの追加要求について、個別の機能ごとに、これは妥当な要求であった、これは妥当な要求ではなかったと判断していくのは現実的ではありません。この判決では、ユーザーの要求内容が、当初想定されていた開発規模(予算・スケジュール)から大きく外れたものとなっていたという一種の定量的な判断の枠組みを用いているようです。具体的には、当初の見積もりが630万円だったにもかかわらず、最終的には外注費だけでも約3400万円になっていたということですから、ユーザーの要求が過大だったことは明白でしょう。

 

このように考えると、当初想定されていた開発規模(予算・スケジュール)をどのように証明するかというのがポイントになることが分かります。通常のプロジェクトであれば、見積書やマスタースケジュールを作成され、そこから予算やスケジュールが分かると思いますが、単に金額や期間のみを記載するのではなく、その金額や期間がどのような前提で見積られたものであるかを分かるようにするということが重要であるということになります。

 

例えば、本件では、ベンダーは、ユーザー側が、マッチング機能、シフト管理機能、勤怠評価機能、課金機能等を備えたものにしたいという要望をもっていたことは理解していたものの、契約締結までの打ち合わせの内容から、本件プロジェクトで作成するシステムはマッチングサイトであり、シフト管理機能、勤怠評価機能、課金機能等については契約金額の範囲内に収まる程度のものにすれば足りるだろうと考えていた、ということですが、書面上はそのような前提を置いていたことは明確になっていなかったようであり、そのような曖昧さが紛争をもたらしたように思われます。

 

このように、予算の金額自体は明確ではあるが、どのような前提で見積もられたものかは明確ではないというケースは多いものと思われます。見積書やマスタースケジュールを作成する際に、その文書からどのような前提を置いているのかが分かるようになっているか、一度考えてみることが大切であるといえます。

 

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

*今回取り上げた東京地判平成22年7月22日については、参考文献の110頁、111頁、114頁にて取り上げています。

Share on Facebook
Share on Twitter
Please reload

ソーシャルメディア
Please reload

タグから検索
Please reload

アーカイブ
  • Facebook Basic Square