見積もりに合意してないから、要件追加分のお金は払いません！：「訴えてやる！」の前に読む IT訴訟徹底解説（22）（2/3 ページ）

» 2015年12月08日 05時00分公開

正式な合意のない追加作業についての裁判所の考え方

　判決の前提として、裁判所は以下のように述べた。

東京地裁平成15年5月8日判決より抜粋して要約（続き）

　本件のようなシステム開発作業においては、作業を進める中で当初想定していない問題が明らかになったり、より良いシステムを求めて仕様が変更されたりするのが普通であり、これらに対応するために追加の費用が発生することはいわば常識であって、追加費用が発生しないソフトウエア開発など希有（けう）であるといって過言ではない（以下略）

　システム開発では要件の追加・変更が発生するのが常識であって、本件もそれを考慮して判断しなければならないと言っている。IT業界の特殊性を裁判所も認識しているということだ。

　こうした前提を踏まえ、判決は以下のように続く。

続きを閲覧するには、ブラウザの JavaScript の設定を有効にする必要があります。

定形外業務も自主的に調べるのがベンダーの努めです
東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、契約内容に盛り込まれていない「オペレーターがデータベースを直接操作する機能」が実装されていないと支払いを拒否されたベンダーが起こした裁判を解説する
締結5日前にユーザーが白紙撤回！契約は成立？不成立？
ユーザー窓口が確約した「○月○日に正式契約しましょう」を信じて一部作業に事前に着手したベンダーは、突然の契約白紙撤回に泣き寝入りするしかないのか？
ベンダーが確実に支払いを受けるための3つのポイント
検収書だけでは不十分？――ユーザーから確実に支払いを得るために、ベンダーがやるべきこととは何だろう？
そもそも要件定義って何なのよ
ITシステムの要件定義では、対象業務のフローや入出力を決める「業務要件」とシステムが持つべき機能を定める「機能要件」、システムの速度や容量、使い勝手やセキュリティなどを定義する「非機能要件」について、ユーザーとベンダで徹底的に議論することが大切です
「要件定義書のアウトライン作成」完全マニュアル
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する