経営コンサルティング会社のリブ・コンサルティングの関代表が、自社のDXコンサルタントから「DXプロジェクトが失敗する理由」を聞き出しているよ。

ここで全部あげるとネタバレになってしまうので、ぜひ動画を見て欲しいけど、概要を紹介すると「企画」「プロジェクトの進め方」「リソース調達」の3つのステップで、それぞれ2つずつ、計6個の失敗理由をあげている。

企画段階の「課題起点ではなくテクノロジー起点になってしまう」「DX組織を作って丸投げして安心してしまう」の2つは、文字を見ただけで「ああ、そうだろうなあ」と思ってしまった。特に組織を作って丸投げというのは、DXに限らずプロジェクトあるあるだ。

リソース調達に関して「費用対効果が合わずに発注もしくは採用ができない」というのも、大きな効果が上がるものでないとコストを掛けられない。そういう意味では、「課題起点」でDXに取り組むことは、かなり重要なことだ。

これは残りの5つの失敗理由にもつながるけど、デジタルな手段を用いるかどうか以前に、「経営にとって緊急度も重要度も高い課題」にフォーカスしていけば、経営者が専門組織や社外に丸投げではいけないことが分かるし、必要なリソースもしっかり投入できる。

プロジェクトの進め方に関する失敗理由では、「アジャイル」について大きく誤解があると指摘されていた。どうやら「DXといえばアジャイル」という固定観念を持っている人が、少なからずいるということなんだよね。

アジャイルとは「素早い」「俊敏な」という意味で、設計・実装・デプロイを短期間に繰り返し、トライアンドエラーで開発を行うことを指す。事前にしっかり仕様を固めて計画どおりに開発を行うウォーターフォール型とは、正反対な手法とされている。

まさにそう。「なんでもアジャイルが適しているわけではない」のは当然の話。それから、アジャイルを「とりあえず作ってみること」と勘違いしていると、出てきたものに迅速なフィードバックをして改善を繰り返してきたけれど、出来上がったものが「本当にこれって重要なの？」という結末を招いてしまう。

このケースも、先ほど言った「課題起点」で考えれば、そんなことにはならない。DXといっても「目的」「課題」が大事なのは変わらず、「手法」や「ツール」が目的化しないように気をつけるべきというのは、どんな仕事でも同じだね。