「エンジニアが何を言っているのか分からない！」DX・AIでの悩みに答えます！経営者とエンジニアの間に通訳が必要な理由

「エンジニアが何を言っているのか分からない！」DXでの悩み。経営者・リーダークラスとエンジニアの間に通訳が必要な理由。

私は現在、AIやDXに関わる仕事をしていますが、企業のDX支援をしたり、AI導入について考えたり、エンジニアと一緒にシステムやプロダクトについて話したりする機会が多いです。

私は元々ITとは関係ない業界からAIやDXの世界に入ったのですが
そんな仕事をしている私ですが、正直に言います。

本気でエンジニアが何を言っているのか分からないときがあります。

API、Webhook、エンドポイント、OAuth、コンテナ、デプロイ、リポジトリ、JSON、SDK、インスタンス……色々とカタカナが出てきます。

もちろん仕事上、ある程度は勉強していますので業務には支障はなくなりました。

それでもエンジニア同士が本気で技術の話を始めると、
すみません。日本語でお願いします。と言いたくなることがあります。

でも面白いことに私が役員をしている会社のトップエンジニアが会議後の雑談で、
「いや、僕らでもわからない、と言うかまともにコミュニケーションが成立しないときがある」
と言う話を聞き、笑いのツボにハマってしまったことがありました。

でもAIやDXの仕事を続けているうちに、あることに気づきました。
これはエンジニアが説明下手だから、という単純な話ではありません。

むしろ、エンジニアという仕事そのものが、専門用語と抽象化を必要とする仕事なのです。

そして企業のDXやAI導入がうまくいかない理由の一つも、実はここにあるのではないかと思っています。

プログラミングやエンジニアリングの専門用語は、説明を短くするためのもの

例えばエンジニア同士なら、
「APIでデータを取得して、Webhookでイベントを飛ばして、非同期処理してDBに保存する」

という会話で済むかもしれません。
しかし、これを非エンジニア向けに言い換えると、

「別のシステムから必要な情報を自動で取得する。
何か変更があったら、こちらのシステムにも自動的に知らせる。
その処理は裏側で進める。最後に結果を保存しておく。」

という説明になります。
長いと言えば長いです。
つまり専門用語とは、ある意味、長い説明を圧縮するための言葉なのだと思います。

医師にも専門用語があります。
弁護士にもあります。
会計士にもあります。
金融にもあります。
エンジニアだけがおかしいわけではありません。

保険業界にいるときには
損保ジャパンを損ジャ、三井住友海上をMSと呼んだりします。
重要事項説明を『重説』と不動産含め多くの業種で略したりします。

専門家同士で仕事をするためには、専門用語があった方が圧倒的に効率がいい。
問題は、その圧縮された言葉をそのまま専門外の人にも投げてしまうことです。

経営者が聞きたいのは、できるのか、できないのか

例えば経営者が、この仕事、自動化できる？とエンジニアに聞いたとします。
経営者が知りたいのは、おそらくこんなことです。

できるのか。
いくらかかるのか。
いつできるのか。
導入すると何が楽になるのか。

ところがエンジニア側では、同じ質問をされた瞬間に違うことを考えています。

• どこまでを自動化と定義するのか。

• 既存システムとの接続はどうするのか。

• APIは提供されているのか。

• 認証方式は何なのか。

• データはどこに保存されているのか。

• 例外処理はどうするのか。

• 権限管理はどうするのか。

• 障害が発生したらどうするのか。

そのため「APIの仕様次第ですね。OAuth周りを確認して、エンドポイントが提供されていれば実装できると思いますが……」という回答になることが多いです。

経営者側からすると、「で、できるん？できへんの？」となります。
でもエンジニアは別に意地悪をしているわけではありません。
むしろ逆です。

正確に答えようとしている。のです。

できると言い切って、後からできませんでした、となる方が問題だからです。ここに大きなすれ違いがあります。

エンジニアは見ているレイヤーが違う

私は、役員をしている会社であえて経営者や取引先、クライアント側で話をすることがあります。
この違いを理解してからエンジニアとの会話が少し面白くなりました。

経営者や現場の人は、何ができるのかを見ています。
エンジニアは、どうやって実現するのかを見ています。

例えば飲食店で、
「この料理、おいしいですか？」と聞いたとします。
聞いた側が知りたいのは、
「はい。うちの人気メニューですよ。」くらいの情報かもしれません。

ところが料理人が、
「63℃で90分加熱して、その後表面温度を上げてメイラード反応を……」
と説明し始めたらどうでしょう。

いや、そこまで聞いてない。となります。
ただし料理人からすると、料理がおいしくなる理由を正確に説明しているだけです。

質問と回答のレイヤーが違うのです。

DX推進・AI導入では、このズレが非常に危険

これが雑談なら問題ありません。
しかし企業のDXでは、このズレがプロジェクトの成否に影響します。

例えば経営者が、「請求書処理をAIで自動化したい。」と言ったとします。
これは経営者としては十分な要望です。

しかし、このままでは私ですら作れません。
エンジニアが聞けば嵐のような質問Slackが飛んでくるのが予想できます。

• 紙なのかPDFなのか。

• メールで届くのか。

• 誰が確認するのか。

• 誰が承認するのか。

• どの会計システムに入力するのか。

• 金額が違ったらどうするのか。

• AIが読み間違えたらどうするのか。

• 最終責任者は誰なのか。

• 保存期間はどうするのか。

• 権限はどうするのか。

こうしたことを決める必要があります。
一方で、これを全部エンジニアから経営者へ技術用語で説明しても伝わりません。

ここで必要になるのが、通訳する人です。

経営者とエンジニアの間には通訳が必要

私はDXの仕事をするようになって、この役割の重要性をかなり感じるようになりました。

例えば経営者が、
請求書処理を楽にしたい。と言う。

それを、

請求書を受け取る
↓
AIやOCRで読み取る
↓
担当者が確認する
↓
上長が承認する
↓
会計システムへ登録する
↓
処理履歴を残す

という業務フローに変換する。
そしてエンジニアには、この業務フローを実現するには何が必要ですか？と渡す。逆にエンジニアから、

APIの仕様上、この部分はリアルタイム連携できません。と言われたら、経営者には、この部分だけ完全自動化が難しいので、1日数回の自動更新にするか、人が確認する仕組みにしましょう。と伝える。

これがDXにおける通訳です。

DX人材はプログラマーでなくてもいい

DXという言葉が広がったことで、DX人材＝ITにものすごく詳しい人というイメージを持つ人もいると思います。

私は必ずしもそうではないと考えています。
もちろん技術知識は必要です。
何も知らなくていいわけではありません。
しかし全員が高度なプログラミングをできる必要もない。

むしろ企業のDXでは、

経営が分かる。
現場が分かる。
業務が分かる。
最低限のITが分かる。
AIで何ができるかが分かる。
そしてエンジニアと話ができる。

この間をつなげられる人が非常に重要です。

私はこれを、技術を作る能力ではなく、技術を会社で使える形に翻訳する能力だと考えています。

AI時代になって、アーキテクト能力が重要になる

生成AIの登場によって、この問題はさらに大きくなると思います。
以前ならシステム開発はエンジニアの領域でした。

しかし今は非エンジニアでも、生成AIを使えば簡単なアプリや自動化ツールを作れるようになっています。

経営者もAIを触る。
営業もAIを触る。
総務もAIを触る。
現場社員もAIを触る。

すると、これAIでできるんじゃない？というアイデアが会社中から出てきます。これは素晴らしいことです。
しかし、できそうと実際に業務で安全に使えるは同じではありません。

• セキュリティ。

• 個人情報。

• 権限管理。

• データ管理。

• 保守。

• 障害対応。

• コスト。

• 既存システムとの連携。

こうした技術的な論点が必ず出てきます。
だからAIが簡単になればなるほど、
技術者と非技術者をつなぐ人間の価値は下がるどころか、むしろ上がるのではないでしょうか。

エンジニアの言葉が分からなくても、恥ずかしくない

私自身、エンジニアが話していることを100％理解できるわけではありません。分からないものは普通に聞きます。

エンジニア同士が喋っていても会話内の擦り合わせは行います。

それって簡単に言うと何ですか？
会社側にはどういう影響がありますか？
それをやらなかったら何が起きますか？
費用はいくら変わりますか？
現場の人には何をしてもらえばいいですか？

こう聞けばいいわけです。
重要なのは専門用語を暗記することではありません。

技術的な話を、経営や業務の話まで持って帰ってくることです。
そして逆も同じです。

経営者の、なんかAIでいい感じにできない？をそのままエンジニアに投げない。

何に困っているのか。
誰が使うのか。
現在何分かかっているのか。
どうなったら成功なのか。
どこまで自動化したいのか。
これを整理して渡す。

それだけでも開発の会話は大きく変わります。

技術と経営の間にいる人材のニーズ

AIとDXの仕事をしていて思うことがあります。
これから価値を持つのは、必ずしも一つの分野だけを極めた人だけではありません。

経営者の言葉が分かる。
現場社員の気持ちも分かる。
そしてエンジニアが何を懸念しているのかも、ある程度理解できる。
その三者の間に立って、

経営者には経営者の言葉で。
現場には現場の言葉で。
エンジニアにはエンジニアの言葉で。
同じプロジェクトを説明できる人です。

私自身、今でもエンジニアの会話を聞いて、本気で何を言っているのか分からない。と思うことがあります。
でも、それでいいのだと思っています。

エンジニアと同じレベルでコードを書くことが私の役割ではありません。
大切なのは、その技術で会社の何が変わるのかを理解すること。
そして、会社がやりたいことを、技術で実現できるところまで翻訳すること。

AIやDXが当たり前になればなるほど、この通訳者の存在は重要になる。
私は現場でDXに関わるようになって、そのことを強く感じています。

室崎 敬太　【Linkedin】【E-mail】
馬車馬テクノロジーズ　業務執行社員/Chief Strategy Officer
その他DX関連の顧問を複数社請け負わせていただいております。
著書2026年９月１日発売
『AI・DX経営論――断絶の時代に、日本企業がどう生き残るか』

17歳で学生起業家として活動を開始し、事業の立ち上げと運営を経験。その後、ファーストリテイリンググループに入社。 三井住友海上火災保険株式会社にて法人営業やリスクマネジメントに従事し、金融・保険分野における専門性を確立。 独立後は室﨑総合保険／MKエージェンシーを創業。不動産会社との業務提携を経て役員に就任。 コロナ渦以降にAIやDX、プログラミングを学び現在は企業のDXおよびAX戦略の立案から実行までをリード。AI・LLMを活用した業務改革や新規事業開発を中心に、複数の企業において顧問として参画している。 国内上場企業から外資系企業まで、繊維、小売、自動車、金融、不動産、建設、サービスなど多岐にわたる業界での実務経験を有し、業界横断的な知見と実行力を兼ね備えたDXに強みを持つ。