“標準機能8割”のはずが、なぜ“カスタム95％”になったのか？――文化シヤッター×日本IBMから学ぶ設計の教訓

DX（デジタルトランスフォーメーション）を進める多くの企業にとって、「スピーディに」「コストを抑えて」「確実に」システムを導入することは大きな関心ごとです。特に近年では、SalesforceをはじめとするPaaS（Platform as a Service）を活用し、標準機能をベースに開発を進める方式が一般的になりつつあります。

しかし、設計段階での判断を誤ると、PaaSのメリットが逆にリスクへと転じてしまうこともあります。本コラムでは、文化シヤッターと日本IBMの間で実際に起きたシステム開発トラブルの事例をもとに、PaaS開発に潜む設計リスクとその教訓についてわかりやすく解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】文化シヤッター訴訟にみるDXの落とし穴、PaaS活用失敗で日本IBMに賠償命令

文化シヤッターの販売管理システム刷新において、日本IBMはPaaS「Salesforce1 Platform」での開発を請け負ったが、カスタム開発が想定の20％から95％に膨張し、開発は頓挫。東京地裁は、同社がPaaSの技術的制約を軽視しプロジェクト管理義務を怠ったと認定し、19.8億円の賠償を命じた。DX推進には、標準機能の活用と業務プロセス改革の両立が不可欠である。

出典：日経コンピュータ、2022年8月4日号 pp.104-106「販売管理システムの開発が頓挫　日本IBMに19.8億円の賠償命令」

【記事要約】文化シヤッター訴訟確定、DX失敗の責任問われ日本IBMに約20億円の賠償命令

文化シヤッターのDX推進の一環で始まった販売管理システム刷新が頓挫し、日本IBMに約20億円の賠償が確定した。最高裁は2025年1月、双方の上告を棄却。PaaS「Salesforce1 Platform」の制約やカスタム開発の過剰による構築失敗が主因とされ、プロジェクト管理の不備がDX失敗に直結した。本件は、クラウド活用における適切な設計と標準機能重視の重要性を浮き彫りにしている。

出典：日経クロステック「文化シヤッターのシステム開発訴訟の判決が確定、日本IBMに20億円の賠償命じる」2025年1月15日

想定は“標準8割・カスタム2割”、現実は“カスタム95％”

文化シヤッターは、老朽化した販売管理システムの刷新を目的に、日本IBMに新システムの構築を依頼しました。提案時点では、SalesforceのPaaS「Salesforce1 Platform」を活用し、「標準機能80％、カスタム開発20％」という前提でプロジェクトがスタートしました。

ところが実際には、最終的にカスタム開発が全体の95％を占めるという、当初の想定を大きく逸脱する結果に至ります。その原因は、旧システムの画面レイアウトや業務フローをできる限り踏襲したいという要望と、それに対してシステム開発会社側が標準機能への誘導を十分に行わなかったことにありました。

設計判断ミスが招いたコスト・スケジュール・品質への影響

カスタム開発が膨れ上がったことで、Salesforce1 Platform特有の「ガバナ制限（技術的制約）」にも抵触しやすくなり、結果として以下のような深刻な影響が生じました。

• 開発費用の増加：当初見積もりの約12億円が、最終的に追加提案で21億円超まで膨れ上がりました。
• 納期の大幅な遅延：本稼働予定だった2016年7月から、実質的にプロジェクトは頓挫状態に。
• 品質の劣化：結合テスト段階で標準の1.6倍以上に及ぶ不具合が発覚し、完成の見通しが立たなくなりました。
• 機能の実現不可能化：業務改革を実現するはずだった18項目のうち、15項目が未達成という結果に。

最終的に文化シヤッターは日本IBMを提訴。東京地裁・高裁ともに、日本IBMのプロジェクトマネジメント不備と設計判断ミスを認定し、20億円超の損害賠償が命じられました。

「設計」の初期判断がDXの命運を分ける

この裁判から得られる最大の教訓は、PaaSを活用する場合であっても、設計段階での選択肢や方針を誤れば、プロジェクト全体が破綻する可能性があるということです。

特にPaaSは「標準機能を活用する」ことを前提に最適化されたサービスであり、標準から逸脱する仕様を積み上げるほど、技術的制限や運用負荷が高まり、想定外のトラブルに発展しやすくなります。

つまり、「業務にシステムを合わせる」のか、「システムに業務を合わせる」のか――この設計方針の判断こそが、DXプロジェクト成功のカギを握っているのです。

フルスクラッチ開発というもうひとつの選択肢

現場業務が複雑で独自性が高い場合、無理にPaaSに業務を押し込めようとするよりも、最初から業務に合わせてゼロから設計できるフルスクラッチ開発を選ぶ方が合理的なケースも少なくありません。

フルスクラッチ開発であれば、業務の特性に合わせて柔軟に設計・開発が可能であり、PaaSの技術的制約に縛られることもありません。DXの目的が「業務改善」「業務変革」である以上、「標準機能でできること」ではなく、「自社にとって必要なこと」が実現できるかどうかを軸に、開発手法を選ぶことが重要です。

まとめ

「標準機能8割のはずが、カスタム開発95％」――この設計判断のズレが、プロジェクト全体の失敗につながった文化シヤッター×日本IBMの事例は、PaaS活用の限界と設計の重要性を如実に物語っています。

DXを成功させるには、ツールやプラットフォームの導入そのものではなく、自社の業務課題に最適な“設計判断”がなされているかどうかが問われます。
 「スピード重視」や「コスト優先」の前に、まずは設計の土台を見直してみませんか？
 そして必要に応じて、フルスクラッチ開発という選択肢を検討することも、堅実なDXへの一歩となるでしょう。
こうした設計段階での判断ミスが、DX全体の成否を左右することは、今回の事例からも明らかです。

フレシット株式会社は、業務の本質を理解することから始めるフルスクラッチ開発を強みとしています。

 「最初は標準機能で十分だと思っていたが、結果的にカスタムが膨れ上がった」――そんな事態を避けるためにも、要件の整理からシステム設計、開発、運用までを一気通貫で伴走し、将来の拡張や変化にも柔軟に対応できるシステムを提供します。

業務の複雑さや独自性に真摯に向き合い、パッケージに業務を“合わせる”のではなく、業務に“寄り添う”システムを構築したいとお考えの方は、ぜひフレシットにご相談ください。

貴社にとって最適なDXの設計をご一緒いたします。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら