「IT化とDXは別物だ」とよく言われます。
確かに、紙をデータに置き換えたり、手作業を自動化したりするだけでは、DXとは呼べません。
しかし、だからといってIT化に意味がないわけではありません。
むしろ、IT化を進めていった結果として、初めてDXの可能性が見えてくることがあります。
IT化すると、会社の構造が見える
紙や口頭で処理していた業務をシステムに置き換えようとすると、これまで見えなかった問題が表面に出てきます。
- なぜ同じ情報を何度も入力しているのか
- なぜこの承認が必要なのか
- なぜ部署ごとに同じような台帳を持っているのか
- なぜ売上と請求と入金が別々に管理されているのか
- なぜ特定の人しか業務の流れを理解していないのか
紙の上では「昔からそうしている」で済んでいたことも、システムにしようとすると、処理の目的や情報の流れを説明しなければなりません。
このときに現れる違和感こそが、DXの入口です。
IT化は、既存業務をそのままデジタルに置き換えるだけの作業ではありません。
会社の構造を可視化し、「そもそも、この構造は必要なのか」と考える機会でもあるのです。
DXの入口が見えた瞬間に、問題が起きる
大切なのは、DXの可能性が見えた瞬間に、適切な情報へアクセスできることです。
ところが現在、その情報へ向かう道の途中に、生成AIが置かれるようになりました。
何か疑問が生まれたら、まず生成AIに質問する。
これは便利ですが、同時に危険でもあります。
生成AIは、質問に対して既存の事例、一般的な業務フロー、普及しているシステム、過去の成功パターンなどをもとに回答します。
その結果、会社の中で見つかった固有の違和感が、次のような既存の言葉へ置き換えられてしまいます。
「それはERPを導入すれば解決できます」
「RPAで自動化できます」
「一般的なワークフローシステムを使いましょう」
「他社ではこのSaaSが使われています」
もちろん、これらが正しい場合もあります。
しかし、それは多くの場合、現在の構造を前提とした改善策です。
本来は構造そのものを見直す機会だったのに、生成AIの回答によって、既存構造の中へ問題が戻されてしまうのです。
生成AIが大量に学んでいるのは「既存の構造」である
DXの「X」は、トランスフォーメーションです。
つまり、既存業務を少し便利にすることではなく、事業や組織、業務、意思決定の構造そのものを変化させることです。
一方、生成AIが大量に学習しているのは、人間がこれまでに作ってきた文章、コード、業務手順、組織論、システム、成功事例です。
その多くは、既存の構造を説明したものです。
生成AIは、既存構造の再現、整理、組み合わせ、効率化を得意とします。
しかしDXで問うべきなのは、
「既存の構造を、どう効率化するか」
ではなく、
「そもそも、この構造を残す必要があるのか」
という問題です。
ここには、明確な方向の違いがあります。
生成AIは、過去から蓄積された構造の中に答えを探します。
DXは、その構造の外側に新しい答えを作ろうとします。
「情報を早く移す」前に、「なぜ分かれているのか」を考える
例えば、受注情報を販売管理システムへ入力し、その内容を在庫管理へ転記し、さらに請求書を作成している会社があったとします。
生成AIに改善方法を尋ねれば、システム同士をAPIで連携する方法や、転記を自動化する方法を提案するでしょう。
これは有効なIT化です。
しかしDXの視点では、もう一段深く考える必要があります。
受注が確定した時点で、
- 在庫の状態を変更する
- 売上予定を記録する
- 請求業務を発生させる
- 入金予定を作る
- 担当者へ次の業務を割り当てる
という処理を、ひとつの出来事から同時に発生させられないでしょうか。
そう考えると、販売管理、在庫管理、請求管理という区切り自体が、本当に必要なのかという疑問が生まれます。
「情報をどうやって早く移すか」ではなく、「なぜ情報が分断されているのか」を考える。
ここから構造の変化が始まります。
生成AIを「答えの入口」に置かない
生成AIそのものがDXを妨げるわけではありません。
問題は、生成AIをどの位置で使うかです。
最初から、
「どのシステムを導入すればよいですか」
「この業務を自動化する方法を教えてください」
と質問すると、現在の業務や組織の構造を前提とした回答が返ってきます。
先に考えるべきなのは、次のような問いです。
- この業務によって、何の状態が変化しているのか
- 誰が、何を判断するために情報を必要としているのか
- 同じ情報が複数の場所に存在するのはなぜか
- 法律や契約上必要な処理と、単なる社内慣行を分けられないか
- 現在の部署やシステムが存在しないとしたら、どのように設計するか
この問いに対して、経営者、現場担当者、顧客、取引記録などの一次情報へ直接アクセスします。
そのうえで生成AIを使い、反対意見を出させたり、類似事例を探させたり、リスクを洗い出したり、プロトタイプを作らせたりするのです。
生成AIに構造を決めてもらうのではありません。
人間が構造変革の仮説を持ち、その仮説を検証するために生成AIを使います。
DX戦略とは、AIを導入することではない
生成AI時代のDX戦略は、最新のAIサービスを導入することではありません。
IT化によって見えてきた違和感を、既存の製品名や一般論へ急いで置き換えないことです。
進め方を整理すると、次のようになります。
- IT化によって、業務と情報の流れを可視化する
- 現場で見つかった重複、分断、例外、違和感を残す
- 既存構造を前提とせず、構造変革の仮説を作る
- 生成AIを使って、仮説、反証、リスク、実現方法を検証する
- 会計、請求、在庫、権限など、会社の資産を変化させる処理は本番用に設計する
この順番が重要です。
生成AIを答えの入口に置くと、未来の可能性が「過去の平均」によって濾過されます。
一方、人間が構造変革の仮説を持った後で生成AIを使えば、AIは強力な加速装置になります。
IT化で見つかった「なぜ」を消してはいけない
IT化を進めると、会社の中にある不合理や分断が見えてきます。
その瞬間に現れる、
「なぜ、この業務は必要なのか」
「なぜ、この情報は分かれているのか」
「なぜ、この人しか判断できないのか」
という疑問を、安易な自動化で消してはいけません。
その「なぜ」の中に、DXの可能性があります。
生成AIは、既存の構造を理解し、再現し、改善することには非常に優れています。
だからこそ、生成AIに任せる領域と、人間が決める領域を分けなければなりません。
会社の構造をどう変えるのか。
その判断まで生成AIへ渡してしまえば、会社は過去の延長線上から抜け出せません。
IT化によってDXが見えたとき、必要なのは、すぐに答えを得ることではありません。
生成AIのフィルターを通す前に、自社の現場、顧客、取引、データ、そして経営者自身の問題意識へ直接アクセスすることです。
そこから、本当のDX戦略が始まります。