悪いのはベンダー! 「わび状」という証拠もあります!「訴えてやる!」の前に読む IT訴訟 徹底解説(87)(4/4 ページ)

» 2021年05月17日 05時00分 公開
前のページへ 1|2|3|4       

おわびをする際のポイント

 では、おわびの文章が全く無視されるかといえば、そんなことはない。裁判においては裁判官や専門委員が、調停では調停委員会が、こうした文章を熟読し、責任の考え方をまとめる上での重要な判断材料としている。

 実際のプロジェクトにおいても、おわびの文章の書き方は大切だ。ベンダーはおわびをしなければならないことを引き起こしたとき、引け目を感じて自身の責任と役割を過大に書き過ぎる傾向にある。すると、その対応にかこつけて、本来約束した役割以上のことをユーザー企業に求められ、それが負担増加と作業品質の低下、そして顧客満足度のさらなる低下を招いてしまう結果となる。

 今回はせっかくなので、おわびをする際のポイントを指南する。私は「おわびのプロ」ではないが、ベンダーとして、ユーザーとして、あるいはIT紛争の解決をお手伝いする立場としての経験を申し述べるので、参考にしてほしい。

 ユーザーが求めるのは、平身低頭するベンダーの姿ではない。現状を正しく理解し、納得できる今後の対応を確実に行う見通しを立てることだ。この際のベンダーの責任は、「契約書に照らして、実施すべきことをすること」であり、それ以上でもそれ以下でもない。

おわびをすべき「事実」を正しく捉える

 まずは、おわびをすべき事実を正しく捉えることだ。わび状の中には、とにかく何でもかんでも自分たちが悪いと、自身の体制や技術などを否定し過ぎるものもあるが、実際には、謝罪すべきは数点だったりする。

 「プロジェクト管理の不行き届き」「技術不足」「作業品質の低さ」などと、ざっくりした言い分をしてしまうと、自身の全否定となり、しなくてもいい対策を求められることにつながるし、ベンダーの会社全体への不信も招きかねない。「PMと○○グループの連絡体制の不備により」「一部担当者の××技術理解不足のため」「作業手順書のレビューが不足しており」など、なるべく具体的に書いた方が、問題点がハッキリするし、過大な対応を求められることもない。

対応策も明確にする

 問題点がハッキリすれば、裏返しで提示する対応策も具体的になる。「連絡方法の見直し」「メンバー教育」「レビューシートの見直し」など、「誰」が「何」をすればいいのかが見えてくるのだ。

 無論、謝罪する点と対策については、書き過ぎもだめだが、不足していてもいけない。ユーザー企業から「いや、もっとこんなこともあるだろう」「あれはどうした」といわれるようでは、謝意そのものも疑われかねない。抜け漏れのある謝罪や対策は、かえってユーザーの不信感を募らせるだけだ。

安請け合いはしない

 おわびをする際にもう一つ注意をしたいのは、何でも安請け合いしないことだ。

 私がユーザーサイドにいたころ、ベンダーの謝罪を受けた担当者が、ベンダーに「不具合に対応するための緊急ユーザー研修を行うなら、ついでに別の研修もやってほしい。接続する他システムの担当ベンダーとも交渉してほしい」と言うのを聞いて、待ったをかけたことがある。本来の役割分担以上の作業をベンダーに押し付けるのは、ただでさえ不具合への対応で逼迫(ひっぱく)するベンダーをさらに追い込み、さらなる問題を引き起こしかねないからだ。

 ベンダーも「お客さまが機嫌を直してくれるなら」と安請け合いしてしまいたくなるかもしれないが、こうした危険を説明して、「やるべきこと」と「やるべきではないこと」をしっかりと区別すべきだ。

 怒りに震える顧客を前にして断るのは勇気がいるが、その場の雰囲気に飲まれそうであれば、「いったん持ち帰って検討」ということにして、後日ユーザーの頭が冷えたころに、言葉を選びつつ断りを入れるという手もある。

 以上が、私が考える「おわびのポイント」だ。一言でいえば、「謝り過ぎず、やり過ぎず、しかし、今後の見通しだけはハッキリさせてユーザーの合意をとる」ということだ。

 余談だが、米国では自動車事故の際、ドライバーは絶対に相手に謝罪をしないという。人の礼儀としてどうかとは思うが、事実確認なしに過分な責任を背負いこまないという姿勢には幾分か学ぶべきところがあるかもしれない。

細川義洋

細川義洋

政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員

NECソフト(現NECソリューションイノベータ)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。

独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。

2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる

書籍紹介

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

成功するシステム開発は裁判に学べ!契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

成功するシステム開発は裁判に学べ!〜契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

細川義洋著 技術評論社 2138円(税込み)

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


システムを「外注」するときに読む本

細川義洋著 ダイヤモンド社 2138円(税込み)

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


プロジェクトの失敗はだれのせい? 紛争解決特別法務室“トッポ―"中林麻衣の事件簿

細川義洋著 技術評論社 1814円(税込み)

紛争の処理を担う特別法務部、通称「トッポ―」の部員である中林麻衣が数多くの問題に当たる中で目の当たりにするプロジェクト失敗の本質、そして成功の極意とは?


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

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

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


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

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

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


前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。