この記事の見取り図

序章 なぜDXの話は噛み合わないのか

「設計対象」が違うのかもしれない

AIやDXについて話していると、同じ言葉を使っているはずなのに、話が噛み合わない場面があります。

• ある人はOCRやRPAの話をしています。
• ある人は業務改善の話をしています。
• ある人はBPRの話をしています。
• また別の人は、新しいサービスやプラットフォームの話をしています。

どれも間違いなく価値のある取り組みですし、広い意味ではすべてDXと呼ばれることもあります。

ただ、それらを一つの言葉でまとめてしまうと、「何を設計しているのか」の違いが見えにくくなってしまうように感じています。

最近は、その違いを「設計対象」という視点で整理すると分かりやすいのではないか、と考えるようになりました。

設計対象は、おおよそ次のように広がっていきます。

1. 処理
2. 業務
3. 仕事
4. 価値提供のサプライチェーン
5. 産業・生態系

最初は一つの処理を自動化するところから始まります。

その次に、複数の処理をつないで業務全体を設計するようになります。

さらに進むと、「この仕事は本当に今の形である必要があるのか」という問いが生まれます。

そして、一つの仕事だけではなく、その前後を含めた価値提供全体、さらには複数の企業や組織が関わる生態系まで設計対象が広がっていきます。

一方で、設計対象が広がるだけではありません。

実は、設計そのものの性質も少しずつ変わっていきます。

処理や業務を設計しているときと、仕事や産業を設計しているときでは、考え方そのものが少し違うのです。

DXエンジニアリングの先には何があるのか

設計対象が広がるだけなら、単純にスケールアップの話で終わります。

でも実際には、それだけではないように感じています。

処理を設計しているときと、仕事を設計しているときでは、そもそも考え方が違います。

さらに、産業や生態系を考え始めると、「設計する」という言葉の意味まで少し変わってきます。

そこで今は、大きく三つに分けて考えています。

• Engineering
• Re-engineering
• Ecosystem Design

この三つは、優劣ではなく設計の種類です。

Engineering

Engineeringは、与えられた目的を実現するための設計です。

例えば、

• OCRを作る
• RPAを実装する
• AIチャットボットを作る
• ワークフローを組む

などです。

「何を実現したいか」はある程度決まっていて、それをどう成立させるかを考えます。

もちろん簡単ではありません。

精度や速度、コスト、運用性、保守性など、多くの要素を考えながら現実に動くものを作る必要があります。

一般的にイメージされるエンジニアリングは、この領域を指すことが多いと思います。

Re-engineering

一方で、仕事を観察していると、別の問いが出てきます。

「この仕事、本当に今の形で存在する必要があるんだろうか。」

例えば契約管理なら、

• 契約書を受け取る。
• ファイル名を付ける。
• フォルダへ保存する。
• 台帳を更新する。

という仕事があります。

でも、本当に欲しいのは保存作業ではありません。

必要なのは、必要な契約を、必要な人が、必要なタイミングで判断に使える状態です。

つまり、今の仕事を効率化することと、仕事そのものを設計し直すことは少し違います。

ここでは、「どう作るか」ではなく、「何を作るべきか」という問いが中心になります。

これがリエンジニアリングだと考えています。

Ecosystem Design

さらに設計対象が広がると、一つの会社や一つの仕事だけでは完結しなくなります。

例えば医療、物流、教育、農業。

一つのサービスだけ良くしても、大きく変わらないことがあります。

行政がいて、企業がいて、利用者がいて、教育機関がいて、地域がいて。

様々な主体が、それぞれ違う目的を持ちながら関わっています。

この段階では、「設計する」というより、参加したくなる条件を作るという感覚に近づいていきます。

ルール。データの持ち方。評価基準。参加方法。利益の分配。情報の流れ。

こうした条件を設計することで、生態系全体が自然に動き始めることがあります。

だから最後だけは、Engineeringではなく、Ecosystem Designという言葉の方がしっくりきています。

何か一つを完成させるというより、続いていく仕組みや関係性を設計することが中心になるからです。

ここまでをまとめると、三つの違いはこんなふうに整理できます。

次章では、この三つの設計の種類と、第1章で紹介した五つの設計対象を重ねてみます。

そうすると、「設計対象が変わると、必要になる設計の性質も変わっていく」という関係が、少し見えやすくなる気がしています。

設計対象が変わると、設計行為も変わる

五つの設計対象を重ねてみる

ここまでで、

• 設計対象は五段階あるかもしれないこと
• 設計の種類は三つに整理できそうなこと

を書いてきました。

では、この二つを重ねるとどうなるでしょうか。

今のところ、一番しっくりきているのは次のような対応です。

Engineering

• 1.処理をデジタル化できる
• 2.業務をデジタル化できる

Re-engineering

• 3.仕事を再設計できる
• 4.価値提供のサプライチェーンを再設計できる

Ecosystem Design

• 5.産業・生態系を再設計できる

もちろん境界はきれいに分かれるものではありません。

ただ、多くのプロジェクトでは、このあたりで考え方が少し変わるように感じています。

Engineeringが扱うもの

例えば、OCRを導入するとします。

最初の目的は、「紙をデータにしたい」です。

あるいは、「問い合わせを自動分類したい」「PDFから情報を抽出したい」「AIで文章を生成したい」こうしたテーマでは、「やりたいこと」は比較的明確です。

そのため、

• 精度
• コスト
• レスポンス
• 保守性
• 運用性

などを考えながら実装していきます。

次に、その処理を業務へ組み込みます。

誰が確認するのか。どこで例外処理するのか。どこで履歴を残すのか。

つまり、処理が業務の中で自然に動く状態を設計します。

ここまでは、「与えられた目的をどう実現するか」が中心になります。

.

.

.

Re-engineeringになる瞬間

仕事を観察していると、少し違う問いが生まれることがあります。

例えば営業なら、「企業調査をAIで効率化したい」という相談があります。

最初は、

• 企業情報を取得して、
• 要約して、
• 営業へ渡す、

という話になります。

でも少し考えてみると、営業担当者が本当に欲しいのは企業情報ではありません。

欲しいのは、良い商談ができる状態です。

そのためには、

• 相手の課題が見えている
• 仮説を持てている
• 過去の接点が分かる
• 次に何を聞けばいいか考えられる

という状態が重要になります。

つまり、企業情報を集める仕事ではなく、良い商談を生み出す仕事へ設計対象が変わります。

ここから先は、「企業情報をどう取得するか」ではなく、「良い商談はどうすれば生まれるのか」を設計することになります。

これがリエンジニアリングに近い考え方だと思っています。

.

.

.

状態を捉え設計する

この段階になると、「状態」という考え方が重要になります。

私は最近、状態とは、その対象が現在何を可能としているかを決める前提条件として整理しています。

例えば、「提案済み」というステータスが欲しいわけではありません。

必要なのは、「提案できる」という状態です。

その状態は、

• 顧客を理解している
• 仮説がある
• 提案内容がまとまっている
• 関係者の確認が終わっている

といった事実によって成立します。

つまり、

• 事実が集まり、
• 状態が決まり、
• 可能な行動が決まり、
• その行動によって新しい事実が生まれる。

この循環を設計することが、仕事を設計することに近いのではないかと考えています。

.

.

.

サプライチェーンを作り上げる

さらに対象を広げると、一つの仕事だけでは価値は生まれません。

営業。契約。提供。サポート。改善。開発。

それぞれが独立しているわけではなく、一つの流れになっています。

例えば問い合わせ対応をAI化する場合でも、問い合わせを減らす設計ができれば、そもそも対応業務は減ります。

利用状況から問題を先回りできれば、問い合わせ自体が発生しないこともあります。

問い合わせ内容を開発へ戻せれば、商品そのものが改善されます。

つまり、一つの仕事を改善するより、価値提供全体を設計する方が、結果として大きな変化につながることがあります。

だから第四段階では、仕事ではなく、価値提供のサプライチェーンそのものが設計対象になります。

こうして並べてみると、設計対象が広がるだけではなく、設計の出発点そのものが少しずつ変わっているようにも見えてきます。

• 最初は処理から始まります。
• その次は業務になります。
• さらに仕事になります。
• そして価値提供全体になります。

設計対象が広がるにつれて、「どう作るか」だけでは足りなくなり、「何を作るべきか」という問いの比重が少しずつ大きくなっていくように感じています。

.

.

.

終わりに：DXの先にあるもの

思うのは、第3段階以降になると、「DX」という言葉だけでは少し説明しきれなくなってくることです。

デジタル技術はもちろん重要です。AIも、クラウドも、ソフトウェアも欠かせません。

でも、設計している対象は、デジタルそのものではありません。

例えば、

• 人とAIの役割分担
• 仕事の進め方
• 契約や責任の持ち方
• 組織同士の連携
• 品質を維持する仕組み
• 価値が循環する構造

こうしたものまで含めて設計対象になっていきます。

つまり、「何をデジタル化するか」よりも、「どんな現実を成立させたいのか」が中心になっていきます。

その意味では、第3段階以降はDXというよりも、「現実を設計すること」に近づいていくのかもしれません。

その先では、「一つの会社の仕事」ではなく、「社会全体として、どうすればより良い価値提供が続いていくか」という問いも現実味を帯びてきます。

もちろん、多くのプロジェクトは第1段階や第2段階で十分な成果を出せます。

それが悪いという話ではありません。

むしろ、そこを丁寧に積み重ねることがとても大切です。

Engineeringから始まり、

Re-engineeringへ進み、

その先にEcosystem Designがある、

という見方は、これからの設計を考える一つの地図として役に立つような気がしています。

まだ仮説の段階ではありますが、この地図を持って現場を見ると、同じ「DX」という言葉の中にある違いが少し見えやすくなります。

そして、それぞれのプロジェクトが今どの段階にいて、次に何を設計しようとしているのかも、以前より整理しやすくなるのではないかと考えています。