システム開発に当たり、ユーザー企業とITベンダーが交わす契約書。その条文の解釈を巡るトラブルが絶えない。大手ベンダーが用意した契約書だからとよく読まずに契約するのは禁物。法律の改正も踏まえ、公正な契約を結ぶ努力が欠かせない。

 契約書の条文に関わるシステム開発のトラブルが近年、増えている。契約書の条文についての認識や解釈の違いから、ユーザー企業とITベンダーが対立し、訴訟に至るケースも多い。

 数十年前のシステム開発案件では、ITベンダーとユーザー企業が契約書を取り交わさず、提案書と注文書を交わしただけで開発がスタートすることもあった。

 現在のシステム開発では、さすがに契約書を取り交わすのが当たり前になっている。これは経済産業省や業界団体がシステム開発取引の健全化を図った成果といえる。

 だが、契約書の存在がユーザー企業に不利益をもたらすケースもある。今回は大手国内ベンダーが作った契約書を十分に確認せずに印を押してしまったA社のトラブル事例を紹介する。

図 A社が陥った契約トラブル
図 A社が陥った契約トラブル
ユーザー企業に不利な契約条項でITベンダーと対立
[画像のクリックで拡大表示]

「経産省のモデル契約に準拠」

 A社は受発注などの基幹業務を担う社内業務システムを刷新するに当たり、大手ITベンダーB社とシステム開発契約を結んだ。B社はA社に対し、自社製パッケージソフトを用いたSI、つまりシステムインテグレーションによる刷新を提案した。

 B社は契約に当たり、システム開発の契約書を自ら用意した。B社の説明によれば、契約書は経産省の「情報システム・モデル取引・契約書」第一版に準じたとのことだった。

 A社の担当者は「省庁が策定したモデル契約書に準じているなら、不当な条文はないだろう」と考え、契約の詳細を確認しないまま契約書を取り交わした。

 A社のプロジェクトで問題が発生したのは、システムテスト以降の工程だった。この工程は経産省のモデル契約書に従い、B社が完成責任を持つ請負契約ではなく、準委任契約に基づいて受託していた。

 このシステムテスト工程におけるA社とB社の役割分担についての認識に、大きなズレがあった。

 ベンダーB社の主張は次のようなものだった。「自分たちが責任を持つのは、請負契約として契約したソフトウエア開発まで。システムテストや移行作業は準委任による支援作業(相談対応、修正設計作業など)をしているだけであり、完成責任は持っていない。システムテストのやり方はユーザー企業が考えるべきであり、契約書に付随した役割分担表でもB社の役割は△(サブ担当)となっているはずだ」。

 この主張に、A社の担当者は驚いた。A社はシステムテストから本番稼働まで責任を持って面倒を見てくれるもの、と考えていたからだ。

 B社の営業担当者がA社に提案したのは、社内業務システムのシステムインテグレーションである。A社はシステムインテグレーションの意味を「B社が本番稼働、つまりシステム構築の完了まで責任を持つ」と考えてB社の提案を高く評価し、B社を選定した。

 ところがB社が提示し、両社が取り交わした契約書は、システムの完成責任を伴う契約ではなかった。

 経産省が策定したモデル契約書第一版は、ウォータフォール型によるソフトウエア開発受託を念頭においている。要件定義や設計などの上流工程は準委任契約、ソフトウエア開発は請負契約、システムテスト・移行支援は準委任契約といった形で、工程ごとに契約形態を分けることを基本とする。

 ユーザー企業が契約時点で開発の主導権が自社にあると認識している場合は、こうした契約形態で問題はない。だがA社は「B社はシステムインテグレーションを提案した以上、システムの完成まで一貫して責任を負う」と考えていた。ここに大きな認識の違いがあった。

 役割分担の認識にズレがある状態では作業がうまく進むはずがない。システムテストはスケジュールより大幅に遅延した。