オフショア開発における契約不適合責任と法的リスクの実態

最近、オフショア開発で構築された営業支援システムの改修を依頼された。 都道府県がランダムに並び、顧客データを毎回送信し、マーケティングに必要な詳細ログが欠けているシステム。 技術的な問題は数多く発見されたが、法的な観点から見ると、この惨状はさらに深刻だった。 そして、このシステムは明らかに契約不適合だった。

第一章：契約不適合責任

民法改正の重要性

2020年4月1日の民法改正により、従来の「瑕疵担保責任」は「契約不適合責任」に変わった。 この変更は、システム開発における責任の範囲を大幅に拡大している。

旧法では「隠れた瑕疵」のみが対象だった。 バグが発見されても、「仕様書に書いていない」「要件定義にない」と言い逃れができた。

だが、新法は違う。 契約の内容に適合しているかどうかが基準となる。

営業支援システムを発注したのに、営業支援として使えないなら、それは契約不適合だ。 仕様書に書いていようがいまいが、関係ない。

開発会社の致命的な勘違い

多くの開発会社は、いまだに旧法の感覚でいる。

「仕様書通りに作りました」 「要件定義書に書いていません」 「追加開発が必要です」

これらは全て、新法では通用しない言い訳だ。 契約の目的を達成できなければ、どんな言い訳をしても契約不適合なのだ。

第二章：システムの根本的欠陥

契約で求められていたもの

RFP（提案依頼書）と要件定義書には、営業支援システムの構築が明確に記載されている。 営業活動の自動化を通じて、営業効率を向上させるという明確な目的がある。

実際のシステムの致命的欠陥

だが、実装されたシステムは、これらの目的を全く達成できない。

営業支援として使えない設計：顧客の詳細な行動履歴が記録されない設計のため、営業担当者が必要とする「誰がいつアクセスしたか」「どの顧客を優先してフォローアップすべきか」といった重要な情報が取得できない。

営業活動の自動化が不可能：顧客の行動パターンを分析してフォローアップの優先順位を決める機能が実装できない構造になっている。これでは営業活動の効率化という契約目的が達成できない。

つまり、営業支援システムの看板を掲げているが、営業には全く役立たないのだ。

第三章：開発会社の責任逃れの論理

「短期開発・工期短縮」論

「工期が短かったから品質が劣るのは仕方ない」

これは詭弁だ。

契約違反の免責事由にならない

開発会社が工期を承諾して契約を締結した以上、工期は免責事由にならない。 「できない工期」なら、契約時に断るべきプロとしての責任がある。

「動いているから問題ない」論

「要件定義書に記載された機能は実装しています」

だが、「動く」と「使える」は全く別物だ。

エピローグ：他人事だから言える現実

35年この業界にいて、これほど酷いシステムは初めてだった。 幸いなことに、これは他人事だ。俺が発注したシステムではない。 だが、民法改正により、発注者は新たな武器を手に入れた。 契約不適合責任。 これが武器になるかどうかはクライアント次第だ。法的対応を取る覚悟があるかどうか、そして適切な専門家に相談する判断ができるかどうか。 これは単なる技術的不備ではない。プロの開発会社としての基本的責任を放棄した重大な契約違反だ。 「仕様書通りに作った」という言い訳は、もう通用しない。 契約の目的を達成できないシステムは、どんな言い訳をしても契約不適合だ。

しかし、この事例は決して珍しくない。 素人が営業マンの巧みな説明を鵜呑みにしてシステム開発を発注すれば、大やけどするという好例だ。 各種調査データからも、オフショア開発の失敗事例は後を絶たない。 開発会社が「瑕疵担保責任」を主張するなら、それは法改正への理解不足を示すものだ。法的専門性の欠如も、問題として指摘される。 新法の時代、発注者は泣き寝入りする必要がない。

だが、戦うかどうかは発注者次第だ。

この記事は実際の事例に基づいているが、システム開発における契約不適合責任は重要な法的概念だ。民法改正により、発注者の権利は大幅に拡大している。泣き寝入りせず、適切な法的対応を検討することが重要だ。

重要な注意：本記事は法的助言ではありません。実際の法的問題については、弁護士等の専門家にご相談ください。