日経コンピュータにおいて、昨年一番読まれた記事に、スルガ銀行と日本IBMの裁判の記事であった。具体的には2008年3月6日に、スルガ銀行がシステム開発が遅れたことで被害を受けたと、日本IBMに対して111億円の損害賠償を求める訴訟を起こしたことを記事にしたものだ。過去にユーザーがベンダーに対して訴訟を起こしたことはあったが、ここまで大きな金額の訴訟は例を見ない。しかも、スルガ銀行からすると、日本IBMはメインのベンダーで、過去に勘定系システムの構築などを二人三脚で行ってきたことからも注目を集めた要因になっている。 スルガ銀行の主張は、大きく分けると4つに分かれる。1つ目は開発の前提となる勘定系パッケージソフトの導入撤回を提案した件。2つ目は、当初計画したシステム化の対象範囲から、大幅な機能削減を提案した。3つ目は、稼動時期の大幅な延期と、段階的な切り替えを提案した。4つ目は、当初計画には無かった大幅な追加費用を要求したということが訴訟の理由だ。

一方、日本IBM側からの反論として、まず、請負契約は締結しておらず、フェーズごとの個別契約のみ締結しており、義務は履行したということ。次に、大幅な機能の削減と遅延に関しては、要件定義で困難を生じた原因は、現行の業務･機能に固執して、業務プロセス改革を行わなかったスルガ銀行側にあるとした。パッケージ導入の拒否に対しては、拒否したわけではなく、現実的な提案をスルガ銀行側が拒否し続けて、一方的にプロジェクトを中止しただけだと反論した。

この裁判は現在でも続いており、最初のボタンの掛け違いがどんどん増幅され、現在はお互いに味方を付けて意見書を出し合っている状態で、すぐには着地点は見つかりそうも無い。このように、ユーザーとベンダーとの関係は、最近になってものすごく変わってきている。

では、ユーザーとベンダーとの関係はどのように変化してきたのだろうか？　1980年代からのメインフレーム全盛の時代には、ユーザー(情報システム部門)とベンダーとは蜜月関係だった。また、当時は独自環境だったので、責任と義務が明確化されていた。コストやリスクはベンダーが支配し、ベンダー側が運用に参画して業務を熟知することで、改善の提案も容易だった。この頃ならば、先ほどのような裁判は起こらなかっただろう。

ユーザーとベンダーとの関係が変わり始めたきっかけは、オープン時代を迎えてからだ。この時代から一括請負から部分請負へ発注方向が変わった。ユーザー側の窓口が多様化し、情報システム部門だけでなくユーザー部門とも取引を行うようになった。しかも、価格競争がシビアになり、コスト中心の競争の時代になった。これが転じてベスト･オブ･ブリードとして、ユーザー側が分野に応じて最適な取引先を選ぶようになった。これにより、コストパフォーマンスに優れた環境が構築できるようになった反面、責任分担やリスク分担が非常に不明瞭になった。さらに、開発と運用が分断されたことも特徴のひとつになっている。

このため、ユーザーの発注形態も大きく変化している。昔は、システムをリプレイスしたり、新しい物を導入したいと思ったら、今まで付き合ってきたベンダーに依頼して、導入するのが基本だった。ところが、オープンシステムの時代に入り、案件ごとに競わせて選ぶことが基本になった。このことはユーザーから見ると、最もよいものを低コストで導入できるというメリットがあるが、ベンダーから見ると競争の中に追いやられることになり、大きなデメリットになる。

実際に、ユーザーは10社に情報収集を行い、その中の5～6社にRFP提示を要求し、1次評価で2～3社に絞って詳細提案を要求し、最終的に1社に発注するという流れになるが、この間にベンダーのコストは、残れば残るほどコストがかさみ、最終的に受注できないときは膨大なコストは持ち出しになってしまう。このことはユーザーとベンダーとの間に大きな亀裂を生じさせるようになった。たとえば、今まではユーザーから多少無理な要求をされたとしても、赤字分は次回の案件で取り返すこともできたが、今は、ユーザー側が要件を明確に決めてもらわなければ引き受けられないというふうに、ベンダー側が意思表示するようになった。

現在、ユーザー側では経営層からはコスト削減を命題化され、システム部門の人員が削減されているにもかかわらず、JSOX法などによって内部統制を強化する方向にある。一方ベンダー側でもユーザー・ニーズが多様化しているほか、技術は急激に進歩しており、今までのように一朝一夕にはいかなくなった。またユーザーと同様に利益追求、内部統制の強化も叫ばれている。お互いがこのような背景を持っていることから、現在ではそれぞれの言い分がかみ合わなくなってきている。

そこで、ベンダー側ではさまざまな自衛策を講じるようになった。具体的には、まず要件が固まるまではシステム開発契約を結ばないということ。つぎに、具体的な提案をしない。ほかにも提案書とは別にベンダー側が定義した「条件書」をつけるなどがある。このようなことは、現在頻繁に行われているのが実情だ。

このことからプロジェクトで失敗を招くユーザーの典型例として、コストを優先して発注者責任が欠如していることが上げられる。逆に、実績あるITベンダーに丸投げして、安請け合いをするITベンダーばかり使うこともよくない。ほかにも、IT部門と利用部門との関係も失敗を招く原因になる。たとえば、ユーザーからの要望に対して優先順位が付けられなかったり、担当者同士のコミュニケーションがしっかり行われないなどが失敗に結びつきやすい。さらに、経営とIT部門においても、経営者が単に指示のみを行う所は、失敗にいたることが多い。日本の経営者の特徴として、積極的にITを活用している人は少ない。CEO、CIO以外の役員はさらに関心が薄い。したがって、IT部門への関与も腰が引けた状態で、自ら発想や判断ができないのが現状だ。

一方、IT部門の問題点として、専門場所として閉鎖的でブラックボックス化していることから、部門からの積極的な発言や経営層との会話が少ない。一方技術は高度化していることからベンダー依存が強く、信頼されない、相談されない、貢献していないの「3ない」状態に陥っている。
　
ベンダー側の問題として、読者の声を聞くとスキル不足、能力を超えたシステム開発受注、SEの責任感と熱意の弱さ、メーカーの仕様が不明瞭でそのとおりに動かない、責任分担があいまいだ、というような不満の声が上がっている。

1　2　次のページ