当たり前のことができていれば防げたIT裁判だったのか

注目のIT裁判ですが、双方の上告を退けたので高裁の判決が確定しましたねぇ。

「二審東京高裁は、システム開発の最終合意段階で、日本IBMは中止の可能性もあり得るとの説明をしていないと指摘。それ以降にスルガ銀行が支払った費用について責任を負うとした。
　一方で、「提案段階では中止につながる要因を予測することは困難だった」などと判断。
日本IBMの賠償確定＝スルガ銀システム開発で―最高裁

「プロジェクトの中止の可能性もあり得るとの説明をしていない」がきになるので、もうちょっと関連記事を見てみましょう。

「勘定系パッケージ「Corebank」の同社による機能検証が不足していたことが、システム開発においてITベンダーが負う義務「プロジェクトマネジメント（PM）義務」違反に当たるとして、日本IBMに約74億円の支払いを命じる判決を言い渡した。」
「一方で東京高裁は2013年9月、日本IBMのPM義務違反は、パッケージを選定した提案・企画段階ではなく、その後の要件定義を経て両社が最終合意書を交わした段階で起きた」
スルガ銀-IBM裁判で最高裁が上告を棄却、日本IBMの約42億円賠償が確定

やばいですねー、これはやばい。SIerはどうすればいいのでしょう。特に「プロジェクトマネジメント義務違反」は、具体的に何をさしているのでしょう。これがわからなければ、プライムコントラクタでSIの請負(推測ですが)なんてうかうかと契約できないです。

「システム開発を継続するなら、開発費用、開発スコープ、開発期間のいずれかを抜本的に見直すか、それが困難なら開発そのものを断念するかを決定すべき局面だったとした。」
スルガ銀-IBM裁判で両社が上告（2/2）

基本的にどこのSIerもプライムで契約していたら「やりきる」の原理原則でプロジェクトを推進するものです。名誉ある撤退なんていう作戦はあり得ません。それは、同時並行している別案件への影響や撤退後の出禁やらビジネスでの風評被害があるからです。第一、離婚と一緒でやりきるより分かれるほうがコストも精神面もヘビーと言われていますから。

「システム開発を継続するなら、」の文面だけを読むと、「ふつうの」プロジェクトマネジメントをしていれば、クオリティ(スコープ)、コスト、デリバリ(納期)のリスク管理ができていて、プロジェクトの推進上の課題とプロジェクトへ与える影響をステークホルダであるお客さまとステアリングコミッティで共有できていれば、先の「プロジェクトマネジメント義務違反には当たらない」のではないか、と思うのです。

たぶん、この裁判に提出されたエビデンスで「プロジェクトの継続する上での困難な状況であった」と認定されるなにかがあったのではないか、と推察されます。

そして、その「なにか」はステアリングコミッティで「共有されなかった」もしくは、「それが記されたエビデンスが残されていなかった」と言うことなのではないかと思うのです。

ただ、その段階が要件定義後の契約のタイミングなんですねぇ。

「一方で東京高裁は2013年9月、日本IBMのPM義務違反は、パッケージを選定した提案・企画段階ではなく、その後の要件定義を経て両社が最終合意書を交わした段階で起きたとして、賠償額を約42億円に減額する判決を下した。」
スルガ銀-IBM裁判で最高裁が上告を棄却、日本IBMの約42億円賠償が確定

契約の観点でいえば、要件定義後に再見積をしていることが想定できます。要件定義でパッケージプログラムとのfit&gapを把握し、その差異から、基本設計以降の契約条件を見直すことができたはずです。教科書的には。

そうしたのか、そうできなかったのかは、当事者ではないのでわかりませんが、いづれにしても最終合意を交わしたという状況からは、QCDの観点ではプロジェクトは完工できるとストーリを仕立てたわけです。

そうだとすると、その見積をした側に要件定義で抱えていたプロジェクトリスクを掌握できていなかったか、掌握できたけれど見なかったか、それとも問題を次工程の契約に放り投げたか、ではないのかしら。

まぁ、この再見積のタイミングでSIerの開発責任者がプロジェクトの中止を申し入れをできる状況下にあるか、といえば…ねぇ。「やりきれ」とプロジェクトマネージャに言うんでしょうねぇ。