ITベンダーがユーザのビジネス結果責任を負う時代の幕開けだ

今年のIT関係で、大きな話題になったものに、日証のシステムの問題があります。これについて、以前メルマガでほんの少し、私の考えを披露しましたが、今回、1年の締めくくりとして、考えてみたいと思います。
この問題には、2つの事象が絡み合っています。
1つは、システム自体がダウンして、ビジネス上に大きな損害をもたらしたこと。もう1つは、みずほ証券の間違った売り注文をそのまま通し、後でキャンセルできなかったことです。こちらもビジネス上大きな損害を与えています。


この問題に対し、開発元の富士通に責任があるような論調が多いですが、私は、そう思っていません。発注元の仕様書がしっかりしており、その通り開発したのであれば、開発側にはなんら責任がないはずです。
これが、前提条件です。仕様書どおりに富士通が開発していなければ、論外です。
本来、仕様書は、発注側が作成するものです。発注側が作れなければ、受注側が作成してもかまいません。ただし、責任は、発注側にあります。
仕様書と言ってもいろいろあります。大別すると、業務仕様、プログラム仕様に分かれます。どのような役割分担で、また責任範囲を明確にしていたかどうかが問題となります。
推測ですが、責任範囲が明確でないままに、すべてを富士通に丸投げしていたのではないかと思います。
また、みずほ証券が1円で売り注文を出したことは、想定外の事態だと思います。開発中にもそのような事態を想定した対応策を盛り込んではいないと思います。
ただし、1円は極端にしろ、市場価格から乖離した売り注文が出た場合のことは想定していたはずです。それは、みずほ証券が発注した時点で出たウォーニングが出たと言うことから推測できます。
それがウォーニングで、その後のプロセスを継続できる仕様が妥当であったかどうかが問題となると思います。エラーとしてはじいていれば問題は起きませんでした。これは後付ですが、開発当時にそのような意識があったかどうか。
仕様書にどのように定義されていたかが問われるでしょう。
また、ユーザ側として、みずほ証券が発注した時点で出たウォーニングを無視して、継続したことも問題です。いつものことだからと思って、無視したのではないでしょうか。ウォーニングを出すこと自体が狼少年になっていたことも考えられます。
この問題には、もう1つの大きな課題があります。損害賠償額の大きさです。通常、契約書上では、損害賠償額は、契約金額の範囲とするのが一般的です。富士通がいくらで契約したかは知りませんが、みずほ証券が被った400億円ではないはずです。
もし、これが契機となり、損害賠償額の範囲が青天井になる可能性もあります。その時は、どのようにして損害賠償額を認定するか詳細を契約書上に記載しなければなりません。現在でも、どのようにして認定するかということはほとんどの契約書には書かれていません。
もし、このようなことになれば、SIベンダーは怖くて契約できないことになるかもしれません。
ITベンダー側も、ユーザのビジネスの結果責任の1部を負わなければならない時期に来ているのかもしれません。ITなしでは、ビジネスが遂行できないからです。
仕様書どおりに開発すれば良いとされた時代から、ユーザのビジネスに強くコミットする新たな時代の幕開けかもしれません。
コミットの方法は、非常に難しいですが、例えば、システム導入で、売上が上がるということを明確にするようなことです。そうすると、今の保守料金体系、アプリケーションのライセンス体系も変化すると思います。
そうなると、ライセンス体系は、売上増加額の一定割合になると思われます。不幸にして、売上が減少してしまった場合には、ライセンス料を請求しない。
開発費用もそうなるかもしれません。
ベンダー側のリスク管理体制が問われるような時代になります。
5年後、10年後に振り返ってみれば、今回の問題は、そんな時代が到来する契機になったと思われているのではないでしょうか。
そのような気がしてなりません。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*