ネットで原因を探せば、記事はいくらでも見つかります。書かれていることは、どれも間違っていないと思います。ただ、読み終えて残るのは「で、明日から何をすればいいのか」という宙ぶらりんな気持ちではないでしょうか。

この連載では、少し違う角度から考えてみます。挙げられた原因は別々のものではなく、ひとつの欠落から生まれた症状ではないか。それが私の見立てです。

いつも同じように語られる、停滞の原因

DXが止まっているとき、その理由はだいたい決まった顔ぶれで語られます。まずはその顔ぶれを眺めてみます。

よく挙げられる4つの原因

ひとつめは、経営層のコミットメント不足。号令はかかっても、予算も権限も降りてきません。

ふたつめは、レガシーシステム。長年動いてきた仕組みは触りづらく、触れば別の何かがおかしくなる予感がします。

3つめは、人材不足。デジタルに明るい人がいない、いても手が空いていない。

4つめは、現場の抵抗です。新しいやり方は、静かに、確実に押し戻されます。

原因が分かっても翌日が変わらない理由

あなたも、この4つはすでにご存じでしょう。むしろ「そのとおりだ」と感じたのではないでしょうか。

問題は、そのあとです。原因がわかっても、翌日の会議で何を提案するかは決まりません。経営の姿勢は一担当者には変えられず、レガシーの刷新には予算が要ります。人材も現場の気持ちも、一晩では変わりません。

原因が記されている地図は正しいのに、歩き出す方向を教えてくれないのです。

「わかっているのに動かない」という感覚

この感覚を、私は様々な現場で見てきました。よく調べてよく考えている人ほど、この場所で立ち止まります。

たとえるなら、健康診断の結果を渡されたようなものです。数値の異常はわかる。でも「今日の晩ごはんを何にするか」は書かれていません。知識と行動の間に「まだ何かが足りない」、そんな状態だと思います。

足りないものが何かを言葉にできると動き出せます。この連載は、その「何か」を言語化にする試みです。

並列に見える原因の「たったひとつの共通点」

ここからが本題です。4つの原因を横に並べず、縦に掘ってみます。すると、どれも同じ場所から生まれていることに気づくはずです。

往復しないまま発注されたときに起きること

経営には「こうしたい」という意図があり、現場には「こうなっている」という実務があります。本来なら何度も行き来して形を変えるものですが、多くの現場では意図が上から一度だけ降り、実務は下に留まったままです。往復がない。たとえ、経営と現場の往復があったとしても、肌感覚の共有が一向に進まない。

その状態でシステム開発を発注すると、要件は「経営の言葉」のまま外に出ます。ベンダーは額面どおりに受け取り、そのとおりに作ります。

そして納品物が、現場の実務とかみ合いません。例外的な業務の流れ、書類の回り方、繁忙期だけ変わる手順。そこまでは、経営の言葉に入っていないからです。

誰も嘘をついていないのに、できあがったものが使われない。この構図を、私は何度も見てきました。

外部委託がノウハウを残さない構造

「自分たちが専門外のことなら外部に任せればいい」と考えるのは自然です。実際、多くの会社がそうしてきました。

ただ、委託先が去ったあとに残るのは、成果物と操作マニュアルだけです。なぜその仕様にしたのか、どんな例外を踏まえた判断か——その理由は残りません。

外部委託を重ねるほど知見が積まれない、という逆説です。

AI導入がPoCで止まる、いちばん新しい症例

近年よく聞くのが、AI導入がPoC（試験導入）で止まるという話です。これも同じ構造だと考えます。

技術は動いていますし、デモもうまくいきます。それでも本番の業務には乗りません。業務のどの部分をどう変えるかを決める必要があり、その決定には業務と技術の両方がわかる人が要るからです。

AIは原因ではなく、同じ欠落がいちばん新しい形で表に出た症例だと思います。

欠けているのは「あいだに立つ人」

ここまで来ると、欠けているものの輪郭が見えてきます。経営の意図と現場の実務を往復し、実装まで持っていく人。この役割が、多くの現場に存在していません。

聞く人・作る人・使う人の分断

今の体制を、役割で分けてみましょう。要件を聞く人がいて、それを作る人がいて、できたものを使う人がいます。

3者はきれいに分かれています。分かれすぎている、と言ってもいいかもしれません。聞く人は業務の細部を知らず、作る人は現場に入らず、使う人は仕様が決まったあとに呼ばれます。

分業そのものは合理的です。ただ、あいだをつなぐ人がいない分業は、受け渡しの連鎖になります。

確かに存在する、翻訳の担い手

ひとつ補っておきます。「業務を理解して仕様に翻訳する」という仕事は、決して無名の役割ではありません。

ITコンサルタント、業務コンサルタント、上流工程を担うSE。一定規模のプロジェクトなら、実際にアサインされます。あなたの会社でも、要件定義の場に外部の専門家が同席したかもしれません。

つまり、翻訳という仕事が知られていないわけではありません。問題は別のところにあります。

契約が切れるのは、翻訳と実装のあいだ

問題は、その人がどのフェーズまで居るかです。

多くの場合、契約は要件定義や基本設計の完了で区切られます。翻訳した内容は開発側に渡り、本人は次の案件へ移ります。翻訳した人が、動くところまで面倒を見ることは稀です。

引き継がれるのは仕様書であって、そこに至った判断の理由ではありません。ここで、往復の糸が一度切れます。

誰の欄にも書かれていない「連続して担う」という条件

つまり欠けているのは、翻訳という仕事そのものではありません。「翻訳と実装と運用を、同じ人が連続して担う」という条件のほうです。

そしてもうひとつ。中堅規模の案件では、そもそも上流専門の人材がつかないことも珍しくありません。その場合は担い手すらいないまま、社内の誰かが引き受けます。この「誰か」には、あとで触れます。

その役割につけられた名前、FDE

近年、この役割に名前がつきました。FDE（Forward Deployed Engineer）です。直訳すれば「前線に配置されたエンジニア」となります。

Palantirから広まり、AI企業が定着させた言葉

もともとはPalantirという米国企業で確立されたポジションです。顧客の現場に入り込み、実際に動くものを作る役割を指します。近年は国内のSaaS企業やAI企業でも、同じ名前の職種を置く動きが広がってきました。

言葉は新しくても、役割そのものは新しくないと私は考えます。20年以上前から必要とされていて、名前がなかっただけだと思います。

SE・コンサル・SES・PMOとの境界線

私が見ている境界線は、ひとつではなく条件の束です。

コンサルタントは業務を翻訳しますが、設計までで契約が切れます。SES（技術者の常駐派遣）は作りますが、指示された範囲を出ません。PMOは管理しますが、自らは作りません。

FDEは、この3つを「同じ人が連続して担うこと」を前提にしています。業務を理解し、自ら作り、使われるところまで見届ける。そのうえで引き継いで去る。

境界線をひとつ選ぶなら「撤収」です。去らずに居続けるなら、名前が違うだけの常駐だと考えます。

発注者にとっての問いは「迎える・使う・引き継ぐ」

大切な前提をひとつ置きます。FDEは、支援する側・ベンダー側の職種です。求人票が出るのも組織を立ち上げるのも提供する側で、あなたの会社が雇う話ではありません。

ではなぜ、発注者が知る必要があるのか。「迎える側の準備によって、その人が力を発揮できるかどうかが決まるから」です。

発注者の問いは3つです。どう見極めて迎えるか。何を渡してどこで判断するか。去ったあと、どう自走するか。

この連載は、その3つに沿って進みます。

実際に現場へ来ていた人材の水準

私はこれまで23年、100件を超えるプロジェクトに関わってきました。ここからは、その経験を振り返っての話です。

稀だったことの、偶然ではない理由

FDEと呼べる水準の人に、私はほとんど出会っていません。業界の商習慣を肌感覚で理解し、現場の空気をつかみ、そのうえで開発や運用にあたる。そういうエンジニアは、非常に稀でした。

なぜそれほど少なかったのか。確率の問題ではないと考えています。供給する側も、迎える側も、この人材を意図して育ててこなかった。誰も育てようとしなかったものが、たまたま育っているはずがありません。

ひとつの例外「業種特化型ベンダー」

例外がひとつだけありました。特定の業種に特化したベンダーです。

同じ業界の顧客を長く担当し、要求の整理から設計・運用・保守までを繰り返す。配置されたエンジニアは、意図されないまま業務の肌感覚を積み上げます。育成プログラムではなく、配置の結果として育っていたのだと想像します。

意図せず起きたことなら、意図すれば設計できるかもしれません。この事実は、あとの回で大きな意味を持ちます。

現実に多かった、もうひとつの構図

では、FDEがいない現場はどう回っていたのでしょうか。私が見てきた圧倒的多数は、次の構図です。

ITに明るい社員が、常駐エンジニアに指示を出す。

業務を知っているのは社員の側、技術を持っているのはエンジニアの側。そこで社員が業務を噛み砕き、指示に変換して渡していました。

この形でも、動くものはできます。実際、多くの現場がこれで回ってきました。ただ、無理が一箇所に集まります。

翻訳を肩代わりしてきた人に起きること

お気づきかもしれません。この構図では、翻訳を発注者側が引き受けています。

指示を出す関係では、エンジニアは指示された範囲でしか動きません。含まれていない例外や不都合に気づく人がいなくなり、気づける社員の負荷だけが増え続けます。

もしあなたがいま、そういう立場にいるとしたら。それはあなたの手際が悪いからではなく、役割が定義されていないから起きているのだと思います。

重い話が続きました。ただ、今日からできることもあります。次の発注の要件に「翻訳を担うのは誰か」を一行だけ加えてみてください。

動き出す起点は、体制図ではなく役割の定義

ここまでは、欠けているものの話でした。ここからは、その埋め方に移ります。

増員やツール導入の前に決めること

DXが止まったとき、多くの会社はまず人を増やすか、ツールを入れます。どちらも悪い手ではありません。

ただ、翻訳する役割が定義されないままだと、増えた人もツールも同じ場所で止まります。先に決めるのは、誰がその仕事を担うのかという一点だと考えます。

順番の問題です。人もツールも、役割が決まったあとなら効いてきます。

今日からできる、ひとつの棚卸し

大がかりな準備は要りません。いま動いているプロジェクトを1つ選び、問いを立ててみてください。

この案件で、業務を仕様に翻訳しているのは誰か。

名前が挙がらないなら、その仕事は宙に浮いています。あなたの名前が挙がるなら、肩代わりしている状態です。どちらの答えでも、次の一手が見えてきます。

会議に諮る必要はありません。まずは自分の中で答えを出すところからで十分だと思います。

この連載で扱う、7つの論点

第2回からは、次の順で扱っていきます。

迎える

［第2回］見極めの方法

［第3回］求めてよい力と求めても出てこない力

使う

［第4回］何を渡し、どこで判断するか

引き継ぐ

［第5回］撤収後を自走させる受け皿

［第6回］その処遇と採用

［第7回］そして投資の説明

迎える・使う・引き継ぐの3段です。どこから読んでも構いませんが、いま止まっている場所に近い回から入るのが早いと思います。

まとめ

DXが進まない理由は、たくさんあるように見えて、実はひとつではないかと考えています。翻訳する役割は存在しますが、実装と運用まで連続して担う人がいない。往復の糸が切れていることが、さまざまな症状として出ているのだと思います。

その役割にはFDEという名前がつきましたが、ベンダー側の職種です。発注者の問いは「自社で雇うか」ではなく、迎える・使う・引き継ぐの3つです。

その水準の人には、ほとんど出会っていません。供給側も需要側も、意図して育ててこなかったからだと思います。裏を返せば、意図すれば変えられます。

いま動いているプロジェクトを、ひとつ思い浮かべてみてください。業務を仕様に翻訳しているのは、誰でしょうか。