プロジェクト炎上からの115億円訴訟、PM失敗、書き換えられた議事録、現場感覚と裁判所の判断のズレ、メンツ潰さずクギだけ刺す、AI議事録対策―――教訓だらけのスルガ銀行vs日本IBM事件

プロジェクトが炎上してから、「こうなると思った」なんて結果論や後知恵バイアスでマウントを取ってくる人がいる。タラレバ論の事後孔明は、漬物石を括りつけて東京湾に沈めるのが世のため人のため。

だが、爆発したプロジェクトの焼け跡を調べ、ボヤを燃えひろげない手立てを考えたり、訴訟リスクを下げる教訓を掘り出すのは有効だ。

この記事では、2013年9月26日東京高裁の、スルガ銀行vs日本IBM事件の判例を元に、「同じような炎上には、どう対処するか」という観点から教訓を引き出す。

あいまいな契約、決まらない要件定義、非協力的なユーザー、動かないカットオーバー、二転三転する提案、激怒する経営陣と、およそ考え得る「炎上プロジェクト」の全ての地獄が詰まっている。ラーメンのトッピングなら「全部入り」、中華料理ならフルコース「満漢全席」だろう。

判決から述べると、こうなる。

• 一審は、日本IBMに対し、スルガ銀へ74億円の損害賠償を命じた
• 控訴審は、日本IBMの賠償責任を認めつつ、賠償額を41億円に減額した

IBMの訴えは退けられ、スルガ銀に損害賠償を支払うことになるのだが、だからといって一方的に「IBMが悪い」という話に留まらない。「IBMがバカだった」で済まそうとするならば、同じ状況で似たような過ちに陥る。

「要件定義が決まらない」なんて日常茶飯事だし、「協力しないユーザー企業」なんてあたりまえで、カットオーバーの動かざること山のごとし。それでも、なんとか回していくのがエンジニアであり、PMだろう。

そんなとき、どうすれば良いか？

一つの指針が、IBMとスルガ銀が見た地獄だ。あなたのプロジェクトを、この地獄の一丁目に行かせないために、どんな教訓が活かせるか、それを掘り出してみる。

なお、判例は WestlawJapanで読める。図書館だと無料で読めるのだが、淡々とした判例文なのに、血で書かれたような生々しさで、動悸・息切れハンパない。そこら辺のホラーよりもずっと怖いので、ご注意を。

炎上から訴訟までの経緯

もともと、IBMはスルガ銀のシステム管理や運用支援を行っていたという。

2000/12　基幹系システム構築の提案を依頼
2003/7　汎用パッケ ージ 「NEFSS」を元に新経営システムを提案
2004/9　基本合意契約1を締結
2004/12　基本合意契約1を訂正した基本合意契約2を締結

この間、開発スコープの範囲が定まらず、計画していた要件定義作業が難航、最終合意の内容を固められない状況が続いた

2005/9　最終合意を締結、プロジェクトの基本運営の覚書を交わす（この時点で、要件定義作業は完了していない）

それでも進捗は難航し、開発日程どおりにシステム稼働ができない状況で、IBMより計画の見直しが提案された

2008/1一括サービスイン（当初計画）
2008/1～12の4段階サービスイン（2006/11提案）
2008/1～2010/1の5段階サービスイン（2007/3提案）

スルガ銀の責任者が激怒、IBMとの信頼関係が失われる

2007/7　スルガ銀は内容証明郵便により、IBMとの契約解除（IBMの債務不履行）

開発中止により大損害を被ったスルガ銀はIBMを相手取り訴訟を起こす。

スルガ銀の主張は以下の通り。IBMに対し、損害賠償＋原状回復により115億円の支払いを求める。

1. 本質的義務違反（2008/1までに89億でサービスインする義務違反） 
2. プロジェクトマネジメント義務違反
3. IBMの説明が不十分のため、スルガ銀は誤った認識で契約したとして、個別契約は無効

IBMも反訴する。

1. 未払の個別契約の代金の13億円の支払い
2. ユーザーの協力義務違反の不法行為に基づき、 NEFSS構築のための投資相当額110億円の支払い

書き換えられた議事録

炎上プロジェクトで、いちばん怖いものは何か。

バグか、遅延か、隠し仕様か、追加コストか。

もちろん、どれも怖いが、やりようはある。コスト・スコープ・スケジュールのどれを削ってどれを優先するかの話になる。「全て最優先でやれ」と言ってくる人は至近距離＆フルパワーで「ご説明」すると、だいたい引き下がってくれる（坊主頭で行くと効果大）。

だが、本当に怖いのは、会議で「ご説明」したはずのリスクが、議事録では別の意味に変わって残ることだ。

その怖さが凝縮された場面がある。

第12回ステコミの議事録だ。ステコミ（ステアリング・コミッティ）とは運営委員会のことで、プロジェクト全体方針を合わせる、いわゆる偉い人会議のことだ。

そこに、こうある。

設計局面以降の見積りコストが当初の計画内に収まらない可能性があるという課題を引き金として、パッケージベースの開発、横展開の資産となるシステムの構築および結果としてのコストの削減を目標とした対策実施を検討中（IBM社内の課題）
2005/10/19　第12回ステアリング・コミッティ議事録（変更前）

日付に注目してほしい。前月の2005年9月に最終合意したにもかかわらず、10月に「当初の計画内に収まらない可能性」が指摘されている。下っ端の悲鳴ではなく、偉い人がステコミで発言しているのだから、この危機感は相当なものだと読み取れる。

これが、スルガ銀の指示により、こう削除された。

設計局面以降の見積りコストが当初の計画内に収まらない可能性があるという課題を引き金として、パッケージベースの開発、横展開の資産となるシステムの構築および結果としてのコストの削減を目標とした対策実施を検討中（IBM社内の課題）
2005/10/19　第12回ステアリング・コミッティ議事録（変更後）

灰色の文字は、削除された文言だ。

削除後に残る文面は、まるで別物になる。

コスト超過リスクへの警告は消えて、「パッケージベースの開発や横展開の資産化を、IBM社内で検討している」という改善課題に変わっている。単なる表現の修正ではなく、プロジェクト全体の危機が、IBMの社内の課題に見えるように丸められている。

IBMがステコミで指摘しているのには、理由がある。

そもそも、基本合意書には、「ユーザ側の費用も含めて95億円以内にすることを確約する」と明記されているし、最終合意でも支払総額が「89億7080万円」と記載されている。当初、スルガ銀は予算枠で進めることを重視し、契約文書にも記載していた。

だからこそ、IBMはその枠を超える可能性を警告した。そして、単に警告するだけでなく、対策の検討をしていると報告した。

にもかかわらず、「コスト超過の可能性」が、スルガ銀側の指示で削除された。

削除された理由は、判例には書かれていない。想像だが、「当初計画に予算が収まらない可能性」が公式資料に残ることを避けたかったのではないだろうか。そのため、予算超過リスクの表現を弱めるために、削除したと思われる。

しかし、結果的として、この削除が「予算超過のリスク警告」から「IBM社内の改善」に変わってしまったことは事実になる。

この事実を重く見るなら、「IBMはまったく説明していなかった」と責めるのは無理があるだろう。

裁判所の判断

もっと怖いのはここからだ。

裁判所は、スルガ銀が削除したことを認定している。削除前の文章も、削除後の文章も把握している。

それにも関わらず、裁判所は、プロジェクトマネジメント義務違反を認めた。特に、危機を説明して判断を促す義務があったにも関わらず、それをしなかったと判断した。

なぜか？

裁判所からすると、これは「スルガ銀が経営判断すべき危機」として提示されたものではなく、「IBM社内の課題」として整理されたものに見えたからだ。文章の末尾に、「対策実施を検討中（IBM社内の課題）」とある。

この一言を重く見ている。前半は、「コストが枠に収まらない可能性」つまりプロジェクト全体の危機を指している。一方、後半は、「IBM社内の課題として検討中」とある。危機の主語があいまいなのだ。

相手のメンツを潰さないよう、穏当な表現としたかったのかもしれないが、これが命取りとなる。スルガ銀が判断すべきプロジェクト全体のリスクなのか、IBMが社内で対応する改善課題なのか、ぼやけてしまっている（削除後の文面では、明確に後者のものに見える）。

もし、危機があったのなら、中止も含めた計画変更を提言し、それをしなければ不利益を被ることを伝える必要があったはずだ。それをしなかったので、義務違反だと判断している。「IBM社内の課題」と書いた以上、それは（前半の主語はともかく）IBMの課題として読まれる。後から「スルガ銀に危機を伝えていた」と言っても、確定した議事録にはそう書いていない。

メンツ潰さず釘を刺す

裁判所は「リスクがあり、不利益になるなら、それをちゃんと伝えるべき」という。それをするのが、プロジェクトマネジメントであり、しなかったので契約義務違反だと。

だが、プロジェクト全体に影響を与えるようなことを、いきなりステコミで言えるのだろうか？言えるわけない。

例えば、こんな風に真正面から行ったら、一発退場だろう。

契約に記載されたコスト超過リスクがある。だから貴行にてスコープ削減し、追加費用、納期延長、中止を判断してほしい

人は変化を嫌がる。

だから、いきなり対決モードではなく、口頭では丸めて伝える。こんな風に。

現時点において、見積もりの前提で課題感が見えている。別途、実務者間で協議をして、選択肢をまとめるので、次回以降の判断材料として相談させてほしい。

断定を避け、ふわっとした言い方にするため、「課題感」とか「スケジュール感」といった物言いがある。曖昧な表現は心底キライなのだが、こういう時は使わせてもらっている。「見込みとして〜」とか「気になる点は〜」といった言い回しも便利だ。

ただし、議事録にはこう残す。あくまで、プロジェクトの目的（ここではコスト枠内に収める）のための営みだという言い方にすると、カドが立ちにくい。

見積もりコスト超過リスクを避けるため、別途検討会を設けて、影響範囲や選択案を整理する。

リスクがあることを、「〇〇というリスクがある」というのではなく、「〇〇というリスクを避けるための方策として〜」と言い換える。そして、その方策はお互いの調整により決まると言うことで、ベンダーだけでなく、プロジェクト全体で未解決の問題だと印象付ける。

あるいは、「コスト超過」や「リスク」とった言葉自体を避けるなら、「前提条件の再確認をしたい」と言い換える。「決めるべきことが輻輳してきたので、優先付けを確認させてほしい」という「お願い」の形にすると、相手のメンツを傷つけずに、決めるべきこと（＝課題）があることを議事録に残せる。

要するに、「（課題の）頭出し」というやつ。プロジェクトの前提や方針に大きな影響がある場合、ステコミでは触れておくにとどめる。「ジャブを打っておく」とか「軽い予告」という人もいる。

そして、「ジャブ」を打ちつつ、下々の人がまとめた対策案を課長間で提示する（担当～PMレベルでの調整）。そこでコスト・スコープ・スケジュールのどれを削ってどれを優先するかの話を握ったうえで、ステコミに当てに行く流れだ。もちろん落としどころ（逃げ場）も考えてあげて事前に課長間で渡しているから、唐突感による拒絶反応を避けることができる。

AI議事録の対策

議事録の件だけでも、こんなに恐ろしい。

「言った／言わない」を避けるために、会議はレコーディングし、議事録を残す。だが、言ったはずのことが歪められ、まるで違う問題にされてしまい、それが「正」となる。削除後の議事録がどこまで行き渡ったか、削除に対するIBMの反応はあったのか等は、判例に残っていない。大人の判断で丸められた議事録は、後から不利な証拠とされる。

ここから何が学べるか。

私の場合だが、偉い人会議でしゃべったことは、しつこいほどトレースし、少しでも想定と異なることが残されそうになった場合、必ず修正させている。

昨今だとAIに要約させた、微妙に焦点のズレた議事録が出回るようになったが、それも追いかけて、曖昧な点を念入りに潰す。AIの場合、してもいない約束を、言葉尻だけで「約束した」と要約する。これ本当にイヤだが、そういう、どっちでも取れるのらりくらりとした発言をしている方にも問題がある（私含めて）。

なお、レコーディングしている会議の場合、時期や金額など、言質を取られそうな部分は、どんなにクドくても、必ず、目的語や前提条件とセットで発言している。

AIは数字の発言を記録しようとするが、人は数字をしゃべるとき、その前提や文脈を省略しがちだ。結果、数字が独り歩きするきっかけとなる。「数字を口にするときは前提とセットで」は、AI要約が標準になりつつある今、声を大にして広めたい。