自分をクビにすることこそDX、というのはつらい話
昔からビジネス改革のプロジェクトは失敗の連続です。ものづくりのプロジェクトなら失敗から学ぶことは有益ですから、チャレンジは有益です。しかしビジネス改革プロジェクトは技術のような積み上げがほとんどできませんから、時間と労力の無駄も多く出てしまいます。
ではなぜビジネス改革、今どきでいうところのDXは失敗するのでしょうか？特に日本では…
私が思うに、話は簡単で、自分が推進するはDXプロジェクトで自分をクビにする結論が出せないからです。これはプロジェクト参加者が保身に走っているからではありません。構造的にそうなるのです。
日本の経営者は、良くも悪くも課題発見・改善型の意思決定をします。そこで、まず課題を整理することをDXプロジェクトに指示を出します。そして、その課題に打ち勝つための策をプロジェクトの結論として出すように指示します。（プロジェクトメンバーの報告書の形式がそうなっているだけかもしれませんが…）この課題解決の方法がデジタルがらみであれば「DX」と認定する、といった風潮があります。
もちろんこう聞くと多くの読者は「それはDXではない、ビジネス改革ではない」と思うでしょう。「単なる改善である」と。しかし現実のDXプロジェクトの多くはこのようなスタイルで進行されています。ただこれはある意味これは仕方がないことです。特に課題の抽出については、自社の主力事業であればあるほど独自のノウハウがあるわけで、外部のコンサルタントでも課題の核心に迫るのは難しく、やはり自社で整理をしなくてはならない。ゆえにDX担当役員はメンバーに課題抽出を指示しますし、それは自然の流れです。
問題は課題解決策の立案の方です。ここを同じチームに任せることは間違いだと私は思います。課題を理解し指摘できる人ほど、今のやり方の良さも知っていて、まったく別な革新的方法を思いつかないからです。もちろん例外的な人もいるでしょうけど…
DXに限らないですが、ビジネス改革のプロジェクトの構造の話として、例えば次のような例を考えてみるとよいと思います。ある、機械部品を作っているビジネスを考えましょう。現場の職人気質のエンジニアは、部品の精度を上げるために日々工夫をするでしょう。それによって品質は向上します。上司が生産性を上げよと、指示をすれば、工程を見直して効率化も図ることができるでしょう。
しかし、生産量を２倍に、３倍にしたい場合には、そのような対応では追いつきません。もっと思い切った自動化や外注化を検討しなければなりません。品質に関するノウハウは現場にはありますが、現場を空洞化させる可能性のある外注化を現場がすぐに思いついて提案することは、かなり難しいことだと思います。やはり上位のマネジメントがコミットし、策を考え、判断実行すべきことになります。
同様なことはさらに上位のマネジメントレベルでも起こります。例えば、そもそも今の商品はやめてしまえ、自社のブランドで勝負すべきだ。いや、今のカテゴリーではだめだ、新カテゴリー創造だ。そうしないと競合に負けてしまう。いや、競合と手を組んで業界標準を作るべきだ、そうしないと海外製品に負けてしまう、などなど。このように構造の改革には常にその一つ上からの視座・鳥瞰が必要となり、今のやり方の否定が必要となります。
ちなみに、もしこれを一人でするならば…自分がやっていることの課題を抽出して…その後自分のクビをする、ということになります。そもそもクビになりそうだと分かっていたら何か手をうっているさ、というのが普通の人の感覚だと思いますが…
さて、多くのDXプロジェクトがなぜ失敗するか、という話に戻りますが、手短に言うと、それは今を見つめるプロセスと、今を否定するプロセスが一緒になっているから。少なくとも私が携わった中ではそのようなことが多かったように思います。
ではどうすべきか？一つの処方箋は、課題整理かつ解決策検討型のチームとは別に、その課題などを別の畑の立場から解決策を考えるチームを持っておくことだと思います。ある種新しいビジネススキームの実験チームですね。現場と実験チームは大概１８０度違う意見を持ちますからお互い対立するかもしれません。が、そこはマネジメントがうまく納めねばなりません。
ということで、構造上、自らのクビを結論とするDXプロジェクトはどこかで機能不全を起こす可能性が高いと思われます。そうなるとDXプロジェクトとは別に、同じ視点の異なる実験チームを走らせることとなり、そのチームがうまくいけば現行のビジネスにとって代わる、オーバーライドする、ということになります。私はこのオーバーライド型こそ、DXの王道ではないかと思っています。