「翻訳コスト」が消えない理由——AI導入の要件が、伝わるたびに削れていく構造

要件書は丁寧に作った。
実績のある外注先も選んだ。
それなのに、届いたものはどこか現場の感覚とずれている。
何が悪かったのか、正直まだよく分かっていない——もしあなたの職場でも、そんな場面に心当たりがあるなら、それはあなたがサボっていたわけでも、判断を誤ったわけでもありません。
むしろ真面目に、手順通りに進めた結果として、これが起きていることのほうが多いのです。

逆の悩みに覚えがある人もいるかもしれません。
PoCまではとても順調に進み、経営会議でも好評だった。
ところが、いざ本番導入の話になった途端、誰も次の一歩を決められなくなる。
作った外注先に聞くと「本番化はまた別のご相談として、あらためてお見積りします」と言われ、社内では「PoCがうまくいったのだから、あとは進めるだけでは」という空気と、「本番で事故が起きたら誰が責任を取るのか」という空気がぶつかり合って、そのまま数ヶ月が過ぎていく。
「あのとき喜んでいたのは何だったのか」と、苦笑いしたくなる状況です。

もし今どちらかに心当たりがあるなら、まず知っておいてほしいことがあります。
あなたは、悪いことは何もしていません。
要件書は丁寧に書いたし、PoCは実際にうまく動いた。
それでも進まなくなる。
原因を突き詰めていくと、多くの場合、技術の話には行き着きません。
行き着くのは、あなたが伝えたことが、別の誰かに届くまでのあいだで、少しずつ形を変えていた、という話です。

この記事では、なぜこういうことが起きるのかという構造と、その構造そのものを変える関わり方としてのFDE（Forward Deployed Engineer）について、できるだけ専門用語を避けて説明します。
技術の話は、実はほとんど出てきません。
出てくるのは、あなたが伝えた情報が、どこでどう目減りするか、という話です。

なぜかうまく進まない現場に共通する「構造」

現場でよく見るパターンは、だいたい3つに絞られます。

1つ目は、要件を渡して待つという進め方です。
「こういうものを作ってほしい」と要件書にまとめ、外部に渡し、3ヶ月後に検収します。
この進め方自体は、間違ってはいません。
ただし要件書を書いた時点の状況は、3ヶ月のあいだに変わり続けます。

担当者が異動します。
扱う商品が変わります。
繁忙期の業務量が、想定と違うと分かることもあります。
要件書は書いた瞬間から少しずつ古くなっていくのに、3ヶ月後に届くものは、書いた瞬間の要件書にだけ忠実に作られています。
仕上がりを見た担当者が「ここは今のやり方と違います」と伝えても、変更は次の契約サイクル待ちになることが多く、その間もまた現場は動き続けます。

2つ目は、PoC(小さく試して動くかを確かめる工程)が本番に育たないというパターンです。
2週間ほどで、それらしく動くものができます。
「思ったより早くできましたね」と喜ばれます。
そしてそこで止まります。
PoCは、整った条件のもとで「動くかどうか」だけを確かめる場だからです。

実際の業務データには欠けがあり、表記はゆれていて、担当者によって判断基準も微妙に違います。
そうした現実を踏まえて本番用に設計し直す判断は、PoCの成功とは別の技術と経験が要ります。
その判断ができる人が、社内にも外注先にも、都合よく空いているとは限りません。
冒頭で触れた、経営会議で好評だったのに本番化の話が止まってしまった現場は、まさにこのパターンでした。
「動くもの」を作る技術と、「動き続けるもの」に育てる技術は、似ているようで別物です。

3つ目は、誰がオーナーかが曖昧なまま進んでしまうパターンです。
経営層は前向きで、現場は「自分たちの仕事が変わるのでは」と身構えていて、間に立つ担当者は板挟みになります。
誰か1人が「これで進める」と決めない限り、プロジェクトは止まったまま関係者だけが増えていきます。
これも、誰かが怠けているわけではありません。
決める役割そのものが、最初から誰にも割り当てられていないだけです。
会議に出る人数だけは毎回増えていくのに、次に何を、いつまでに、誰がやるのかという議事録の行が、いつまでも空欄のままという状態になりがちです。

3つとも、技術力の不足が原因ではありません。共通しているのは、どこかの時点で情報が誰かの手を離れ、別の誰かの手に渡っている、という構造です。

パターンを並べると、こうなります。

• パターン: 要件を渡して待つ / 典型的な状態: 届いたものが、届く頃にはすでに現場の状況と合わなくなっている / なぜ止まるか: 要件書は書いた瞬間から古くなるが、実装は書いた瞬間の内容に忠実に作られる

• パターン: PoCが本番に育たない / 典型的な状態: 試作は好評だったのに、本番化の話になると誰も次の一歩を決められない / なぜ止まるか: PoCは整った条件で「動くか」だけを確かめる場であり、本番設計には別の判断が要る

• パターン: オーナーが曖昧 / 典型的な状態: 会議に出る人数は増えるのに、次に誰が何をやるかが決まらない / なぜ止まるか: 決める役割そのものが、最初から誰にも割り当てられていない

自社が同じ状態にあるかを確かめる

3つのパターンに心当たりがあるかどうかは、次のような問いで確かめられます。

• 直近のAI関連プロジェクトで、要件を最初に書いた人と、いま実際に手を動かしている人は同じ人か: 別人なら、その間ですでに一度は情報が翻訳されている

• 仕様のずれに気づいたのは、途中の時点か、それとも納品されたあとか: 納品後に気づくほど、直すための手間が大きくなる

• PoCが動いた日から、本番稼働に向けた作業は続いているか、それとも止まっているか: 止まっているなら、PoCと本番のあいだに担当の空白が生まれている

• 「これで進める」と最終的に決める人が、誰なのか今の時点で言えるか: 言えないなら、決める役割がまだ誰にも割り当てられていない

4つのうち2つ以上で答えに詰まるようなら、翻訳コストがすでに発生している可能性があります。
これは診断のための問いであって、責める意図はありません。
多くの現場が、悪気なくこの状態に入り込みます。
むしろ、こうした問いを自分たちで立てられること自体が、次の一歩を決めるための材料になります。
答えに詰まった項目があっても、それは「今のやり方がまずかった」ということではなく、「情報がどこかで途切れている場所が分かった」ということです。
場所さえ分かれば、そこから先の直し方はいろいろあります。

「翻訳コスト」の正体

先日、ある会社の担当者にヒアリングをしていて、こんな話を聞きました。「請求書のこの数字は、毎回目でチェックしています」。理由を聞くと、金額の桁を打ち間違えるミスが過去に何度かあり、それ以来、担当者の目で最終確認をする運用にしている、とのことでした。

この話が、要件定義のミーティングを経て、外注先への発注書になるとどうなるか。
私は何度も、この過程を見てきました。
まず「金額チェックの理由」が、社内の要件定義シートでは「金額の妥当性確認」という一行に整理されます。
次にこのシートが外注先に渡ると、提案書では「入力値バリデーション機能」という項目になります。
最後に設計書の段階では、「数値型・桁数チェック」という技術仕様だけが残ります。

ここで何が起きたか。
「桁を打ち間違えたことがあるから、人の目で確認している」という、最初のいちばん大事な理由が、どの段階でも間違ってはいないのに、気づけば消えています。
できあがったシステムは、たしかに桁数はチェックします。
しかし、担当者が本当に不安だったのは「金額そのものが正しいかどうか」であって、桁数の形式ではありませんでした。
この食い違いに、担当者は納品されてから初めて気づくことになります。

私はこの、要件が人から人へ渡るたびに具体的な理由が目減りしていく現象を、「翻訳コスト」と呼んでいます。
これは確立した専門用語ではなく、現場を見てきた中で私が使っている言葉です。
技術と業務のあいだには、常に翻訳が必要です。
業務の言葉を技術の要件に翻訳し、技術的な判断をまた業務の言葉に翻訳し直す。
この往復のたびに、翻訳という作業そのものは間違っていなくても、文脈が少しずつ削れていきます。

厄介なのは、この目減りが誰か1人のミスではなく、正しい手続きを踏むほど起きやすいという点です。
要件定義シートを整理する担当者も、提案書を書く営業も、設計書を書くエンジニアも、それぞれの持ち場では正確な仕事をしています。
ただ、持ち場が変わるたびに情報が圧縮され、圧縮するたびに「なぜそれが必要か」という理由から先に落ちていきます。

似たことは、数字を扱う業務に限らず起きます。
別の現場では、問い合わせ対応の担当者が「このパターンの問い合わせだけは、必ず先輩に確認してから返信している」と話していました。
理由を聞くと、過去にそのパターンで誤った案内をして、取引先との関係がこじれたことがあったからだといいます。
この話も、要件定義の段階では「エスカレーションフローの整備」という項目に整理され、できあがったシステムには「特定条件で担当者に通知する」機能だけが実装されました。
通知は届くようになりましたが、なぜそのパターンだけ慎重に扱う必要があるのかという背景は、誰にも引き継がれていませんでした。
技術的には正しく作られているのに、現場が本当に守りたかったものとは、少しずれてしまっています。

そして外部委託という形は、この翻訳を非同期にします。何かを聞いてから答えが返ってくるまでに、日数がかかります。その間にも現場は動き続けていて、要件書はその瞬間から少しずつ古くなっていきます。翻訳がうまくいかないことよりも、翻訳のたびに時間差が生まれることのほうが、実は深刻な問題です。

FDE(Forward Deployed Engineer)とは何をする人か

FDEを一言で説明すると、要件を聞く人と、それを作る人を、同じ1人にする関わり方です。

普通の外部委託では、営業担当が要件を聞き取り、その内容がプロジェクトマネージャーを経て、実際に手を動かすエンジニアに伝わります。
聞いた人と作る人が違うので、その間で翻訳が発生します。
FDEは、現場に常駐して要件を直接聞き、その場で実装まで担う技術者です。
翻訳の受け渡しをする相手が、そもそも存在しません。

イメージとしては、通訳を介した会議と、両方の言語を話せる人が直接話す会議の違いに近いものです。
通訳を挟むと、発言のたびに一度翻訳を待つ必要があり、細かいニュアンスも削れます。
「多分こういう意味だろう」という推測で埋められる部分も出てきます。
両方の言語が分かる人が直接話せば、その場で聞き返せるし、言い回しの意図もその場で確認できます。
分からないことを分からないまま持ち帰る必要がありません。
FDEがやっているのは、業務の言葉と技術の言葉の両方を1人で扱い、その場で判断することです。

具体的には、こんな動き方をします。
まず、現場に定期的に、あるいは常駐に近い形で入り、担当者の隣で実際の業務を見ます。
「なぜその数字を目でチェックしているのか」を、要件定義シートを介さずに直接聞きます。
要件が変わったときは、契約変更の手続きを待たずに、その場で設計を調整します。
そしてPoCがうまく動いたときは、そこで契約が一区切りになるのではなく、同じ人がそのまま本番向けの設計判断を続けます。

ここで大事なのは、FDEが「優秀な外注担当者」ではないという点です。
優秀さの問題ではなく、役割の設計そのものが違います。
従来の外注は、聞く人と作る人を分業することで専門性を高める設計です。
分業自体は多くの場面で合理的です。
ただしAI導入のように、業務側の状況が頻繁に変わり、その変化を正確に技術側へ伝える必要がある局面では、分業の継ぎ目こそが翻訳コストの発生源になります。
FDEは、その継ぎ目を最初からなくす設計です。

もう少し具体的に、ある1日の動き方を想像してみます。
午前中、担当者から「今週から取引先が1社増えて、請求書のフォーマットが少し変わった」という話を聞きます。
従来の外注であれば、この話はいったん要件変更として持ち帰られ、影響範囲の調査、見積もり、承認を経てから着手されます。
FDEの場合、その場で実際の請求書を見せてもらい、どこがどう変わったのかをその場で確認し、影響が小さければ午後には修正を反映させます。
影響が大きい場合も、少なくとも「これは今日中には終わらない、こういう理由でこれくらいかかる」という見通しを、その場で共有できます。
担当者にとっては、依頼したことがブラックボックスに消えていく感覚がなくなります。

ここで、FDEという言葉そのものについても触れておきます。
この肩書きは2011年、データ分析企業Palantir Technologies社が、それまで「ソリューションエンジニア」「インテグレーションエンジニア」と呼ばれていた技術者たちに新しく与えたのが始まりだとされています。
社内では彼らを「Deltas」とも呼んでいたそうです。
当時の経緯はAndreessen Horowitzの解説記事（2026年8月確認）に書かれています。
その後、Wikipediaの該当項目（2026年8月確認）によれば、OpenAIやAnthropic、AWSなど、AIを扱う企業を中心に同様の役割を置く動きが広がってきました。

ただし、ここは注意して書く必要があります。
FDEという言葉の中身は、企業によって統一されていません。
技術系ニュースレターThe Pragmatic Engineerは「Every company has their own flavor of FDE（FDEの中身は会社ごとに違う）」と述べ、企業ごとの違いを具体的に比較しています（2026年8月確認）。
求人情報サイトを分析するBloomberryの記事では、FDEを名乗る求人1,000件を調べたところ、実質的には性格の異なる3種類の仕事に分かれていたと報告されています。
約6割が現場に入って本番システムを直接作る仕事、約3割が商談のデモやPoC支援が中心の仕事、約1割が自社の営業・マーケティング部門向けの社内ツール開発でした（全文はこちら、2026年8月確認）。

• 求人票に「FDE」と書かれた仕事の内訳: 本番システムを直接作る仕事 / 割合: 約6割 / 仕事の中身: 現場に入り、要件を聞くところから実装まで担う、この記事で説明しているFDE

• 求人票に「FDE」と書かれた仕事の内訳: 商談のデモやPoC支援が中心の仕事 / 割合: 約3割 / 仕事の中身: 提案活動や実証実験の支援が中心で、本番実装までは担わない

• 求人票に「FDE」と書かれた仕事の内訳: 自社の営業・マーケティング部門向けの社内ツール開発 / 割合: 約1割 / 仕事の中身: 現場の業務担当者ではなく、自社の別部門に向けた開発

つまり、「FDE」という求人票や肩書きを見かけても、それがこの記事で説明した動き方と同じとは限りません。この記事でFDEと呼んでいるのは、上のうち現場で本番システムを直接作る働き方を指します。この意味とは違う前提で「それはFDEではない」と考える人がいても、それ自体は自然なことです。
この記事は、肩書きの正しさそのものではなく、「要件を聞く人と作る人を同じにする」という働き方が翻訳コストにどう効くかを論じるものとして読んでください。

普通の外部委託と何が違うのか

同じ場面を並べて比べると、違いがはっきりします。

要件が変わったとき

・従来の外注 → 変更内容を担当者に伝え、見積もりの出し直しを待ち、契約書を書き直してから着手する
・FDEがいる場合 → その場で一緒に相談し、その日のうちに設計の方向を変える

検収のタイミング

・従来の外注 → 3ヶ月後にまとめて確認し、そこで初めて現場の感覚とのずれに気づく
・FDEがいる場合 → 数週間ごとに実際に触れる場を作り、ずれが小さいうちに気づいて直す

PoCが動いたあと

・従来の外注 →「動作確認ができました」で一区切りとなり、本番化はまた別の相談・別の契約になる
・FDEがいる場合 → PoCが動いた瞬間から、同じ人がそのまま本番に向けた設計判断を引き継ぐ

要件が伝わる経路

・従来の外注 → 担当者の言葉が、要件定義シート、提案書、設計書と、人の手を渡るたびに文脈が薄まる
・FDEがいる場合 → 最初に話を聞いた人がそのまま最後まで作るので、薄まる継ぎ目自体が存在しない

この図で変わっているのは、経由点の数だけです。担当者はどちらの図にも同じ姿で立っています。
効いているのは「その場にいる時間の長さ」でも「特別に優秀な1人を連れてくること」でもなく、経由点の数そのものです。だから、常駐している時間の長さを競っても、優秀な人を1人配置しただけでも、経由点そのものが減らなければ翻訳コストは残ります。

こうして並べると分かる通り、FDEは外部委託を「やめる」提案ではありません。
人手を減らす、コストを削るという話でもありません。
むしろ手間のかけ方を変える提案です。
従来の外注では、契約と手続きに手間をかけて分業の精度を上げようとします。
FDEでは、同じ人が最初から最後まで関わり続けることに手間をかけて、翻訳という工程そのものを削ります。

どちらが優れているという話でもありません。手続きに手間をかける設計は、要件が変わりにくい定型業務には向いています。関わり続けることに手間をかける設計は、要件が動き続けるAI導入のような場面に向いています。大事なのは、自社が今取り組もうとしている業務が、そのどちらの性質に近いかを見極めることです。

なぜそれで解決するのか

FDEが有効な理由は、根性論でも、単に優秀な人を配置しているからでもありません。構造として、翻訳の往復回数が物理的に減るからです。

普通の外部委託では、1つの要件が「聞く→整理する→伝える→実装する→確認する」という経路を通ります。
経路が長くなるほど、途中で情報が欠ける可能性のある地点(翻訳が発生する場所)が増えます。
FDEでは、この経路の「聞く」と「実装する」が同じ人の中で完結するため、経路そのものが短くなります。
短くなった分だけ、情報が欠ける地点も減ります。

もう1つの理由は、判断のタイミングです。
従来の外注では、判断のための情報が全部そろってから、まとめて意思決定をする設計になりがちです。
だからこそ3ヶ月後の検収でまとめて確認する形になります。
FDEは、その場に居続けることで、小さな判断を毎日積み重ねます。
1回あたりの判断は小さくても、積み重なるうちに、大きなずれが起きる前に軌道修正ができます。
3ヶ月に1回の大きな答え合わせより、毎日の小さな答え合わせのほうが、間違いに気づいたときの修正コストは小さくなります。

これは、家を建てるときの検査に似ています。
完成してから一度だけ検査するより、基礎、骨組み、配線と、工程ごとに確認するほうが、後から直せないところで問題を見つけずに済みます。
工程ごとの確認には手間がかかりますが、その手間は、完成後にやり直す手間より、たいてい小さく済みます。
AI導入における日々の小さな判断も、同じ理屈で働いています。
壁の中に隠れる配線を、壁を塗った後に直そうとすれば、壁を壊すところからやり直しになります。
AI導入における要件の食い違いも、これと同じで、表に見えなくなってから気づくほど、直すための手間が跳ね上がります。

そしてPoCから本番への移行が途切れない理由も、同じ構造で説明できます。
PoCを作った人と本番を設計する人が別だと、「なぜこのPoCはこう動いているのか」という背景を、また誰かに伝え直す必要が生まれます。
ここでも翻訳が1回発生します。
FDEは、PoCを作った本人がそのまま本番の設計に進むため、この翻訳自体が発生しません。

よくある疑問

ここまでの説明に対して、実際によく聞かれる疑問が3つあります。

1つ目は、費用についてです。
「常駐に近い形」と聞くと、通常の外注より高くつくのではと思われがちです。
実際にどちらが安いかは、案件の規模や期間によって変わるため、一概には言えません。
ただ、比較するときに見落とされがちなのが、従来の外注で発生している「手戻りのコスト」です。
3ヶ月後の検収で食い違いが見つかれば、そこから再度要件を整理し、作り直す時間と費用がかかります。
この手戻りが起きにくくなる分を含めて考える必要があります。
見積もりを比べるときは、最初の契約金額だけでなく、「作り直しが起きたときに、その費用と時間は誰が負担するのか」まで含めて確認すると、実質的な比較がしやすくなります。

2つ目は、常駐が必須なのかという点です。
物理的に毎日同じ場所にいる必要はありません。
大事なのは「聞く人」と「作る人」が同じであることで、オンラインでの定例的なやり取りでも、その条件は満たせます。
目安としては、要件の変化にどれだけ早く反応できるかで考えるとよいでしょう。
週に1回、決まった曜日にまとめて確認する形でも、聞く人と作る人が同じであれば、翻訳という工程自体は発生しません。
ただし、頻度が月1回のような従来型のプロジェクト管理に近づくほど、往復のたびに記憶が薄れ、結局は誰かがまた要件を整理し直すことになりがちで、翻訳コストを減らす効果は薄れていきます。

3つ目は、社内で人を採用して内製化するのと何が違うのか、という点です。
先に整理しておくと、FDEは「外注をやめて内製に切り替える」話ではありません。FDEは会社の外にいる技術者で、その立場のまま現場に深く関わります。内製化は、会社の中に技術者を迎え入れる話です。この2つは別の軸にあります。

内製化を目指す場合も、この所属の違いを契約の初期段階で明確にしておくと、後の移行がスムーズになります。

内製化も、聞く人と作る人を同じにするという意味では、FDEと同じ方向を向いています。
違いは立ち上がりの速さです。
内製化は採用と育成に時間がかかり、AI関連の技術を扱える人材の採用自体が簡単ではありません。
採用がうまくいったとしても、その人が自社の業務を理解して現場から信頼されるまでには、やはり時間がかかります。
FDEは、その専門性を持つ人が最初から現場に入るため、立ち上げを早められます。
将来的に内製化を目指す場合の橋渡し役として使われることも少なくなく、FDEが現場で積み重ねたやり取りの記録が、そのまま採用後の引き継ぎ資料になることもあります。

FDEが向かない場面

ここまで良い面を中心に説明してきましたが、FDEが万能というわけではありません。

業務のルールがすでに明確に固まっていて、変化がほとんど起きない場合は、翻訳コストそのものが小さいため、従来の外注で十分なことが多くあります。
要件が変わらないなら、聞く人と作る人が別でも、目減りする情報自体が少ないからです。
定型的な事務処理の自動化のように、対象業務のルールが誰の目にも明らかで、担当者によって判断が割れない場合は、要件書と実装を分けたやり方の方が、かえって手離れがよいこともあります。

また、経営判断として「誰が最終的に決めるか」が決まっていない状態でFDEを入れても、翻訳コストの問題は減らせても、オーナー不在の問題は残ります。
3つのパターンのうち1つ目と2つ目にはFDEが直接効きますが、3つ目のオーナーシップの問題は、体制そのものを社内で決める必要があります。
ここは技術的な関わり方の工夫だけでは解決できません。

さらに言えば、FDEは「現場の言葉を正確に汲み取って形にする」ことに強みがある関わり方であって、そもそも何を作るべきかという事業判断そのものを代わりに下すものではありません。
何を優先して着手するかという判断は、最終的には社内の意思決定者が担う必要があります。
FDEにできるのは、その判断のために必要な情報が、目減りせずに手元に届く状態を作ることまでです。

具体的にどう進むか

FDEを入れる、と言っても、いきなり大掛かりな体制を組む必要はありません。多くの現場で、最初はこんな流れになります。

1歩目は、業務の棚卸しです。
現状の業務の中で、担当者が「毎回これだけは自分の目で確認している」という判断を、いくつか書き出してもらいます。
先ほどの請求書の例のように、理由まで含めて聞き出すことが目的です。
理由が分からないまま「この作業をAI化してください」と依頼すると、また翻訳コストが発生してしまうからです。
この段階では、AIで解決できるかどうかはまだ考えません。
まず「何を、なぜ確認しているか」を言葉にすることに集中します。

2歩目は、小さな試作です。
書き出した判断の中から、1つか2つを選んで、実際に一緒に動きながら試します。
ここでのポイントは、要件書を作ってから渡すのではなく、担当者の隣で見て、聞いて、その場で試作することです。
1週間から2週間ほどで、まず動くものを作ります。
試作がうまくいかなければ、その場で理由を確認し、当日のうちに直します。
ここでのやり取りの速さが、従来の外注ともっとも違う部分です。

3歩目は、そのまま本番設計に進むことです。
試作が現場の感覚に合ってきたら、担当者や契約の窓口を切り替えず、同じ人がそのまま本番向けの設計に進みます。
データの欠けや表記のゆれ、例外的な処理といった、PoCの段階では見えていなかった現実に対応するのはこの段階です。
ここで契約や担当者が切り替わらないことが、翻訳コストを発生させないための一番の条件です。

4歩目は、次の業務への展開です。
1つの業務で、現場の言葉が目減りしないまま形になる経験を作ると、その経験自体が社内の共有財産になります。
「何を、どこまで、誰に確認すればいいか」という進め方の型が一度できると、次にどの業務から手をつければいいかという判断も、社内でしやすくなります。
最初から全社導入を目指す必要はありません。
むしろ、最初の1つを丁寧に、翻訳を挟まずに作りきることのほうが、後々の広がり方に効いてきます。

歩みを並べると、こうなります。

• 歩目: 1歩目：業務の棚卸し / やること: 担当者が「毎回自分の目で確認している」判断を、理由まで含めて書き出す / ポイント: AIで解決できるかはまだ考えず、何を、なぜ確認しているかを言葉にすることに集中する

• 歩目: 2歩目：小さな試作 / やること: 書き出した判断のうち1つか2つを選び、担当者の隣で見て、聞いて、その場で試作する / ポイント: 要件書を作ってから渡すのではなく、一緒に動きながら1〜2週間で動くものを作る

• 歩目: 3歩目：そのまま本番設計 / やること: 担当者や契約の窓口を切り替えず、同じ人がそのまま本番向けの設計に進む / ポイント: 契約や担当者が切り替わらないことが、翻訳コストを発生させないための一番の条件

• 歩目: 4歩目：次の業務への展開 / やること: 1つの業務でできた経験を、進め方の型として社内に残す / ポイント: 最初から全社導入を狙わず、最初の1つを丁寧に作りきることを優先する

この4歩を通じて変わらないのは、最初に話を聞いた人が最後まで関わり続けるという点だけです。
逆に言えば、この1点さえ守られていれば、体制の大きさや契約の形はさまざまなやり方があります。
すでに社内にAI導入の担当者がいる場合は、その担当者とFDEが並走する形にもできますし、専任の担当者がまだいない場合は、FDEが立ち上げの間だけ実質的にその役割を担うこともあります。

進め方の型さえ社内に残れば、その後の業務はFDEがいなくても、同じ考え方で広げていけます。
FDEの役割は、いつまでも外部に居続けることではなく、翻訳を挟まずに進める型を現場に根づかせるところまでです。
型が根づいたかどうかは、FDEがいったん現場を離れても、担当者同士が「なぜその確認をしているか」を自分たちの言葉で説明できるかどうかで確かめられます。

次の一歩

冒頭の2つの場面を、あらためて思い出してください。
要件書通りに届いたものが現場の感覚とずれていた場面と、PoCが好評だったのに本番化が止まってしまった場面です。
どちらも、あなたが何かを間違えたわけではありません。
ただ、要件を聞いた人と、それを作り続ける人が、いつの間にか別々になっていました。

もし今、自分の関わっているAI導入がうまく進んでいないと感じているなら、まず自分に確かめられる問いがあります。
要件を最初に聞いた人と、それを今形にしている人は、同じ人でしょうか。
違うなら、その間で情報が何回、誰の手を渡っているでしょうか。
そこに、この記事で書いた「翻訳コスト」が発生しているかもしれません。
技術力の不足ではなく、関わり方の設計の問題として捉え直すところから、次の一歩は始まります。