早嶋です。約3200文字。
企業のDXには、大きく分けて2つの型がある、自前型と依存型だ。
自前型は、自社の中にITやシステムの専門家がいて、あるいは外部の力を借りながらも徐々にDX部隊のような組織を内製化し、設計思想を自分たちの中に取り込んでいく組織だ。
依存型は、IT部門があっても、その中身は出向者や委託会社で成り立ち、システムの設計思想も意思決定も外にある組織だ。
この違いは、技術力の差ではない。ポイントは２つあり、意思決定権の所在が内側か外側がであることと、DXにおける設計思想を、誰が握っているかだ。20年近く、大手の現場を垣間見ながら色々な戦略整理と問題解決の伴走支援を取り組んできた。DXを競争優位の源泉にして成功している企業は、自前型だ。意思決定と設計思想を強烈に持ち、実行しながらブラッシュアップしている。（※典型的な企業の情シス事業についてはこちらを参考に）
直接の関与はないが、福岡銀行は、DXという点でかなり進んでいると思う。最初はIBMのような外部パートナーを大胆に入れながら、単なる委託で終わらせず、ノウハウを内部に取り込み、子会社をつくり、徐々に内製化していった。今でも外部のプロを適宜活用する組織体制ではあるが、システムの設計思想も意思決定も確実に福岡銀行が主導だ。その結果、生活者目線のアプリは使い勝手がよく、アップデートも速い。裏側には、APIやデータ統合を前提とした思想があるのだろう。
一方で、巨大組織になるほど難しくなるのも理解できる。このような組織は、個別には超優秀な人材が点在している。しかしグループ全体を俯瞰し、統合思想をマネジメントできる構想者がほとんどいない。仮に居たとしても、その人に意思決定の権利がほとんど無いし、発言権も実際は無いようなものだ。その結果、システムは分断される。今では随分と改善されていると思うが、長らくJR九州のアプリ予約は最低な顧客体験を提供していた。アプリで予約しても、改札で発券が必要な意味不な使用体験を平気で実装していたのだ。これはまさに典型で技術がないのではなく、思想と意思決定の権利が追いついていなくて、分断した取組しか出来なかったと推測する。
早嶋はDXの本質は目的に尽きると思う、つまり戦略そのものだ。もし、DXを生産性向上、つまりコスト削減を目的にするなら、既存SaaSを導入すればいいし、RPAで人手を減らせば良いとなり兼ねない。それでも一定の成果は出るだろう。しかし競争力を高めたいのなら話は別だ。顧客体験や業務構造そのものを再設計する必要があるからだ。その際、設計思想と広域な意思決定件がなければ部分最適の積み上げになってしまい、連携が取れず顧客体験が最低になってしまう。
ここ3年で時代が変わった。専門的なAIを駆使する必要もなく、汎用AIが高いレベルで活用できるようになったのだ。今後のDXは、目的を競争優位性の確保とし、AIを活用して進める局面に入ると思う。まだ仮説だが、その構想を以下記述する。
従来のSaaS一辺倒の導入から、現場単位のスクラッチ開発から、徐々に統合していくモデルに再び理想の軸が触れると考える。まずは業務単位で小さな成功をつくる。そして、現場が「これは使える」と実感する雰囲気を演出する。そのうえでデータ統合のレイヤーを構築し、全体最適の構想を常に描き続け実装するのだ。そして共通モジュール化を進め、最終的には他地域や他業界に展開できる形に昇華させる。最初からSaaSで押し込むのではなく、結果としてSaaSにする構想だ。
ガソリンスタンド、レンタカー、メンテナンス、フィットネス、建築、コンビニや携帯店舗や飲食などのFCモデル。これらは、どこにでもある事業だが、実際に現場に入ってみると、まったく同じ会社は1つもない。立地が違えば顧客層が違う。商圏が違えば在庫の回転も違う。店長の癖や職人の段取り、長年の取引先との関係性まで含めて、その会社のやり方、独自ルールのオンパレードだ。
こうした現場に、いきなり巨大SaaSを入れるとどうなるか。標準化という名のもとに、現場の微妙な調整が削ぎ落とされる。すると現場は「使いにくい」と言い始める。やがて裏でエクセルが走り出すのだ。結局、二重管理になってしまい、期待するほどコストは下がらない。むしろSaaSのサブスク料金が従来の取組にアドオンするという不明な状況が構築できるのだ。しかし、経営層はDXが進んでいると勘違いして、現場は5年、10年前との変化を実質的に感じないのだ。
だからこそ、最初の一歩は違うアプローチが必要だ。現場に入り、業務の流れを一緒に観察する。「どこで時間を取られているのか」「どこで判断に迷っているのか」「どこが属人化しているのか」。現場の声を多方面から聞きながら、現場で起きている現象を構造化して整理する。そして、その一部分から、小さく実装してみるのだ。
いまは汎用AIがある。GPTでもGeminiでもいい。画面設計も、簡単なロジックも、データベース設計も、プロトタイプなら数日で形になる。以前のように半年かけて要件定義書を書き込む必要はない。仮説を立てて、試しにつくり、現場で触ってもらい、修正する。このサイクルを高速で回すのだ。
重要なのは、現場の声をそのまま全部実装することではない。現場が感じている不便さの奥にある構造を見つけることだ。例えば「在庫管理が大変」という声の裏には、リアルタイムで数字が見えていないという問題があるかもしれない。「シフト調整が面倒」という声の裏には、繁忙時間帯のデータが共有されていないという構造があるかもしれない。
その構造を抽象化し、モジュールとして設計する。顧客管理モジュール、在庫管理モジュール、要員配置モジュール。最初は一店舗、一拠点で使う前提でつくるが、データ設計だけは将来の統合を見据えておく。IDの持ち方、APIの出口、ログの取り方。ここをきちんと設計しておけば、後から横につなげられるからだ。
こうして、現場の声を起点にしながら、小さくつくり、高速に回し、徐々に共通化していく。最初から「業界標準」を押しつけるのではなく、現場から抽象化された標準を生み出す。この順番が重要だ。業務ごとにモジュール化し、それらをAPIでつなぎ、データ統合レイヤーを後からかぶせる。以前なら大掛かりな基幹刷新が必要だったことが、いまは段階的にできる。だから、このアプローチは十分に現実的だと思っている。
巨大SaaSで一気に塗り替えるのは昔の話になったかもしれない。AIが活用できる今だからこそ、現場で試し、磨き、統合するのだ。その繰り返しの先に、結果としてSaaSを立ち上げる。この順番を間違えないことが、AIを活用した取組では無いだろうか。
成功の鍵は明確だ。業務を理解しないまま設計するエンジニアに任せないことだ。現場の声をそのまま全部入れるわけではないが、現場を無視した設計は必ず破綻する。構想者は、現場の要望の背後にある構造を読み取り、抽象化し、将来の統合を見据えて設計するのだ。
当然に、IT業界の資質がかわる。今後は、人月を積むことでの価値は減少する。能力として、セキュリティを前提とした設計力、データモデルの統一、APIの思想、そして将来拡張を見越したスケーラビリティの想像力が必須になると思う。少数精鋭とは、単にコードが速く書ける人ではない。クライアントの業務構造とデータ構造を同時に描ける人だ。
DXとは、おまじないではなく、企業の戦略に紐づいた取組だ。誰が統合思想を握るか。経営か、現場か、外部の伴走者か。ここを曖昧にすると、どれだけAIが進化しても、部分最適の山が蓄積するだけで現場は混乱するだけなのだ。
