ITの開発をベンダーが受注するとき、他の工程はともかく「要件定義」つまり、どんなシステムを作るのかを定義する工程だけは、準委任契約で行うことが推奨されています。

請負契約というのは、納品する成果物を完成させる義務を受注者であるベンダーが負うことになる契約ですが、要件定義工程の成果物である「要件定義書」や「仕様書」と呼ばれるものが本当に完成したのかどうかというのは、実際のところ曖昧で、システム構築が終わってみないと分からない場合すらあるわけです。

例えば、顧客であるユーザーから、「WEB上で注文を受けるシステムを作ってほしい」と言われ、では要件定義から始めましょうと、「ログイン」、「商品カタログ表示」、「商品選択と注文」、「決済処理」なんて機能を要件として定義したとします。ベンダーは顧客のいろんな部門からヒアリングをして、これらの機能が必要だろうと考え、要件として定義したわけですが、実は、ここに抜けがあり、「顧客情報管理画面」がないなんてことが後になって発覚した、そんなことがあったとします。しかもこのことには、ユーザーサイドも気づかずに、要件定義書が納品されてしまい、もう実際の開発が始まった後で抜けに気付いたとなると、もう一度、顧客のヒアリングから初めて、要件を見直し、設計やプログラミング、テストまでやり直すなんてことになって、膨大な手戻り工数が発生することもあるわけです。実際、こんなトラブルのせいで、数億円、数千億円をどぶに捨てるなんてプロジェクトもあったりするわけでえす。

この場合、客観的に見れば、むろん、当初の「要件定義書」には不備があり未完成ということになるのですが、要件定義工程が請負契約である場合と準委任契約である場合では、責任の所在が大きく異なってきます。

準委任契約の場合、ベンダーは基本的に成果物、つまり要件定義書の完成義務は負いません。ベンダーは、専門家としてのスキルを発揮して約束した時間、ちゃんと働けば、顧客の指示の下作り、納品された要件定義書を作り直す義務はないことになります。（実際には追加費用を貰って修正することが多いとは思いますが。。。）そして、不備な要件定義書を元に作ったシステムに機能の欠落があったとしても、それは要件をちゃんと伝えなかったユーザーが悪いということになり、膨大な手戻り工数の為に係る追加費用も原則はユーザーが持つことになります。

ところが、これが納品物の完成義務を負う請負契約の場合、ケースバイケースではありますが、ユーザーにきちんとヒアリングをせずに欠落のある要件定義書を作ったのはベンダーの責任だし、その結果システム開発がうまくいなかい責任もベンダーが悪いということにもなりかねないわけです。全く、同じ作業を行って、同じようにミスをした結果なのに、契約形態が違うだけで、ベンダーが膨大な費用を出さなければならないこともあるわけです。

もちろん、こうしたことは、その時、その時の事情によって変わり、いつも同じ結果が出るとは限らないのですが、やはりベンダーが要件定義工程を請負で行うのは相当なリスクを伴うということになるでしょう。以下の訴訟解説では、そのあたりのことを実例を交えてお話しています。インターネットサービスプロバイダを営むユーザーが、システムの完成後に、いやいやISPなんだからアクセス解析の為の統計ツールが必要なことは、分かってたでしょ？と要件になかった機能を後出しじゃんけんのように言い出した事案なのですが、さて、裁判所はどんな判断を下したのでしょうか？

製造工程に入ってるけど、やっぱこの機能も追加してくださーい：「訴えてやる！」の前に読む IT訴訟 徹底解説（91）（1/3 ページ） – ＠IT (itmedia.co.jp)

IT開発雑記帳一覧に戻る