ベトナム人エンジニアの日本語能力はどこまで通じるか【2026年版】N1〜N5と開発現場の対応表

「ベトナム人エンジニアは日本語が通じると聞くが、実際どこまで通じるのか」——オフショア開発やベトナム人エンジニアの採用を検討している方から、こうした問いをよく受けます。提案書には「日本語対応可能」「N2以上」と書いてある。面談でも受け答えはできた。それでも、仕様の細かい意図や、障害が起きたときの一次報告まで日本語で回るのかは分からない。言葉の問題は、確かめようがないまま契約日が来てしまうものです。

結論から言うと、日本語能力はJLPTの等級ではなく「開発現場のどの業務まで日本語で回せるか」で判断してください。N2は仕様書を読んで大意をつかむ水準で、会議での即応や正確な議事録は別の訓練が要ります。そしてもう1つ、日本語ができることと技術力が高いことは別の軸です。日本語で人を絞るほど、技術力の母集団は狭まり、単価は上がる。これが実情です。

この2つを踏まえると、取るべき方針は1つに絞れます。日本語を1点に集約し、残りは設計で補うことです。要件を言語化する役割を日本人PMかブリッジSEに集め、チームの残りは技術力で選び、用語集と文書化で伝達の精度を確保する。そうすれば、日本語人材の希少性と単価に振り回されずに体制を組めます。

本記事では、JLPTのN1〜N5が公式にどう定義されているかと開発現場5業務との対応表、日本語人材の分布・希少性と「日本語プレミアム」の実額、ブリッジSEの役割と日本語に依存しない体制3パターンの比較、日本語力に頼りきらないコミュニケーション設計、当社の位置づけと向く案件・向かない案件、よくある質問の順に解説します。数字は出典と年版を明記しました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。日本語で失敗した相談に共通するのは、たった1つです。「N2という履歴書を見て、面談で受け答えができたので大丈夫だと判断した」。この記事を読み終えるころには、等級の代わりに何を確かめればよいかが分かるはずです。

JLPTのN1〜N5は何を意味するのか——開発現場でできること・できないことの対応表

「N2以上のエンジニアを配置します」という提案を受けたとき、その言葉が自社の開発現場で何を意味するのかを説明できる方は多くありません。JLPT(日本語能力試験)の等級は、日本語教育の枠組みで定義されたものであり、開発現場の業務を想定して作られてはいないからです。この章では、まず公式の定義を確認し、そのうえで開発現場の5つの業務に対応づけます。等級を業務に翻訳できれば、提案書を評価する物差しが手に入ります。

まずJLPTの公式定義——N1〜N5は「読む」「聞く」の目安であり、「話す」「書く」は試験範囲外

日本語能力試験の公式サイトでは、N1からN5までの認定の目安が「読む」「聞く」という言語行動で示されています。要約すると次の通りです。

ここで見落とされがちな点が1つあります。定義がすべて「読む」「聞く」で書かれていることです。JLPTは「話す」「書く」を試験科目として測っていません。この事実は日本で働く外国人エンジニア向けの解説記事(forworkinJapan)でも明示されており、だからこそ「N1を取得していても実際のビジネス会話が苦手な人もいれば、N3でも流暢に話せる人もいる」という現象が起きます。

つまり、N2という等級は「読む・聞くの受信側が一定水準にある」ことの証明であって、「書く・話すの発信側ができる」ことの証明ではありません。開発現場で発注側が困るのは、たいてい発信側です。議事録が要点をとらえていない、レビューコメントの意図が伝わらない、障害の第一報が状況説明になっていない。これらは等級では測れません。

開発現場の5業務×JLPTレベルの対応表——仕様書の読解から障害の一次報告まで

では、開発現場の業務ごとに、どのレベルで何ができるのか。私が約100社の体制を見てきたなかでの実感と、上位の解説記事が示す職種別の目安をあわせて整理すると、次の表になります。レベルは目安であり、個人差と業務知識の有無で前後します。

この表で伝えたいのは、「N2ならここまで」という上限ではなく、業務ごとに必要な技能が違うという点です。仕様書の読解は読む力で足り、議事録は書く力が要り、定例での即応は聞く・話すに加えて瞬発力が要ります。等級を1つ上げるより、業務の側を設計し直すほうが早いケースが多いのが実情です。

N2でもできないこと、N1でも訓練が要ること——「わかりました(わかっていない)」が起きる理由

一般社団法人ベトナムオフショア開発協会は、「N2を持っている=業務で通用する日本語が使える」とは限らないとして、現場で起きる3つのずれを挙げています。1つ目は障害報告が経緯の説明になり、管理者が求める「何が・いつから・どの範囲に」が出てこないこと。2つ目は「以前開発した画面と同じようにつくってください」という曖昧な指示に対し、「わかりました(わかっていない)」と返ってしまうこと。3つ目は「簡単に使えるUI」のような語の解釈が、日本側と海外チームでずれることです。

3つとも語彙や文法の問題ではありません。結論から先に述べる構造化された説明の型、明示されていない期待値を確認し直す習慣、用語の定義を揃える作業——いずれも日本語の等級とは別に訓練や仕組みが要るものです。同協会はJLPTとは別にBJT(ビジネス日本語能力テスト)の活用を勧めていますが、発注側としては「相手の等級を上げる」よりも「型と用語集を先に渡す」ほうが確実に効きます。

私が見てきた失敗の相談も、ここに集中しています。共通するのは1つで、「N2という履歴書を見て、面談で受け答えができたので大丈夫だと判断した」という判断でした。面談は準備できる場です。質問はある程度予想でき、時間の余裕もあり、相手も聞き取りやすく話してくれます。障害の第一報や、仕様の解釈が割れた場面での確認とは、負荷がまったく違う。ここを同一視するのが失敗のもとです。

職種別の目安と、面談で日本語力を見る4つの確認項目

職種別の目安としては、プログラマはN4〜N3、ブリッジSEはN2以上、というのが解説記事に共通する整理です(行政書士法人バタフライエフェクトの業種・職種別の表など)。ただしこれは「最低ライン」であって、日本語の総量を誰が引き受けるかの設計とセットで考えるべきものです。

そのうえで、面談で日本語力を見るなら、次の4点を確認してください。当社の場合も、アサイン後に候補者面談の場を設けており、発注側が自分の目で確かめられるようにしています。

1. 構造化された説明ができるか: 「直近のプロジェクトで起きたトラブルを、何が・いつから・どの範囲に・どう対応したかの順で説明してください」と依頼する
2. 曖昧な指示を確認し返せるか: わざと曖昧な依頼を1つ出し、そのまま「わかりました」と答えるか、条件を聞き返すかを見る
3. 書く力を見る: 面談後に、その場の決定事項を5行程度のテキストで送ってもらう。要点の取捨選択と正確さが分かる
4. 業務用語の理解: 自社の業務で頻出する用語を3つ挙げ、意味を説明してもらう。知らないこと自体は問題ではなく、知らないと言えるかを見る

等級を業務に翻訳し、面談で発信側を確かめる。ここまでが「見極め」の話です。次は、そもそも日本語ができる人財がどれくらいいて、いくら高いのかという「調達」の話に移ります。

日本語ができる人財はどれくらいいるのか——分布・希少性と「日本語プレミアム」の実額

「ベトナムは日本語人材が厚い」という説明はよく聞きます。実際に厚いのですが、厚いのは母集団であって、発注側が本当に欲しい層——日本語ができて、実務経験があり、技術力も高い人財——はきわめて薄いのが実情です。この章では、公開されている調査で分布を確認し、日本語ができると単価がいくら上がるのか、そして日本語力と技術力がどういう関係にあるのかを整理します。

母集団の大きさ: 日本語学習者は約17万人、ただしIT×日本語の層は薄い

国際交流基金の「2021年度 海外日本語教育機関調査」では、ベトナムの日本語学習者は約17万人(169,582人)です。2012年の約4.7万人から約3.6倍に増えており、大学・専門学校の日本語クラスに加え、IT+日本語のカリキュラムを提供する教育機関も増えています。JLPTの受験者数も多く、日本語能力試験の公式サイトが公表する実施状況によれば、2019年(第1回・第2回の合計)のベトナムの受験者数は78,318人、応募者数は91,425人でした。国際交流基金は同年第1回について、海外の応募者数が中国・韓国に次いでベトナムが3番目に多かったと発表しています(いずれも2026年9月21日に確認)。

一方で、レベル別の内訳となると話が変わります。ベトナムのJLPT合格者をレベル別に集計した公的な統計は公表されておらず、「N1・N2が何割か」を裏づける原典は確認できませんでした。数字を置く代わりに、当社が採用の現場で見ている事実を書きます。応募者の大半は初級から中級のレベルにとどまり、設計意図や受け入れ条件を日本語の文章で正確にやり取りできる層は、母集団に対してごくわずかです。IT分野に限れば、さらに絞られます。ベトナムのIT求人のうち日本語スキルを要件に含むものは全体の3.5〜4.0%にすぎません(TopDev「Vietnam IT Market Report 2024-2025」。2026年9月21日にレポート本体で確認)。

この2つを掛け合わせると、「日本語N2以上」「IT実務経験3年以上」「技術力が一定水準以上」の3条件を同時に満たす人財が、いかに小さな集合かが見えてきます。母集団が17万人でも、発注側が求める層は数千人規模まで絞られる。だから採用競争が激しく、報酬も高くなります。開発スキル・実務経験・日本語力の3つをすべて満たす人財が限られていることは、当社が人財紹介の現場で日々直面している事実でもあります。

日本語プレミアムの実額: 日本語要件の求人は平均より38%以上高い、白書ではPGとBrSEに約1.5倍の差

では、いくら高くなるのか。数字は3つの角度から確認できます。

3つは測っている対象が違います。TopDevは現地の求人給与、白書は日本企業が支払う発注単価、当社の公開単価は職種の役割ごとの提示額です。それでも、日本語を要件に加えた瞬間に費用が3〜5割、役割まで含めれば2倍近く上がるという傾向は一致しています。円表記は1USD=150円での換算目安です。

なお、ブリッジSEの単価差は「日本語ができるから」だけではありません。要件の言語化、優先順位の整理、レビュー、リスクの報告といった役割が乗っているためです。逆に言えば、日本語ができるだけのエンジニアに、ブリッジSEの単価を払う必要はありません。提案書で日本語人材の単価が高いときは、「何の役割に対する費用か」を分解して聞くことをおすすめします。現地の給与水準そのものは「ベトナムIT人材 給与」の記事に職種別・経験年数別でまとめています。

「日本語ができる=技術力が高い」ではない——83%が情報系学部出身、弱いのはドキュメントと上流

もう1つ、費用より大きな誤解があります。日本語ができる人を選べば、技術力も高いだろうという思い込みです。この2つは独立した軸であり、相関はほとんどありません。

ベトナムの転職サイトITviecが自社で実施した調査「IT Salary Report 2023-2024」(ベトナムのIT人材2,207名が回答、調査期間2023年9月19日〜10月10日)では、回答者の83.0%が大学・カレッジでITまたはIT関連分野の学位を取得しています(2026年9月21日に同社の公開レポートで確認)。一方、当社が現地でエンジニアと働いてきた実感としては、プログラミング能力やクラウドの知見は日本人SEに劣らない一方、弱いのはドキュメント作成と上流工程です。理由は、外資系オフショア企業が多く、顧客の言語と商慣習を理解する外国人が上流を担当し、ベトナム人は開発に専念する体制が定着したためです。

この構図は、発注側にとって重要な示唆を持ちます。第一に、技術力を求めるなら日本語で母集団を絞らないほうがよい。日本語N2以上に限定した瞬間、技術力で選べる候補は大きく減ります。第二に、日本語ができる人に期待すべきはドキュメントと上流の一部であって、実装の品質ではない。実装の品質は言語ではなく、コードレビューと完了の定義という仕組みで担保するものです。

私が体制の相談を受けるとき、必ず最初に切り分けるのがこの2軸です。「日本語ができる人を何人入れるか」ではなく、「要件を言語化する役割を誰が持ち、残りの枠は技術力で選ぶ」。日本語人材の希少性と単価は変えられませんが、必要な人数は設計で変えられます。次の章では、その設計——日本語人材に依存しない体制の作り方を3パターンで比較します。

ブリッジSEの役割と、日本語人材に依存しない体制の作り方——3パターンの比較

日本語人材が薄くて高いのなら、答えは「日本語の総量を減らす」ことです。全員に日本語を求めるのではなく、要件を言語化する役割を1点に集め、残りは技術力で選ぶ。この章では、その1点を誰が担うのかで分かれる3つの体制を比較し、翻訳ツールと生成AIがどこまで代替できるかも整理します。体制の選び方は、自社に英語で仕様を書ける担当がいるかどうかでほぼ決まります。

ブリッジSEは何をする人か、そして何ができないか——属人化という代償

ブリッジSE(BrSE)は、発注企業と現地の開発チームの橋渡しを担うエンジニアです。日本語で受け取った要件を実装可能な形に落とし、現地から出た質問を発注側が判断できる形に戻す。加えて、進捗の報告、レビューの取りまとめ、リスクの早期共有まで担うのが一般的です。日本語能力は手段であって、本体は要件を翻訳する技術です。

ただし、ブリッジSEを置けば安心かというと、そうではありません。代償は属人化です。要件の解釈がその人の頭の中にしかない状態になると、退職や交代でプロジェクトが止まります。人材リスクは、日本語人材が希少であるほど大きくなる。さらに、伝達が1段階増えるぶん、往復に時間がかかります。

ブリッジSEにできないこともはっきりしています。「何をなぜ作るか」を決めることです。優先順位の判断と、業務としての正解の決定は発注側に残ります。ここを任せてしまうと、3か月後に画面が想定と違うという結果になる。「日本語対応可だから丸投げできる」という理解は、失敗のもとです。ブリッジSEの役割と必要になる規模の目安は「ブリッジSE」の記事で詳しく整理しています。

体制3パターン比較表——日本人PMがフロント / ブリッジSE経由 / 英語+ドキュメント

要件を言語化する役割を誰が持つかで、体制は3つに分かれます。費用・精度・向く案件を並べると次の通りです。

3つのうち1つを選ぶというより、案件の規模に応じて組み合わせるのが現実的です。私が相談を受けるときは、社内に英語で仕様を書いて週次で確認を回せる担当がいるかを最初に聞きます。いれば3つ目が候補になり、技術力だけで候補者を選べるので単価も下がる。いなければ1つ目か2つ目になります。英語で進める場合の仕様書の書き方と国別の前提は「オフショア開発 英語」の記事にまとめました。

事例で言えば、介護記録SaaS「CareViewer」は日本語ブリッジSE1名+フルスタックエンジニア2名という構成です。要件が動き続けるプロダクトで、週次の優先順位判断だけを発注側が担い、言語化はブリッジSEに集約しました。結果として従来の半分以下のコストで継続開発が回っており、「想像以上にエンジニアのレベルが高い」という評価をいただいています。3名のうち日本語を求めたのは1名だけ、という点がこの体制の要点です。

翻訳ツールと生成AIの使い方と限界——曖昧な日本語は曖昧な訳文になる

近年は「翻訳ツールと生成AIがあれば日本語人材は要らないのでは」という質問も増えました。答えは、テキストのやり取りは大幅に楽になったが、要件の曖昧さは解けない、です。

使える場面ははっきりしています。仕様書やチケットの下訳、用語の統一、長文の要約、コードコメントの翻訳。テキストベースで時間をかけられる作業は、ほぼ置き換わりました。一方、限界も明確です。第一に、曖昧な日本語を入れれば曖昧な訳文が出ます。「適宜対応してください」は、どの言語に訳しても「適宜」のままです。第二に、業務固有の用語や社内の略語は誤訳されます。第三に、リアルタイムの会議での即応には使いにくく、最終的な判断は人が担うしかありません。

つまり翻訳ツールは、次章で述べる用語集と文書化の設計が済んでいる現場では強力な戦力になり、済んでいない現場では誤解を高速に拡散する道具になります。順番を逆にするのは要注意です。

日本語の「総量」を減らす——誰が要件を言語化するかを1点に決める

3パターンに共通する原則は1つです。日本語を必要とする作業を洗い出し、その大半を1人に集約する。集約された1人は日本人PMでもブリッジSEでもよく、場合によっては発注側の担当者が英語で書く形でもかまいません。重要なのは「全員が少しずつ日本語を使う」状態を避けることです。

全員が少しずつ使う体制は、一見すると柔軟に見えて、実際には誰も責任を持たない翻訳が各所で発生します。仕様の解釈が3通りに分かれ、誰の解釈が正なのか分からなくなる。私が見てきた限り、これが日本語まわりで最も多い失敗のパターンです。日本語は、薄く広げるのではなく、1点に集めて厚くする。これが体制設計の結論です。

日本語力に頼りきらないコミュニケーション設計——書き言葉中心、用語集、決定事項の文書化

体制を決めたら、次は日々の進め方です。ここで効くのは語学力ではなく設計です。同じN2のメンバーでも、設計のある現場では仕様のずれがほとんど起きず、設計のない現場では毎週のように手戻りが出ます。以下の4原則は、当社が日本人PMをフロントに置く案件でも、ブリッジSE経由の案件でも共通して最初に決めているものです。必要な日本語のレベルを、仕組みの側から下げる考え方です。

原則1: 話し言葉ではなく書き言葉で決める——口頭の合意は必ずテキストに落とす

第二言語での会話は、読み書きより難易度が高くなります。JLPTが「読む」「聞く」を測っていることは先に述べた通りですが、会議での即応はそこに「話す」と瞬発力が加わる。つまり、口頭で決めた合意ほど、相手の理解度が確認できないまま進みます。

対策は単純です。決定は必ずテキストに残す。会議は決めるための場ではなく、テキストで決めた案を確認する場にする。具体的には、議題と論点を前日までにテキストで共有し、会議では「この理解で合っているか」を確認し、決定事項を会議後に箇条書きで送って相手に復唱してもらう。この3ステップを守るだけで、N2のメンバーでも認識のずれはかなり減ります。

もう1つ、チャットでのやり取りには「時間をかけて考えられる」という利点があります。テキストなら辞書も翻訳ツールも使えますし、後から検索もできる。当社が日々の指示をチャットとチケットに集約しているのは、日本語の負荷を下げるためでもあります。

原則2: 用語集を最初の1週間で作る——業務用語・画面名・状態名の対訳を固定する

日本語まわりの誤解のうち、かなりの割合が「言葉の定義のずれ」です。ベトナムオフショア開発協会が例に挙げた「簡単に使えるUI」の解釈違いはその典型で、日本側は直感的な操作を、海外チームはデザインの簡素さを想像することがあります。

これを防ぐのが用語集です。プロジェクトの最初の1週間で、次の3種類を表にしてください。

1. 業務用語: 「受注」「検収」「締め処理」など、自社の業務に固有の言葉。日本語・英語(必要なら越語)と、1〜2文の定義を書く
2. 画面名・機能名: 画面の呼び方を固定する。「一覧画面」「明細画面」が人によって違う呼び方になると、チケットが追えなくなる
3. 状態名: 「下書き」「申請中」「差戻し」など、データの状態を表す語。実装上の値(draft、pending など)と対で管理する

用語集は一度作って終わりではなく、新しい語が出るたびに追記します。当社の案件では、この表をプロジェクトのドキュメントの先頭に置き、翻訳ツールを使うときも必ず用語集の訳語に揃えるルールにしています。

原則3: 決定事項と受け入れ条件を文書化する——「適宜」「いい感じに」を残さない

仕様の曖昧さは、語学の問題ではなく日本語の問題です。「適宜」「いい感じに」「よしなに」「原則として」といった語は、日本語ネイティブ同士でも解釈が割れます。第二言語の相手に渡せば、確実に割れます。

そこで、チケットには受け入れ条件(完了の定義)を書きます。「この機能が完成したと言えるのは、どの操作をしたときに何が起きる状態か」を、箇条書きで3〜5行。数値で書けるものは数値にする。「速く表示する」ではなく「一覧の初回表示を2秒以内」と書く。ここまで書けば、日本語の等級に関係なく実装の判断ができます。曖昧さを残さない書き方の型は「仕様書 書き方」の記事で詳しく扱っています。

実装の品質そのものは、言語ではなく仕組みで担保します。当社の場合は、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点です。日本語ができないエンジニアの成果物の品質が落ちる、という心配をよく聞きますが、落ちるのは伝達の精度であって実装の品質ではありません。伝達は用語集と受け入れ条件で、品質はレビューで解く。分けて考えると、日本語に求めるものがぐっと減ります。

原則4: 非同期と同期を使い分ける——時差2時間を前提にした週次の会議設計

ベトナムと日本の時差は2時間で、ベトナムのほうが遅れています。日本の午前10時はホーチミンの午前8時、日本の18時は現地の16時です。勤務時間の重なりが長いため、日本側が午前に投げた質問はその日のうちに解消でき、翌朝には回答が揃っています。これは欧州や南米のオフショアにはない利点です。

そのうえで、同期(会議)と非同期(チャット・チケット)を使い分けます。同期に回すのは、優先順位の判断、仕様の方針が割れたときの合意、振り返りの3つ。それ以外——進捗の共有、細かい仕様の確認、レビューのやり取りは非同期で十分です。週次の定例を1本、朝会は必要な期間だけ。会議を減らすほど、会議での即応に必要な日本語レベルも下がります。

ここまでの4原則は、どれも特別な投資を必要としません。では、これらを前提にしたとき、当社はどういう体制を提供していて、どんな案件に向き、どんな案件には向かないのか。次章で正直に整理します。

当社の位置づけと、日本語人材が向く案件・向かない案件

ここまでの整理を踏まえて、当社TALENTBASE VIETNAMがどういう体制を提供しているかを書きます。売り込みではなく、前章までの原則を実際の提供物に落とすとどうなるかの一例として読んでください。あわせて、日本語人材を厚くすべき案件とそうでない案件、そして当社が向かないケースも正直に書きます。

当社の体制と公開単価——2,000名以上の人財データベース、日本人PMフロント、候補者面談

当社はホーチミンを拠点に、グループで2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)を保有し、そこから直接アサインしています。協力会社や紹介を経由しないため、仲介マージンがかかりません。公開している単価は次の通りで、当社調べで市場相場の約1/2です。円表記は1USD=150円での換算目安です。

体制は2パターンから選べます。パターンAは日本人PMまたはブリッジSEをフロントに置き、その後ろにエンジニアを配置する形(推奨)。パターンBはエンジニアのみで、発注側に要件を言語化できる担当がいる場合の構成です。1名から契約でき、開始は最短2週間、増員は約1週間、縮小や交代は1か月単位で調整します。最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。

日本語力については、提案書の記載だけで判断していただく必要はありません。フローは打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始という順で、開始前に候補者と直接話す場があります。前章の4つの確認項目をその場で試していただくのが、いちばん確実です。契約・支払いは日本国内法人・日本法準拠で、海外送金は不要です。時差は2時間、祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)、テト(旧正月)休暇は2026年は2月14日から22日です。

日本語人材を厚くすべき案件と、厚くしなくてよい案件

日本語の必要量は案件の性質で決まります。判断の目安は次の通りです。

左に多く当てはまるなら、日本人PMかブリッジSEをフロントに置く体制を。右に多く当てはまるなら、日本語を求めず技術力で人を選んだほうが、同じ予算で高い水準のチームが組めます。当社の事例でも、介護記録SaaSのCareViewerは日本語ブリッジSE1名+フルスタック2名、HELTEQはフルスタック4名、金融系マッチングはPM1名+フルスタック2名と、案件の性質に応じて日本語の厚みを変えています。

当社が向かないケースも正直に書く

当社が向かないケースもあります。第一に、要件が確定していて成果物単位で費用を固定したい単発案件です。当社は準委任のラボ型を主としているため、請負で見積もれる会社のほうが適しています。第二に、24時間の有人監視や、日本国内での常駐が要件に含まれる案件です。第三に、開発の優先順位を判断する担当を発注側に一切置けない案件です。日本人PMをフロントに置けば負担は週1回の判断まで減らせますが、ゼロにはできません。日本人PMを置く体制の詳細は「オフショア開発 日本人PM」の記事をご覧ください。

日本語の観点で言えば、「N1のエンジニアだけでチームを組みたい」という要望にも、正直にお応えしていません。前章までに書いたとおり、それは技術力の母集団を大きく狭め、単価を2倍近くに引き上げる選び方だからです。同じ予算なら、日本語を1点に集め、残りを技術力で選ぶほうが、成果は確実に大きくなる。自社の案件はどちらに当てはまるでしょうか。

ベトナム人エンジニアの日本語能力でよくある質問

日本語能力について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内で体制を説明するときの材料にもお使いください。

Q1. N2があれば業務日本語は問題ないですか?

業務によります。仕様書を読んで大意をつかむ、事前に議題を共有した定例に参加する、といった業務はN2で成立します。一方、その場で出た論点への即答、要点を絞った議事録、障害時の構造化された第一報は、N2でも別の訓練か型の用意が要ります。JLPTは「読む」「聞く」を測る試験で「話す」「書く」は範囲外のため、等級だけでは発信側の力が分かりません。

Q2. 日本語ができるエンジニアだけでチームを組めますか?

組めますが、おすすめしません。ベトナムのIT求人で日本語を要件に含むものは全体の3.5〜4.0%(TopDev 2024-2025)で、日本語要件のある求人は全求人の平均より少なくとも38%高くなります。全員に日本語を求めると、技術力で選べる母集団が狭まり、単価も上がります。日本語は1点に集約し、残りを技術力で選ぶほうが同じ予算で高い水準になります。

Q3. 翻訳ツールと生成AIがあれば日本語人材は不要ですか?

不要にはなりません。テキストの下訳・用語の統一・長文の要約は大きく楽になりましたが、曖昧な日本語は曖昧な訳文になります。「適宜対応してください」は訳しても曖昧なままです。用語集と受け入れ条件を先に整えれば強力な戦力になり、整えないまま使うと誤解が高速に広がります。

Q4. 面談で日本語力をどう見ればよいですか?

4点を確認してください。(1)直近のトラブルを「何が・いつから・どの範囲に・どう対応したか」の順で説明してもらう、(2)わざと曖昧な依頼を出し、聞き返すかどうかを見る、(3)面談後に決定事項を5行程度のテキストで送ってもらう、(4)自社の業務用語を3つ挙げて説明してもらい、知らないと言えるかを見る。当社は開始前に候補者面談の場を設けているので、その場で試していただけます。

Q5. 日本語ができないエンジニアだと品質は落ちませんか?

落ちるのは伝達の精度であって、実装の品質ではありません。実装の品質は、設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックという仕組みで担保します。伝達の精度は、用語集と受け入れ条件の文書化で上げる。品質と言語を切り分けて設計するのが、日本語人材が薄い市場での現実的な打ち手。

まとめ: 等級ではなく業務で見る——日本語は1点に集め、残りは用語集と文書化で補う

ベトナム人エンジニアの日本語能力は、JLPTの等級ではなく「開発現場のどの業務まで日本語で回せるか」で判断してください。JLPTは「読む」「聞く」の目安であり、「話す」「書く」は試験範囲外です。N2は仕様書の大意をつかみ、議題を事前共有した定例に参加できる水準。その場で出た論点への即答、要点を絞った議事録、障害時の構造化された第一報は、N2でもN1でも型の用意と訓練が別に要ります。面談で受け答えができたことを根拠に判断するのは、失敗のもとです。

そして日本語力と技術力は別の軸です。ベトナムの日本語学習者は約17万人(国際交流基金 2021年度)と多いものの、設計意図を日本語で正確にやり取りできる層は薄く、IT求人で日本語を要件に含むものは3.5〜4.0%、日本語要件の求人は全求人の平均より少なくとも38%高い(TopDev 2024-2025)。日本語で人を絞るほど技術力の母集団は狭まり、単価は上がります。取るべき方針は、要件を言語化する役割を日本人PMかブリッジSEに1点集約し、残りは技術力で選ぶこと。そのうえで、書き言葉中心・用語集・決定事項と受け入れ条件の文書化・非同期と同期の使い分けという4原則で、必要な日本語のレベルを仕組みの側から下げることです。実装の品質は言語ではなく、設計レビューとコードレビューとリリース前のダブルチェックで担保します。

当社は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインし、日本人PMをフロントに置く体制を選べるようにしています。公開単価は実務3年目安1,500USD(約22.5万円)、ブリッジSE 3,000USD(約45万円)で、開始前に候補者面談の場があるため、日本語力はご自身の目で確認いただけます。言語の選び方と仕様の伝え方はオフショア開発に英語は必要か、ブリッジSEの役割と必要な規模はブリッジSEとはもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、日本語をどこに集約すべきかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。