ユーザーが資料をくれないのは、ベンダーの責任です：「訴えてやる！」の前に読む IT訴訟 徹底解説（11）（2/2 ページ）

ユーザーが要件定義に必要な資料を提供しなかったため、システム開発が頓挫した。責任を取るべきはユーザー、ベンダー、どちらでしょう？

[ITプロセスコンサルタント 細川義洋，＠IT]

　判決の趣旨は以下の通りである。

【裁判所の判断】（東京地裁 平成19年12月4日判決より、抜粋して要約）

　ユーザーによる契約の解除は有効であり、既払い金の1800万円は全額返金とする。

　ご覧の通り、判決はベンダーの完敗であった。そして、問題の「ユーザーによる情報提供」について裁判所は「（システムの）具体的な仕様の確定は、発注者の要望をまとめた要求仕様と受注者の提案の基本設計をもとに双方が協議して確定されるものであり、その意味で発注者側の協力は欠かせないものである」と述べながら、以下のように結論付けている。

【裁判所の判断】（東京地裁 平成19年12月4日判決より、抜粋して要約）

　（ベンダーが自身の望む情報提供を受けるためには）ベンダーが資料に関する作業量を見積もるべきであったし、作業を見積もっていないのであれば資料がそろわないことの負担は、ベンダーが負うべきであった。

　少し補足をすると、ここでいう「仕様確定に必要な情報」とは既存システムのデータなどで、取り出すのに技術的な作業が必要なものである。だからユーザーは、「ベンダーから依頼された情報を取り出そうにも、作業内容と作業量が分からず作業ができなかった」とのことだ。

　裁判所はこうした状況を踏まえて、ベンダーには少なくとも作業量の見積もりを行って、結果をユーザーに通知する義務があったと判断したのだ。

机上の責任分担より現実的に誰ができるのかが問題

　ユーザーが行うべき作業の見積もりまで行わなければいけないとは、ベンダーにとって酷な判決に思われる読者もいるかもしれない。私も最初に判決文を読んだときには、自分が過去に行ってきたシステム開発プロジェクトの経験に照らして、ユーザーの作業をベンダーが見積もるという考え方には、正直違和感を覚えた。裁判所はどのような考え方に基づいてこうした判決を出したのであろうか。

　同様の問題を取り扱った他の判決なども参照して考えると、裁判所の根底にある考えは、どうやら「餅は餅屋」といったもののようだ。つまり「できる人がやるべきことをやる」ということであり、専門家が「やると約束したことをやりましたでは事足りない」ということだ。

　IT導入のあるべき姿は、「導入したシステムやソフトウェアがつつがなく動作して、ユーザーが業務的な目的を達成する」ことだ。そして、その達成のためにはユーザーとベンダーがおのおの、自分たちができることをしっかりとやる。それが双方の責任となるというのが裁判所の考え方のようだ。

　本件で言えば、既存システムの調査をどのように行い、どれだけの作業量が掛かるのかを見積もるのはITの専門家にしかできないことであり、ベンダーが見積もってくれないことには素人のユーザーが作業計画を立てられず調査を行えなかったとしても、その責はベンダーに求められる。

　随分とユーザーに都合の良い判決に見えるかもしれない。しかし逆に、ユーザーの業務に関する調査をベンダーが行うのであれば、ユーザーが段取りや作業見積もりを行わなければベンダーが作業を完遂できなくてもその責は問われないという考え方になるのであり、どちらに有利という考え方ではない。

　無論これらの考え方は、こうした場合の双方の責任分担・役割分担を契約書などに明記していない場合の話だ。もしもユーザーの調査に関わる作業についてこれらが具体的に定められていたならば、裁判所はそれを元に責任の所在を判断するはずで「餅は餅屋」という考え方を持ち出す必要はない。

　しかし通常は、IT導入に関わる契約書でそこまで詳細な責任分担の定義をすることの方が少ないのが現実であろう。システム開発プロジェクト、特に要件定義や受入テストなど、ユーザーとベンダーの責任分担が曖昧になりやすい工程ではユーザーとベンダーが共に、自分たちでなければできないことは何なのかをよく考えて、都度責任分担を再考する姿勢が求められる。

「「訴えてやる！」の前に読む IT訴訟 徹底解説」バックナンバー

• 保守ベンダーが調査してくれなかったから、不正アクセスされちゃったじゃないか！
• OSやミドルウェア由来の不具合まで、わが社のせいにしないでください
• DOS版をWindows用に書き換えただけで著作権を主張するとは、ちゃんちゃらおかしいわ！
• ReactJSで作るはずだったのに、Laravelで作ったので訴えます
• IT訴訟解説筆者が考える「セクシー田中さんドラマ化」問題と破綻プロジェクトの共通点――原因と再発防止案は？
• 開発が遅延した上に、メンバーの体調不良までわが社のせいにするのか！
• 仕様書通りにシステムを作りました。使えなくても知りません
• 何でスキル不足のエンジニアをアサインしたからって訴えられるんですか
• ベンダー社員過労死の遠因はユーザー企業にもあるのか
• この契約は、請負でも準委任でもありません
• ファイアウォールの設定を、すり抜け放題にしました☆
• 準委任契約だけど、責任は取ってください
• たった1日連絡しなかっただけで契約解除ってどういうことですか!?
• 契約書にも民法にも書かれていませんが、「義務」なので履行してください
• ソフトは転売していません。マニュアルを販売しただけです
• 「パワハラされてリストラされたので、転職サイトに書き込んでやりました」の追い解説
• お前とは絶交だ！　契約も解除してやる！
• 顧客も社員も奪われて、わしゃもう死んでしまいたい
• 入館拒否や帰宅命令までしないと安全配慮義務違反になるんですね
• 江里口美咲＆細川義洋対談「ここがダメだよ、IT業界！」
• 業務をパッケージに合わせると言ったけど、めんどくさいからやっぱりやめた
• 取った資格は俺のもの、もらったお金も俺のもの
• パワハラされてリストラされたので、転職サイトに書き込んでやりました
• 同僚を引き連れて起業するなんて、この恩知らず！
• 基本設計書は納品前ですが、システム作っちゃいました
• 技術的に不可能でも、セキュリティ対策は万全にしろ！
• 業績の悪い社員を解雇して何が悪いんですか？
• 仕様は確認しないし、運用テストもしません　全部出来上がってから確認します
• 製造工程に入ってるけど、やっぱこの機能も追加してくださーい
• お任せしたのですから、契約の範囲外でも対応してください
• 従業員が作ったセキュリティホールの責任を会社が取るなんてナンセンスです
• 私が決めた要件通りにシステムを作ってもらいましたが、使えないので訴えます
• 悪いのはベンダー！　「わび状」という証拠もあります！
• 不合格通知をもらわなかったから、検収合格ですよね
• こんな裁量労働制は嫌だ！
• 何で仕様も教えてくれないんですか！
• こんなパッケージソフトいらない！　だって使えないんだもん！
• 私のふんどしで相撲を取らないでください
• やった分はお金ください。納品してないけど
• 代金を支払わないからシステムを引き上げるなんて、どういう了見だ！
• 「お任せください」ってカンバンに書いてあるじゃないか！
• あるエンジニアの死
• 「退職するなら、2000万円払ってね」は、本当に会社だけが悪かったのか
• 似たようなデータベース作ったからって、泥棒よばわりするのやめてもらえません？
• あなたの能力も態度も信用できません
• 退職するなら、2000万円払ってね
• 派遣は工程表を作っちゃダメなんですか!?
• 最後の不具合が除去されるまで、働き続けてもらいます
• リバースエンジニアリングしたけど、もうけてないから問題ないでしょう？
• 運用保守契約は永遠です

細川義洋

東京地方裁判所 民事調停委員（IT事件担当） 兼 IT専門委員　東京高等裁判所 IT専門委員

NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。

2007年、世界的にも季少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

ITmedia オルタナティブブログ「IT紛争のあれこれ」

美人弁護士 有栖川塔子のIT事件簿

書籍紹介

「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

細川義洋著　日本実業出版社　2160円（税込み）

提案見積り、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。

なぜ、システム開発は必ずモメるのか？

細川義洋著　日本実業出版社　2160円（税込み）

約7割が失敗するといわれるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。