デジタル設計から変革化ではなく、
変革設計からデジタル化を考える
DXという言葉が広く使われるようになりました。
業務をデジタル化する。
紙をなくす。
Excelをシステムへ置き換える。
生成AIを導入する。
クラウドサービスを利用する。
もちろん、これらも大切です。
しかし、一つ大きな疑問があります。
デジタル化した結果、会社がどのように変わるのかを、デジタル化する前に設計しているでしょうか。
私たちは、これからのDXには順番そのものを見直す必要があると考えています。
そこで提案したいのが、
DXからXDへ。
本稿ではXDを、
Transformation → Digital
つまり、
「変革を先に設計し、その変革を実現するためにデジタル化する」
という考え方として使います。
「とりあえずデジタル化」が危険な理由
現在行っている業務を、そのままシステムへ置き換える。
これは一見すると合理的です。
紙の申請書をWebフォームへ変える。
Excel台帳をデータベースへ移す。
人が行っていた集計をAIに任せる。
しかし、それだけでは現在の会社の構造をデジタル上に再現しただけかもしれません。
本来考えるべきなのは、その前です。
そもそも、その申請は必要なのでしょうか。
その承認は人間が行う必要があるのでしょうか。
その情報は誰が入力すべきなのでしょうか。
AIが判断できる部分はないのでしょうか。
顧客自身に入力してもらった方が合理的ではないでしょうか。
会社が10倍の規模になったときも、その業務は同じでしょうか。
こうした問いを飛ばして現在の業務をそのままデジタル化すると、今存在している非効率までシステムの中へ固定してしまいます。
そして数年後、
「会社の組織を変えたい」
「AIを導入したい」
「承認工程を減らしたい」
「拠点を増やしたい」
と思ったときに、今度はシステムそのものが変革の障害になることがあります。
DXのために作ったシステムが、DXを妨げる。
そんな逆転現象が起こり得るのです。
先に「未来の会社」を設計する
私たちが考える順番は逆です。
まず、
この会社を、将来どのような会社へ変えたいのか。
を考えます。
そのうえで、
誰が働くのか。
どの仕事を人間が行うのか。
どの仕事をAIに任せるのか。
誰が判断するのか。
誰が承認するのか。
顧客や取引先はどこまでシステムへ参加するのか。
どのようなデータが必要なのか。
誰がそのデータを見ることができるのか。
会社が成長したときに組織や権限をどう変えるのか。
を設計していきます。
つまり、
未来の会社像
↓
業務構造
↓
人・AI・システムの役割
↓
データ・権限・状態
↓
デジタル実装
という順番です。
デジタルから会社を考えるのではありません。
会社からデジタルを考える。
これがXDという考え方です。
システム設計はIT部門だけの仕事ではなくなる
ここで重要になるのがシステム設計です。
経営者がプログラムを書く必要はありません。
システム開発会社へ依頼してもいい。
フリーランスへ依頼してもいい。
社内エンジニアに作ってもらってもいい。
生成AIにコードを書かせてもいい。
重要なのは、
何を作らせるべきなのかを、経営側が理解していることです。
なぜなら、これからの会社では、
人間だけでなく、
システム、
生成AI、
AIエージェント、
外部サービス
が会社の業務を構成するようになるからです。
将来の会社をイメージするためには、将来のシステム構造まである程度イメージできなければなりません。
逆に言えば、
イメージできない会社を実現することはできません。
そして、
言語化できないシステムを、AIにも開発会社にも正確に作らせることはできません。
「動けば完成」ではない
ホームページや短期間のマーケティングツールであれば、
表示される。
フォームが送信できる。
広告効果を計測できる。
それで目的を達成できるものもあります。
しかし業務システムは違います。
使い始めた瞬間から、
顧客情報、
契約、
請求、
在庫、
社員、
権限、
承認、
業務履歴
といった会社そのものの情報が蓄積されていきます。
だから、
動いたから完成
ではありません。
社員が増えても使えるか。
部署が増えても対応できるか。
権限変更に対応できるか。
同時に多くの人が操作しても壊れないか。
AIを追加できるか。
業務そのものを変更できるか。
こうした変化へ耐えられることが重要です。
業務システムにおける完成とは、
「動くこと」ではなく、「変え続けられること」
なのです。
AI時代だからこそ、設計が重要になる
生成AIによって、コードを書くことのハードルは急速に下がっています。
これは非常に大きな可能性です。
これまでシステム開発会社へ依頼しなければ作れなかったものを、企業自身が作れる時代が始まっています。
しかし同時に新しい問題も生まれます。
設計を知らなくても、
画面を作れる。
データベースへ保存できる。
ログイン機能を付けられる。
APIへ接続できる。
テストコードまで生成できる。
つまり、
設計を知らなくても、それなりに動くシステムまで作れてしまう。
以前なら技術力不足によって途中で止まっていたものが、AIの支援によって完成してしまう可能性があります。
だからこそ、
AI時代に価値が上がるのは、コードを書く能力だけではありません。
何を作るべきか。
どのような構造にすべきか。
どんな権限が必要なのか。
どんなデータを残すべきか。
会社が成長したときにどう変化できるのか。
それを判断する設計力です。
内製化すべきなのは「開発」ではなく「設計」
私たちは、すべての企業がプログラマーを抱える必要があるとは考えていません。
開発は外注しても構いません。
むしろ高度な専門技術は、専門家へ頼んだ方が合理的です。
しかし、
会社の未来をどう設計するのか。
ここまで外部へ丸投げしてしまえば、会社の将来そのものを外部へ委ねることになります。
だから企業が本当に内製化すべきなのは、
プログラミングではありません。
設計判断です。
何を作るのか。
なぜ作るのか。
誰が使うのか。
誰に何をさせるのか。
AIへ何を任せるのか。
会社が成長したらどう変えるのか。
ここを自社で考えられるようになる。
そうすれば、開発会社とも対等に話せます。
複数の開発会社を比較できます。
生成AIも正しく使えます。
専門家へ頼むべき部分も見えてきます。
DXからXDへ
デジタル化してから、会社がどう変わるかを考える。
その順番ではありません。
変えたい会社を先に描く。
そして、その会社を実現するために、
業務を設計し、
人とAIの役割を設計し、
システムを設計し、
最後にデジタル化する。
これから必要なのは、
デジタル設計から変革化ではなく、
変革設計からデジタル化を考えること。
だから私たちは提案します。
DXからXDへ。
デジタル化を設計する前に、変革を設計しよう。
未来の会社を先に描き、
その未来を実現するために、
デジタルを使う。
それが、AI時代のDXに必要な新しい順番ではないでしょうか。