以前、以下の通り、日本IBMとスルガ銀行の訴訟について考察してみました。
その際、調べてみて見つけたのですが、日経テクノロジーオンラインによると、2017年11月、シャッターや建材を手がける文化シヤッターが、販売管理システムの開発委託先だった日本IBMに対し、システム開発の失敗による損害賠償を求めて提訴したそうです。
文化シャッターは防火シャッターの大手です。
防火シャッターでも防げなかった？文化シャッターのシステム開発プロジェクト炎上の考察
ネットで見た中で一番おもしろいというか、シャレの聞いたタイトルがこれです。
この訴訟の経緯を調べて考察してみました。
日本IBMと文化シャッターの訴訟の経緯
日本IBMと文化シャッターの訴訟の経緯は次の通りです。
から引用しています。
文化シヤッターが既存の販売管理システムを刷新するプロジェクトを始めたのは2015年3月のことだ。文化シヤッターは日本IBMに提案依頼書（RFP）の作成を委託。そのRFPに基づき複数のITベンダーから提案を受けたうえで、日本IBMをシステム構築の委託先として選定した。
RFPはRequest For Proposal (リクエストフォープロポーザル)の略。
通常はシステム開発の依頼者がシステム開発の範囲、要望等を作成して、複数のベンダーに提案を依頼しますが、書くのが難しかったり、忙しかったりするので、今回のように依頼者がベンダーに依頼することはよくあります。
普通に考えてみれば、中立を保ったコンサル会社に頼んだ方があるべき姿なのですが、今回のようにRFPをベンダーである日本IBMに依頼したことを考えてみれば、開発も日本IBMに依頼する予定だった出来レースだったんでしょう。
日本IBMの提案は、販売管理システムの構築にERP（統合基幹業務システム）などのパッケージを使わず、米セールスフォース・ドットコム（Salesforce.com）のクラウド開発基盤「Salesforce1 Platform」を利用してシステムを「手作り」するというものだった。稼働時期は約1年半後の2016年7月、総開発費用は約12億3500万円を見込んでいた。
セールスフォースドットコムは世界最大のクラウドプラットフォーム企業です。
日本では2007年に日本郵政公社が採用したり、2009年にエコポイントの導入などで特に有名になりました。エコポイントのシステムに関しては、SaaSの特性をいかして、経済産業省の打診からわずか3週間でシステムを開発し稼働させたそうです。
従来型のウォーターフォール型のシステム開発なら3週間でシステム開発は不可能だろうな。
クラウドプラットフォームについては、そのレベルに応じて、SaaS、PaaS、IaaSがありますが、Salesforce Platform は、クラウド化された PaaS（Platform as a Service, サービスとしてのプラットフォーム）です。
PaaSの場合、ミドルウェアまで用意されているために、ハードウェアの手配や運用、ソフトウェアのインストールの手間が省けてアプリケーションの開発に専念できます。
開発工期が1年半と短いのはPaaSを使って開発しようとしたからだと思います。
また、アプリケーションの部分も完全にスクラッチ開発ではなくて、95%はスクラッチ開発、5%はパッケージの部分を使ったそうです。
SaaS、PaaS、IaaSの違いについては以下にまとめました。
両社は当初、アジャイル開発とウォータフォール開発の併用によるシステム構築を目指していたが、途中からウォータフォール開発のみに方針を転換。要件定義、設計・開発、システムテストと工程を進めた。
1年半という開発工期を考えれば、アジャイル開発が妥当かと。
途中でウォーターフォール開発に変えたのは何かトラブルが起こったのでしょう。
私が推測するに、アジャイル開発を進めてみて、途中で要件が膨らみすぎてスコープがわからなくなったので、要件から再定義したかったのではないでしょうか？
ウォーターフォール開発では基本、局面ごとに進んでいくので後戻りがありません。
ウォーターフォール開発については以下をご覧ください。
日本IBMと文化シャッターのプロジェクト、受け入れテスト(UAT)で不具合多発
プロジェクトは当初予定より数カ月遅れ、両社は稼働時期を2016年7月から11月に延期。
新たな日程を前提に、同年8月にユーザー受け入れテストを始めた。ここで問題が噴出した。
同テストで「多数の不具合が発見され」た。その数は同年10月までに600件以上にのぼったという。両社の会議で日本IBMの担当者は、受け入れテストの段階で不具合が多数見つかった理由として「要件定義フェーズ、設計フェーズの遅延に伴う開発フェーズの期間圧縮・テスト検証不足」を挙げた。加えて、受け入れテスト段階で要件の変更に当たる事項も顕在化し、その理由として「機能要件および外部設計に関するヒアリング・確認が不十分」などを挙げた。
日本IBMは立て直しを図るため、10月末にプロジェクトマネジャー（PM）を交代させるとともに、セールスフォースの技術担当者もプロジェクトに参画させた。だがその後、受け入れテスト工程で発生した追加工程の費用支払いをめぐって文化シヤッターとの間で意見が対立。日本IBMは2017年1月から作業を中断した。
うーん。
別のソースを調べてみると、日本IBM側は要件定義や設計段階での遅延が不具合発生の原因とし、また受け入れテスト段階での要件変更も顕在化していたらしいです。
最終的に不具合は1000件ほどになり、IBMは、うち800件は「仕様変更」と主張していたとのこと。
1年半のプロジェクトで、開発手法もアジャイルからウォーターフォール型へ変えたわけですから、4ヶ月遅れ自体は普通のことでしょう。
そんなに「遅れた！」という印象は感じませんね。
あと、12億円ものプロジェクトなら、不具合が仮に1000件あったとしても、大して多いとは思いません。
仮に1人月100万円のSEがプロジェクトに携わるとしたら、月に70人のSEが1年半携わるプロジェクトなのですから。
コミュニケーションの齟齬やスキルの違いもあるでしょうから、1000件の不具合は許容範囲。
ちなみに、IBMのSEなら1人月200万円から300万円ぐらいはするでしょう。
また、仮にIBMの主張が正しいとしたら、1000件の中で仕様変更が800件、IBM側の不具合は高々200件な訳だから、むしろ不具合は少なかったと言えるのではないでしょうかね。
2016年10月の状況だけを想像するに、UAT (受け入れテスト) で、ユーザーが想定する以上にバグが発生した。
で、「IBMさん、どうしてくれるんだ？」ってことだろうけれど、ちゃんと筋道たててお客さんに説明して自身のバグを地道に直していけばよかったんじゃないのかな？？？
IBMは立て直しを図るためにPM交代したらしいですが、PMを交代すればいいとかそういう問題なのかな。
問題が起きれば、PMのせいにしてPM交代を解決策にする文化はいかがなものか。
きっと、こんな最後に引き継いだPMはまともに事態を収束できないと思うな。
そして訴訟へ
日本IBMはこのうち約800件を「プログラムのバグでなく仕様の変更に当たる」とし、バグは200件弱と主張した。文化シヤッターはこの分類に異論を唱えつつも、システムの早期稼働を優先。まず日本IBMがバグと認めた200件弱の不具合のみを修正してシステムを稼働させるよう、日本IBMに要請した。
IBMに対してIBM自身が認める不具合のみ修正を依頼したのは、文化シャッター側の賢明な判断。
実際の所、本当に不具合なのか仕様なのかは定かではありませんが、IBM自身が不具合と認めたものを修正して稼働させようとする、ここまで文化シャッターが賢明ならプロジェクトはうまく行きそうだけど。
だが日本IBMは文化シヤッターの案を受け入れず、2017年2月に全く異なる提案を示した。Salesforce1 Platformを使ったカスタム開発から、Salesforce1 Platformの標準機能を活用した開発へと方針を転換する内容だ。
これが事実だとすれば、IBMからの提案は極めて不可解。
開発を進めたシステムは、Salesforce1 Platformの標準機能で実装した部分が5％、同基盤上でカスタム開発した部分が95％だった。これを標準機能が80％以上、カスタム部分が20％以下になるよう開発し直す。標準機能を多用するため、画面のレイアウトやシステムの機能にも制約が加わる。
要するに、当初の1年半のプロジェクトでは、SalesForceのパッケージが持つ機能が5%で、カスタム開発が95%だった。
その結果として1000件もの不具合が発生し、おそらくは、IBM自身が認めた200件の不具合も修正が困難。
よって、SalesForceのパッケージが持つ機能を80%以上にして、カスタムで開発する部分を20%以下にしましょうっていう提案か？？？
これが本当？だとしたら、これまでの開発のやり直しを意味するとんでもない提案です。
なんでIBMは、文化シャッターの言うとおりに200件を素直に修正しようとしなかったんだろうか？
IBMにスキルが無いとは思えないので、他の不具合も起こりそうで怖くて直せなかったのか？
あるいはコストの問題だろうか？
それとも200件を直してもシステムは稼働しないっていう判断だろうか。
IBMからの提案、パッケージの部分を80%以上にすればそりゃ、不具合も起こらないわな。
ただ、それなら最初に言えよっていうのが文化シャッター側の主張ではないでしょうか？
過去、IBMとスルガ銀行の訴訟では、途中でIBMがパッケージ変更の提案をしたことに対して裁判所は、
本件システム開発の経緯に照らすと、極めて唐突なものである上、その内容も本件システム開発進行の打開方策としては粗雑なものといわざるを得ず、重要プロジェクトを担うベンダとして不見識、無責任とのそしりを受けてもやむを得ない。
と指摘しています。
IBMはこの訴訟から何か学ばなかったのでしょうか？
まとめ
文化シャッターはシステム開発の失敗を特別損失で計上しています。
東証1部上場の建材メーカー「文化シヤッター」は、2018年3月期第2四半期（累計）連結業績予想を下方修正し、四半期純損益が7億円の赤字に陥る見通しを明らかにしました。
生産性の向上を目的として、新しい販売管理システムの開発を行っていたものの、当初想定した効果が見込めないと判断し、システム開発の継続を断念したことから、固定資産除却損として17億5000万円の特別損失を計上したため、純損益は従来の黒字予想を一転し赤字見通しとなりました。
2018年3月期第2四半期（累計）連結業績予想：文化シヤッター
| 売上高 | 営業損益 | 純損益 | |
|---|---|---|---|
| 前回予想 | 710億円 | 30億円 | 16億円 |
| 今回予想 | 690億円 | 15億円 | △7億円 |
| 前年同期 | 631億6000万円 | 23億9000万円 | 13億3900万円 |
システム開発を依頼して、何かが納品された場合、例え不具合があったとしても会計上は自社の「資産」になります。
その「資産」の価値が無く、捨てるしか方法がないので損失として計上したってことでしょうね。
この訴訟、IBM側からの主張がまだ分からないので今後にも注目していきたいです。
要件定義は難しい。下記も参考にしてください。
コメント
[…] ・https://urashita.com/archives/19379 […]