『システムを「外注」するときに読む本』の第5章では、「ベンダー側のメンバー離脱」というリスクを、「それはベンダーの問題だ」と突き返した発注者のプロジェクトが危機に陥る場面を描いていますが、こうしたことは、実際にも数多くあります。
たとえば、スルガ銀行の勘定系システムの導入が失敗し、ベンダーだったＩＢＭと100億規模の訴訟になった有名な事件でも、「ベンダーの主要メンバーの離脱」や「使おうとしていたパッケージソフトが実は使えなかった」といった問題への対応を、当初ベンダー任せにしていたがために傷口を広げて、とうとうプロジェクトが頓挫してしまった事例でした。
もちろん、こうした問題はベンダーが責任をもって解決すべきことです。しかし、だからと言って、問題が発生したときにその解決のすべてをベンダーだけに任せていると、結局、大金をドブに捨てることになるのは発注者側なのです。
メンバーが離脱したとなれば、発注者が手伝えることはないか検討する。
技術的な困難があるなら、思い切って、システムの実現方法を変えるように指示する。
そうしたことは発注者側にできることですし、少なくとも、プロジェクトがうまく進捗していないことを経営層に伝え、費用の追加や納期延長等について交渉しておくくらいのことは必須です。
そして、とにもかくにもプロジェクトを完了させ、その後で、ベンダに対して発注者が被った被害に応じて支払い金額の減額等を求めることが、発注者とベンダー双方の被害を最小限に食い止める手段です。
たとえベンダー側の責任で解決するべき問題も、プロジェクトを危険に晒すリスクであることには変わりありません。一旦は、「発注者」と「ベンダー」という立場を超えて解決に協力し、精算は後で行なうほうが、プロジェクトの成功率はぐっと高まります。
ベンダーはＩＴの専門家ですが、神様ではありません。
任せておけば全て安心などということは、決してないのです。
経済産業省CIO補佐官。ITプロセスコンサルタント。立教大学経済学部経済学科卒。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。大学卒業後、NECソフト株式会社（現NECソリューションイノベータ株式会社）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。
これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より経済産業省の政府CIO補佐官に抜擢され、政府系機関システムのアドバイザー業務に携わる。著書に『システムを「外注」するときに読む本』（ダイヤモンド社）、『なぜ、システム開発は必ずモメるのか！』『モメないプロジェクト管理77の鉄則』（ともに日本実業出版社）、『プロジェクトの失敗はだれのせい？』『成功するシステム開発は裁判に学べ！』（ともに技術評論社）などがある。
