仕様の未確定はベンダーのプロジェクトマネジメント義務違反か?
東京地方裁判所 令和3年11月25日判決
本件契約締結前に作成した(中略)見積書の各項目は、幅のある内容であり、(中略)本件ソフトウェアは、いわゆるアジャイル型の開発が企図されていたのであり、本件契約の締結に当たり、本件ソフトウェアの仕様が予め確定していたわけではないと認められる。
(中略)
本件ソフトウェアの仕様については確定しないまま本件契約を締結していることからすれば、その後の本件ソフトウェアの仕様の確定に当たっては、実装作業に伴う費用が業務対価に見合うよう、仕様または追加の業務対価を調整する必要があることが予め想定されていたというべきであり、単に(発注者が)その希望する仕様を(受注者に)伝達すれば、それをもって本件ソフトウェアの仕様が確定するというものであったとは認め難い。
事件番号 平30〔ワ〕25117
この連載の読者の中には、開発ベンダーの「プロジェクトマネジメント義務」という言葉を想起された方もいらっしゃるかもしれません。開発ベンダーはITの専門家として、ユーザーの振る舞いがプロジェクトの進行に影響を与えるなら、これをリスクとして説明し、なんらかの対処をしたり、促したりする義務があるというものです。たとえば、ユーザーがいつまで経ってもシステムの要件を決めずにプロジェクトが破綻した場合、その責任はベンダーにもあるというものです。
このケースは、まさにそうした義務違反の典型にも見えますが、一方では異なった考え方も成り立つように思えます。法律の解釈論のようになってしまって恐縮ですが、プロジェクトマネジメント義務違反というのは、あくまで契約の履行、つまりユーザー側の「契約の目的に資するシステムの完成」を前提にしたものです。ところがこの事件の場合、その契約の目的に資するシステムとはどのようなものかといった点が不明だったのです。
この連載でも、これまでベンダーのプロジェクトマネジメント義務違反については何度か取り上げてきました。しかし、本義務が認められたプロジェクトというのは、この開発がどのような目的(業務効率化やコスト削減、顧客満足度向上など)で実施され、そのために必要なシステム化要件がどのようなものであるのかが明示的・黙示的に定められたものであったように思います。
ところが、この事件の場合は、目的のためのシステム化要件(概要の業務要件など)が不十分なまま進められていたようです。そうなると、いったい何を目指すプロジェクトマネジメントなのかが不明確であり、結果としてプロジェクトマネジメント義務は問えないのではないか……。そんな考え方も成立するかもしれませんし、一方で、「そうは言っても素人のユーザーは、要件が不確定であることの真の影響を理解できなくても仕方がない。それはベンダーがガイドすべきことであり、プロジェクトマネジメント義務はやはりあったはずだ」との意見もあるでしょう。
さて、では裁判所はどのように判断したのでしょうか。判決の続きを見てみましょう。
この記事は参考になりましたか?
- 紛争事例に学ぶ、ITユーザの心得連載記事一覧
-
- アジャイル開発にありがちな、途中でコロコロ変わる発注側の要望……仕様が未確定のまま納期を過...
- 裁判所が重視するプログラムの「新規性・独自性」とは? 自社のプロダクトを守るために知ってお...
- 「ユーザー側の態度」が破綻したITプロジェクトの予後を左右する──“野村HD vs 日本I...
- この記事の著者
-
細川義洋(ホソカワヨシヒロ)
ITプロセスコンサルタント
経済産業省デジタル統括アドバイザー兼最高情報セキュリティアドバイザ
元東京地方裁判所 民事調停委員 IT専門委員
筑波大学大学院修了(法学修士)日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステム...※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
