DXEが持つべき姿勢。良いDXEとは。

ここでいうDXEとは、

DXを構想し、業務と技術の接続を設計し、実用化まで導く役割を指す。

DXEの仕事は、AIを導入することでも、業務を自動化することでも、依頼されたシステムを正確につくることでもない。

技術によって変えてよいものと、変えてはいけないものを見極める。現在の業務を分解し、未来の使われ方を描き、実際に価値が生まれるところまで進める。

そのために必要なのは、技術知識だけではない。

必要なのは、相手より先に答えを出すことではなく、相手とともに正しい問いを持ち、現実が変わるところまで扱う姿勢である。

良いDXE

1.相手の知識/経験/解像度から見える本当に欲しいものを引き出せる

同意主義は誰のためにもならない

• DXEが持っていくべきものは、完成した答えだけではない。
• 相手が考えるための問いである。
• この仕組みが完成したら、どこで使いますか。誰が最も喜びますか。逆に、誰も使わないとしたら何が原因ですか。精度と速度ならどちらが重要ですか。すべてを検知する必要がありますか。問題が見つかった後、誰が何をしますか。
• こうした問いによって、相手は現在の業務を説明するモードから、未来の業務を想像するモードへ移る。
• 相手の解像度と思考の幅を広げるとは、詳しい説明を与えることではない。
• 相手が自分の頭でもう一度業務を想像できる問いを渡すことである。

相手が考える余白を、意図的に残す

• DXEがすべてを整理しすぎると、クライアントは評価者になる。
• 提示された案を承認するか、修正するかを選ぶだけになる。
• しかし、本来クライアントは、その業務に最も多くの情報と価値判断基準を持つ共同設計者である。
• その知識を引き出すには、資料の中に余白が必要になる。
• 決め切っていない選択肢、比較するための具体例、現場でしか答えられない問いを残す。
• 良い資料とは、説明だけで完結する資料ではない。
• 相手の頭が動き始める資料である。

解像度の高い仮説ほど、正しく見えてしまう。誤った要求に着地するリスクを踏まえるべき。

• DXEは、クライアントよりも先に情報を整理し、構造化された仮説を提示できる。
• しかし、仮説の完成度が高いことと、その仮説が正しいことは同じではない。
• 論理的で具体的な案を提示すると、相手は「それです」「確かにそうです」と答えやすい。
• だが、その反応は本当に必要なものへ到達した証拠ではない。
• 単に、相手がそれ以上考えなくて済むほど、提案が強く見えている可能性がある。
• DXEの仮説は、相手の思考を助けることもあれば、相手の思考を奪うこともある。

自分たちの不安や迷いも、プロジェクトへ開示する

• 「私たちは、このまま進めると実用化から遠ざかる可能性を感じています」
• 「この仮説には納得感がありますが、現場で本当に必要とされるかはまだ分かりません」
• 「作ることはできますが、使われる場面をまだ描き切れていません」
• こうした発言は、弱さではない。
• 不確実なものを不確実なまま共有し、相手を本当のプロジェクトメンバーとして扱う姿勢である。
• DXEは、すべてを分かっている専門家として振る舞う必要はない。
• 分からないものを明らかにし、必要な検証を共同で設計する専門家である。

2.実際に仕事が成立する仕組み、つまり現実を作ることができる

技術ではなく、現実の変化を扱う

• DX案件では、「何をつくるか」が話の中心になりやすい。
• AIで採点する。問い合わせを自動化する。データを一元化する。ダッシュボードを構築する。
• しかし、これらはすべて手段である。
• 本当に確認すべきなのは、その仕組みができることで、誰の仕事がどのように変わるのかだ。
• 判断が速くなるのか。 問題を早期に発見できるのか。 顧客への対応が良くなるのか。 人が本来向き合うべき仕事に時間を戻せるのか。
• 高度なシステムが完成しても、実際の業務で使われなければ、変革は起きていない。
• 反対に、入力形式を少し変えただけでも、大きな負担がなくなり、必要な結果が得られるようになったなら、そこには確かなDXがある。
• DXEが扱うべきなのは成果物ではなく、成果物によって変わる現実である。

つくれるものではなく、成果が得られるものをつくる

• プロジェクトの開始時には、誰もが成果を求めている。
• ところが、実際に開発が始まると、いつの間にか目標が小さくなる。
• まずは動くものをつくろう。今月中に検証できる状態にしよう。一定の精度が出れば成功としよう。
• こうした中間目標は必要である。しかし、それがプロジェクトの最終目的に置き換わると、「つくれたが、使われない」という結末が生まれる。
• DXEは、つくれるものをつくる方向へ流されてはいけない。
• 目指すべきなのは、成果を手に入れるところまでである。

ゴールを、成果物ではなく使われている一場面で描く

• 「品質を向上させる」「業務を効率化する」「問題を早期発見する」といったゴールは、方向性としては正しい。
• しかし、抽象的な言葉だけでは、必要な仕組みを具体化できない。
• DXEは、実際に使われている一場面を描く。
• 誰の画面に何が表示されるのか。いつ通知されるのか。何を確認するのか。次にどの行動を取るのか。その行動によって何が改善されるのか。
• たとえば、重大な問題が検知されると、管理者のチャットへ通知が届く。通知から該当する会話を確認できる。管理者が内容を確認し、必要な場合だけ担当者へフィードバックする。
• ここまで描けば、通知量が多すぎると信用されなくなる、録音データの反映が遅いと役に立たない、精密な点数より早いアラートが必要だ、といった要件が見えてくる。
• 実用シーンを具体化すると、技術要件は後から立ち上がってくる。

To-Beではなく、明日の仕事を描く

• 抽象的な理想像だけでは、業務は変わらない。
• DXEが描くべきなのは、いつか実現する理想的な組織ではなく、その仕組みが導入された翌日に起きる仕事である。
• 誰が何を見て、何を判断し、何をしなくてよくなり、何に時間を使えるようになるのか。
• 明日の仕事を具体的に描けなければ、その仕組みが本当に必要かを判断することもできない。

作業ではなく、達成状態を定義する

• 作業の分解だけでは不十分である。
• 本当に定義すべきなのは、何をしたかではなく、どの状態になれば仕事が完了したと言えるかである。
• 必要な情報がそろっている。判断可能な状態になっている。顧客の不安が解消されている。次の担当者が迷わず動ける。後から判断根拠を確認できる。
• 達成状態が定まれば、現在の手順に縛られず、複数の実現方法を比較できる。
• DXEは、既存作業を機械へ移すのではなく、望ましい状態へ到達する方法を設計する。

変えてよいことと、変えてはいけないことを先に分ける

• 要件整理で確認するべきなのは、既存業務を正確に再現できるかだけではない。
• 何が法律や契約上の制約なのか。何が事業上守るべき価値なのか。何が現場の慣習なのか。何が単に昔から続いている形式なのか。
• 変えてはいけないのは、業務の目的や重要な価値である。
• 現在の手順や形式まで、すべて保存する必要はない。
• むしろ、目的を守るために形式を変えることがDXである。

数字に表れない価値を、存在しないものとして扱わない

自動化の効果は、削減時間や人件費として計算しやすい。

一方、安心、感謝、納得、信頼、関係性といった価値は計算しにくい。

そのため、DXでは計測できるものだけが重視され、計測しにくいものが無視されやすい。

しかし、数字に表れないことと、価値がないことは同じではない。

顧客がサービスを使い続ける理由や、問題が起きても離れない理由は、しばしばこうした見えにくい価値の中にある。

DXEには、測定可能なコストだけでなく、失われる可能性のある価値を捉える視点が必要である。

3.実装者であると同時に業務を構造化するパートナーであれる

答えを渡す人ではなく、未来の業務を共同で発見する人になる

• 技術情報を伝えるだけなら、いずれAI自身ができる。
• ツールを導入するだけなら、製品ベンダーができる。
• 指示されたものをつくるだけなら、開発会社ができる。
• それでもDXEが必要とされるのは、技術と現場のあいだに立ち、まだ言葉になっていない価値や、相手自身も想像していない業務の可能性を発見できるからである。
• DXEは、自動化する人ではない。
• 変えてよいものと、変えてはいけないものを見極める人である。
• 現在の業務を分解し、未来の利用場面を描き、相手の思考を起動し、実行によって理解を深める人である。
• そして、技術的に完成するところではなく、現場が変わり、成果が手に入るところまでをプロジェクトとして扱う。
• それが、DXEが持つべき最も重要な姿勢である。

信頼されることではなく、相手が具体的に考えられる範囲を広げる

• DXでは、クライアントとの信頼関係が重要だと言われる。
• もちろん、誠実さや約束を守ることは前提である。
• しかし、DXEの価値を信頼関係だけで説明することはできない。
• 業務に詳しいのはクライアントであり、何を価値とするかを決めるのもクライアントである。
• DXEが持つのは、技術の知識、他社事例、構造化能力、未来の業務を具体化する方法である。
• 両者の知識は代替関係ではない。
• DXEがするべきことは、相手の業務知識を奪うことでも、相手に代わって未来を決めることでもない。
• 相手がAIや未来の業務について考えられる範囲を広げ、その解像度を高め続けることである。

自動化できる範囲ではなく、自動化してよい範囲を見極める

• 技術的に自動化できることと、自動化するべきことは一致しない。
• DXEが最初に確認すべきなのは、どこまで自動化できるかではなく、どこまで自動化してよいかである。
• 人が行っている仕事には、処理結果だけでは説明できない価値が含まれている。
• 人が対応してくれた安心感、自分の事情を理解してもらえた感覚、困ったときに頼れるという信頼、感謝や関係性が生まれる余白。
• これらは、対応件数や処理時間には表れにくい。
• 自動化によって作業時間が減っても、顧客との関係や継続理由が失われるなら、その効率化は成功とは言えない。
• DXEは「この作業を人が行う意味は残っているか」と問わなければならない。

現在の作業形式を、守るべき要件だと思い込まない

• 多くのDX案件では、現在の操作や帳票、承認手順、入力形式が、そのまま業務要件として提示される。
• しかし、それらの多くは目的ではない。
• 過去の制約や使用していた道具に合わせて生まれた、現在の実現方法にすぎないことがある。
• たとえば、ある帳票から選択結果を読み取る必要があり、画像認識の精度が安定しないとする。
• 現在の帳票形式を維持したまま精度向上を目指せば、難しい技術課題になるかもしれない。
• しかし、入力を選択式から明示的な記述式へ変えてよいのであれば、問題は簡単に解ける可能性がある。
• 守るべき要件は「現在の帳票を読み取ること」ではなく、「必要な情報が正しく記録されること」である。
• DXEは、現在の方法と、本当に達成するべき状態を分けて考えなければならない。

「○○業務を自動化する」と言わない

• 一つの業務には、性質の異なる複数の作業が含まれている。
• 問い合わせ対応であれば、顧客情報の参照、内容の分類、契約の確認、定型回答、個別判断、他部署への確認、履歴の記録などが混在している。
• これらを一つの業務として扱うと、「全部自動化するか、全部人に残すか」という粗い判断になる。
• DXEは、業務を作業単位に分解する。
• 情報参照は自動化する。定型判断はAIに任せる。テンプレート対応は自動化する。例外は人へ渡す。最終判断は人に残す。
• 作業を分解することで、人とAIの役割を具体的に設計できる。

4.賢さでは解けない問題を、対話と把握とモノづくりを進めながら解くことができる

最初から正しい優先順位を決められると思わない

• DXを始めるとき、候補となる施策は多数存在する。
• どの会社にも、改善した方がよいことは30個以上ある。
• その中から最も効果の高い施策を、開始前に正確に選ぼうとすることには限界がある。
• クライアントは、自社の業務には詳しいが、AIで何が可能かを完全には理解していない。
• DXEは、AIには詳しいが、その会社の業務、データ、例外、文化を最初から理解しているわけではない。
• 双方の理解が不足している状態で、最適な優先順位を確定できると考える方が不自然である。

最初の実装は、成果物ではなく探索/観測装置として扱う

• 必要なのは、完璧な優先順位表をつくることではない。
• まず一つか二つを実際に動かし、その結果から次の判断精度を上げることである。
• 実装すると、初めて分かることがある。
• データが想定より整っていない。現場が困っていた場所が別にある。AIより入力形式の変更が効く。自動化より判断基準の整理が先である。一つの仕組みが別の領域にも応用できる。
• 最初の実装には、成果を出す役割と、その会社を理解する役割がある。
• DXEは、最初から正解を当てようとするのではなく、実行によって正解へ近づいていく。

仮説は提案ではなく、議論の材料として置く

• 仮説を提示するときには、それが暫定的なものであることを明確にする必要がある。
• 「これが正解だと思います」ではなく、「現時点の情報からはこう見えますが、私たちには見えていない現場の事情があるはずです」と伝える。
• そして、仮説への同意を取るのではなく、仮説では説明できない場面や、別の可能性を聞く。
• 業務に最も詳しいのはクライアントである。
• 何を価値と感じるかを決めるのもクライアントである。
• この構造は、DXEがどれほど経験を積んでも変わらない。
• DXEの役割は、相手に代わって正解を決めることではなく、相手がより広く、より具体的に考えられる状態をつくることである。

5.いらないモノを作って、顧客の時間とお金を無駄にしない

「これが完璧に完成したら、本当に使いますか」と何度でも聞こう。

• 技術検証では、精度や処理速度が中心的な評価指標になる。
• しかし、精度が上がったからといって、使われるとは限らない。
• そこで有効なのが、極端な前提を置いた問いである。
• 「この仕組みが完璧な精度で完成したら、本当に使いますか」
• 「完成した翌日から、誰が、いつ、何のために使いますか」
• この問いによって、技術的な可能性ではなく、実際の利用場面を考えるモードへ移れる。
• すると、全件を詳細に採点する必要はないかもしれない、重大な問題だけ通知されればよい、特定の部署だけが使う、リアルタイム性の方が重要である、といった本当の要求が見えてくる。

小さく作ることと、目的なく作ることを混同しない

• 小さく試すことは重要である。
• しかし、小さく試すことには、何を学ぶための試作なのかという設計が必要になる。
• 利用場面を検証するのか。データ品質を見るのか。現場が行動を変えるかを見るのか。技術的な精度限界を確かめるのか。
• 検証したい仮説がない試作は、単なる制作である。
• DXEは、素早い開発を目的の代わりにしてはいけない。
• 速く作れるからこそ、何を学び、次にどの判断をするための実装なのかを明確にする。

ゴールや進め方を変える前に、このまま進んだ未来を関係者と共有する

• プロジェクトの途中で目的と手段のずれに気づいたとき、DXEは新しいゴールを提案したくなる。
• しかし、相手にとっては、なぜ突然ゴールを見直すのかが分からないことがある。
• DXEの頭の中では、実用化から遠ざかっている、評価すること自体が目的になっている、使われないものをつくる可能性がある、といった危機感が生まれている。
• その危機感を説明せずに目的やゴールだけを再整理すると、相手にはベンダー側の内部事情に見えてしまう。
• 必要なのは、まず回避したいバッドエンドを共有することである。
• 「現在の進め方でもシステムは完成します。しかし、完成後に実際の業務で使われない可能性を感じています」
• 「精度を高めることに時間を使っていますが、本当に必要なのは一部の重大な問題を早く発見することかもしれません」
• このリスクに相手も納得できれば、その後のゴール再設定は共同作業になる。

進め方や実装案ではなく、リスクの認識共有から始める

• DXEは問題に気づくと、すぐに整理し、解決策をつくりたくなる。
• しかし、相手と共有されていないリスクに対する解決策を提示しても、なぜその提案が必要なのかは伝わらない。
• リスクの共有を飛ばして、リスクを潰す方法から話してはいけない。
• まず、このまま進むと何が起きるのかを共有する。
• その未来を相手がどう捉えるかを聞く。
• そこで初めて、目的、ゴール、進め方を一緒に考えられる。

AI開発は安いからこそ、不要なものを作りやすい

• AIによって試作や開発のコストは大きく下がった。
• 以前なら数か月かかっていた検証が、数週間でできることもある。
• これは大きな利点である。
• 一方で、安く早く作れることによって、「本当に必要か」を考える前に作り始める危険も増えている。
• とりあえず作る。精度を見てから考える。使わなければ別のものを作る。
• この進め方が常態化すると、制作すること自体がプロジェクトの活動になる。
• AI開発はコストが低いからこそ、発注者も支援者も、成果ではなく制作へ逃げやすい。