DX成功のために組織の変革が必要な理由

最近、「コロナ禍以降、企業のデジタルトランスフォーメーション（以下：DX）が加速している」という発言を様々な場所で見聞きするようになりました。もちろんそれは、ビジネスの世界でよく見かける単なる宣伝文句や根拠のない噂話ではありません。以前、このDX-laboの『調査結果から見えてきたDXの現状と課題』という記事でも紹介したように、様々な調査結果で明らかにされている事実なのです。

とはいえ、一方では加速するどころか、DXのスタートラインにすら立てていない企業も多く存在します。本当は止めた方が効率的なのはわかっているのに、「組織の仕組み上、ルール変更に時間を要する」などと言い訳を重ね、いまだにペーパーレスや脱ハンコに手をつけられていない企業も少なくありません。しかし、このようなちょっとしたスピード感の差が、やがて大きな競争力の差となって業績にあらわれるのは間違いないでしょう。

企業のDXを阻む壁として、前述の記事では「顧客データの課題」「現行システムの課題」「人材育成・採用の課題」と３つの課題を挙げました。もちろん、いずれも多くの企業を悩ませている重要な課題であることは間違いないのですが、しかし、これらの課題を克服してもなお、DXの推進を阻む壁は存在します。それが「組織の課題」です。

他のビジネスにおける取り組みと同様に、組織の構造やあり方がDXの成否に与える影響は少なくありません。ご存じの方も多いかもしれませんが、何よりITの領域には「コンウェイの法則」と呼ばれる有名な法則があります。簡単に説明すると、「システムやソフトウェアの構造は開発する組織の構造に似やすい（影響を受けやすい）」というもの。つまりDXに最適なシステムを開発するのであれば、組織も従来型ではなく、DXに最適化したものでなければならないということです。

言い換えると、それくらい従来の開発とDXで求められる開発は別物ということでもあります。

例えば従来のシステム開発では、まずIT部門が要求仕様書を作成し、それに基づいて予算と規模を見積もり、RFP（提案依頼書）をITベンダーに提示し、ベンダーの提案を受けてシステムを発注し、数年かけて構築するという進め方が一般的でした。時には要件定義に１年近くの期間を費やすケースも珍しくはありませんでした。

開発が始まれば始まったで、各工程で成果物を求められ、さらにその修正に時間と手間を取られます。せっかく時間をかけて作った要件定義が認識違いを引き起こし、プロジェクト迷走の一因になってしまうこともあります。事前準備が綿密な分、一度問題が発生すれば後工程に甚大な影響を及ぼしてしまいます。

もちろんこうした開発手法にもメリットは多々あり、簡単に否定して良いわけではありません。ただしDXでの開発には向いていないのです。DXの目的は、近年の変化の激しいビジネス環境で、社会や顧客のニーズをもとに新たな価値を創出すること。社外向けの開発であれ社内向けの開発であれ、最優先すべきは実際にシステムやソフトウェアを利用する「ユーザー視点」です。

そしてユーザー視点で忘れてはいけないことが、ユーザー自身、自分が求めているものが具体的にどんなものなのか、その完成の形や基準が完全に把握できているわけではないということです。となると、事前にいくら供給側で綿密に要件や工数を固めたところで意味はありません。つまりDXの開発で必要なのは、「まず出来ることからスタートする」「継続的にユーザーの反応を確認する」「失敗してもすぐに次の行動に移る」といったアプローチなのです。

こうした開発手法は「アジャイル開発」と呼ばれ、DXの基礎技術であり、開発に「柔軟性」と「スピード感」をもたらす「分散型」のマイクロサービス・アーキテクチャというソフトウェア開発手法とも不可分です。そして、先ほど挙げた「コンウェイの法則」に倣って言うなら、システムやソフトウェアだけでなく、DXの開発組織もまた「柔軟性」と「スピード感」を持つ「分散型」組織でなくてはならないということでもあります。では、どのようにしてそのような組織を作れば良いのでしょうか？ 次回の記事で紹介します。