【IT】27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴
■ このスレッドは過去ログ倉庫に格納されています
アルミ建材大手の文化シヤッターが、販売管理システムの開発が頓挫した責任は委託先の日本IBMにあるとして、約27億4000万円の損害賠償を求めて日本IBMを提訴していたことが、日経コンピュータの取材で明らかになった。
文化シヤッターは2017年11月に東京地方裁判所へ訴訟を提起した。同社は2017年度第2四半期決算（2017年7〜10月）で、販売管理システムの開発継続断念に伴う17億4500万円の特別損失を計上済み。同システムの開発委託で日本IBMに支払った費用などの返還を求める。
文化シヤッターが既存の販売管理システムを刷新するプロジェクトを始めたのは2015年3月のことだ。文化シヤッターは日本IBMに提案依頼書（RFP）の作成を委託。そのRFPに基づき複数のITベンダーから提案を受けたうえで、日本IBMをシステム構築の委託先として選定した。
日本IBMの提案は、販売管理システムの構築にERP（統合基幹業務システム）などのパッケージを使わず、米セールスフォース・ドットコム（Salesforce.com）のクラウド開発基盤「Salesforce1 Platform」を利用してシステムを「手作り」するというものだった。稼働時期は約1年半後の2016年7月、総開発費用は約12億3500万円を見込んでいた。
両社は当初、アジャイル開発とウォータフォール開発の併用によるシステム構築を目指していたが、途中からウォータフォール開発のみに方針を転換。要件定義、設計・開発、システムテストと工程を進めた。
プロジェクトは当初予定より数カ月遅れ、両社は稼働時期を2016年7月から11月に延期。新たな日程を前提に、同年8月にユーザー受け入れテストを始めた。ここで問題が噴出した。
開発やり直しを提案
日経コンピュータが入手した訴状によれば、同テストで「多数の不具合が発見され」た。その数は同年10月までに600件以上にのぼったという。両社の会議で日本IBMの担当者は、受け入れテストの段階で不具合が多数見つかった理由として「要件定義フェーズ、設計フェーズの遅延に伴う開発フェーズの期間圧縮・テスト検証不足」を挙げた。加えて、受け入れテスト段階で要件の変更に当たる事項も顕在化し、その理由として「機能要件および外部設計に関するヒアリング・確認が不十分」などを挙げた。
日本IBMは立て直しを図るため、10月末にプロジェクトマネジャー（PM）を交代させるとともに、セールスフォースの技術担当者もプロジェクトに参画させた。だがその後、受け入れテスト工程で発生した追加工程の費用支払いをめぐって文化シヤッターとの間で意見が対立。日本IBMは2017年1月から作業を中断した。
この時点で見つかっていた不具合は1000件ほど。日本IBMはこのうち約800件を「プログラムのバグでなく仕様の変更に当たる」とし、バグは200件弱と主張した。文化シヤッターはこの分類に異論を唱えつつも、システムの早期稼働を優先。まず日本IBMがバグと認めた200件弱の不具合のみを修正してシステムを稼働させるよう、日本IBMに要請した。
だが日本IBMは文化シヤッターの案を受け入れず、2017年2月に全く異なる提案を示した。Salesforce1 Platformを使ったカスタム開発から、Salesforce1 Platformの標準機能を活用した開発へと方針を転換する内容だ。
開発を進めたシステムは、Salesforce1 Platformの標準機能で実装した部分が5％、同基盤上でカスタム開発した部分が95％だった。これを標準機能が80％以上、カスタム部分が20％以下になるよう開発し直す。標準機能を多用するため、画面のレイアウトやシステムの機能にも制約が加わる。
日本IBMが5月に提示した具体案は、標準機能とシステム要件の適合性を見極めるため要件定義からやり直す内容で、開発に2年4カ月と従来の1.6倍の期間を要するものだった。
文化シヤッターは、この提案は実質的に従来のプロジェクトの成果を破棄するものであり、この段階でプロジェクトは頓挫したと判断。開発失敗の責任は日本IBMにあるとして、同社に支払った開発委託費約22億円を含む27億4475万円の損害賠償を求めて同社を訴えた。
日経コンピュータの取材に対して文化シヤッター、日本IBMともにコメントしなかった。
争点を明確化する第1回弁論準備手続が2018年1月18日に行われ、次回は4月の予定。裁判では不具合の内容や原因に加え、当初の要件定義や開発手法の選択が適切だったかなどが争われることになりそうだ。
http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/00014/ いい加減パッケージ使おうよ
業務をシステムに合わせようよ… システムは最初から完璧を目指すものじゃないんだよといつになれば分かるのか…
安請負の営業トークにも問題あるだろうけど まず業務に合わせてカスタムする必要あるの？
てか、いいかげん業務見直した方が安いよ。標準パッケージに合わせて仕事しろよ。
どうせ企業内で独自の手順作って非効率になってるくせにな。 最初から完璧なシステムなど存在しない。
その時は、完璧なシステムであっても時間の経過とともに経営管理上不具合が出てくる。
最低基準、最低要件が満たされていたかどうかだな。ｗ RFPって依頼する方が作るんじゃなくて？
それも作ってもらうような程度の低さだと、揉める種は仕込み放題でわ スルガ銀行もIBMやったっけ?
ちなみにうちは、IBMは出禁になってます。 システムは出来るだけ、その時その時で柔軟に変更できるようにしていた方が良いよな。 IBMな時点で笑
冷たい外資に、日本のシステム開発とか無理だろ ウォータフォールの典型だよね、プロジェクトの最後で重大な問題が発覚するの。 これはアジャイルやってて業務のややこしさに気づいたパターンやろ 95パーセントカスタムってなんだよｗ
パッケージ導入の意味が分かっていない。
仕様変更も相当出たんだろうな。
要件定義の段階でキーマンをしっかり理解させないといけない。
どちらもあほだろ、こりゃ。 システムの指向性はあっても、一つ一つの業務に関するソフトをパッケージにして、
そのパッケージの集まりが一つのシステムを構成する。
これならば一つの部署のソフトを変更しても全体には影響しない。
家でいえば、部屋の模様替え、一部建て替えだな。ｗ
流石に全体が古くなれば、買い替え・建て替えだ。ｗ >>7
コレだね
業務フローが特殊なのって、単なるマスをかいているだけ
そんなだからマトモに要求仕様が切れず、後追いになって開発現場が大混乱
良くある話だワ >だが日本IBMは文化シヤッターの案を受け入れず、2017年2月に全く異なる提案を示した。Salesforce1 Platformを使ったカスタム開発から、Salesforce1 Platformの標準機能を活用した開発へと方針を転換する内容だ。
これっておそらく現状の成果物として杜撰な要件定義書と動かないシステムがあるだけで、
仕様書や設計書の類がほぼ何も残されていないということですよね(;^_^A？
それなら途中からウォーターホールに変更してUATで問題噴出という経緯も頷ける気がしますけど。
人員整理で全く畑違いの人がSI事業のPMに放り込まれたとかでしょうか？ しかしIBMの担当者は無能だな
出来ないことを請け負うなよ >>7
しかし、その手法が良いか悪いかはフィットアンドギャップ分析を経て決めることですからね(;^_^A・・・
文化シャッターさんが強引にねじ込んだとも思えないのですが。
むしろIBMからそうしようと提案したんじゃないかと思えますね。 いや、これはPMは実直な奴で、顧客の要件を最大限実現させようとしたんだろ。
しかし、SALESFORCEの担当者が入ってきて、こんなのカスタム化しないでもできますよ、と。
業務プロセスを抽象的に把握できる能力がないとこうなるW 受注管理、建材管理までシステムに入れ込むのは、業務がわかってないと使えるものにならないかもね
簡単に粗利が出せる作りじゃないとシステム化する意味がない 日本IBMに数億円のECシステムとハードの発注したけどサービス開始日に稼働しなくてその後数か月全く稼働しなくてひどい目にあった。
プロマネ交代でお茶を濁したが、IBMの部長がトラブル初日に「サーバー一台では無理」だって。
プロマネが無能だし、上級職がチェックしていない最悪の経験だよ。こんな会社要らない。
セールスフォースとかオラクルとか外部会社一切関係ないのにこれだよ。 完璧なプログラムとかないよりも
27億という金を受け取って、案件を請け負ったわけなのだから
IBMが100%悪いやろ
無理なら最初から受けるべきじゃなかった話 しかしいくら悪評ついてもこんな風に日本IBMに発注するアホが次から次に沸いてくるんだから
世間の風評だとかまったく関係ねーなって状態だな >>13
どこを柔軟に作るかという匙加減をするには結局、業務知識が必要なんですよ(;^_^A・・・
まあ、知らないなら知らないで設計担当者や実装担当者がユーザーの業務部門の方と綿密にコミュニケーションを取りながら開発できる態勢作りをすれば良い話なんですけどね。
（現実問題として規模が大きいと難しいでしょうけど）
とくある失敗としてユーザーの情シスなど窓口部署とだけ調整してしまうパターンですね。
しかし、そういった場合でもシステム会社の側から業務部門の方と話したいと言えば良いだけのことなのですが。
ｂｙ かもめ党（鼎 梯仁） >>2
得意先の情シス部長がIBMと仕事して、飛ばされた。
「IBMに騙された」と言っていたな。
>>29
大きい会社さんほど「部署による」「担当者による」という感じですからね(;^_^A・・・
ただ記事を読んだ限りではIBMのマネージャーさんが極端に不出来といいますか、
単純に受託開発の段取りをよく分かって無かったんじゃないかと思えますね。
マネージャー変えてほぼ１から作り直したいと当のIBMが言ってるくらいですから。 れこはIBMの判断による事実上の損切りやろな
すんませーんとは言えないからもう裁判で負け認めるからごめーんみたいな >>6
それは動かないシステムの言い訳にはならない。 >>11
文化シヤッタークラスの会社なら、社内にまともなシステム部門なければRFPを作るには外部の助けを借りるだろ？。
ただ、一般的にはRFP策定にあたった会社は応札しないのが原則。
応札前提だと自社に有利な要求入れるかもしれないから。
そこら辺をしっかりしないで、IBMなら安心と思ってしまったのが間違いの元だね。
1がすべて事実なら、原因の大部分はIVMにある。 ■ このスレッドは過去ログ倉庫に格納されています
