追加仕様と追加機能と追加費用の関係・・搾取構造？

あるある、でしょうね。

丸投げしたんだから、頑張ってくださいよ（作業量は増えたけどね）：IT訴訟解説
https://news.mixi.jp/view_news.pl?media_id=39&from=diary&id=5679551
丸投げしたんだから、頑張ってくださいよ（作業量は増えたけどね）：IT訴訟解説 3
2019年06月26日 07:12 ＠IT

日記を読む( 1 )限定公開( 2 )
チェックするつぶやく日記を書くfacebookでシェアする
＠IT
写真写真
　IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回取り上げるのは、「元請けベンダーと下請けベンダーの間に起きた機能追加費用を巡る争い」だ。



【その他の画像】



　昨今、問題視されることの多いソフトウェア開発における多重請負構造。ユーザー企業から発注を受けた元請けベンダー（以降、本文中は「元請け」と表記）が作業の一部（あるいはほとんど！）を下請けベンダー（以降、本文中は「下請け」と表記）に再委託することは、むしろ一般的といってもいいほど数多く存在する。



　両者の間で作業の分担や支払い、不具合の責任などを巡る争いが絶えないことも、また事実である。



　当然ながら、元請けと下請けの間には力関係が存在し、優位な立場にある元請けが、正式な契約を結ぶことなく下請けに作業を依頼し、後になって見積もりなどの条件について合意できずに紛争となるケースは、IT紛争の定番と言ってもいいくらいだ。



　今回の事件も、そうした類型に属するものだ。ただ、「機能の追加の量」と「下請けからの追加見積もり金額」が非常に大きいことが一つの特徴である。



　通常の請負開発でも、開発中に発注者から機能の追加要望があり、成果物が当初の予定と異なることはよくある。ただ本件の場合、追加の作業量が当初の6倍以上となり、追加の見積もり金額はもっと大きな差異となっている。



　こうなると「そもそも当初契約は有効なのか」が問題になってくる。



●46機能でよろしく→やっぱり296機能にして



　事件の概要から見ていこう。



東京地方裁判所 平成23年4月27日判決から（要約）---



元請けベンダーがユーザー企業から医療材料の物品管理システムの再開発を約4300万円で受託した。元請けベンダーは、実際の開発を下請けベンダーに46機能を約3300万円で発注することとして、両者は開発する契約を締結した。



ところが、開発中に機能数の見直しを行ったところ、機能数が296まで増大することとなり、下請けベンダーは元請けベンダーに対して、追加費用約1億6000万円の見積もりを提示したが合意に至らず、数カ月後に下請けベンダーは作業を中止した。元請けベンダーは、これを債務不履行であるとして、契約を解除する通知を発した。



下請けベンダーは、増額の合意および解約の際の出来高支払請求権として5億6700万円を請求し、一方、元請けベンダーは開発作業の履行拒絶が債務不履行にあたるとして、約1億5100万円の損害賠償を請求して裁判となった。



---



　「3300万円」で受託した作業に「1億6000万円」の追加見積もりがあり、裁判では「5億6700万円」を請求するという金額の推移は、驚きを通り超えて奇異にすら見える。こうなると、当初の3300万円と実際の作業内容は、別の契約だ。



　ここまで極端な例は珍しいかもしれないが、私も当初依頼された作業内容と実際の作業が大きく懸け離れてしまった経験が多々ある。



　「財務会計の機能を実装する」話だったはずが「管理会計用の分析まで」やってほしいと言われる、「顧客管理」システムだったはずが、いつの間にか「営業支援の機能まで付ける」ことになる――結果、工数が当初の2倍3倍になり、追加費用を巡って顧客と一触即発の状態になったこともある。



●下請けに拒否権はあるのか



　こうした場合に難しいのは、「下請け側が自分の意思で契約を解除できるのか」という点だ。



　追加機能について別の契約を結ぶ前提であれば、見積もりに元請けが合意しなければ、契約をしなければ済むことだ。下請けは粛々と当初の3300万円分の作業をすればいい。



　しかし多くのシステム開発がそうであるように、この事件の場合も、契約はそのまま残し、その条件（金額や期間）を変更することで対応しようとした。



　こうなると、追加の作業を行わない場合、あるいは行ったが完成しなかった場合、「契約全てが債務不履行」となり、下請けは一銭ももらえないどころか、損害賠償まで請求されかねない（事実、本件では元請けが1億5100万円を請求している）。



　元請けからすれば、元の3300万円分の作業のみを下請けにしてもらったところで、ユーザー企業の最終的な要望に応えられない。



　下請けが機能追加を行ってくれないことには、ユーザー企業／元請け間の契約も意味を成さなくなり、元請け自身がユーザー企業からお金をもらえないかもしれない。



　だが、下請けが主張する追加の1億6000万円という金額に元請けは納得がいかなかった。交渉してもラチが明かず、契約を解除せざるを得なかった。



　そしてモノは完成していないわけだから、「これは債務不履行に当たる」という論だ。



　一方の下請けの主張は、「大幅な機能追加について見積もりを出したのに、元請けがこれに同意しないまま契約の解除を通知してきた」のだから、これは「元請けの意思に基づく解約」だ。



　「自分たちの債務不履行ではなく、元請けが一方的に解除してきたのだから、行った作業の分だけは払ってもらう」という論になる（それが5億円以上の価値があったかどうかはともかく）。



　追加見積もりに合意しないまま、空中分解してしまったプロジェクトは「債務不履行」なのか「一方的な契約解除」なのか――裁判所は、どのような判断をしたのだろうか。



●予定43.5人月→実態278.7人月



　判例の続きを見てみよう。



東京地方裁判所 平成23年4月27日判決から（要約）（つづき）---



機能数の増加に伴い、開発作業が中止されるまでに下請けベンダーが実施した開発作業の工数は、278.7人月に上っている。これに対し、本件下請け契約の締結時点においては、下請け企業は、予定作業工数を43.5人月、月額単価を70万円と見積もっていたものと認められる。



そうすると、下請けベンダーが実施した開発作業の工数の実績値は、本件下請け契約締結時の見積もりの約6.4倍に相当する作業量であり、代金額にして1億9509万円に上るものである。



以上のように、開発に要する作業量が著しく増大したことによって、開発作業は、本件下請け契約が締結された時点とは、その内容において著しく異なることとなり、これに伴って、必要作業量も著しく増大したものであって、その前提が契約締結当初とは根本的に異なるものとなってしまったということができる。



これに照らせば、元請けベンダーが下請けベンダーに対し、プロジェクトを全面的にストップする指示を受けた時点においては、（下請けベンダーが）開発作業を継続し、完成する義務を負っていたと解することはできない。従って、下請けベンダーが、作業を中止したことは、本件下請け契約についての債務不履行を構成しないというべきである。



---



　「下請けの債務不履行はなく、そこまでにかかった費用は支払え」という判決だ。金額は「1億8000万円」。要求通りとはならなかったが、下請け側の勝訴と考えていいだろう。



　単に「追加見積もりが合意に達しなかった」ということであれば、もともとの契約にあった部分についての債務不履行が認められる余地もあったかもしれないが、本件の場合「当初の予定とあまりにも懸け離れた作業内容となったので、契約自体が既に破綻している」とする考え方だ。



　要するに、機能追加の大きさが分かった時点で、別の契約を結ばなければならなかったし、元請けはその時点で、下請けの作業をいったんストップさせなければならなかった（他の判決にもあるように、受注者が作業をしているのを知りながら、発注者がこれを止めないと、実質的な発注と見なされ、契約なしでも費用の支払いを命じられる場合がある）。



　これがもっと小さな機能追加であるなら、そこまでの必要はなかったかもしれないが、これだけの規模になったら、もはや当初契約は何の役にも立たないものになったと見なされるのだ。



　スケジュールが苦しい中、いったん作業を止めて見積もりの合意を待つのは、元請けにとっても、下請けにとっても、あるいはユーザー企業にとっても好ましい話ではない。



　だが、実質的に破綻した契約の上で作業をしたところで、本件のようにモメて、プロジェクトが破綻してしまう可能性は大きい。当初見積もりと追加の「差」を慎重に見極めて、ある時点になったら契約解除と再契約、そして必要なら「そもそもシステム開発を行う動機となった経営計画そのもの」も第三者が見直す必要すら出てくる。



　システム開発のためにそこまでやる必要があるかと思う方もいるかもしれないが、例えるなら、「店の建築が遅れたら、開店時期を遅らせざるを得ない」という、ごく常識的な話である。



●細川義洋



政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる


＠IT

作業は丸投げ、支払いは？――元請けvs.下請け裁判の行方
下請けが現場をトンズラ。取り残された元請けの運命は？
もしもシステムの欠陥により多額の損害賠償を求められたら