最近IT企業がシステム納入できずに、ユーザー企業から提訴される件が年に数回報道される。
裁判になるレベルなので、失った金額は大きく弁償してもらいたい金額も非常に大きい。

http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/00014/

大体のシナリオは、社内システムを新しくしたい企業が、大手IT企業と契約をしたが、思うように開発が進まずにっちもさっちもいかなくなり計画は中止、損害が出た分を払ってほしいとユーザー側が提訴するというのがいつものパターン。

今回の件もそのようなパターンになっている。
日経xTECHの記事には少々状況を詳しく書いているのでよんでみた。
自分はプログラマなのでIBMに同情的になってしまうが、報道を読んで思ったことがある。

一人のIT業界の末端の人間の視点として読んでもらいたい。

もちろん、報道で明らかになっていないところもあり、結果的に瑕疵がどちらにあるのかは判決を待たなければならない。

RFPの作成をIBMがやっていた件について

今回の件はユーザー企業側が販売管理システムを刷新するプロジェクトを始め、IBMに発注したそうだが結果的にプロジェクトは失敗しシステムは納入できなかった。
支払った費用の返還を求めている。

最初にRFPに基づき複数社から提案を受けて最終的にIBMに決まったそうだが、
RFPの作成をIBMにまず委託していた。

RFPとは提案依頼書のことであり、開発会社に提案してもらうために、自分らがどんな要望を持っているのかをちゃんと説明するために書くものである。
かいつまんでいえば「こういうことがほしいです。」という依頼について「我々はこういうのができます」ということをもっと具体的にしてもらうための、「ほしいです」を具体的に書いたもので
ユーザー企業の業務プロセスをどうしたいのかという意思がしたためられているものだ。

本来ならばユーザー企業の情報システム部あたりが担当して、役員など意思決定者が責任を持って現状の業務プロセスに手を入れて、「自分たちはこうする」というのが決まるのが望ましいが、コンサルが入って書くこともある。
だが、コンサルとの意思疎通ができていなかったり、現状の業務プロセスに手を入れようとしなかったり、役員が参加しておらず現状プロセスを変えることができなかったりすると、この時点で曖昧な提案依頼書ができてしまう。

IBMがおそらくコンサルに入りながらも最終的にテストフェーズで要件定義が不十分という結論に達したということから、RFPの時点でもう意思疎通ができていなかったのだろう。

文化シヤッターがというわけではないが、世間一般的に非IT企業では情報システム部の権限が弱い場合があるそうだ。
社内システムは単なる道具としてしか見られておらず、現状業務フローを簡単に素早く終わらせることに主眼が置かれがち。

だが、本来の情報システム部というのは企業の情報を担当する部署であり、社内システムは業務フローそのものである。
社内システムを変え効率を良くするためには、業務フローや社内制度にも手を入れて行く必要がある。
だから役員がメンバーに入り、情報システム部はシステムのお守りだけでなく社内制度にも精通していなければならない。

料理屋で例えるなら、時短テクを使って早く食材を切って早く火を通すなどのテクニックで効率をあげるか、
良い器具を導入、効率の良いレシピに変えて、食材の入荷とロスを減らす仕組みにするなど根本を変える活動もしていくのかの違いだ。

各部署からは手に馴染んだ現状の業務フローがいいという声も上がる。
業務フローは役員がトップダウンで決めなければならないところだが、役員も現状のままでやっていこうという気持ちになっていると、業務フローが変わることができない。
一社員でしかない情報システム部の担当者は他部署の要望をまとめることしかできなくなる。

要件は『現状のまま』だった可能性

「現状のままでいい」という言葉は知らない人が聞けば、新しいことを考えなくていいので楽に感じるかもしれない。
だが、真逆だ。
「今日のご飯はなんでもいいよ」レベルに1番困ると言っても過言ではない。

今回の件も、報道によるとセールスフォースのSalesforce1 Platformで、ほぼカスタム開発で行ったようだが、
カスタムが必要になる場合は、だいたい現状そのままにしたいときに見られるパターンだ。

現状のままで良い場合は、実は現状を詳しく知っている人がいないということが多い。
だからコンサルが入る余地があるわけだが、明文化されていないプロセスについて外部の人間も知ることは難しい。

システムをそっくりそのまま作ると言うのは不可能だ。
絵を見て頑張ってトレースしてもちょっと違う絵になるように、システムも同じようにはできない。
大きな筋は同じにできても、重箱の隅でちょっと違うことがある。
蓋を開けてみれば実はそのちょっと違うことが現状の業務プロセスではなくてはならないことだったということがある。

今回の件では、アジャイルからウォーターフォールに変わったらしい。

アジャイルは開発単位を小さくしてその中で反復して開発をして、短時間（1週間から2週間）で要件から設計、実装、テストまでしてそのサイクルを何度も繰り返していくという開発技法だ。

アジャイルを止めたということは、おそらく機能を細分化できなかったということなのかもしれない。
ばっちり要件を決めて、設計を決めて、全部揃って次のフェーズに行くというウォーターフォールモデルにしたということは、機能を分割できるレベルでの要件でもまとまらないので完全に出来るまで先に進めない状態になっていたのかもしれない。

パッケージに合わせるのが1番楽な道

最終的に今の仕様では納入できないということでIBMはセールスフォースの標準機能でやろうと提案したが、結局それもできずにプロジェクトは破綻したようだ。

社内システムを導入するにあたり、パッケージに業務フローを合わせることが基本になっているが、先程いったような役員不在であったり、部署間との力関係で業務フローを変えることが難しい企業が日本にはままある。

多くの納入できなかった事例では、多くカスタマイズの部分の要件が全然まとまらないことに端を発している。
カスタマイズに頼らず、自社自身をカスタマイズしていく。
これは自社の稼働がかなりかかるわけだが、1番低リスクだ。

IT炎上事例が広く他の業界でも知られて、ユーザー企業はどうすれば危険な橋を渡らないで済むか理解されるといいな。

終わりに

IBMの肩を持つような書き方をしてしまったが、
IBMだって瑕疵がないわけではない。
営業が理想論を語りすぎたり、YESマンだったということもあるかもしれない。

プロジェクトマネージャーがプロジェクトの全貌を把握できず、参加者全員の意識共有できなかったかもしれない。
出来ることと出来ないことのスコープの設定をあやまったかもしれない。
コンサルが夢を語り、それをPMに押し付けたかもしれない。

だれかが100%悪いというわけではなく、誰もが少しずつ失敗をしてこういう事態になったのだと思う。

このブログを非IT企業の人が読んで、IT企業の中の人はこういうところが怖いと思っていると伝われば幸いだ。
そして、みんなが少し失敗しないようになればいい。

ともかく判決でどうなるか今後も注視していきたい。