目次を閉じる
シェアハウス問題で揺れるスルガ銀行、日本IBMと訴訟の過去
スルガ銀行には、かつて昭和46年に導入し、30年以上にわたり利用してきた基幹システムがあった。
同行は当時、このシステム刷新の提案を日本IBMに依頼するも、結果としてプロジェクトは中断、どちらに原因があるのかを裁判で争うことになった。
最終的には、日本IBMがスルガ銀行に対して74億円あまりの支払義務があることが認められ、結果としては、スルガ銀行の主張が認められたという格好だ。
時系列で事件を整理すると次のようになる。
| 年月 | 出来事 |
|---|---|
| 2004年9月 | パッケージ「Corebank」をベースに新システムを95億円で開発することに基本合意、要件定義が開始される |
| 2005年9月 | 2008年1月に新システムの稼働を目指す「最終合意」を交わす |
| その後2回の要件定義を実施するが、要件確定に失敗する | |
| 2006年8〜9月 | システムリリース時期の延期を日本IBMが提案するも、受諾されなかった |
| 2006年11月 | まで折衝を重ねて、「2008年12月にリリースとしましょう」との合意に至る |
| 2007年4月 | 採用パッケージの変更を日本IBMから提案する |
| 2007年7月 | 契約解除通知＝中止となった |
この一連の流れを読んで、「この人たちは、一体この3年間のなかで、実際になにかモノを作ったのだろうか？」という疑問が生まれるかもしれない。
そう、この案件では一度たりとも「開発フェーズ」に着手していない。ずっと「何をどう作るか」「いくらでいつまでに作るか」の議論をループさせているだけなのだ。
これぞまさに必要な作業が一切前に進まない負のスパイラルにはまった、目的地と進め方が決まらない漂流型プロジェクトである。
スルガ銀行、日本IBMと訴訟で賠償金を勝ち取るも
本件裁判で賠償金を勝ち取ったスルガ銀行だが、同行が日本IBMに対して、自分たちに有利な記録となるような議事録を残すように強要していたことが日経コンピュータ（日経BP社）の取材で明らかにされている。
「そんなこと、拒絶すればよかったではないか」と思うかもしれないが、証人尋問では、叱責や軟禁などの手段を使って強要されたというから、いささか度が過ぎた話だ。
ベンダー側の担当者からすると「いつか不利になる話だとしても、この場でそれを受け入れれば、当面の苦痛からは開放される」と感じてもおかしくはない状況である。
いま現在、女性専用シェアハウスに関連する事件が取り沙汰されているスルガ銀行だが、こちらでも組織的な不正の可能性が高いことが指摘されている。
短絡的な憶測は避けるべきだが、社風や体質といった面で問題があったのではないかと深読みしたくなる。少なくとも、まったく別の事件で、類似した組織行動が指摘されるというのは、着目するに値する事実だろう。
筆者の経験でも、システム開発プロジェクトにおいては、その企業の社風や体質が顕著に現れやすいと感じることがある。
願望ではなく事実を重視し、合理的な意思決定をを大事にする企業もあれば、上意下達の圧力が強く、中間管理職陣にいわゆる「忖度」の傾向が強い企業もある。
要件定義フェーズにおける「Corebank提案」の是非
システム構築の話に戻そう。ものづくりの世界には、「QCD」という言葉がある。次の3要素に着目し制御することで、生産活動が良くなるようにマネジメントするための概念だ。
- Quality（品質）
- Cost（コスト）
- Delivery（納期）
「QCD」は、システム開発においても大事な観点である。その握り方がプロジェクトの成否をわける生命線となる。つまり、Q＝「何をどう作るか」とC＝「いくらで」、D＝「いつまでに」作るか、ということだ。
本件の時系列的な流れを見ていくと、まずは採用するパッケージありきで次の合意がなされている。
- C（コスト）：約90億円
- D（納期）：2008年1月にリリース
スルガ銀行は、この「握り方」にこそ問題の根源があった。
Q＝品質基準とその実現方法の想定が不明瞭な段階で、費用と納期を約束してしまうことが問題なのである。
実務の現場ではよく、「ざっくりでいいから概算で」とか、「概概算でもいいから、だいたい〇〇万円ぐらいですか」なんて言葉が交わされる。
これが非常にくせ者なのであって、Q＝「何をどう作るか」が決まっていないものに対して、「概算」というものは原理的に算出不可能なのである。
開発実績が多い横展開型のプロジェクトなら「目安」「参考見積」を提出することもあるが、やめておいたほうがいい。
筆者の周辺でしばしば目にする話であるが、「参考見積」がいつのまにか「概算」に読み替えられて、気づけば「社長稟議」の根拠にまで祭り上げられてしまい、いざ開発しようとするとお金も時間も全然足りない。
追加予算の稟議はけんもほろろに却下され、進むも地獄、退くも地獄。後の祭。こうなってしまっては誰も幸せにはなれない。
本件事案においては、旧システムのリバースエンジニアリングを含めて、3回もの要件定義プロジェクトを実施したが、ついに要件を確定できなかったという流れがある。
それと同時並行で、リリース時期を2008年1月から12月に変更する交渉を、3か月もの時間をかけて行っているところがポイントだ。
ここで起きているのは考えるだけでも恐ろしい負のスパイラルである。
- 何をどう作るかが見えていない
- 打ち合わせを重ねる
- C（コスト）とD（納期）の残存リソースが削られる
- リカバリ方策を求められる
- 残存リソースがもっと削られるが、妙案なし
- Q（何をどう作るか）がもっと見えなくなる
プロジェクトが一度このレールに乗ってしまうと、どんな優秀なプロジェクトマネージャであっても、打開はできない。
「うちはこれだけ大きな費用を支払っている」「おたくはこの世界のプロなんだから」なんとかしなさい、するべきだ、と、ユーザー側企業は主張する。
問題が大きくなればなるほど、この2点を根拠にして強行に主張する。しかし、残念ながらそれは問題を解決には導かない。それどころか、解決をより困難にするのだ。
