DXエンジニアリングとは、人間の不統一な現実と理想的な処理をつなぐ仕事

人間は同じ依頼をしても、

• フォームに入力する人もいれば、メールで返す人もいる。
• 電話で伝える人もいれば、廊下ですれ違ったときに口頭で答える人もいる。
• 正しい手順を知らない人、知っていても急いで別の方法を選ぶ人
• 途中で条件を変える人、対応したこと自体を忘れる人もいる。

DXエンジニアリングとは、この不統一な現実を排除し、人間をシステムに従わせる仕事ではない。

人間がすでにつくっている複雑な現実を観察し、それを壊さないまま、機械が扱える理想的な処理へ接続する仕事である。

DXEの役割1.

”人間の行動ではなく、業務の状態を統一する”

人間の不統一な行動を扱う方法として、すべての利用者に同じ操作を強制する設計が選ばれることがある。

申請は必ずフォームから行う。問い合わせは必ずチケットシステムへ登録する。承認は必ず指定された画面で行う。例外は認めない。

業務によっては、この標準化が有効な場合もある。しかし、あらゆる不統一を人間の教育やルールによって解消しようとすると、システム導入そのものが新しい負担になる。

重要なのは、全員に同じ行動をさせることではない。異なる行動から生まれた結果を、共通の状態として扱えるようにすることである。

フォーム、メール、電話、対面という異なる経路から届いた回答を、すべて「回答済み」という同じ状態へ反映する。システム上の承認と口頭での承認を、必要な記録を残したうえで同じ「承認済み」へ接続する。

統一すべきなのは、人間の入口ではなく、業務上の意味である。

この考え方に立つと、システムの中心は画面や入力フォームではなくなる。誰が何をしたか、その結果として現在どの状態にあるか、次に何が必要かを表現する状態管理が中心になる。

人間の行動はばらばらでもよい。ただし、それぞれの行動が業務にとって何を意味するのかは、共通の状態として記録できなければならない。

DXEの役割2.

実用性と汎用性を混同しない

具体的な業務に合わせてシステムを作ると、「他の部署でも使えるのか」「あらゆるケースに対応できるのか」という問いが出てくる。

もちろん、将来的な展開を考えることは重要である。 しかし、実用性と汎用性は別の問題である。

ある担当者が毎月何時間も費やしている日程調整を確実に減らせるなら、そのシステムは一人にしか使われなくても実用的である。

反対に、あらゆる部署で使えるように多くの機能を備えていても、誰の業務も十分に楽にできなければ実用的とはいえない。

最初からすべての業務を網羅しようとすると、対象が抽象化されすぎて、誰が何のために使うのかが分からなくなる。

一方で、特定の一件だけに合わせすぎると、その業務がなくなった時点で役割を失う可能性もある。

重要なのは、最初から完全な汎用性を目指すことではない。

まずは、解像度の高い一つの業務で実用性を成立させる。その後、似た負担を持つ別の利用者へ、必要な機能を少しずつ追加していく。

これはITではなくAIを用いた実装や仕組みだからこそ行うべきプロセスである。 ITとは異なりデータの型が柔軟になったため「最初から完璧に作らずに仕組みを育てる」という理想論が現実的に行える。

DXEの役割3.

”技術的に動くこと、業務として使えることの違いを理解して進行する”

システム開発では、「処理が成立すること」と「現場で運用できること」がしばしば混同される。

たとえば、

• 申請フォームから受け取った情報をデータベースへ保存し、条件を満たした場合に承認者へ通知する処理は、技術的にはそれほど難しくない。
• 入力形式が一定であり、全員が定められた経路を使うなら、処理はきれいに自動化できる。
• 問題は、フォームを使わずにメールで申請する人がいることである。
• 承認者へ直接口頭で相談する人もいる。入力後に内容を変更したい人もいれば、承認だけ先に進み、記録が後から追いつくこともある。

システムがフォームからの入力しか認識できなければ、現実には承認済みなのにシステム上では未承認となる。システムは設計通りに動いているが、業務の状態を正しく表していない。

技術的な正しさや機能する状態と、 業務上の正しさや機能する状態は別物。

正常系以外における現実の出来事を、どのようにシステム上の状態へ反映できるかまで設計する必要がある。

電話で受けた回答を担当者が代理入力できるのか。口頭で承認された事実を後から記録できるのか。自動処理を一時停止できるのか。誤った状態を人間が修正できるのか。

こうした操作は、自動化の不完全さではなく、人間の現実と自動処理を接続するために必要なインターフェースまでをDXEがデザインすべきであるということ。