ITには機能追加がつきもの
そもそもITの素人であるユーザの担当者と業務の素人であるベンダの技術者が、絵に描いただけの新業務を想定して、まだ見ぬシステムに持たせるべき機能を定義しようというのが機能要件定義ですから、これを最初から不足なく定義するのはドラえもんでもいない限り至難の業でしょう。開発の現場では、どうしても「やっぱり、この機能もほしいなあ、「えっ？こういう画面を作ってくれるんじゃなかったの？困るよ。」 というエンドユーザの声を聞かざるを得ないのが現実です。
要件定義も終わって、さあ設計だ、プログラミングだと走り出したいベンダの技術者や、あとはベンダに任せられるかな、と密かに休日の計画を練り始めるユーザ企業のシステム担当者からすると 、エンドユーザのこうした不満や要望は、“後出しじゃんけん” のようで納得いかないこともありますが、「その機能なしじゃあ、システム化の目的を果たさないよ。」 と言われれば、スケジュールや要員をやりくりしなおして、もう一度要件を考え直さなければなりません。いつまで経っても苦労が絶えませんが、悲しいかな、それがITというものです。
要件追加についての判例
今回は、そんな要件の追加に係る判例をご紹介しようと思います。まずは事件の概要から見ていきましょう。この判決は当連載の第四回 「システムの要件定義とは」でもご紹介したのですが、今回は要件の追加と、それに基づく費用の算定について述べている部分について取り上げます。
【要件の追加に関する裁判の例】
(東京地方裁判所 平成17年4月22日判決より抜粋・要約)
あるシステム開発会社(以下 ベンダ)は書籍の管理・配送業者(以下 ユーザ)から書籍在庫管理システム(2325万円)の開発を受託し作業を開始したが、開発中にユーザの要望が増大し、当初182としていた機能数が414に増加した。
この開発の契約には「作業着手後の機能追加，変更等により工数に大幅な変動が生じた場合は別途相談させていただきます。」との特約があり、ベンダはこれに基づいて機能追加作業を行ったが、結局開発を完遂しないまま撤退した。
ベンダは開発費として当初分と追加分の5568万円を請求したが、ユーザは追加開発には正式に合意していなかったこと、ベンダが途中で撤退したことを理由に支払いを拒み訴訟となった。
少し補足をすると、この機能追加に当たっては、ユーザが機能追加の要望を出してはいますが、正式な追加開発合意は行われていません。ユーザの主張は、正式な発注を行っていないのに勝手に作業し、ましてシステムは完成もしていないのに費用など払えないというものです。一方、ベンダの主張は、契約の特約に”別途ご相談”とある以上、要望があれば開発は行うし費用も頂くというものです。
