DXプロジェクトの半数は「失敗」

DXで活用するIT技法は作業をプロジェクト単位に分けて進める場合が多い。新システムの構築や既存システムの刷新が典型だ。「成功だった」と堂々と言える場合もあれば、「失敗だった」と言わざるを得ない結果に終わることもある。

日経コンピュータが2018年3月1日号で公表したプロジェクト実態調査の結果によれば、1745件に上るシステム導入/刷新プロジェクトのうち「成功」は52.8％、「失敗」は47.2％と成功がわずかに上回った。調査ではスケジュールとコスト、満足度の3条件を満たすプロジェクトを「成功」と定義し、それ以外を「失敗」と見なした。調査の対象や方法、評価項目が異なるために単純な比較はできないが、2008年に日経コンピュータが実施した調査では成功率が31.1％だった。

10年間でプロジェクトの成功率が高まったとの見方もできそうだが、依然として失敗の割合は大きいと言える。プロジェクトの成否を評価する際はQ（品質）・C（予算）・D（納期）の3項目に基づき判断する場合が多い。日経コンピュータの2018年の調査はQを満足度とした。予算に関しては、プロジェクトに投じた費用が予算通りまたは下回っていれば「成功」、予算を超えていたら「失敗」と見なした。

日本情報システム・ユーザー協会（JUAS）は「企業IT動向調査」でQ・C・Dがどの程度達成できたかを調べている。2004年度から2009年度までの達成率は10％から20％程度で、ほとんど変化がなかった。Q・C・Dを達成した成功プロジェクトはごくわずかしか存在しなかったわけだ。

現在も状況が大きく変わったわけではない。「企業IT動向調査2018」を見ると、500人月以上のプロジェクトの48.0％がDすなわち納期を達成できていない。先に触れた日経コンピュータの調査でも、プロジェクトの失敗理由として挙がったのは「要件定義の甘さ」など古典的とも言える内容だった。

［図表1］システム構築プロジェクトにおける要素別達成率

この10年、20年でIT業界を取り巻く環境は激変している。しかもユーザー企業やベンダーは数々のプロジェクトの失敗から学んでいるはずだ。にもかかわらず、これらの調査結果を見る限り、根本的な問題はいまだに解決していないと言わざるを得ない。ある大学院の教授は「DXを取り巻くIT業界の失敗は100年たっても変わらない」と話す。

真の失敗理由を究明できない経営者

なぜDXをとりまくIT業界はプロジェクトの失敗につながる根本的な問題を放置しているのか。筆者は「真の失敗原因」を究明できていないためだと考えている。真の失敗原因ではなく、別の要因に目を奪われている印象を受ける。

「失敗データベース」は一例だ。「社員が失敗に早く気づけるようにするにはどうすればいいか？」。筆者は経営者からこんな相談をよく受ける。経営者に現状の対策を尋ねると、返ってくるのは「失敗データベースを作っている」という答えだ。過去のプロジェクトにおけるQ・C・Dの失敗を蓄積してデータベースを作り、社内に公開した。にもかかわらず、「データベースを社員が活用してくれない」と経営者は嘆く。

各社が失敗データベースの作成に乗り出す背景として、米国の安全技術者ハーバート・ウィリアム・ハインリッヒが提唱した「ハインリッヒ（ヒヤリハット）の法則」が挙げられる。「1件」の重大災害の陰に「29件」のかすり傷程度の軽災害がある。さらにその陰に「300件」のケガはないがひやりとした経験がある、という内容だ。ご存じの方も多いだろう。

［図表2］ハインリッヒ（ヒヤリハット）の法則による事故の発生率

失敗データベースは「1件」につながる「29件」または「300件」に関する過去の事象をまとめておく取り組みと言える。過去の事象を参考にして、未来に起こる可能性がある「1件」の大きな事故やトラブルを防ぐのが狙いだ。

こうしたデータベース作りに意味がないと言うつもりはない。だが、そこには落とし穴がある点に注意したい。相談を受けた経営者に、筆者は以下の2点を確認している。

一口に「失敗」と言っても内容や要因は事象ごとにそれぞれ異なる。そうした違いを踏まえずに事象だけをまとめても、意味があるデータベースにはなりにくい。何より「まず様々な失敗の事象を集める」というのは作業の手順が間違っていると筆者は考えている。

優先すべきは「真の失敗原因」の究明だ。真因が判明して初めて、起こった事象を適切に分類できる。失敗の経験を後々まで伝えられるようにもなる。まさに「急がば回れ」である。

《最新のDX動向・人気記事・セミナー情報をお届け！》
≫≫≫DXナビ　メルマガ登録はこちら