4回方針変更されて納期に間に合わず破綻→21億円が請求される訴訟となったプロジェクトから学べること『システム開発のトラブル回避は裁判に学べ』

「やってはいけない」悪手をアンチパターンというが、システム開発プロジェクトにおけるアンチパターンの満漢全席の事例がある。

1. 要件定義も含めた一括で請負契約（契約額7億円）
2. 「あるべき姿」を曖昧にして要件定義が未確定のまま開発スタート
3. 現場の要求が統一できず、業務改革派と現行踏襲派が揺れる
4. アーキテクチャレベルでの方針転換が4回繰り返される（現行踏襲→統合型→既存業務維持→コアシステム独立化）
5. 顧客関係を優先しスコープ外作業も善意で対応
6. 要件整理・再設計の必要性を再三警告しつつも開発を進める

結果、プロジェクトは混乱し、納期には間に合わず、完成見込みも無くなった。

発注側は契約解除して、損害賠償請求の訴訟を起こし、他のベンダへ再開発を依頼した額（20億円）、現行システムの延命費等で、総額21億円の総被害額を主張する。

一方、ベンダ側は、方針変更が繰り返されたこと、ユーザ側のコンセンサス形成不足で、当初想定を大幅に超える複雑さが一方的に通知されたとし、発注側の協力義務違反を主張し、未払い報酬＋契約外作業費用等で13億円を請求する。

『システム開発のトラブル回避は裁判に学べ』で解説されているのだが、胃をキリキリさせながら読んだ。これ、下手なホラーより段違いで怖い。

開発プロジェクトをやってるなら、身に覚えがあるだろう。程度の差こそあれ、普通にSI屋の現場で起きうることだ。

だが、悪手がフルセットで発生し、アンチパターンの悪循環に陥ったらどうなるか？プロジェクトは炎上爆発し、跡形もなくなる。

教訓と学びが得られる恰好の機会なのだが、「失敗＝失態」とみなされ、隠される。偉い人の会議で損失計上され、「ちゃんとやりましょう（意訳）」と周知されてお終い……ってマクドで女子高生が言ってた。

社会的な影響を及ぼすような騒動はネットやマスコミで知ることはあれど、センセーショナルな箇所だけ取り上げられて、再発を防いだりリスクを下げる学びは少ない。かつて日経で「動かないコンピュータ」があったが、取材を受けてくれる企業は皆無だろう。

そんな場合は、トラブルの判例が参考になる。

プロジェクトが爆発しても、費用や損害賠償など、オトシマエを付ける必要がある。泣き寝入りして裁判沙汰にならないケースが大多数だろうが、表に出るのであれば、互いに言い分があるに違いない。

そうした中で、「陥りがちな罠は何か？」「どうしたらよかったのか？」という観点で裁判所の判断を解説する。

一審の判決

冒頭のアンチパターン満漢全席の例では、「1. 要件定義も含めた一括請負契約」が最悪手になる。

裁判所の判断では、「要件定義を請け負うとは、すべてを請け負うこと」になる。

そして、契約の最終目的を果たすものを作る責任はベンダーにあるとする。要件定義から請け負ったベンダーの責任は、当初示された要件を満たすシステムを作ることではなく、契約の目的、即ち業務改善に資するシステムを完成させることにあるというのだ。

この判断、現場目線だと、明らかに変だ。

契約の目的を果たすために要件を整理するのだが、それが充分決まらないままスタートし、さらに大きな変更を追加して、それでも（一括契約だから）同じ価格で提供しろというのは、常識はずれといっていい。

ラーメンを注文して作っている途中に「やっぱチャーハンにして……それもキャンセルして、ステーキにしてね、同じ値段で」と言っているようなものだ。

だが、現場感覚では理不尽に見えるが、裁判所のロジックは別にある。

まず、要件が大幅に変わっても、スコープ外の作業だとしても、それでも開発を進めていたという事実がある。

ベンダ側としては、多少の無茶は呑み込んでも顧客との関係性を優先させたいという「善意」と、撤退した際のサンクコストが大きすぎるといった事情があったからだろう。

だが、それが裏目に出て、「それでも契約を解除せず、作業を継続した以上、完成義務は残る」というものになる。ITの専門家として携わる以上、プロジェクト遂行の是非を含めたマネジメント義務ができていなかった……という考え方になる。

裁判所が見ているのは、「現場がどれだけ苦労したか」ではなく、「契約関係をどう処理したか」に尽きる。

結局、裁判所は、ベンダ側に債務不履行責任があるとして、ベンダ→発注側に1.4億円の支払い命令をする。そして、ベンダ側の請求は全て棄却された。

二審の判決

これが控訴審では逆転する。

裁判所は、発注側の責任を重く見る。要求を整理しなかったことや、情報提供が不足していたこと、方針転換のくり返しを問題視して、「基本方針が二転三転したのでは、円滑な開発を遂行することは不可能」とまで述べる。

そして、ベンダ側が契約変更の要求をしていたこと、要件が未整理で、再設計の必要性を再三通知していたことを認定する。

その上で、「完成不能になった原因は、発注側の協力義務違反にある」として、今度は発注側→ベンダに7.7億の支払い義務を認めることになる。

後知恵で学ぶリスクヘッジ

ここまでこじれる例は少ないだろうが、もし、似たような炎上に出くわすなら、どうすればよかったのだろうか？実態としてできる／できないはともかく、教訓は大量に得られる。

1.要件定義も含めた一括で請負契約

　　・要件定義を準委任に
　　・業務改革とシステム実装を別契約に
　　・要件定義完了時点で再見積もり

2.「あるべき姿」を曖昧に要件定義が未確定のまま

　　・管理表でオープン項目を明文化
　　・最初に業務フローを確定
　　・要件凍結日を契約書に明文化

3.現場の要求が統一できず、業務改革派と現行踏襲派が

　　・発注側に最終意思決定者を配置
　　・現場の調整役から降りる
　　・業務改革会議と開発会議を分離
　　・要求の優先順位化

4.アーキテクチャレベルでの方針転換が4回

　　・方針変更時は契約変更・再見積もりを必須に
　　・変更に伴う影響分析を必須にし、変更コストは経営層判断

5.顧客関係を優先しスコープ外作業も善意で対応

　　・「善意」ではなく正式作業化、チケット化
　　・口頭依頼の禁止、全依頼のレコーディング

6.要件整理・再設計の必要性を警告しつつ開発を進める

　　・「警告」ではなく「停止条件」の明文化
　　・継続不能条件を事前に設定
　　・GO／NOGO意思決定のルール化

もちろん、これらは完全に後知恵だ。

この判例となった案件を始める時、まさかここまで炎上するとは思いもよらなかっただろう。あるいは、これらの全てに関わる人はごく少数だろうし、「気づいたら巻き込まれていた」人が大多数に違いない。

それでも、異変を感じたらこの判例と照らし合わせ、アンチパターンに応じた対策を、後付けでもいいから手を打っておく。

もし、実態として難しいなら、せめて、裁判沙汰になったとき、少しでも有利になるよう、議事録、警告メッセージ、オープン項目等をエビデンスとして残しておくといった防衛策はしておきたい。

システム開発は、「技術」の問題であると同時に、「契約」と「組織」と「意思決定」の問題でもある。

厄介なのは、炎上プロジェクトの多くが、最初から悪意や無能で始まるわけではないことだ。「まずは進めよう」「顧客との関係維持のために」といった現場の判断が積み重なった結果、気づけば誰も止められなくなる。

要件変更、スコープ膨張、善意の無償対応など、開発トラブルの判例における様々な争点は、今も多くの開発現場で繰り返されている問題が、極限まで拡大した姿だ。

だからこそ、判例には価値がある。

そこには、「何をすべきだったか」だけでなく、「どこで止めるべきだったか」「何を文書化すべきだったか」「どの時点で契約変更すればよかったか」といった、リスクヘッジの対策が大量に埋まっている。

炎上案件の判例は、失敗談であると同時に、未来の事故を避けるためのケーススタディでもある。

そして、これが下手なホラーよりも段違いで怖いのは、「特殊な事故」ではなく、「普通に起こりうる未来」として読めてしまうからだ。

他にも、無能だったので退職するなら2,000万円払うよう請求された話や、ワンマン開発体制のメンバーが急死してプロジェクトが詰んだ話、セキュリティホールの責任を「個人が」払わされる話など、ヤバすぎる裁判沙汰ばかり紹介されている。

最初は胃をキリキリさせながら読んでるうちに、恐怖心が麻痺してくる。「言うて、まだ死んでないし」と思うと、少しは気が楽になる。