【事実】DXは実はほとんどが失敗している

昨今注目されメディアで取り上げられない日はないと思われる「DX」ですが、実はほとんどのプロジェクトが“失敗”に終わっています。

ここでいう“失敗”とは当初想定よりも【スケジュールが遅延する】【予算が超過する】【品質に不満】ということで、想定通りには進めることが出来ないということを指しています。

この記事を読んでいただいている方の中には、これからDXのプロジェクトに取り組まれたり、その可能性があるという方も少なくないと思いますが、“DXは基本失敗する”という前提に立ってプロジェクトに取り組む意識が必要と考えます。

その前提でどのように進めればDXの失敗の確率を下げられるのか、失敗による損失を最小限にできるのか、失敗する理由を先んじて潰していけるのか。

この記事を最後まで読んでいただければ、そのポイントは押さえられます。

最低でも60％以上が当初予定通りにプロジェクト完了せず。80％以上が品質に満足していない。

DXプロジェクトにおける、スケジュール・予算・品質の順守状況において一般社団法人日本情報システム・ユーザー協会（JUAS）がまとめた調査データがあります。
サマリーとしては下記にまとめておりますが、ほとんどのDXプロジェクトが上手くいっていない≒失敗に終わっているということがよくわかります。

スケジュール

・プロジェクトの大きさによるが、67％~85％が当初予定のスケジュールを遅延
・プロジェクトは大きくなることに比例して、スケジュール遅延の可能性は増大
・年々スケジュール遅延するプロジェクトの割合は増えている

予算

・プロジェクトの大きさによるが、60％~85％が当初予定の予算を超過
・プロジェクトは大きくなることに比例して、予算超過の可能性は増大
・年々予算超過するプロジェクトの割合は増えている

品質

・プロジェクトの大きさによるが、80％~90％が品質に満足していない
・プロジェクトは大きくなることに比例して、品質への満足度は下がる
・年々満足度は低下傾向ではあるが、2021年度をピークに下げ止まりか

次からは、グラフと合わせて実績をご紹介します。

スケジュールの遅延

出典：一般社団法人日本情報システム・ユーザー協会（JUAS）　https://juas.or.jp/cms/media/2023/04/JUAS_IT2023.pdf

大型プロジェクトの85％、小規模でも2/3が当初想定のスケジュールを遅延
☑当初想定のスケジュール通りに完了できているのは、500人月以上だと、わずか14％で、年々低下傾向
☑全体的に年々、スケジュール内で完了できない割合が増えてきている
☑大きなプロジェクトほど、完了できていない
☑ある程度は予算内で完了でも、5割～8割。明らかに2割～5割は予算を超過している

予算の超過

出典：一般社団法人日本情報システム・ユーザー協会（JUAS）　https://juas.or.jp/cms/media/2023/04/JUAS_IT2023.pdf

大型プロジェクトの85％、小規模でも60％が当初想定の予算を超過
☑当初想定の予算で完了できているのは、500人月以上だと、わずか14％で、年々低下傾向
☑全体的に年々、予算内で完了できない割合が増えてきている
☑大きなプロジェクトほど、完了できていない
☑ある程度は予算内で完了でも、6割弱。明らかに4割は予算を超過している

品質への不満

出典：一般社団法人日本情報システム・ユーザー協会（JUAS）　https://juas.or.jp/cms/media/2023/04/JUAS_IT2023.pdf

大規模プロジェクトの9割が何かしら不満。小規模でも8割弱
☑品質に満足できているのは、500人月以上だと、わずか11％。
☑年々満足度は全体的に低下傾向であったが2021年度をピークに下げ止まっているように見受けられる。
☑予算、スケジュールと同じく、大きなプロジェクトほど、品質への満足度は低い

DX失敗の原因は開発前の「企画・計画」段階に起因

DXプロジェクトはほとんどが失敗しているという事実を把握したところで、なぜそれだけ多くのプロジェクトが失敗するのか？上手く進められないのか？ということが次の疑問として出てくると思われます。

結論から申し上げれば、その理由はほとんどが「企画・計画」段階の問題です。こちらも調査データを活用しながら説明していきます。

[DX失敗]の原因分析①　JUAS企業IT動向調査報告書2023より

計画時点での検討の甘さが50%を超える主原因となっている
・工期、予算においては「計画時の考慮不足」が50％を超え、最も高い要因となっている。
・同じく4割以上の要因となる「仕様変更の多発」も、つまるところ計画時に仕様を検討しきれていないということが原因と考えられるの
・全体として4割を超える「想定以上の現行業務・システムの複雑さも」同じく、計画時の考慮不足といえる
・品質に限ってはベンダーのスキル不足が50％を超過。スケジュールと予算に影響がないのは品質不満なので、とりあえず無理やりスケジュールと予算以内で終わらせることを優先し、ネクストをベンダー変更や体制変更を想定していると考えられる。


出典：一般社団法人日本情報システム・ユーザー協会（JUAS）　https://juas.or.jp/cms/media/2023/04/JUAS_IT2023.pdf

[DX失敗]の原因分析②　JUASソフトウェアメトリックス調査2016より

要件定義フェーズでの問題が大きく30～44%、次いでプロジェクト体制で6～18%の要因となっており、ともに計画フェーズでの問題といえる。
・要件仕様の決定遅れが最も多く44％。ただこれは考え方としては、結果的に検討がしっかりされた部分もあると考えられる。
・要件分析作業不十分が34％。
・開発規模の増大はつまり、要件定義フェーズで要件を抑えきれなかったと捉えられる。
・プロジェクト体制の要因のなかでも最も高いのは、「構築チームの能力不足」で18％となっている。

システム開発工程の観点から説明

DXプロジェクトは、３つのフェーズに分かれます。

企画を考え、企画を基に要件定義を行う開発前の「計画フェーズ」、実際に開発に着手する、設計～実装～テスト～リリースまでの「開発フェーズ」、リリース後の「運用」フェーズです。

図をみていただけるとお分かりになるかと思いますが、「要件定義」が最後の砦です。ここを超えてしまうと開発に着手してしまいます。一度開発を進めてしまうと、手戻りや方針転換が生じた際、リスクとコストが一気に増えるため、失敗確率を高めてしまいます。計画フェーズで調査、検討を重ねて、要件定義の段階でせき止める必要があるのです。

要件定義フェーズまではプロジェクト全体を俯瞰してみること基本ですが、いざ開発フェーズに入ると1つ1つ機能の開発を進めるため、問題も1つ1つ細かく発生していきます。クリティカルな問題が発生するとそもそも方針転換が必要になることもあり、作った各機能も、全てやり直しといったになりかねなません。

『V字モデル』の観点から説明

V字モデルはシステム開発の手法の考え方の一種です。

V字型の左側が、開発までの進め方の流れを示し、右側は開発後のテストの流れを指します。それぞれの同じ高さの部分は開発の詳細さのレベルを表していて、開発までは概要から詳細、一方開発後のテストは細かい点から大きな観点になっていく逆の流れであることがわかります。

要求定義の段階では、企画レベルで「やりたいこと」「やるべきこと」「できること」「できないこと」が混ざった状態であれやこれやと要求が出てきます。
その要求を、「予算」「スケジュール」「品質担保」といった制約条件を考慮したうえで、「目的」「目標達成」「課題解決」の論点で「やるべきこと」「できること」に絞り込むのが要件定義です。

設計フェーズは1つ1つの項目にフォーカスしていくので、この段階での検討が甘いと、後々問題が発覚することになり、DXプロジェクトが失敗するリスクが増すのです。

現役最前線のDXコンサルタントにインタビュー「計画フェーズで”失敗する理由”4か条」

結論から申し上げれば、やはり計画フェーズでの原因が9割という回答でした。

各コンサルタントの話を聞いていくと、計画フェーズでの原因は4つの問題に集約できることがわかりました。それは下記の4点です。

・『システム仕様』問題
・『コミュニケーション不足』問題
・『そもそも無理な与件』問題
・『不要な議論』問題

また、開発フェーズはほぼ「技術者の力量次第」ということで、ベンダー選定、チーム選定の問題で、これも計画フェーズでの問題と捉えられるものでした。
4つの問題に関する、各コンサルタントの声を紹介していきます。

4つの問題①　システム仕様問題

「企画や要件定義の段階でしっかりと時間をかけないで進めると、後々、既存システムの問題が理由で、実装しようとしていた機能が『これ出来ないじゃないか』となってしまいがちです。」

「現行の仕様をしっかりと理解できていないと、設計段階に入った後に、『これとこれが繋がらないよ』という事象が発生しがちです」

「類似のツールの実装経験があるため、該当のツールも実装可能と考えて取り組んだところ、結果としては対応が出来なかった。ということがよくあります。」

「ソフトウェアメーカーの営業だけに話を聞いて「出来る」と回答があったが、実際には出来ないこともよくあり、システム担当含めしっかりとした事前の検証が必要です。」

「要件定義だけでお金をとられることを嫌がった結果、まともな会社が開発を受けてくれず、結果的にプロジェクトが上手くいかずに炎上、というこは起きがちです。」

上記のような問題を受けての対策のポイント
・計画段階でやりたいことが「システム仕様」的に実現可能か、伸長に検討をする
・類似のツールの実績があるという理由でベンダーの営業担当がOKと言ったからといって油断しない
・失敗の確率を下げるため、要件定義こそ、しっかりとした会社にしっかりお金をかけれ依頼すべき

4つの問題②　コミュニケーション不足問題

「ベンダーや開発会社からの「実装可能」という回答には、実は、「お金をかければ（実装可能）」「開発会社が追加開発すれば（実装可能）」という意味を含んでいることが良くあります。しっかりと費用が不要か？どれくらいの時間がかかるか？等の詳細をセットで確認をしないと危険です。」

「単語の使い方の違いで、「開発範囲」「スコープ」の捉え方が違った状態で進めてしまい、気づけば、開発側と、発注側の認識が異なっているということは起きてしまいがちです。」

「現場、つまりお客様の業務担当とベンダー間のすり合わせが弱く、徐々に認識の乖離が生まれていくことも良く起きがちです。例えば、『会話の抽象度が高いまま何となくわかった、了解したつもりで進んでしまうが、実は共通認識・理解を持てていない』、『幹部メンバーしか会議に参加ぜずに、現場の人は何となくしか理解できていないがOKを出してしまう』、『幹部が多く参加する打ち合わせで現場が本音を、気になることを話せない。』そういった組織構造的な問題が起因となります。」

上記のような問題を受けての対策のポイント
・「実現可能」という回答を疑う。予算、時間、現実性をしっかりと確認する
・抽象的な、複数の捉え方のある語句は使わない。認識相違を極力減らす努力を行う
・現場の実働部隊をしっかり巻き込み、空中戦で何となく「いいね！」と終わらせない

4つの問題③　そもそも無理な与件問題

「そもそも無理なスケジュールで進めていたため、エンジニアを無理させてしまい倒れて遅延、ということも良く見られます。会社側の都合のスケジュールと予算が現実的に難しいのがわかっていながらも、社内調整や社内評価の悪化を嫌がり、ベンダーも受注をしたいので何とか無理して受けるが、結果的には崩壊してしまう事例です。 この構造は前提としてかなり多くのプロジェクトで見受けられます。」

「ベンダー側が見積を甘く設定してしまう問題も見られます。プロジェクトでは何が起こるか読めない部分が多いので本来はバッファを読んで見積をしなくてはいけません。単純にそのバッファが読めていない、甘いパターンもあります。また、バッファを読むととどうしても見積が高くなってしまい、受注できない、予算が取れないということで抑えに行きます。
そうすると結果的にプロジェクト開始後に、予算超過やスケジュールが守られない事態に陥ります。」

「計画段階で目的、目標をROIを考慮して達成できるかどうか、課題が本当に解決できそうかどうか？開発する前にわからないことがよくあります。そういう場合は、いきなり本番として開発に着手するのではなく、ステップを切って、まずはPOC的に試してみて、実現が可能性が高く見積もられれば本番として検討着手するという進め方がありますが、残念ながらこの観点をそもそも持たれていない会社は多いです。」

上記のような問題を受けての対策のポイント
・結果的に失敗してしまうパターンが大半なのだから、難しいスケジュールを無理やり調整しようとすることは極力避ける
・見積はしっかりとバッファを読む
・ステップを分けてPOCでまずコストを抑えて試してみるという観点を持つ

4つの問題④　不要な議論問題

「実はそこまで重要ではない『1つの例外』に執着してしまい時間がとられてしまうことがあります。現場の人はシステムを『導入するとシステムに制限される』という印象を持ちがちで、『こういうパターンもあるのですが、大丈夫ですか？』という問いが出てきます。確信犯的に、あわよくばでついでのBプランを押し込んでくることもあります。ベンダー側はそのパターンを判断が難しいので向き合って1つ1つ検討しがちですが、本来は発注側のPMが社内で議論し、整理すべき内容です。向き合って検討するのにもベンダー側の工数はとられてしまいます。」

「本質的に開発を進めるためには不必要な、会議の開催や、ドキュメント(説明資料)が都度都度追加で求められることで開発時間が減っていくということはほとんどのプロジェクトで見受けられます。特に大きなプロジェクトになれば社内さまざまな関係者への説明が必要になるのでそうなります。
また、発注側の知識不足の不安から説明を求める目的からも要望されます。これらが、スケジュール、コストに負担をかけていきます。」

「開発側が良かれと思ってやってしまう『各方面のステークホルダーへの配慮』が逆に“失敗”の一因になることも多いです。スコープをしっかりと切って合意はしているけど、事業側の担当者は出来ることが絞られて不満を持っている。気持ちでくみ取って進めようとすると作業が増える。他にも階層コミュニケーションへの気遣い等。」

上記のような問題を受けての対策のポイント
・発注側で整理すべきことは事前に整理することで不必要な議論に開発を巻き込まずにコスト、スケジュールへの影響を抑制する
・会議や、ドキュメントの作成も工数やスケジュールに影響することを理解し、必要最低限を意識する

大手企業のDXの失敗事例分析

ここからはメディア等で公開されているDXの失敗事例を分析していきます。

17の大型のDX失敗事例を分析

東洋経済の記事「システム開発はなぜこうも｢失敗｣を繰り返すのか」から分析してみます。
2000年～2022年の間で発生したシステム開発の大型損失プロジェクトの社名と発生事由がまとめられています。

プロジェクト例は17社あり、損失額は9,000万円～最大で154億のプロジェクトまで幅広くありますが、これらの発生事由を見てみると大きく３つとその他に分けることが出来ました。

1つは「プロジェクトそのものの不備」、2つ目は「プロジェクトを取り巻く環境変化の影響」、3つ目は「経営方針変更による影響」です。

これを比率で分けてみると、53％が「プロジェクトそのものの不備」です。発生事由の概要を見ても、損失額がここまでになる前に判断が出来なかったの化という内容であり、企画段階での読みの甘さがあったと考えられます。
残り2つの「プロジェクトを取り巻く環境変化の影響」「経営方針変更による影響」がそれぞれ18％で合わせて36％にも登ります。事業を取り巻く環境の変化が多く、激しい今の時代にあたっては、こういったことを想定して損失額を抑制する工夫が必要と考えられます。それこそ、POCなどで小さく始めていく動きが必要と考えられます。


出典：東洋経済オンライン（https://toyokeizai.net/articles/-/654474）

なお、このなかの4つのプロジェクトは少し詳しい情報がメディアや会社からの情報発信により確認が出来るため、少しですが詳しく紹介いたします。

失敗プロジェクト事例①　ノーリツ（損失額：16億円）

■プロジェクト概要

4年がかりで進めた独SAP社の大型ERP（統合基幹業務）パッケージのシステムを、丸々廃棄

■損失額

16億円（2000年12月期）

■背景と経緯

・トヨタ流生産方式(JIT)に新たなノウハウを導入し業務改善を期待
・業績回復のために、業務改善のため海外のERPパッケージに着目（当時はERPパッケージの選択肢は今と比べて乏しい）
・世界標準の業務の仕組み導入を期待しR/3の導入を意思決定
・検討段階でJISとR/3に大きなギャップが露見し、多くの機能の独自開発を行った
・当初の予定であった99年1月から1年半ほど過ぎた2000年半ばにシステムが外付けのシステムも含めていったん完成
・1997年バージョンは2000年秋でサポート打ち切りの通告
・パッケージの横では20程度のシステムを独自で開発
・外付けシステムが数年毎にバージョンアップをすると、都度、動作検証・修正に数億円の追加費用が予想されることに

■DX失敗原因

①業務方針への適合の検討不足
・トヨタ流生産管理(JIS)とR/3が前提にする生産管理とが相入れるものかどうか、プロジェクト開始前に慎重に検討する姿勢の不足
・システムありきで業務を変えようとした
②ベンダー側の経験不足
・ベンダー側のR/3の導入サポート事例の不足
・追加開発はサポートできず

出典：日経クロステック　https://xtech.nikkei.com/it/atcl/news/16/101402993/

失敗プロジェクト事例②　みらかホールディングス（損失額：147億円）

■プロジェクト概要

子会社で受託臨床検査事業を手掛けるエスアールエルのシステム開発プロジェクトを中止

■損失額

147億円（2016年9月期）

■背景と経緯

・開発を中止したのは、エスアールエルの新基幹業務システム「ナビラボ」。病院などから血液や尿といったサンプルを受け取って検査する一連の作業に使う。
・みらかホールディングスは、開発ベンダー名は非公開としているが「3社以上」とのこと。
・当初の計画より、稼働開始時期が1年以上遅れていた。
・開発プロジェクトが始まったのは2010年。広報によると、「2014年10月ごろの稼働を計画していたが開発が遅れ、2015年10月ごろに首都圏の一部地域で利用を開始していた」とのこと。
・開発を中止した主な理由は、追加開発コストの発生。「臨床検査の現場業務の実態に合っていなかった。第三者であるコンサルタント会社に見積もってもらったところ、追加の開発コストが必要なことが分かった」（同社広報）。追加開発コスト額は非公開。
・エスアールエルは2017年3月までにナビラボの利用を停止し、従来使っていた基幹業務システムを全面的に利用する考え。「新基幹業務システムの今後については、現在検討中」としている。

■DX失敗原因

DXプロジェクト参加メンバー選択の不備
・現場の業務を理解しているメンバーや、システムの専門家が不在であったと見て取れる

出典：日経クロステック　https://xtech.nikkei.com/it/atcl/news/16/101402993/

失敗プロジェクト事例③　NIPPON EXPRESS ホールディングス（損失額：154億円）

■プロジェクト概要

航空輸送事業におけるグローバル共通基盤の構築 を目的とした「新・国際航空貨物基幹システム」の開発を断念

■損失額

154億円（2016年9月期）

■背景と経緯

・当初計画 よりも更なる開発コストの増加、開発期間の延長が見込まれること等から、システム開発を断念することを決定。
・遅延が発生した要因は、「開発ベンダーとのコミュニケーションに問題があったのではと社内で分析している。納品前において、成果物の検証をしっかり行うプロセスができていなかったのではないか」（赤石氏）。
・今回の事案を踏まえ、2023年1月に新設したITデジタルソリューション本部では今後の大型開発案件について妥当性評価やモニタリングを徹底していく様子

出典：東洋経済オンライン（https://toyokeizai.net/articles/-/654474）

失敗プロジェクト事例④　大同特殊鋼（損失額：56億円）

■プロジェクト概要

受注管理や生産管理などの社内基幹システムの開発中止

■損失額

154億円（2016年9月期）

■背景と経緯

・13年度から子会社のシステム関連会社を中心に自前で社内基幹システムの再構築を進めてきたが、「ノウハウ不足により」（同社）開発の継続が困難になったという。
・当面は現行の社内基幹システムの使用を続ける。

出典：日本経済新聞（https://www.nikkei.com/article/DGXLZO92285340Q5A930C1DTA000/）

大手企業の事例から見えるDX失敗の“メカニズム”

DXプロジェクトの失敗事例の詳細は滅多に表に出てきていません。僅かな事例ですが、そこから見えてくる傾向について整理しました。
DXプロジェクトの“内”的要因と“外”的要因の２つです。

“内”的要因は、「業務不適合」と「ノウハウ不足≒プロジェクト体制」の２点が見受けられる。

ノーリツ社の事例では、ツールありきでの検討が先走り、現業業務との相性が悪いということはわかっていたが、立ち止まることをせず、みらかHDでは現場業務との実態が合わない状態で進むという事象が発生しています。ここからは仮説ですが、特に組織が大きい分、上層部だけで大きな絵ありきで現場業務への適用が軽んじられた状態で話が進んでしまい、プロジェクトが進められてしまっているような状況があったように想定されます。
また、ノウハウ不足の問題も本質的には連動しているように見受けられます。ベンダー、ツールの検討、進め方においてシステム開発、業務理解をしているメンバーを入れて、しっかり実現可能性を検討している動きがあるようには思えない結果となっています。
DXプロジェクトを進めるために、大企業で大規模であるがゆえの構造的な問題があるように見受けられます。

“外”的要因は、「外部環境変化」と「会社方針変更」という２点です。

大規模なDXプロジェクトになるほどプロジェクトには時間がかかります。大企業であれば関係組織や関係者の数も多くなり、プロジェクト規模は大きくなりがちだと思われます。
経営環境を取り巻く変化のサイクルが短くなり、競争環境も激しい昨今では、開発しているシステムが開発途中で不要になってしまう、変更する必要がある、といった状況は想定できます。
３６％がこういった要因からプロジェクトの中止を引き起こしているようです。
こういった前提を考慮すると、そもそもシステム開発の必要性の検討、または出来る限り既存システムの活用、小規模でチャレンジするような対応が必要になってきていると考えられます。

DXの失敗を防ぐ根本的な対策

DXのプロジェクトは、スケジュール通りにいかない、当初予定の予算は超過する、品質も不満足が多い、といったように失敗といえるモノが多く、その要因はほとんどが「企画・計画」段階の甘さであるということはよくご理解いただけたと思います。

その問題の本質は、そもそも“DXプロジェクト”というものの難易度の高さです。まずは、ここを前提として理解すべきと考えています。
システムというものは複雑であり、全く同じ環境や業務のシステム開発は基本ありません。複雑に複数のシステムが絡むような取り組みで、毎回が異なるプロジェクトであり、まったく同じものは滅多にありません。そのため、事前にどれだけ調べても問題発生の可能性を0にすることは困難です。

但し、最もこの問題発生の可能性を減少させられるのが、『経験者』の存在です。まったく同じではなくても類似のプロジェクトの経験者を集めることでリスクはかなり軽減することが出来ます。ちなみに、ソフトウェアのサービスを取り巻く環境は深化が早く、常に変わるので出来る限りリアルタイムでの経験が重要です。

また、会社の方針や環境によりプロジェクトを止めざるを得ないという損失は非常に勿体無いです、これは当社の提唱するリーン・トランスフォーメーションという極力、既存のツールを組み合わせてコストを抑えてクイックにPOC的なDXを行うという進め方における対策で、リスクを軽減することが可能です。

まとめ

さいごに、DXコンサルタントのインタビューで印象的かつ、象徴的な失敗原因についてのコメントを紹介したいと思います。

「データで示されていますが、ベンダー側は、ある意味、（DXのプロジェクトが）問題発生すること(スケジュール遅延や予算超過)が普通になっていて、慣れてしまっている、ということも結果的に失敗を引き起こす一因と考えられます。
70%成功、30％失敗と思ったら、90％失敗します。120％の自信がないと、ほぼ“失敗”すると思った方がよい。柔軟に社内体制を調整できるくらいの余裕をもったり、発注側も、当初予算、スコープにバッファを読んでおく必要があります。」