専門用語をいっさい使わずに、経営層にDXの意義を伝えたい

予想はしていましたが、いまやDXというキーワードはなんでもあり、のバズワードです。最先端のAIやIoTといった技術を使いこなすのもDX、老朽化した基幹系刷新もDX(そういえば、このテーマについては「2025年の崖」でも語られました)、そしてノーコードやローコード開発ツールを学んで現場主導で内製化するのもDXです。ここまで対象が広いと、なんのためのDXだったのか、私も見失いそうになります。そこで今回、ITの専門用語を使わず、経営層に的を絞ってDXの意義を伝える文章を書いてみることにしました。

労働生産性の議論

これも経営層にとっては一度ならずも見聞したことがあるネタですが、いわゆる日本の労働生産性の問題です。

公益財団法人 日本生産性本部の「労働生産性の国際比較2021」によると、日本の時間当たり労働生産性は49.5ドル(5,086円)で、OECD加盟38カ国中23位とあります。

www.jpc-net.jp

労働生産性とはそもそも何か、という議論は専門家がいろいろお話しされていますのでそれはパスしますが、経営層にとって労働生産性を高めるというのは

売上を上げるか、経費を削減するか

という指標であり、これを意識していない経営層は皆無のはずです。しかし一向に改善しないのはなぜか、ここに根の深い問題がありそうです。

労働生産性だけが指標ではない、2022年の状況

仮に日本のバブル景気が終わったとされる1992年を起点としたとき、このブログを書いている2022年は、あれから30年が経過しています。この間、各社とも手をこまねいていたわけではないでしょう。

労働生産性だけに着目するなら、新製品の投入や値引きによる拡販、さらには雇用の非正規化といった荒療治をも組み合わせた人件費削減など、これまで知られてきた対策のいくつか(あるいはすべて)をやってきたはずです。これらをやりつくしてもなお、改善の糸口がみえない、というのが多くの企業の現状ではないでしょうか。

現在は、さらに事情が複雑になっています。次の3点セットすべてを改善しなさい、というのが社会で共有されつつあります。

  • 労働生産性
  • 顧客満足度
  • 従業員満足度

つまり企業をとりまくすべての関係者(顧客、従業員、株主)すべての満足度を高めるように配慮するのが経営層の努めになっています。より複雑な方程式を解くことが求められています。

指標の「見える化」ができていない

労働生産性、顧客満足度、従業員満足度は密接にからみあっています。生産性を高めるために売上アップをはかる、しかしそのために従業員に過度のノルマを与え、かつそれを非正規雇用で達成したり残業代未払いで経費削減しようとするとブラック企業化します。従業員満足度が下がるだけでなく、悪評がSNSで拡散し、結果として企業の売上に影響します。では適正な仕事量で売上アップや経費削減しようとすると、業務の見直しが避けられません。ところが部署をまたがった業務フローの見直しは関係者調整が多いため、社内の誰もやりたがりません。

つまり経営層は、やるべきことはわかっているにもかかわらず、

  • 何かを変えようとしたとき、それがどこにどのような形で影響するのかを把握できていない。
  • もっとも効果的な対応はどれか、という優先順位をつけられない。なのでヒト・モノ・カネの資源割り当てが適切に行えない。

といった問題を抱えています。

実は、この対策はすでに明らかです。企業が扱う情報の流れと、格納される値の両方を「見える化」することです。別の言い方をすると、適切な見える化ができていない状態では、何から手をつければいいのか、判断することはどんな名経営者にとっても至難の業です。

DX の D は、見える化の土台をつくること

ようやくDXの話とつながりました。D すなわちデジタルとは、すべての情報を自分たちのコントロール化におくこと、です。

そしてほとんどの企業が、ここで足踏みしています。

企業が扱うデータは確かにデジタル化されています。しかしその実情は「基幹システムが持っているデータ」「現場がExcelで個別にもっているデータ」「クラウドサービスで管理しているデータ」など、ばらばらです。

これはデジタル化されているものの、これらのデータをつなげ、意味のある流れとして解釈しようとすると、データ連携という膨大なコストがかかります。さらに、例えば「売上」や「顧客」といったもっとも基本的なデータでさえも、各システムごとに個別の解釈でデータ化していることがあり、同じ名称だがデータの意味が異なるということも珍しくありません。

つまり私がいう「見える化の土台」とは、「統合化されたデータベース」をもちましょうということです。

ここでのポイントは、統合化されたデータベースとは、データとデータの関係性が明らかになった状態であること、を含んでいることです。あるデータの変更は、どのデータに影響するのか、これが見える化されてはじめて、次のステップに進むことができます。

DX の X は、部門をまたがる業務フローを見直すこと

統合データベースをもってはじめて、X すなわちトランスフォーメーション、業務の流れの見直し、の議論ができるようになります。

ただ「見直し」ましょう、だと何をすればいいのかわかりません。そこで、先に挙げた「労働生産性」「顧客満足度」「従業員満足度」をできるだけ高めるという観点が指標になります。組織構造の見直しや、人的リソースの再配置も含む、大きな話になるでしょう。つまり DX とは、最終的に大きな話になるものです。

なんちゃって DX との違いが明確に

ここまでの話から、多くの企業でトライしている DX が、なんちゃってDXと揶揄される程度のものかどうかを確認できます。統合データベースを指向せず、組織体制と業務フローは温存したまま、一部業務だけに先進的な AI を取り入れることは、DX ではなく業務改善の一環です。もちろん多少の成果はあるでしょうが、これで我が社のDXは完成だ、と経営層が安心してしまうのは危険です。

ローコード、ノーコード開発とDXの関係

そして現場が自分の業務をローコード、ノーコード開発ツールで内製できた = DX というわけではない、ということもお伝えしたいことです。繰り返しになりますが、自分たちが扱える(ERPパッケージでブラックボックス化されていない)統合データベースを設計し、そのデータベースを土台にした業務システムをローコード、ノーコード開発ツールをつかって内製する、のが DX です。

わかりにくいかも知れませんが重要なのでもう一度。現場がローコード、ノーコード開発ツールで業務アプリをつくったとき、それぞれのアプリごとにデータベースを個別に用意したのでは、統合データベースとかけ離れた状態になります。これはいわゆる「野良アプリ」として、あとあとマイナスに作用する懸念さえあります。

DX の王道は、統合データベースを出発点とすること、というのが私の持論です。個人的には何も目新しいことはなく、当たり前のことを言っているだけと思うのですが、システム開発を生業とするIT業界全体では、このような意見が少数派である、と感じているので、あらためて書きました。