恐怖! 暴走社長「仕様は確定していませんが、納品はしてください」:「訴えてやる!」の前に読む IT訴訟 徹底解説(44)(3/3 ページ)
自社の不手際でプロジェクトが遅延しているのに、ベンダーを訴えたユーザーの社長。勝ち目のない裁判に社長が打って出た理由は何だったのだろうか?
頑迷な社長をどう説得するか
ベンダーは、ホッと胸をなでおろしたかもしれないが、見方を変えると、これだけ一方的にユーザーに非があるにもかかわらず、裁判にまで持ち込まなければ費用を取れないとするなら、ベンダーにとってもかなり気持ちの暗くなる事件だ。
ベンダーがユーザーを訴えるのは、よほどのことだ。多くは、その後のユーザーとの関係や世間の評判、そして裁判に掛かる労力などを考慮して、ある程度は我慢してしまう。
ユーザーが期日までに要件を決めてくれなかったり、テストデータを作ってくれずにプロジェクトが遅れても、ユーザー側担当者というフィルターを通してしか情報を聞いていない経営者は、部下の都合の良い理屈をうのみにしてしまう。揚げ句の果てには「ベンダーこそ要件定義を主導すべき」「テストデータの作り方を指示してくれない」など、自分たちこそ被害者だと考えてしまいがちだ。
本件のように、ユーザーのトップが冷静な判断を失い、「自分たちには非がないはずだ」と言い続けたら、ベンダーがかなり苦しい立場に追い込まれてしまうのは事実だ。泣く泣く請求額を減額したり、契約を解除されたりしてしまうケースもままある。
では、こうしたユーザー、あるいはユーザーのトップに対して、ベンダーはどのように対応したらよいのだろうか。
特効薬のようなものはないが、1つの方法として、私がかつて在籍していた会社にいたプロマネの話を紹介しよう。
そのプロマネは、ある中堅金融業のシステム開発を担当することになったたとき、顧客の過去担当者から、注意するように言われた。顧客のトップが非常に強引な人で、「システムのトラブルは全てベンダーが悪い」と、一銭も費用を払わずに作業をさせたことがあるというのだ。
その話を聞いたプロマネは、プロジェクト開始に当たって、自分が動かせる1番上の上司(具体的には事業部長)をユーザー先に連れて行った。同行した上司は、相手の社長に、「月に1度、自分の口からプロジェクトの状況を社長に報告する」と申し出た。
今回の判例もそうだが、トップがベンダーだけを一方的に非難する場合は、ユーザーのシステム担当者から正確で客観的な報告が上がっていないことが多い。自分たちの不手際をできるだけ小さく見せようとする担当者が、ベンダーの責任を強調した話し方をしてしまうのだ。
これを防ぐためにプロマネと上司は相談し、客観的な資料を示してプロジェクト状況を直接説明する場を作ったのだ。こうしておけば、一方的に自分たちだけが悪者にされる可能性は低くなる。ユーザーの担当者以外に報告のパスを作ったのだ。
さらに上司は、社長の信頼を得る努力を怠らなかった。プロジェクト実施中足しげく社長を訪問しては、社長が興味を持ちそうな他の金融業のシステムの話(公開されている情報に限る)や、それを支えるIT技術の話をいろいろとした。ある時期から、社長は自社のITについて、この上司に相談するようにもなった。
案の定、プロジェクトは、ユーザーが要件を取りまとめられずに遅延した。社長は当初、「責任はベンダーがユーザーをリードしていないからだ」と言っていたが、件の上司が何度も社長を訪問し、相談するうちに態度が軟化した。
上司はプロジェクト実施中の議事録を調べ直し、要件定義の遅れの主因がユーザーにあることをエビデンスベースで社長に告げたのだ。
ユーザーの担当者たちは社長に、ベンダーの責任のみを報告していたらしいが、ある程度信頼関係のできた上司から、議事録という正式な情報を基に論理的に説明された社長は、矛を収めたようだ。結局、要件定義を急ぐよう、社長がユーザー内部にゲキを飛ばすことで、プロジェクトは立ち直った。
もちろん、いつもこのようにうまくいくとは限るまい。しかし、ユーザーのトップに対して率直に現場の生の情報を上げられる仕組みを作ることが、プロジェクト成功の確率を高めるのは間違いない。今回の判例でも、もう少しベンダーにこうした知恵があったら良かったのに、と思わざるを得ない。
細川義洋
ITコンサルタント
NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。
2007年、世界的にも希少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。
書籍紹介
本連載が書籍になりました!
成功するシステム開発は裁判に学べ!〜契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック
細川義洋著 技術評論社 2138円(税込み)
本連載、待望の書籍化。IT訴訟の専門家が難しい判例を分かりやすく読み解き、契約、要件定義、検収から、下請け、著作権、情報漏えいまで、トラブルのポイントやプロジェクト成功への実践ノウハウを丁寧に解説する。
細川義洋著 ダイヤモンド社 2138円(税込み)
システム開発に潜む地雷を知り尽くした「トラブル解決請負人」が、大小70以上のトラブルプロジェクトを解決に導いた経験を総動員し、失敗の本質と原因を網羅した7つのストーリーから成功のポイントを導き出す。
プロジェクトの失敗はだれのせい? 紛争解決特別法務室“トッポ―"中林麻衣の事件簿
細川義洋著 技術評論社 1814円(税込み)
紛争の処理を担う特別法務部、通称「トッポ―」の部員である中林麻衣が数多くの問題に当たる中で目の当たりにするプロジェクト失敗の本質、そして成功の極意とは?
「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則
細川義洋著 日本実業出版社 2160円(税込み)
提案見積もり、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。
細川義洋著 日本実業出版社 2160円(税込み)
約7割が失敗するといわれるコンピュータシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 最低限の知識も理解もないユーザーと渡り合うには?
「出荷管理をシステムを発注したにもかかわらず、勘定科目を把握していない」「意見を社内でまとめず、五月雨式に投げてくる」「モックを本番と勘違い」――こんなユーザー、あなたならどうする? - 2年超も仕様が確定しないのは、ベンダーの責任か?
ステム設計書を提出しても、プロトタイプを作成しても、どうしても仕様を確定させてくれないユーザー。この契約、解除しても大丈夫? - ユーザーが資料をくれないのは、ベンダーの責任です
ユーザーが要件定義に必要な資料を提供しなかったため、システム開発が頓挫した。責任を取るべきはユーザー、ベンダー、どちらでしょう? - ソクラテスになれ――無知なユーザーとの仕事の進め方
ユーザーの知識が不足していたり、担当者が十分な引き継ぎもなく交代したりするのは、ままあることだ。それでもプロジェクトを成功に導くために、ベンダーは何をすべきだろうか? - 定形外業務も自主的に調べるのがベンダーの努めです
契約内容に盛り込まれていない「オペレーターがデータベースを直接操作する機能」が実装されていないと支払いを拒否されたベンダーが起こした裁判を解説する