「DX 推進担当を置いたんですけど、なかなか進まなくて……」
研修の合間に、人事担当の方からこんな相談を受けることがある。話を聞くと、ちゃんと推進役を任命している。研修も受けさせた。ツールも導入した。なのに、組織全体としては何も変わっていない。
正直に言うと、この話を聞くたびに「まあ、そうだろうな」と思ってしまう。いや、思ってしまうというか……何度か同じ光景を見てきたので、既視感がすごいのだ。
いや、推進役を置くこと自体は正しい。むしろ必要なステップだ。でも、推進役を置いただけで組織が変わると思っているなら、それはちょっと楽観的すぎるというか……。たとえるなら、「通訳を一人雇ったから、もう言葉の壁はない」と言っているようなものだ。通訳がいても、話す気がない人同士では会話は成立しない。
エンジニア目線で見えるもの
私はエンジニア出身なので、まずエンジニア側の視点から話してみたい。
DX 推進の文脈で「AI を使おう」「業務を自動化しよう」という話が出たとき、エンジニアの頭の中ではこんなことが起きている。
「あ、それなら ○○ というツールがあるな」
「API を叩けばできそう」
「データの形式を揃えれば自動化できる」
技術的な解決策がパッと浮かぶ。これはエンジニアの強みだ。
ただ、ここで問題が起きる。
「え、なんでやらないの？」
エンジニアからすると、技術的にはできることが明らかなのに、なぜか組織が動かない。「やればいいじゃん」と思ってしまう。そして、その「やればいいじゃん」が態度に出てしまうことがある（自戒を込めて書いている）。
「こうすれば効率化できますよ」と説明しても、相手の反応が薄い。「分かってもらえない」という感覚。これがエンジニア側のフラストレーションになる。
非エンジニア目線で見えるもの
一方、非エンジニアの視点ではどうだろう。
私は非エンジニア向けの研修も担当しているので、そちら側の声もよく聞く。
「AI って、結局何ができるんですか？」
「便利なのは分かるけど、今の業務で具体的にどう使うの？」
「導入したら、私の仕事なくなるんですか？」
これらは決してネガティブな質問ではない。むしろ、真剣に向き合おうとしているからこそ出てくる疑問だ。
でも、エンジニアが「API を叩けば……」と言い始めた瞬間、非エンジニアの頭の中では別のことが起きている。
「また専門用語か……」
「結局、エンジニアがやるんでしょ？」
「私には関係ない話だな」
シャッターが下りる音が聞こえる。いや、本当に聞こえるわけじゃないんですけど、表情で分かるんですよね。「あ、今この人、聞くのやめたな」って。
非エンジニアが「分かってもらえない」と感じるのは、「自分の業務にどう関係するのか」が見えないとき。技術的に可能かどうかではなく、「で、私は何をすればいいの？」が知りたいのだ。
「分かってくれない」の正体
面白いことに、エンジニアも非エンジニアも同じことを言っている。
「分かってくれない」
エンジニアは「技術的にできることを分かってくれない」と思っている。
非エンジニアは「業務の実情を分かってくれない」と思っている。
両者とも、相手が悪いわけではない。見えている景色が違うだけだ。
エンジニアには「技術的な可能性」がくっきり見えている。
非エンジニアには「日々の業務の制約」がくっきり見えている。
そして、お互いに「なぜそれが見えないの？」と思っている。
ここに、DX 推進役を一人置いただけでは解決しない理由がある。推進役がどちらかの出身である限り、もう一方の景色は見えにくい。エンジニア出身の推進役は技術寄りになりがちだし、非エンジニア出身の推進役は「技術的に何ができるか」の解像度が低くなりがちだ。
橋渡し役という発想
じゃあどうするか。
一つのアプローチは、「橋渡し役」を意識的に作ることだ。
推進役が旗を振る人だとすれば、橋渡し役は通訳のような存在。エンジニアの言葉を非エンジニアに翻訳し、非エンジニアの懸念をエンジニアに伝える。
「API を叩けばできます」
これを橋渡し役が翻訳すると、こうなる。
「今やっている ○○ の作業、ボタン一つで自動化できるかもしれません。まず、どの作業が一番手間かかってますか？」
技術の話ではなく、業務の話から入る。非エンジニアが「それなら、この作業が面倒で……」と言い始めたら、そこが糸口になる。
逆に、非エンジニアからエンジニアへの翻訳もある。
「現場が抵抗してるんですよ」
これを橋渡し役が翻訳すると、こうなる。
「今のシステムに慣れているので、新しいツールに切り替えるハードルが高いんです。特に ○○ の部分が心配らしくて。技術的にそこをケアする方法ってありますか？」
「抵抗」という曖昧な表現を、具体的な懸念に分解する。エンジニアは具体的な問題には対処できる。曖昧な「抵抗」には対処しようがない。
小さな成功体験の共有
橋渡しがうまくいき始めると、小さな成功体験が生まれる。
「あの作業、自動化したら 10 分が 1 分になりました」
「AI に下書きさせたら、レビューだけで済むようになりました」
こういう成功体験を、両方の言葉で共有することが大事だ。
エンジニア向け: 「○○ の API 連携がうまくいって、処理時間が 1/10 になった」
非エンジニア向け: 「毎日やってた ○○ の作業、ほぼ自動になって楽になった」
同じ成功を、それぞれの言葉で語る。これがないと、「あっちの部署の話でしょ」で終わってしまう。
組織が動き始めるとき
組織が動き始めるのは、推進役が頑張ったときではない。
「自分ごと」になった人が増えたときだ。
「あの人ができたなら、私もやってみようかな」
「うちの部署でも使えるかも」
この連鎖が起きたとき、初めて組織が動き始める。
推進役の仕事は、この連鎖のきっかけを作ること。そして、橋渡し役の仕事は、その連鎖がエンジニアと非エンジニアの壁を越えて広がるようにすること。
一人の推進役がすべてをやろうとすると、すぐに限界が来る。「あの人はすごいけど、自分には無理」と思われて終わりだ。
だから、推進役は自分がやるのではなく、やれる人を増やすことに注力したほうがいい。そのためには、エンジニアの言葉と非エンジニアの言葉、両方で語れる人が近くにいるかどうかが鍵になる。
あなたの組織では誰が橋渡し役になれるか？
ここまで読んで、「うちにはそんな人いないよ」と思った方もいるかもしれない。
でも、意外といるものだ。
- 元エンジニアで今は企画にいる人
- 非エンジニアだけど技術に興味がある人
- 両方の部署と仲がいい人
あるいは、Day 7 で書いたような「非エンジニアだけど AI 推進役として育った人」も候補になる。彼らは非エンジニアの気持ちが分かりつつ、技術の可能性も理解している。
推進役を置いて終わりではなく、**橋渡し役を見つける（または育てる）**ところまでが DX 推進のスタートラインなのかもしれない。
さて、ここまで偉そうに書いてきたが、私自身も完璧にできているわけではない。エンジニア出身である以上、どうしても技術寄りの視点になりがちだ。研修で「それ、伝わってないな」と感じる瞬間は今でもある。
ただ、両方の立場で話を聞く機会が多いからこそ、「どちらも悪くない」ということだけは確信を持って言える。
あなたの組織では、エンジニアと非エンジニアの間に橋はかかっているだろうか？
……かかっていなくても、大丈夫。橋は、一本の丸太からでも架けられる。