このブログでは、「ツール先行思考を捨てたシステム導入の極意」と題し、全4回にわたり「もう失敗したくないシステム導入・また失敗しないための業務設計とシステム設計」について解説していきます。

• 第一部：成功率52.8％の理由から紐解くシステム導入
• 第二部：ツール選定よりも大切な【業務設計】と【システム設計】
• 第三部：「ベンダー任せ」の落とし穴とツール選定のコツ
• 第四部：システム運用戦略とPDCAサイクルの重要性

今回は第二部ということで、ツール選定よりも大切な【業務設計】と【システム設計】を詳しく解説します。

このブログをご覧の皆さまの多くは、過去何かしらのプロジェクトで、ITツールを導入された（あるいはしようと思った）経験がおありでしょう。

しかしながら、第一部でも取り上げたように2社に1社がシステム導入プロジェクトの成功を実感できていないという現実があります。

では、なぜシステム導入の失敗は繰り返されるのでしょうか？
そして、システム導入を成功させるために本当に必要なこととは何なのか？

第二部では、第一部で取り上げた内容を踏まえ、システム導入プロジェクトの失敗を断ち切る方法をより深く解説していきます。

より具体性を増すために、今回は実際に起こったIT訴訟をご紹介しながら、業務設計とシステム設計の重要性について考察していきましょう。

IT訴訟やトラブルから読み解く！業務設計・システム設計の重要性

近年、システム導入に関するトラブルが原因で訴訟に発展したケースがいくつも報じられています。

「システムが予定通り稼働しなかった」
「想定していた業務フローと合わなかった」
「追加開発や修正対応が膨れ上がり、プロジェクトが破綻した」

こうした問題が、企業とベンダーの間で深刻な対立を生んでいます。

本来、システム導入は業務の効率化や生産性向上を目的として行われるものです。

にもかかわらず、なぜ多くの企業が期待した成果を得られずに終わり、法廷闘争や大規模なトラブルにまで発展してしまうのでしょうか？

こういったシステム導入プロジェクトには、ある共通する問題点があります。
それは【業務設計】と【システム設計】の欠如です。

この章では、実際に訴訟に発展したシステム導入の事例や、大規模なシステムトラブルの事例をもとに、

• なぜプロジェクトが頓挫したのか？
• どこで業務設計・システム設計に問題が生じたのか？
• どのような対策を取れば、同じ失敗を防げるのか？

を読み解き、システム導入を成功に導くために本当に必要なことを考えていきます。

IT訴訟事例：文化シヤッターの販売管理システムリプレイスにおける裁判

【システム開発の背景】

文化シヤッターは2015年、販売管理システムのリプレイスを目的に、日本IBMに提案依頼書（RFP）の作成を委託。その後、複数のITベンダーからの提案を比較し、最終的に日本IBMをシステム構築の委託先として選定しました。

当初、開発手法はアジャイル開発とウォーターフォール開発を併用していましたが、プロジェクト途中でウォーターフォール開発に一本化。
しかし、開発は遅延し、4ヶ月の延期を経ても多数の不具合が発生。文化シヤッター側は、バグ修正と並行しながら「早期稼働を優先する開発手法」を提案しましたが、日本IBM側はこれを拒否。
「要件定義のやり直しから始める開発手法」を提案しました。

この方式では、さらに2年4ヶ月の開発期間が必要となるため、文化シヤッターは「実質的に従来のプロジェクトの成果を破棄された」と主張し、開発委託費約22億円を含む27億4,475万円の損害賠償を求めて東京地裁に提訴。

【開発方針との乖離】

当初、文化シヤッターの新販売管理システムは、Salesforce Platformを基盤とし、標準機能を80％活用。カスタム開発を20％に抑える予定でした。
しかし、実際の開発が進むにつれ、カスタム開発の割合が9割以上に膨れ上がり、Salesforceの標準アップデート（年3回）に対応しづらくなるという懸念が発生。

このため、日本IBMは「開発を継続するには追加費用として21億5000万円が必要」と提案し、結果として当初の開発方針とかけ離れた形になってしまい、プロジェクトの負担が大幅に増加する事態となったのです。

【参考元】

・ 企業法務ナビ「文化シヤッターが日本IBMとの損害賠償請求訴訟の判決を公表」
　－https://www.corporate-legal.jp/news/4848

・ Business Journal「なぜ日本IBMに20億円の賠償命令、文化シヤッター開発頓挫…ベンダ側に責任」
　－https://biz-journal.jp/company/post_386127.html

・ 日経XTECH「文化シヤッターのシステム裁判、二審判決で日本IBMの過失割合を異例の引き上げ」
　－https://xtech.nikkei.com/atcl/nxt/column/18/00001/09645/

システムトラブル事例：江崎グリコの基幹システムトラブル

【システム開発の背景】

江崎グリコ株式会社は、2019年12月に基幹システムの刷新プロジェクトを開始。
このプロジェクトは、SAP S/4HANAへの移行を目的としていて、当初の投資予定額は215億円とされていました。

しかし、プロジェクトの進行に伴い、投資額は342億円にまで膨らみ、完了予定時期も2022年12月から2024年3月に延期してしまいました。

【システムトラブルが与えた影響】

2024年4月3日、新基幹システムへの切り替え直後に物流部門でデータエラーが発生。
この影響で、チルド商品の出荷が停止し、「プッチンプリン」や「カフェオーレ」などの主力製品が市場に供給できなくなり、取引先にも大きな影響を及ぼしました。

その後、2024年6月25日から一部商品の出荷を再開しましたが、完全復旧には至らず、段階的な対応が続く状況となっています。

また、このシステム障害により、2024年12月期の連結純利益は、当初予想の6％増から一転し、前期比22％減の110億円へ下方修正。
通期の営業利益は60億円減、売上高は200億円減と、大幅な業績悪化が報告されました。

【参考元】

・ CloudCIRCUS「江崎グリコが直面したERP(基幹システム)導入の障壁」
　－https://fullstar.cloudcircus.jp/media/dx-column/glico_dx

・ セキュリティ対策Lab「グリコのシステム障害のまとめ」
　－https://rocket-boys.co.jp/security-measures-lab/summary-of-glico-sap-system-failure/

IT訴訟とITトラブルの事例から学ぶ業務設計・システム設計の重要性

システムリプレースは、多くの企業にとって業務効率化やDX推進の大きなチャンスである一方、プロジェクトの進め方を誤ると、訴訟や経営危機にまで発展するリスクを伴います。

今回紹介した文化シヤッターと日本IBMのような訴訟事例や、江崎グリコのシステムトラブルは、いずれも業務設計・システム設計の不備が原因で、重大な問題を引き起こすことを示しています。

ここでは、経営陣・システム部門・ユーザー部門それぞれの視点から、業務設計・システム設計のポイントを整理してみましょう。

システムリプレースは、全社が納得できるスケジュールで進んでいたか？

失敗の多くは、現実的でないスケジュール設定から始まります。

● 文化シヤッターの事例では、当初の計画と実際の開発方針が大きく乖離し、想定以上のカスタム開発が発生。結果、開発期間が延長され、最終的に訴訟へと発展。

● 江崎グリコの事例では、当初のシステム切り替え時期が何度も延期されたが、十分な移行準備ができないままリリースされ、物流部門の混乱を招いた。

【重要ポイント】

• 経営陣、システム部門、ユーザー部門が納得できる十分なスケジュールで調整する
• 業務の繁忙期を避け、十分なテスト・移行期間を確保する
• 「納期優先」で進めず、「業務影響」と「システムの安定性」を両立させる

システムを業務に合わせるのか？業務をシステムに合わせるのか？方針は明確だったか？

システム導入時、最も重要な経営判断のひとつが「システムに業務を合わせるか、業務にシステムを合わせるか？」という基本方針です。

しかし、多くのプロジェクトでは、この判断が曖昧なまま進み、開発途中で認識のズレが発生します。

● 文化シヤッターの事例では、当初は「Salesforceの標準機能80％活用」とされていたが、実際にはカスタム開発が90％を占め、プロジェクトのコストと期間が大幅に増加した。

【重要ポイント】

• 「業務をシステムに合わせる」or「システムを業務に合わせる」の方針を明確に決める
• 「すべてをカスタマイズすればいい」という考えを捨て、標準機能を最大限活用する方向性を重視する
• 利用部門の意見を尊重しつつも、長期的な運用コストを考慮した最適解を導く

システム利用イメージが明確な状態で開発が進められていたか？

システム導入の失敗事例では、ユーザー部門が「システムをどう使うかのイメージを持たないまま開発が進行」してしまうケースが多発しています。

特に、開発手法や、クラウドERPなどのツール特性に引っ張られると、開発の進行と業務のフィット感にズレが生じるリスクが高まります。

● 文化シヤッターの事例では、Salesforceの標準機能を活用する予定だったが、実際にはカスタマイズが大幅に増加し、想定していたシステムの形とは異なるものが開発されてしまった。

● 江崎グリコの事例では、基幹システムの利用イメージが十分に構築されておらず、切り替え後に業務フローとの不整合が発生。

【重要ポイント】

• 開発前に「業務プロセス」と「システムの動作」のすり合わせを徹底する
• アジャイル開発の柔軟性に頼りすぎず、初期段階で業務フローと要件を明確化する
• 開発の途中でもユーザー部門と継続的にフィードバックを行い、利用イメージと乖離が生じていないか確認する

まとめ：IT訴訟・ITトラブルから学ぶべきこと

これらの事例から、システム導入の成功には以下の3つのポイントが不可欠であることがわかります。

システム導入は、単なる「ITプロジェクト」ではなく、業務の変革プロジェクトです。

経営層・システム部門・ユーザー部門が一体となって進めなければ、開発の途中で認識のズレが生じ、最悪の場合、訴訟や業績悪化につながるリスクがあります。

IT訴訟やシステムトラブルの事例を「他社の問題」と考えるのではなく、自社のプロジェクトにどう活かすか？を意識しながら、システム導入の成功に向けた準備を進めることが重要です。

 

システム導入成功率を高める「要求定義×業務設計」

システム導入プロジェクトにおいて、「要求定義」 と 「業務設計」 は成功のカギを握る重要なステップです。

しかし、多くの企業では「どのシステムを導入するか？」「どの機能が自社に最適か？」というところばかりに目を向けてしまい、
「自社の業務をより効率的に進め、効果を出すために改善すべき業務はどれか？そしてそれを支えるシステムはどんな機能が必要か？」というのを十分に整理しないままプロジェクトが進んでしまうケースが後を絶ちません。

そこで、ITシステム導入の成功率を高めるカギである「要求定義」と「業務設計」というステップについて解説し、
「システムを導入することがゴールではなく、業務に定着させることがゴール」という視点を持った業務設計の重要性を考えていきます。

システム導入プロジェクトにおける【要求定義】とは？

【要求定義】とは、システムを導入する目的を整理し、それを実現するための要件を明確化するプロセスです。

システムを導入する前に、以下のようなポイントを整理しておきましょう。
重要なのは、「システムを導入すること」自体が目的にならないようにすることです。

• なぜシステムを導入するのか？（課題の整理）
• 導入することで何を実現したいのか？（業務上の目的）
• どの業務を改善するのか？（対象業務の特定）
• どのような機能が必要なのか？（システムに求めるもの）

例えば、単に「Salesforceを導入する」「CRMを導入する」ということを目的にするのではなく、

• 顧客対応の抜け漏れをなくし、受注率を向上させるためにCRMを導入する
• 商談履歴を蓄積し、マーケティング部門と営業部門の連携を強化する

といったように「システム導入が業務改善にどうつながるのか？」を具体的に整理しましょう。

要求定義を正しく行うための【業務設計】

【業務設計】とは「システムを業務にフィットさせるための準備」であり、「現行の業務プロセスを整理し、システム導入後の業務フローを設計すること」を指します。

この作業を怠ると、システム導入後に「現場で混乱が生じる」「期待していた業務改善効果が得られない」といった問題が発生します。

業務設計において重要なポイントは、次の通りです。

• 現行業務の整理（どの業務がどのように行われているか？）
• 業務プロセスにおける課題を明確化（どの部分が非効率なのか？）
• システム導入後の業務フローの設計（どの業務をシステムに置き換えるのか？）
• 業務の標準化とルール策定（システム運用に必要な業務ルールは何か？）

業務設計を進める上で重要な判断の一つが、前章でも触れた「業務をシステムに合わせるのか？システムを業務に合わせるのか？」という方針決定です。

この方針が不明確なまま開発を進めると、後から仕様変更が頻発し、コスト増加やスケジュール遅延の原因となってしまいます。

また、業務設計の本質は「システムに業務を合わせるのか？業務をシステムに合わせるのか？」を決めることではなく、まず既存の業務を整理します。
そして、それを俯瞰して見たうえで、システムのあるべき姿や位置づけを決めることです。

この順序を誤ると、業務とシステムがうまく噛み合わず、導入後に「現場で使われないシステム」となってしまう可能性が高くなります。

システム導入の目的は、あくまで業務の最適化であり、システムを導入すること自体が目的ではないことを忘れずに進めていきましょう。

フライクの業務設計プロジェクト：成功するシステム導入のための5ステップ

システム導入を成功させるには、単にツールを導入するだけでなく、業務フロー全体を見直し、企業の成長に繋がるシステム設計を行うことが重要です。

フライクでは、この目的を達成するために「業務設計プロジェクト」を以下5つのステップで進めています。

STEP 1：ビジネスの全体像を理解する

まず、クライアントのビジネスモデルや強みを深く理解し、システム導入の目的を明確にします。

• 事業の価値、ターゲット顧客、競争優位性を把握
• 将来的な課題も見据え、柔軟なシステム基盤を設計
• 時には顧客視点での体験を通じ、現場の課題を抽出

STEP 2：組織の現状を把握する

次に、業務フローと情報の流れを「見える化」し、非効率な作業や重複業務を特定します。

• 各部署の連携状況を分析し、業務のボトルネックを発見
• 情報の流れを整理し、システムが組織全体の力を引き出せる設計へ
• 不要な業務や属人的な作業を削減し、業務効率を向上

STEP 3：顧客の課題を予測する

顧客へのヒアリング前に、業界知識や市場データを活用し、仮説を立てたうえで課題を抽出します。

• 顧客が抱える潜在的な課題を分析
• より効果的な質問ができるよう事前準備を徹底
• 本質的な課題を見極め、的確なソリューションを導き出す

STEP 4：業務フローと課題を徹底分析する

業務の流れを詳細にヒアリングし、組織や業務に潜む問題を特定します。

• 現場の実情を深く理解し、ツール導入で解決すべきポイントを明確化
• フライクの視点から仮説をぶつけ、潜在的な課題をあぶり出す
• 業務フローの前後関係も分析し、根本原因を突き止める

STEP 5：最適なシステムを設計し、ツールを選定する

これまでの分析をもとに、最適なシステムの構築方針と導入ツールを決定します。

• システムで解決すべき領域を特定し、優先順位を決定
• 単体システム、連携システムなど、最適なアーキテクチャを検討
• 初めてITツールの選定に着手し、UI・UXも考慮した設計へ

この5ステップをもとに、企業の現状と顧客のニーズを深く理解し、最適な業務フローとシステム設計を実現します。

• 単なるツール導入ではなく、業務改革を目的としたシステム構築
• 業務フローに適合したシステム導入で、企業の生産性を最大化
• システムが「業務の足かせ」ではなく「成長の加速装置」になる設計

プロジェクトの進め方や具体的な納品物イメージについては、下記のブログにストーリー調で記載していますので、このブログと一緒にご確認くださいませ。

システム導入を成功に導く「業務設計」のススメ：（1）無駄なIT投資から脱却する方法

要件定義のための【システム設計】

最後に、システム導入の成功には「要求定義（業務設計）」と「要件定義（システム設計）」を正しく進めることが不可欠です。

まず、業務設計プロジェクトで実施する要求定義の段階で「なぜシステムを導入するのか？」「業務をどのように改善するのか？」 を整理します。

そして、システム設計プロジェクトでは要件定義である「どの業務をどのようなシステムで実現するか？」 を技術的な要件に落とし込んでいきます。

つまり、業務設計の延長線上にシステム設計があるということになるのです。

この章では、要件定義の役割と、正しくシステム設計を進めるポイント について解説します。

システム導入プロジェクトにおける【要件定義】とは？

システム開発において、要求定義と要件定義の違いと位置づけは以下となります。

① 要求定義（業務設計）： 「どの業務をどう改善するのか？」 を整理するフェーズ

② 要件定義（システム設計）： 「どのシステムでどう実現するのか？」 を決めるフェーズ

言葉は非常に似ていますが、役割が異なります。
しかしながら、この2つは密接に関わっており、業務設計をきちんと定めないまま要件定義を進めると、業務に合わないシステムができ上がってしまいます。

例えば、CRMシステムを導入する場合、

業務設計の視点では…

• 営業プロセスを標準化し、商談履歴を可視化する仕組みが必要
• 顧客ごとの対応履歴を一元管理し、マーケティングとの連携を強化する

システム設計の視点では…

• CRMの標準機能で商談管理・顧客管理を実装するのか？
• 自社の業務フローに合わせたカスタマイズが必要なのか？
• 営業支援ツールやマーケティングツールとどのように連携させるのか？

このように、業務の目的とシステムの仕様をつなげるプロセスが【要件定義】です。

要件定義を正しく行うためのシステム設計

要件定義を適切に行うためには、次のポイントを意識してシステム設計を進めることが重要です。

ポイント①：ユーザー視点で「実際に使えるシステム」を定義する

システム導入が失敗する原因の一つに、現場の業務プロセスとシステムの仕様がズレている ことがあります。

そのため、要件定義の段階で、以下の点を確認しましょう。

• 「誰が」「どの業務で」「どのように使うのか？」を明確にする
• 現場の作業フローとシステムの操作性をすり合わせる
• 「システムを業務に合わせるのか？業務をシステムに合わせるのか？」の方針を決める

ポイント②：必須機能と拡張機能を切り分ける

要件定義の際に陥りがちなのが、「すべての業務要件をシステム化しようとすること」 です。
これにより、機能が過剰になり、開発コストと期間が膨れ上がるケースが多発します。
そこで、「必須機能」と「拡張機能」を明確に分けることが重要です。

• 「この機能がなければ業務が成り立たない」ものは必須機能
• 「あると便利」「将来的に必要になるかもしれない」ものは拡張機能として後回し

このように整理することで、開発の優先順位が明確になり、プロジェクトの進行がスムーズになります。

ポイント③：システム間の連携を考慮する

業務システムは、単体で完結するものではなく、他のシステムとデータを連携することが前提です。

例えば、CRMを導入する場合、

• 販売管理システムや在庫管理システムと顧客データを連携するのか？
• マーケティングツールとのデータ連携は必要か？
• 会計システムと請求データの連携が発生するのか？

このようなシステム連携の要件を明確にすることで「後から連携が必要になり、追加開発が発生する」という問題を未然に防ぐことができます。

ポイント④：UI/UX設計を重視する

どんなに高機能なシステムでも、現場のユーザーが直感的に使えなければ、定着しない可能性があります。

そのため、要件定義の段階で、「使いやすさ（UI/UX）」を考慮したシステム設計を考えます。

• 「ワンクリックで処理が完了するか？」
• 「入力項目が多すぎて現場の負担にならないか？」
• 「スマホやタブレットでも快適に操作できるか？」

そうすることで、現場で実際に使われるシステムを設計できます。

 

まとめ

いかがでしたか？

今回は「ツール選定よりも大切な【業務設計】と【システム設計】」というテーマで、IT訴訟やITトラブルからの教訓を活かし、要求定義・要件定義の重要性について解説しました。

システム導入の成功は、「要求定義（業務設計）」と「要件定義（システム設計）」の精度にかかっています。

• 業務設計で「何を改善するか？」を整理し、それをシステムに落とし込むのが要件定義
• システム設計では「要件をどう技術的に実現するか？」を明確にする
• 現場の業務フローに合ったシステム設計を行い、実際に使われる仕組みを作る

これらのステップを丁寧に進めることで、業務にフィットし、長期的に活用されるシステム を構築することができます。

システム導入は、単なるツールの導入ではなく、企業の業務を最適化し、成長を加速させるための手段だということを忘れずに、プロジェクトの土台づくりをしっかりとしていきましょう。

次回の第三部では「「ベンダー任せ」の落とし穴とツール選定のコツ」をテーマに、システム導入における具体的な進め方についてさらに掘り下げていきます。

ぜひ、そちらも合わせてお読みください。

このブログを参考に、皆さんのシステム導入成功につながりますように。