ここから本文です

恐怖!暴走社長「仕様は確定していませんが、納品はしてください」:IT訴訟解説

8/2(水) 6:10配信

@IT

 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は、プロジェクト管理義務とユーザーの協力義務が争われた裁判を題材に、クセのある発注者とのプロジェクト運営のコツを解説する。

【キミたちの言い分は聞かない。訴えてやる!】

●ユーザーの協力義務を理解していないトップ

 本連載では何度も、「ユーザーはシステム開発プロジェクト成功のため、ベンダーに協力しなければならないという義務がある」と述べている。ユーザーはしかるべき時期までに、要件や他システムとのインタフェース仕様など、自分たちでなければ決定できないことを決め、受け入れテストや検収行為も遅滞なく行わなければならない。

 しかし、これらを理解し、プロジェクトがうまくいかないときに自分たちの非を全面的に認めてくれるようなユーザーの数は、まだまだ少ない。逆に「ベンダーにこそ非がある」と、費用の支払いを拒む例は珍しくない。

 こうしたケースでは、ユーザー側トップの考え方がプロジェクトに大きく影響する。ある意味、客観的に物事を見ることができ、最悪の場合、損を承知でプロジェクトの中止を判断できるトップが、プロジェクトのトラブルに際して冷静に双方の非を見極め、お互いの改善点を指摘してくれるなら、傷口は浅くて済む。

 しかし実際には、そうした物分かりの良いユーザーの経営者は少数派かもしれない。私の経験では、ユーザーの社長は普段現場を見ておらず、担当者からの報告だけ聞いて状況を把握するせいか、ベンダーにこそ責任が大きいと判断する人が多い。

 今回は、ベンダーにとって迷惑この上ないトラブルが裁判にまで発展した例を取り上げる。

●プロジェクト管理義務とユーザーの協力義務が争われた事件の例

 まずは、概要から見ていただこう。

---
東京地方裁判所 平成27年3月24日判決より抜粋して要約

通信販売業を営むユーザーは基幹システムの刷新を目的として、新システムの要件定義、設計、開発、運用準備および移行の支援をベンダーに委託した。費用規模は10億円を超えるプロジェクトで、順次分割して支払われたが、ソフトウェア開発の途中段階で、ユーザーは費用の支払いを拒絶し、その後、開発がまだ完了する前であったが、契約を解除する旨がベンダーに通知された。解除の理由は、ベンダーには開発を完遂させるのに十分な経験や能力がなく、成果物の未納や遅延が多数あること、また納められたものについても不備があることだった。

これに対してベンダーは、プロジェクト遅延の原因は、ユーザー側の分担となっていたユーザーインタフェース仕様の整理や移行方式の承認などが遅れたためであり、自分たちに責任はないと主張し、ユーザーは損害賠償を、ベンダーは残りの費用を請求して裁判となった。
---

 ここまでは、本連載で何度となく取り上げられてきた「ベンダーのプロジェクト管理義務とユーザーの協力義務の争い」である。プロジェクトの遅延は、ユーザーが協力しないからか、ベンダーの管理が不十分だったかの争いということだ。

●担当者の説得も聞かずベンダーの責任のみを追及した社長

 今回の判例が他と少し違うのは、ユーザー側が一枚岩ではなかった点だ。

 判決文を読むと、ベンダーの責任を厳しく追及し費用を払わないとする自社の社長を、ユーザーの担当者が説得し、何とかプロジェクトを継続しようと苦慮する姿が垣間見られる。また、ユーザーのシステム監査人が、後になって「もう社長を信頼できない」とサジを投げた言葉も見られる。

 つまり、ユーザーの社長だけがベンダーを強く非難し、プロジェクトを継続したいと考える担当者やシステム監査人の説得を聞かずに、プロジェクトを中断してしまった様子が伺われるのだ。

 そんな状況が分かったのか、裁判所は以下のような判断を下した。

---
東京地方裁判所 平成27年3月24日判決より抜粋して要約(つづき)

(ベンダーが納品しなかった)「インタフェース一覧」については、ユーザーの分担にかかる外部インタフェース仕様整理がされていないために未納であり、同じく、「システム/データ移行設計書」については、ベンダーが移行作業方針および移行処理方式の確認を求めたのに対し、ユーザーの回答がないために作成できなかった。

(中略)

上記前提事実によれば、ユーザーが未納と主張する成果物は、納品されているか、または未納となっていることについてベンダーには帰責事由はないと言わざるを得ない。また、各フェーズにおいて、納期に遅れて納品された成果物があることが伺われるが、個別の成果物の納品の遅滞は、主にユーザーによる情報提供などの遅れやベンダーの受注範囲外の他システムの仕様確定の遅れなどに起因するものであって、ベンダーには帰責事由がないと認められる。
---

 恐らくこうした判決が出ることはユーザーの担当者たちも分かっていて、だからこそ社長を説得しようとしたのだろう。しかし社長はそれに聞く耳を持たず、訴訟に出て一方的に負けてしまったのだ。

●頑迷な社長をどう説得するか

 ベンダーは、ホッと胸をなでおろしたかもしれないが、見方を変えると、これだけ一方的にユーザーに非があるにもかかわらず、裁判にまで持ち込まなければ費用を取れないとするなら、ベンダーにとってもかなり気持ちの暗くなる事件だ。

 ベンダーがユーザーを訴えるのは、よほどのことだ。多くは、その後のユーザーとの関係や世間の評判、そして裁判に掛かる労力などを考慮して、ある程度は我慢してしまう。

 ユーザーが期日までに要件を決めてくれなかったり、テストデータを作ってくれずにプロジェクトが遅れても、ユーザー側担当者というフィルターを通してしか情報を聞いていない経営者は、部下の都合の良い理屈をうのみにしてしまう。揚げ句の果てには「ベンダーこそ要件定義を主導すべき」「テストデータの作り方を指示してくれない」など、自分たちこそ被害者だと考えてしまいがちだ。

 本件のように、ユーザーのトップが冷静な判断を失い、「自分たちには非がないはずだ」と言い続けたら、ベンダーがかなり苦しい立場に追い込まれてしまうのは事実だ。泣く泣く請求額を減額したり、契約を解除されたりしてしまうケースもままある。

 では、こうしたユーザー、あるいはユーザーのトップに対して、ベンダーはどのように対応したらよいのだろうか。

 特効薬のようなものはないが、1つの方法として、私がかつて在籍していた会社にいたプロマネの話を紹介しよう。

 そのプロマネは、ある中堅金融業のシステム開発を担当することになったたとき、顧客の過去担当者から、注意するように言われた。顧客のトップが非常に強引な人で、「システムのトラブルは全てベンダーが悪い」と、一銭も費用を払わずに作業をさせたことがあるというのだ。

 その話を聞いたプロマネは、プロジェクト開始に当たって、自分が動かせる1番上の上司(具体的には事業部長)をユーザー先に連れて行った。同行した上司は、相手の社長に、「月に1度、自分の口からプロジェクトの状況を社長に報告する」と申し出た。

 今回の判例もそうだが、トップがベンダーだけを一方的に非難する場合は、ユーザーのシステム担当者から正確で客観的な報告が上がっていないことが多い。自分たちの不手際をできるだけ小さく見せようとする担当者が、ベンダーの責任を強調した話し方をしてしまうのだ。

 これを防ぐためにプロマネと上司は相談し、客観的な資料を示してプロジェクト状況を直接説明する場を作ったのだ。こうしておけば、一方的に自分たちだけが悪者にされる可能性は低くなる。ユーザーの担当者以外に報告のパスを作ったのだ。

 さらに上司は、社長の信頼を得る努力を怠らなかった。プロジェクト実施中足しげく社長を訪問しては、社長が興味を持ちそうな他の金融業のシステムの話(公開されている情報に限る)や、それを支えるIT技術の話をいろいろとした。ある時期から、社長は自社のITについて、この上司に相談するようにもなった。

 案の定、プロジェクトは、ユーザーが要件を取りまとめられずに遅延した。社長は当初、「責任はベンダーがユーザーをリードしていないからだ」と言っていたが、件の上司が何度も社長を訪問し、相談するうちに態度が軟化した。

 上司はプロジェクト実施中の議事録を調べ直し、要件定義の遅れの主因がユーザーにあることをエビデンスベースで社長に告げたのだ。

 ユーザーの担当者たちは社長に、ベンダーの責任のみを報告していたらしいが、ある程度信頼関係のできた上司から、議事録という正式な情報を基に論理的に説明された社長は、矛を収めたようだ。結局、要件定義を急ぐよう、社長がユーザー内部にゲキを飛ばすことで、プロジェクトは立ち直った。

 もちろん、いつもこのようにうまくいくとは限るまい。しかし、ユーザーのトップに対して率直に現場の生の情報を上げられる仕組みを作ることが、プロジェクト成功の確率を高めるのは間違いない。今回の判例でも、もう少しベンダーにこうした知恵があったら良かったのに、と思わざるを得ない。

●細川義洋

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

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

●書籍紹介

本連載が書籍になりました!

成功するシステム開発は裁判に学べ!~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック
細川義洋著 技術評論社 2138円(税込み)

本連載、待望の書籍化。IT訴訟の専門家が難しい判例を分かりやすく読み解き、契約、要件定義、検収から、下請け、著作権、情報漏えいまで、トラブルのポイントやプロジェクト成功への実践ノウハウを丁寧に解説する。

システムを「外注」するときに読む本
細川義洋著 ダイヤモンド社 2138円(税込み)

システム開発に潜む地雷を知り尽くした「トラブル解決請負人」が、大小70以上のトラブルプロジェクトを解決に導いた経験を総動員し、失敗の本質と原因を網羅した7つのストーリーから成功のポイントを導き出す。

最終更新:8/2(水) 6:10
@IT