Sier案件で裁判になったプロジェクト【閲覧注意！】

野村証券と日本IBM（係争中）

経緯

野村証券は当時、老朽化した基幹システムを2013年までに全面刷新する計画を進めていた。
さらに、システム開発を野村総合研究所（NRI）に依存する体制からの脱却を狙っていた。
現行システムはNRIが手掛けたもので、ランニングコストが高く新システムの導入が検討されていた。

日本IBMは、スイスの金融系ソフト大手テメノスが開発したパッケージソフト「Wealth Manager」をカスタマイズして導入しようとしていた。
でも、途中から要件定義書にない追加要件が野村証券から多発し始めた。
そして開発に遅れが出始めて、システム開発が頓挫。

開発に失敗した原因

野村證券からの度重なる追加開発の要望がきたため。
発注側という強い立場を利用したAさんが横暴な振る舞いをしたから。
Aさんは社内で強い発言力を持ち、野村の情報システム部門も意見を言いづらい雰囲気があったそうです。

開発の途中で、日本IBMはプロジェクトの途中で野村証券に仕様凍結を求めたものの、野村證券は応じなかった。
さらにAさんは、日本IBMの担当者らに対して「辛辣な他罰的、攻撃的発言」を繰り返したそうです。

X氏は後日開かれた日本IBMとの別の打ち合わせの場（野村証券側はX氏のみ）で新たな業務要件を追加。
そのうえで「今後もIBMに伝えきれていない要件が見つかる可能性がある」などとした。
X氏はその後も変更要求を多発し、日本IBMに対して「他罰的かつ攻撃的な苦情を述べることを繰り返した」と判決文に記されている。

考察

社内で権力は強いものの、システム開発については無知な人がプロジェクトをかき乱したことが失敗の原因のようです。
日本IBMが要件定義を作成したけど、野村證券側はある程度できあがるまではその要件定義をシッカリとは理解できません。
そしてプロジェクトがある程度は進んだ段階で、野村證券側が誤りに気付いて、設計の変更を依頼するという流れが続いたようですね。

システム開発においては、どこかで仕様を決定しないことにはシステムは絶対に終わらないのですが、野村證券の人達にはそれがわからなかったようです。

結果として、以下のような両者の食い違いが起きたまま、時間だけが無駄に過ぎていくことになります。

裁判と賠償金額

裁判の判決は二転三転しています。

委託したシステム開発が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。
プロジェクト失敗はベンダー側に非があるとした2019年3月の一審判決から一転、2021年4月の控訴審判決はユーザー企業側に責任があるとした。

1. 2019年3月の一審判決では日本IBMに約16億円の支払いを命じた（野村の勝ち）
2. 東京高裁は2021年4月21日の控訴審判決で野村側の請求を棄却した。
   逆に野村側に未払いの業務委託料など約1億円の支払いを命じた（反対にSierの勝ち）
3. 野村側は、最高裁に上告を申請中。

NTT東日本と旭川医大（旭川医大がNTT東日本へ14億円の支払い）

経緯

旭川医大がNTT東日本へ、「電子カルテを中核とする病院情報管理システムの開発」を依頼。
プロジェクトの開始直後から、現場の医師から追加開発の要望が相次ぐ。
旭川医大の医師が「現行システムの機能が提供されないと現場の混乱につながり、認められない」と発言し、他の医師も賛同。

NTT東日本が625項目の追加開発要望を受け入れたうえで、いったんは仕様を凍結する。
その後も、仕様凍結後も追加の要望は止まらず、旭川医大はさらに171項目の開発を要望したという。

NTT東日本が納期に納品できずにケンカ別れ。

開発に失敗した原因

旭川医大からの度重なる追加開発の要望が来たため。
要件が決定したので開発に入る → 追加の要望が増える → 要件が決定したので開発に入る → 追加の要望が増える

このような流れが続いたのが問題だったようです。
どうして、最初の時点で要件を決めきれなかったのかは気になります。

考察

Sier開発でよくある話なのですが、旭川医大で働く関係者の人達にとって、「新しいシステムの開発」の優先度は低かったのだと思います。
おそらく、関係者の方にとって、「新しいシステムの成功の有無」は出世や給料には反映されなかったのではないでしょうか？

もう少し丁寧に現場の説明をすると、病院関係者のボスは、「新しいシステム開発のために、なるべくNTT東日本に協力してあげてね」と部下に言います。
部下の人達は、彼ら自身の仕事があり、その上でNTT東日本の人に協力しなければいけないので、どうしても新しいシステムの優先度が低くなります。

そうして、システムが50%ぐらい出来あがった後になってから、「こんなシステムでは使いものにならない！」と文句を言い始めます。
そうすると、システムを修正するために、NTT東日本の方では手戻りが発生して、納期が遅れていきます。
これが、ウォーターフォール型開発の問題点で、最初にシステムの要件をシッカリと決めておかないと、後になって何度も手戻りが発生します。

そうして、以下のような両者の食い違いが起きたまま、時間だけが無駄に過ぎていくことになります。

裁判と賠償金額

裁判の判決は二転三転しています。
旭川地裁は、「NTT東日本は、旭川医大からの要望を断ればよかったやん！」と言っています。

一審の旭川地裁判決は、追加開発の要望を受け入れて開発が遅延すると予測できる場合、「（仕様凍結の）合意を理由に拒絶する」か、代替案を示すなどして「開発要望を取り下げさせるなどの対応を取るべき」とした。

それに対して、札幌高裁は、「旭川医大の無茶ぶりの要求に対して、NTT東は誠意を持って対応した」と言っています。

札幌高裁は、仕様凍結の合意は追加開発要望の拒否に当たるとして、NTT東は開発ベンダーとして「しかるべき対応をした」と認定。

そうして、結果としては、旭川医大がNTT東日本へ14億円を支払うことになりました。
Sier側の勝ち！

IBMとスルガ銀行（IBMがスルガ銀行へ42億円の支払い）

経緯

スルガ銀行が日本IBMに対して、勘定系システムの構築を委託。
日本IBMが、2004年/9月にパッケージ「Corebank」をベースに新システムを95億円で開発することで基本合意して、要件定義が開始される。
3年後の2007年/7月にケンカ別れ。

開発に失敗した原因

基本的には、コミュニケーション不足です。
スルガ銀行とIBMは対等な関係であるべきなのに、スルガ銀行が上司で、IBMが部下のような関係になってしまったのが原因なようです。

日本IBMは再三にわたって、要件定義における要件の絞り込みが不十分であるとスルガ銀行に伝えていた。
このままでは大幅な予算超過を招くとの危惧を何度も報告していた

また、スルガ銀行のパワハラ体質も影響していたようです。

証言によれば、日本IBMのメンバーは、スルガ銀行の責任者や担当者に大声で怒鳴られることが珍しくなかったという。
「厳しい叱責を受けるのはしょっちゅうだった。
提出した資料をその場で放り返されたり、都合のいい答えを返すまで会議室に軟禁されたりしたこともあった」

考察

これもよくある話の一つです。
Sierの場合は、受発注関係があるので、得てしてこのような主従関係ができてしまいます。
現場のエンジニアの気が弱いと、そのまま発注者に押し切られてしまいます。
また、面と向かって反抗するようなエンジニアは、その現場から外されてしまいます。

結果として、以下のような両者の食い違いが起きたまま、時間だけが無駄に過ぎていくことになります。

裁判と賠償金額

そうして、結果としては、IBMがスルガ銀行へ42億円を支払うことになりました。
発注側の勝ち！

インテックと三菱食品（127億円で係争中）

経緯

三菱食品は基幹業務システムの刷新に伴う企業間EDIシステムの構築をインテックに委託したが、そのプロジェクトが頓挫した。

開発に失敗した原因

責任の所在が曖昧だったようです。

システムの完成を請け負った事実はなく、完成義務違反はないとした。
三菱食品が示したプロジェクトマネジメント義務も負っていないとする。
インテックが請け負ったのは基幹業務システム刷新プロジェクトの一部であり、 上位に「プロジェクト全体統括」があった。
プロジェクトマネジメントに関する職務を果たすべきはインテックではなく、 PMOの業務を担っていた三菱食品または委託先ITコンサルティング企業だと主張した。

考察

Sierが手掛けるプロジェクトには、一社だけではなく数社が入ることもあります。
そうすると、プロジェクト体制が曖昧になりがちで、お互いが責任をなすりつけ合う関係になります。

結果として、以下のような食い違いが起きたまま、時間だけが無駄に過ぎていくことになります。

裁判と賠償金額

127億円で係争中！

まとめ

この記事では、Sierの受発注構造、ウォーターフォール型開発、寄り合いチームの負の側面について、実例に基づいて解説しました。
程度の差はあれど、Sier業界で働くとことは、こういったことを経験するということを意味します。
Sier志望の人は、その覚悟をした上でSier業界で飛び込んで下さい。

また、プロジェクトの炎上を避けたい人は、これらの本を一読してみてもいいかもしれません。
色々な視点でのプロジェクトの捉え方がわかるはずです。

「コンサル一年目が学ぶこと」と「予定通り進まないプロジェクトの進め方」は、「Kindle Unlimited」の30日間無料体験で読むのがオススメです ^^
無料体験後も、200万冊以上の本を月額980円で読むことができる、読書好きにはもってこいのプランです。

Good luck with your engineer life!

▼ DevOpsについて詳しく知りたい人は、こちらの記事を読んで下さい