ブリッジエンジニアを立てるか迷っている方へ
オフショア開発の体制を検討していて、「ブリッジSEは付けたほうがいいのか」「単価に見合うのか」で止まっている方に向けて書いています。
先に立場を書きます。付けるかどうかより、何を頼むかを決めるほうが先です。ここが決まっていない状態で人を立てると、単価に関係なく成果が出ません。
そして何を頼むかは、受注側では決められません。
「必要なスキルが分からない」が半数を超えています
IPAが2025年に公表した「DX動向2025」に、痛いところを突く数字があります（IPA DX動向2025）。
DXの推進に必要なスキルを把握できているかを、日本・米国・ドイツの企業へ尋ねた結果です。
| 回答 | 日本 | 米国・ドイツ |
|---|---|---|
| 必要なスキルと、人材の過不足まで把握している | 14.9% | 約半数 |
| 必要なスキルを把握できていない | 57.1% | 10%以下 |
半数を超える企業が、自分たちに何のスキルが要るのかを把握できていない。米独との差は誤差ではありません。
これはDX推進人材についての設問で、オフショア開発の調査ではありません。ただ、外部へ開発を出すときに起きることは、この延長線上にあると私は読んでいます。必要なスキルを言語化できていない発注側が人を探すと、「何を頼むか」を決める仕事まで相手に渡ることになります。
その受け皿になるのが、たいていブリッジエンジニアです。
通訳を探すと、通訳しか来ません
役割定義を「日本語とベトナム語ができて、進捗を報告してくれる人」と書けば、そのとおりの人が来ます。
そして、要件の穴は誰も埋めません。埋める役割が定義に書かれていないからです。
AIが実装へ入ると、仕事は前工程へ寄ります
ここ1年で変わったのは、実装の速度と量です。
コード生成が現場に入ると、仕様が曖昧なままでも動くものが出てきます。以前なら「これでは作れません」と実装で止まっていたものが、止まらずに通過するようになりました。曖昧さが検知される場所が、実装から受入テストへ後ろ倒しになったということです。
後ろ倒しになると、手戻りは高くつきます。作ってから直すからです。
だからブリッジ役に必要な能力の重心が、翻訳と進捗管理から、前工程へ移ります。具体的には、要件の欠けを見つけて発注側へ質問を返す力、受入基準を先に文章にする力、AIが出した実装を仕様と突き合わせる力です。
言語能力が要らなくなるわけではありません。ただ、言語だけができる人に払う金額としては、この1年で明らかに合わなくなりました。
職務記述に何を書くか
人を探す前に、頼む内容を1枚にします。
ブリッジ役の職務記述に書く5項目
- 要件の欠けを誰に返すか: 曖昧な指示を受けたとき、質問を返す先の担当者名と、返答期限
- 受入基準を書く責任の所在: 「完成」の定義を書くのは発注側か、ブリッジ役か。共同なら誰が最終承認するか
- AI生成物の扱い: 生成コードのレビュー範囲と、レビュー記録を残す形式
- 判断してよい範囲: 仕様の解釈をその場で決めてよい範囲と、必ず持ち帰る範囲の線引き
- 記録の成果物: 議事録・決定事項・変更履歴のうち、納品物に含めるもの
体制の検討会議にそのまま持ち込めます。5項目とも「誰が」を空欄にせず埋まったら、人を探す段階へ進めます
1つ目で詰まる会社が多いはずです。質問を返す先が決まっていないと、ブリッジ役は聞くのをやめて推測で進めます。それが手戻りの最大の原因です。
単価表より先に、頼む内容を1枚にする
ブリッジエンジニアが要るかどうかは、単価の問題ではありません。要件の曖昧さを誰がどこで止めるかを決めたかどうかの問題です。
決めていれば、その役割に必要な能力が書けます。書ければ、単価が高いか安いかも判断できます。決めないまま単価表を比べても、比べる基準がありません。
日本側PMの側から同じ問題を扱った記事がAI時代のオフショア開発で日本側PMが担う役割です。役割の重心がどう動くかは重なるので、体制を設計する段階では両方を見てください。
現地の人材市場の前提はベトナムのIT給与は国内で2番目に高い水準です、AI活用を体制へ落とす進め方はAIネイティブ開発で扱っています。
職務記述の1枚目から一緒に作りたい場合は、お問い合わせからご相談ください。