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

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業界で飛び込んで下さい。

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

Good luck for your engineer life!

▼今後のIT業界の方向性を知りたい人は、こちらの記事を読んで下さい

Sierは必要なくなり、企業でITの内製化が進んでいきます【社員はSierから逃げるべき】

▼日本でクラウド化が遅れている理由を知りたい人は、この記事を読んで下さい

日本のクラウド化はSierのせいで遅れています【Sierは必要ない！】

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

DevOpsが日本企業に浸透しない理由【受発注構造が諸悪の根源】

▼ブログの内容を復習をしたい人は、動画を見て下さい