先日、わたしが参加しているある勉強会で、なかなか聞けない貴重なお話をうかがいました。システム委託開発でのトラブルが訴訟にまで発展したケースに関するもので、その経緯を当事者であった方が直接お話しされたのです。

この事例では、契約書に対する相互の認識が不明確であったがゆえにトラブルに収拾がつかず、最終的には互いに提訴しあう形で裁判になりました。いま係争中のスルガ銀行と日本 IBM との裁判と、かなり似ています。

わたしがこの話の中で気になったことのひとつに、「業界経験のないベンダーに任せてしまった」というものがありました。このユーザー企業は、委託ベンダー側に自社の業界でのシステム開発経験がないことを知っていたのに、結果的にはコスト重視で発注してしまったとのことでした。

なぜ経験のないベンダーを選定してしまったのかと聞くと、

「本当は開発せずに既存ソフトの移行だけで済まそうと計画していたところ、実はコストが予想以上にかかることがわかり、上層から開発に切り替えるよう言われてしまった」

「別に大規模プロジェクトが社内で並行しており、新たなプロジェクトが突然降って湧いても、そこに割ける社内の人員がいなかった」

「対象のシステムは保守期限が迫っており、時間がなかった」

との回答が返ってきました。

想定外の、やむにやまれぬ事情があったというわけです。ただ、わたしは一方で、この話を聞いて、意思決定プロセス設計の盲点と難しさを感じました。

このケースでは、もともとコストも時間もかけない「ソフト移行」という方法を採ろうとしていました。ところがそれでは予想外にコストがかかるということがわかり、計画は突如として「ソフト開発」に変更されたわけです。この際に、「上層が『開発』するよう判断」したということですが、この判断は結果的には誤りでした。

通常の意思決定のプロセスであれば、プロジェクト推進可否の決定は、戦略委員会や PMO のような合議制の組織を母体にして、コストパフォーマンスはもちろん、プロジェクトリスク、組織リソース、納期順守、ベンダー評価など、さまざまな視点から評価を行うものです。こうした評価を行っていれば、「大規模プロジェクトが並行しているからリソースが足りない」ことも、「保守期限に間に合わせる必要性」も、「ベンダーリスクの高さ」も、検討の俎上に載っていたはずです。

このプロセスが、「突然の計画変更」かつ「時間がない」という事情で、実施されませんでした。わたしが想像するに、「上層による開発の判断」というのは、おそらく特定の人物の（言い方は少々悪いですが）独断であったのではないでしょうか。

こうした課題は、いわゆる「ガバナンス」の問題です。「ガバナンス」を設ける意味は、「透明性の確保」「判断スピードの速さ」「判断の安定化」といったことにあると思います。

つまり、どんな課題に対しても関係者のだれもが同じ判断をスピード感を持って下せる、という状態をつくり出すのが「ガバナンス」を設ける目的だということです。

もちろん、場合によってはスピード重視で即決判断が必要な場面もあります。ただ、人間は合理性よりも面倒の回避を優先するところがあります。それを許すと判断が偏ったり不正確になるリスクがありますから、即決判断する場合も、その条件と責任の所在を仕組み化します。実際、CEO による即決のプロセスをガバナンスに組み込んでいる事例もあります。

ガバナンスというと何か堅苦しいものと考えてしまいがちですが、本来は、「組織にとって最も有効なオプションを迅速に選択するための手法」なのです。逆に、ガバナンスを「面倒なもの」と捉える環境ができてしまうと、判断を間違う確率は高まります。

このあたりは、J-SOX に対する考え方も同じです。J-SOX を会計監査上のルールとしてやむを得ない対応事項と捉えれば、面倒が先に立ちます。一方、J-SOX を「正確な財務集計をハイスピードに行うための仕組みづくり」と捉えれば、モチベーションが変わってこないでしょうか。

今回話をうかがった裁判のケースでも、いったんは通過した意思決定プロセスにもう一度乗せて判断していれば、訴訟によって膨大なエネルギーとリソースをそがれることは、そもそもなかったかもしれません。もちろん、結果論ではありますが。