全3246文字
PR

システム開発の失敗を巡るシステム裁判が絶えない。ユーザー側の責任を厳しく問う判決が増えているとの見方もある。ただ発注者と受注者が果たすべき義務の本質は変わらない。

 プロジェクトの途中で仕様変更を繰り返すユーザー企業と、対応に苦慮するITベンダー――。システム開発の現場で何十年と繰り返されてきた光景だ。ひとたびシステム開発が頓挫すれば、訴訟にまで発展するケースもある。

 典型例が、2021年4月21日に控訴審判決が言い渡された「野村-IBM裁判」だ。システム開発の失敗を巡って発注者の野村ホールディングス(HD)らが委託先の日本IBMを訴えた。

 東京高等裁判所の判断は「プロジェクト失敗の原因は仕様凍結後も変更要求を多発したユーザー企業(野村側)にある」というものだった。日本IBM側に非があるとした一審を覆し、逆転敗訴の判決を下したことからも同裁判は注目を集めた。野村HDは現在、上告を申し立てており、最高裁判所が今後受理するかを判断する。

 発注者という強い立場に乗じ、ユーザー企業がITベンダーに対して「変更要求に対応させる」といった強硬な態度を取れば、裁判で不利になる可能性が高い。その事実を野村-IBM裁判は改めて示した格好だ。

 システム訴訟に詳しいアドバンスト・ビジネス創造協会(ABC協会)の細川泰秀副会長は「裁判所がプロジェクトの実態を精査したうえで、ユーザー企業側の責任を厳しく問う判決を下すケースが増えている」と話す。ただ、「ユーザー企業の変更要求が全て悪とされる」と捉えるのは早計だ。その判断にはシステム開発にまつわる複雑な法的視点が介在するからだ。

システム訴訟において、ユーザー企業側の責任を厳しく問う判決が増えている
システム訴訟において、ユーザー企業側の責任を厳しく問う判決が増えている
[画像のクリックで拡大表示]

 近年はDX(デジタルトランスフォーメーション)の成否が事業の競争力に直結するようになり、ユーザー企業にとってシステム開発中止による経営上の痛手は相対的に大きくなった。費用も時間もかかる訴訟という事態を招かないためにも、システム開発において発注者と受注者の双方がどのような義務を負うかという「基本」を改めて理解しておくことが、リスク管理に一層欠かせなくなっている。

争点は「PM義務」と「協力義務」

 一般にシステム開発の失敗を巡る裁判では次の2つが争点となりやすい。

 ITベンダー側はプロジェクトを適切に管理する「プロジェクトマネジメント(PM)義務」に違反する行為がなかったか、ユーザー企業側は適時に仕様を決定するなどITベンダーに協力する「協力義務」に違反する行為がなかったか、である。裁判官はプロジェクトの議事録やメールのやりとり、証言などの資料を基に、どちらにどのような違反行為があったかを認定する。

 「ユーザー企業が仕様を決めなかった」「ユーザー企業が追加要件を多発した」――。これはシステム訴訟でITベンダーがユーザー企業の協力義務違反を指摘する際に使う決まり文句だ。

 ITベンダーが失敗の原因をユーザー企業の変更要求にあると主張するならば、前提としてプロジェクトの過程で要件をきちんと固めていたかが問われる。「要件を固めていたと示す証跡は裁判で重要な要素となる。互いが仕様の凍結に確かに同意したと、証跡としてしっかり残すことが望ましい」。システム訴訟に詳しい松島総合法律事務所の松島淳也弁護士はこう話す。

 とは言え、実際の開発現場はなあなあにもなりがちだ。「進捗会議などの場でユーザー企業とITベンダーが『要件が固まりましたよね』といった会話をして、何となく仕様を固めたつもりで次の工程に進んでしまっているプロジェクトは非常に多い」(松島弁護士)。この場合、万が一開発が頓挫して訴訟になった際に、仕様が固まっていたと認められない可能性があるという。

 対策はある。松島弁護士は、要件定義と概要設計が終わったタイミングで情報処理推進機構(IPA)が2020年12月に第2版を公開した「情報システム・モデル取引・契約書」にのっとり、要件定義書と概要設計書に双方の責任者が必ず署名なつ印することを勧める。

 「近年のシステム裁判の流れを見ると、要件定義や概要設計の最中にユーザー企業が要件を追加しても仕様変更扱いとは見なされないケースが多い。要件定義書と概要設計書が完成し、それぞれが署名なつ印してからは、追加要件の対応に相応の費用が生じ、スケジュールの見直しも場合によって必要となる旨をITベンダーはユーザー企業に強調しておく必要がある」。松島弁護士は続ける。「概要設計までに要件を固める必要があることをユーザー企業には最初から強く訴えるべきだ」。