実用化されるDXを導くためのコンピテンシー

DXエンジニアリングにおける再現性とは何から齎されるのかを整理してコンピテンシー評価軸にまとめてみました。

作るは容易くても、実用化に至れないバッドループから抜けるための力ともいえます。

コンピテンシー表、その力が必要な理由、要素ごとの解説を書いています。

.
.
.

5つのコンピテンシー

まとめるとこんな感じです。

DXエンジニアリングといっても今の時代は、実装者と設計者とPMを全て同一人物が担うことも多いです。

その前提、ただの実装スキルは成果の再現性のための支配要因にならないため含めていません。

ぶっちゃけ、
項目1の要求探索力が永遠にめっちゃむずいです。

2,3は、経験すれば確実に伸びます。
4,5は、現在の設計や進行を疑うための"アンテナ"のようなものが育っていけばいけます。仮説の弱さや更新すべきタイミングや発見があった時に気づけるようになります。

要求探索力が難しいから、エンジニアあがりのDX担当者が一旦そこそこ作れるのに現場的には意味が出せない状態になりやすかったりします。

エンジニア上がりでは、成果を出せないという意味ではなく、不思議な話なんですが、文系が推進するよりも難易度が高まる場合もある。という話です。

基本的には、
現場側や業務経験豊富な当事者を巻き込むか、業務の当事者自身が主体になってDXの進行が出来れば、要求探索の効率も精度も常に高くなります。

リアリティを失う可能性が低いからです。
いつ何時も、それが理想です。

.
.
.

DXやAI活用の失敗は、現実への理解を更新することを止めると起きる

コンピテンシーの詳細解説の前に、なんで失敗がこんなにも頻度高く起きているのか？の根本を書きます。

DXプロジェクトは、技術力が足りないから失敗するケースはもうほとんど存在していないです。

現場や現実的なイメージを十分に理解できていないまま、要求を決め、設計し、実装し、完成へ向かってしまうプロジェクトが失敗しています。

問題は、
良い設計が最初から作れないことではないです。
進行の途中で、現場への理解や、作られるべき業務像が適切に更新されなくなることです。

色々と出来そうだし、
作るのも楽しい。
だからといって、リアリティのないモノづくりをしてしまった結果、失敗が起きています。

現実の理解を更新し続けることで、使われないものを完成だとしてしまうバッドループから逃げ切り続けることが出来れば実用化に至れます。

.
.
.

以下は、各コンピテンシーの解説です。

1. 要求探索力：相手の知識・経験・解像度から、本当に欲しいものを引き出せる

相手が考えられる問いを渡す

• DXEが持ち込むべきものは、完成した答えだけではないと思っている。
  

• むしろ、相手が考えられる問いを持ち込めるかどうかが、その後のプロジェクトを大きく左右することが多い。

たとえば、

1. 「この仕組みが完成したら、誰が一番喜びますか。」

2. 「精度と速度なら、どちらが重要ですか。」

3. 「問題が見つかったあと、誰が何をしますか。」

• こうした問いによって、相手は現在の業務を説明する状態から、「未来の業務はどうあると良いのか」を考える状態へ移っていく。

• DXEが相手より先に正解を提示することよりも、相手自身もまだ言葉にできていない要求を一緒に見つけていくことの方が、結果として良いDXにつながると感じている。

相手が考える余白を残す

• DXEが整理しすぎると、クライアントは提案を評価するだけの立場になってしまう。

• 一方で、その業務について最も多くの知識や判断基準を持っているのは、現場で働く人たちである。

• だから自分は、資料や議論の中に、意図的に余白を残すようにしている。

• 決め切っていない選択肢を残したり、現場でしか答えられない問いを置いたりする。

• そうすると、「実はこういう例外がある」「この人だけは違う」「ここは昔からこうしているだけ」といった、設計に本当に必要な情報が自然と出てくることが少なくない。

• 良い資料とは、説明し切った資料ではなく、相手の思考が動き始める資料なのではないかと思っている。

仮説は答えではなく、思考を広げる材料にする

• DXEは、クライアントよりも先に情報を整理し、解像度の高い仮説をつくることができる。

• ただ、その仮説の完成度が高いほど、「それが正解らしく見えてしまう」という難しさもある。

• 論理的で具体的な提案ほど、相手は「確かにそうですね」と受け入れやすい。

• でも、それが本当に必要なものに辿り着いた結果なのか、それとも考える余地がなくなっただけなのかは、意外と分からない。

• だから自分は、仮説は答えではなく、議論を始めるための材料として扱うようにしている。

• また、不確実なことは、不確実なまま共有することも大切にしている。

• 「この方向には可能性を感じています。ただ、本当に現場で価値があるかは、まだ一緒に確かめたいと思っています。」

• そうした姿勢の方が、結果としてクライアントもプロジェクトの当事者になりやすく、より良い設計につながることが多かった。

.
.
.

2. 実用像の設計力：実際に仕事が成立する仕組み、つまり現実をつくることができる

技術ではなく、現実の変化を設計する

• DXの話になると、「何をつくるか」が議論の中心になりやすい。

• 自分はそれ以上に、「その仕組みによって仕事がどう変わるのか」を考えることが重要だと思っている。

• 判断が速くなるのか。

• 問題を早く見つけられるのか。

• 顧客への対応が良くなるのか。

• 本来向き合うべき仕事へ時間を戻せるのか。

• システムが完成しても、仕事の進め方が変わらなければ、DXとしては少しもったいない。

• 逆に、小さな入力方法を変えただけでも、現場の負担が大きく減ることもある。

• DXEが見ているのは成果物そのものではなく、その先で変わる現実なのだと思っている。

ゴールを、使われている一場面で描く

• 「業務を効率化する」「品質を向上させる」。

• こうした目標は方向性としては間違っていない。

• ただ、それだけでは必要な仕組みを具体的に考えるのは難しい。

• そのため自分は、できるだけ「使われている一場面」を想像するようにしている。

• 誰が。いつ。どこで。何を見て。どう判断し。そのあと何をするのか。

• 例えば、重大な問題だけが管理者へ通知され、その場で内容を確認し、必要なケースだけ担当者へフィードバックする。

• ここまで描いてみると、「通知が多すぎると見なくなる」「リアルタイムで届かないと意味がない」「100点満点の採点よりも、重大な問題だけ分かれば十分かもしれない」といった、本当に必要な要件が見えてくる。

• 技術要件は、使われる場面を具体的に描いたあとから立ち上がってくることが多いように感じている。

作業ではなく、達成状態を設計する

• DXでは、現在の作業をそのままシステムへ置き換えようと考えてしまうことが少なくない。

• でも、自分は「何をしているか」よりも、「どんな状態になれば仕事が終わったと言えるのか」を考える方が、本質的だと思っている。

• 必要な情報が揃っている。

• 判断できる状態になっている。

• 次の担当者が迷わず動ける。

• あとから判断の理由を確認できる。

• こうした達成状態が決まると、今の手順に縛られず、いくつもの実現方法を比較できるようになる。

• その結果、「昔からこの帳票だから」「今はこの順番だから」という制約から離れて考えやすくなる。

• 守るべきなのは現在のやり方ではなく、仕事の目的や価値である。

• そう考える方が、結果としてより柔軟で実用的なDXにつながることが多かった。

.
.
.

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

自動化できることではなく、自動化してよいことを考える

• AIの性能が上がるほど、「どこまで自動化できるか」という話になりやすい。

• ただ、自分は「どこまで自動化してよいのか」の方が、先に考えるべき問いだと思っている。

• 人が行っている仕事には、処理結果だけでは説明できない価値が含まれていることがある。

• 安心感だったり、納得感だったり、「困ったときには相談できる」という信頼だったり。

• こうした価値は数字では測りにくいが、サービスが選ばれ続ける理由になっていることも少なくない。

• 作業時間は減ったけれど、顧客との関係性まで失われてしまった。

• そんな状態は、必ずしも良いDXとは言えないだろう。

• だからこそ、「この仕事を人が担う意味はどこにあるのか」を考え続けることも、DXEの大切な役割だと考えている。

現在の方法ではなく、本当に守るべき要件を見る

• DXの現場では、現在の帳票や入力方法、承認フローが、そのまま要件として語られることが多い。

• もちろん、本当に変えてはいけないものもある。

• 一方で、それらの多くは、過去の制約や使っていた道具に合わせて生まれた「実現方法」に過ぎないことも少なくない。

• 例えば、帳票を画像認識する仕組みをつくろうとして苦労していた案件でも、「帳票の形式は変えてもいい」と分かった瞬間に、一気にシンプルな解決策が見つかることがある。

• 守るべきなのは帳票ではなく、必要な情報が正しく記録されることだった、というケースである。

• DXEは、現在の方法と、本当に守るべき価値や目的を分けて考える視点を持っていた方が、より良い設計につながると感じている。

業務ではなく、作業まで分解する

• 「問い合わせ対応をAIで自動化したい。」こうした相談はよくある。

• ただ、問い合わせ対応という一つの業務の中には、実際にはさまざまな種類の仕事が含まれている。

• 顧客情報を調べる。問い合わせ内容を分類する。定型的な回答を返す。例外かどうかを判断する。他部署へ確認する。履歴を残す。

• これらは、それぞれ性質が違う。

• だから、「問い合わせ対応を自動化する」と考えるよりも、一つひとつの作業へ分解した方が、人とAIの役割は設計しやすくなる。

• 情報検索はAIが得意かもしれない。

• 最終判断は人が担った方が良いかもしれない。

• 例外対応だけを人へ渡す設計も考えられる。

• DXEは、「人かAIか」を決める仕事というより、「どの仕事を、誰が担うと最も自然か」を構造化する仕事なのではないかと考えている。

.
.
.

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

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

• DXを始めるとき、改善できそうなことはたくさん見つかる。

• その中から「何を最初にやるべきか」を決める必要はあるものの、最初からその優先順位が正しいとは限らないと思っている。

• クライアントは、自社の業務や現場をよく知っている。

• 一方で、AIで何ができるかはまだ見えていないことも多い。

• 逆にDXEは、AIや技術には詳しくても、その会社特有の文化や例外、現場の暗黙知までは分からない。

• お互いに見えていないものがある状態で、最適解を最初から決め切るのは、実はかなり難しい。

• だから自分は、最初から正解を当てることよりも、プロジェクトを通して正解へ近づいていく方が自然だと考えている。

最初の実装を、探索と観測のための道具として扱う

• 最初の実装には、「完成させること」だけではない役割があると思っている。

• 実際に動かしてみることで、初めて分かることが本当に多い。

• データが想像以上に整っていない。現場が本当に困っていた場所は別だった。AIを入れるよりも、入力方法を変えた方が効果が大きい。一つの仕組みが、別の業務にも応用できそうだ。

• こうした発見は、机の上で考えているだけではなかなか見えてこない。

• だから最初の実装は、成果を出すためだけでなく、「この会社をもっと理解するための探索」でもある。

• 小さくつくること自体が目的ではなく、次の判断をより良くするための材料を集めることが目的だと考えている。

仮説は、議論を始めるために置く

• 自分は、仮説は「正解」ではなく、「議論を始めるための材料」として扱うようにしている。

• 「現時点ではこう見えています。ただ、現場にはまだ見えていない事情があると思っています。」

• そんな前提で話を始める方が、クライアントから本当に大切な情報が出てくることが多い。

• また、不確実なことを無理に断言しないことも意識している。

• 「この実装の方向性には可能性を感じていますが、実際に価値があるかは一緒に確かめたい。」

• そう伝えることで、クライアントは提案を評価する立場ではなく、一緒に仮説を育てる当事者になりやすい。

• DXEは、最初から正解を知っている人ではなく、対話と実装を繰り返しながら、プロジェクト全体の解像度を上げていく役割なのではないかと思っている。

.
.
.

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

「完成したら本当に使いますか」を、何度でも問い直す

• AI開発は、以前よりもずっと速く、小さく試せるようになった。

• だからこそ、「つくれるかどうか」ではなく、「本当に使われるかどうか」を考える時間が、以前より大切になったように感じている。

• 自分がよく使う問いがある。

• 「もしこれが完璧な精度で完成したら、本当に使いますか。」「完成した翌日から、誰が、いつ、何のために使いますか。」

• この問いを投げると、技術的な可能性ではなく、実際の利用シーンについて話せるようになる。

• DXでいつも最重要なのはリアリティだと思っている。

• 「全件を採点する必要はないかもしれない。」「重大な問題だけ通知されれば十分かもしれない。」「リアルタイム性の方が大切かもしれない。」

• そんなふうに、本当に必要で欠かせない品質要件が少しずつ見えてくることが多い。

小さく作ることと、目的なく作ることは違う

• 小さく試すこと自体には、とても大きな価値がある。

• ただ、小さく作れば良いわけではないとも思っている。

• その試作で何を確かめたいのか。

• 利用シーンなのか。データ品質なのか。AIの精度なのか。現場が本当に行動を変えられそうかなのか。

• そこが曖昧なまま実装すると、試作ではなく「制作」になってしまう。

• 速く作れる時代だからこそ、学べる設計になっているかを意識したい。

リスクをいつも共有する

• プロジェクトを進めていると、「このままでも完成はする。でも、使われないかもしれない」と感じる瞬間がある。

• そんなとき、自分はすぐに新しいゴールや進め方を提案するよりも、まずその違和感を共有するようにしている。

• 「このまま進めてもシステムは完成すると思います。ただ、実際の現場ではあまり使われない気がしています。」

• 「今は精度を高めていますが、本当に必要なのは、一部の重大な問題を早く見つけることかもしれません。」

• こうしたリスクを共有できると、その後のゴールや進め方の見直しも、「ベンダーからの提案」ではなく、「一緒に考えるテーマ」へ変わっていく。

• プロジェクトは、解決策から始めるよりも、「何を避けたいのか」を共有した方が進めやすい場面が多いように感じている。

あとがき

AIによって、ものを作るコストはこれからも下がっていくと思う。それ自体は、とても良い変化だと思う。

一方で、「とりあえず作ってみよう」が簡単になるほど、「本当に必要なものは何か」を考える姿勢は、これまで以上に失われやすくなる。

「すぐ作り直せるからいいのでは？」
ってのも正しいんだけど、想像さえしていれば違うとわかる道を何度も通る必要はないと思っている。

ノリで作って自動化するような業務ではないからいまだに人間が担当している現実があるんだとも思っている。

学びあるかもと思ってくださった方へのおすすめの過去記事

推進者ではなくそもそもの実用化の難しさの背景に何があるのかはここにまとめています。

マーケティングの仕事の方が好きなんですが、マーケティングの再現性についてはこっちでまとめています。

そもそも、仕事は嫌いではないですが、めっちゃ好きというわけでもないので、普段はこういうことを考えたりしています。

システム論だとこの辺を書いてます。