日本国内での開発と異なり日本国外でのソフトウェア開発、いわゆるオフショア開発を検討する際、必要となることが多いのが発注元である日本企業（及び日本人担当者）と現地のオフショア会社（ベンダー）におけるエンジニアとを橋渡しする「日本語人材」です。
彼ら彼女らの日本語能力はどうなのかといった点や、どのようにコミュニケーションを取れば上手くいくのか、注意しなければいけないことは何か、もしくはそもそも日本語人材は必要なのかという点で不安や疑問に思われている方も多いでしょう。
そこで今回はオフショア開発において日本語人材は必要なのか？という点について分かりやすく解説をします。
1.オフショア開発における日本語人材とは？
オフショア開発会社（ベンダー）によっては、現地在住の日本人をアサインするケースもありますが絶対数が少ないこともあり、通常は日本語が話せる現地人のことを指して日本語人材と言われます。
なお一口に日本語人材といっても以下の様な役割に分かれます。また会社によっては定義が異なる場合がありますので、あくまでも一般的な分類です。
1-1.ブリッジSE（BrSE）
日本語が話せてソフトウェア開発における知識や経験がある人材です。
主な業務としては、要件定義書・基本設計書など各種ドキュメント類の作成（補助）、翻訳、通訳、進捗管理、タスクの割り振り、成果物の品質チェックなどを行います。
能力やスキルとしては、日本語能力（日本語検定1級～2級、通常N1～N2と呼ばれるレベルでビジネスに活用できるレベル）となり、加えてシステム開発やプロジェクト管理への知見がある方々です。
さらに、ソフトウェア開発における知識や経験を活かして、エンジニアに対して技術的な指示や修正依頼を自ら出せる人材もいます。
ただしどこまで対応できるのかはその人物の過去の経歴、例えば元々エンジニアであり現在はブリッジSEとして活動している人材であれば対応できても、そういった経験がない人材であれば対応が難しいなど人によっても異なるため、オフショア開発会社（ベンダー）へ事前に確認が必要です。
1-2.ITコミュニケーター
日本語と現地語の少なくとも2ヵ国語を話すことができ、発注者と開発エンジニアとを繋いでコミュニケーション対応を行う人材です。
言語の通訳・翻訳、ドキュメント作成の補助、会議のファシリテーション、日々の報告などを行います。
日本語能力面では、ブリッジSEとITコミュニケーターの違いはありませんが、ブリッジSEと異なりITコミュニケーターには、ソフトウェア開発における専門知識や経験は問われず、あくまでもコミュニケーションに特化した人材であることが多いです。
2.状況によって変わる日本語人材アサインの必要性
では、どういった状況で日本語人材をアサインする必要性が高く、どういったケースでは低いと考えられるのか、それぞれを見ていきます。
2-1.日本語人材の必要性が高いケース
（A）アジャイル開発をする場合
短いサイクルで頻繁にミーティングを行い、要件を調整しながら進めるアジャイル開発では、リアルタイムかつ細やかな意思疎通が不可欠となります。それゆえ発注者がそれを日本語で実施したい場合、オフショア開発側でも日本語人材が不可欠となります。
（B）与件整理や要件定義など上流工程から依頼する場合
まだ漠然とした形で頭の中にあるアイデアからビジネス要件、システム要件を整理して開発するものを明確にしていく。このような「何を作るか」が明確になっていない段階においては、背景にある課題や意図を正確に汲み取る能力が必要となり、日本語人材の重要度が高いと言えます。
（C）複雑な業務システムや日本独自の商慣習、日本の生活環境などが関係するプロジェクトの場合
金融、医療、または日本特有の「おもてなし」「帳票文化」など、知識や文化的背景の理解が必要なシステム開発においては、それを英訳してもなかなか伝わりづらいです。
（D）発注側においてオフショア開発の経験やITリテラシーが乏しい場合
初めてのオフショア開発であるケースや、そもそも開発依頼をすることも知見があまりない場合、オフショア側に日本語人材がいた方が意思疎通の面で齟齬を防ぎ、また安心感もあります。
なお上記の（B）や（C）については、日本語人材よりも可能であるならば日本人がいる開発先（ベンダー）や、もしくは日本に留学経験のある日本語人材の方が良い場合があります。
例えば、現在では少し状況が変わったものの数年前までベトナムのハノイやホーチミンには都市鉄道（地下鉄）が無かったため、「通勤時に電車が来るまでホームでの待ち時間で使える･･･」といった概念や感覚が伝わりづらいこともありました。
よって日本語人材の必要性が高く人材がいる場合であっても、開発内容によっては伝わりづらいことも考えられるため、事前にオフショア開発会社（ベンダー）へ相談しどういう日本語人材なのかの確認をした方が良い場合もあります。
2-2.日本語人材の必要性が低いケース
（A）仕様書・詳細設計書が完全に固まっている中での開発の場合
例えばウォーターフォール型開発における下流工程など、あとはコードを書くだけ、という状態であれば、設計書自体の翻訳さえ正確であれば、日本語人材のアサインを最小化して開発することも考えられます。
（B）保守・運用やテスト業務など、ルーチンワークが多い場合
オフショア開発で多いのが、既にあるシステムやサービスにおける保守運用業務の移管です。イレギュラーな事態が少ない業務であり、こういった業務では、マニュアル化をしやすく、1度現地語でマニュアル化をしてしまえば、日本語人材の常時アサインが不要となるもしくはアサイン量を最小化できるケースが多いです。
（C）自社（発注側）が英語or現地語で直接コミュニケーションできる場合
社内のエンジニアやPMが英語に堪能であれば、現地のエンジニアと直接やり取りした方が、伝言ゲームを防げてスピードも速くなることも多いです。
また最近では日本で採用した外国籍人材の活用、例えば日本語も話せて自社の社員であるベトナム人エンジニアを活用して、オフショア側（ベンダー側）のベトナム人エンジニアとベトナム語でコミュニケーションをしながら開発を進めるといったケースもあります。
また他の国籍の社員を使って、彼らから英語でコミュニケーションをとるというケースも今後増えていくと考えられます。日本語人材は、アサインすることでどうしてもコストが発生してしまいます。よってタスクが明確であり、言語によるコミュニケーションへの依存度が低い場合は、日本語人材ではなく英語人材とするもしくは、日本語人材のアサイン量を減らすことで、コストメリットを最大化できます。
3.日本語人材は、日本語ネイティブの日本人ではない
オフショア開発である意味失敗事例として多いのは、「日本語が話せる」＝「日本にいる日本人と同じ」という誤解をして結果、コミュニケーション上の齟齬が生じてしまうケースです。
それを避けるために、以下のようなポイントについて注意が必要です。
3-1.ハイコンテクストでは伝わらない
「いい感じで」「なる早で」「よしなに」といった日本特有の曖昧な表現は、相手に通じないと考えた方が良いですし、意図しない成果物ができあがる原因にもなり、そこから修正対応が発生してしまいます。
いつまでに何をどうして欲しいのか、明確に伝える必要がありますし、それをビジネスChatやメールなど文章で残すことで、間違い発生のリスクを低減できます。
3-2.会話能力には個人差が大きい
日本人が挑戦しても問題によっては、正解するのが難しい「日本語検定1級（N1）」。この資格を持っている方であっても、会話能力についてはかなりばらつきがあります。そこでできるだけ分かりやすい表現を心掛け、ゆっくりと相手に伝えることで、齟齬を避けることに繋がります。
逆の立場に置き換えてみるとイメージしやすいです。
例えばアメリカ人からネイティブな英語で話しかけられる際に、難しい単語を交えた長文を早口で伝えられると聞き取れなかったり間違って理解する可能性が高まります。しかし、ゆっくりと分かりやすい単語や表現で話してもらえれば、正しく理解できる可能性が高まるのと似ています。
3-3.「分かりました」の重みの違い
これは相手の国民性や個人にもよりますが、理解していなくてもとりあえず「はい、分かりました」と返事をしてしまう事も多いです。
本人としては、別に騙そうとしているのではなく、サービス精神でそう答えるケースや、メンツとしてそう答えてしまう場合、または、まずはそう答えた方が望ましいと思って回答しています。
よって、大事なことや複雑な事である場合は、本当に理解しているのかを確かめるために、発注者から質問をして日本語人材から理解した内容を説明してもらう、最初に説明した内容を復唱してもらうといった確認を行うことにより、コミュニケーション齟齬を避けることに繋がります。
3-4.働き方への配慮
日本語人材に限った話ではありませんが、日本語が話せるとつい日本人と同じ様に接する発注者の日本人のケースも見受けられます。
例えば金曜日の夕方くらい（残りの勤務時間が短い状況）で、今週中にこれを終えておいてとたくさんの作業を依頼するようなケースです。他にも残業や休日対応を前提としたギリギリのスケジュールを組んで依頼するようなケースも不適当なケースです。
最近では日本国内でも働き方改革などで変わってきましたが、一昔前には主流であったこのような「気合で乗り切る」事を前提とした働き方を押し付けても、相手は日本人ではないので受け入れてくれませんし、それが続くと辞められてしまったり生産性が下がったりします。
日本からオフショア開発の依頼先国で約半数を占めるベトナムは、「勤勉な国民」というイメージもありますが、勤勉＝日本の昔からの働き方が通用するという意味ではありません。日本語でコミュニケーションを取れるとしても相手は日本人ではないので、バッファ（余裕）を持たせた計画と依頼の仕方、進め方が重要となります。
4.オフショア開発を成功させるための工夫
以上で述べてきたように、「日本語を話せる人材がいる」というだけでコミュニケーションに齟齬が生じないわけではありません。
日本語人材というコストを負担している以上、日本語ができるという点は最大限活用しつつ、発注者側でも最大限歩み寄ることが、結果的に開発成功への鍵となります。
4-1.「視覚的」なコミュニケーションを活用する
これは日本人相手のコミュニケーションの場合でも同じですが、言葉だけでの説明、文字だけでの説明だと相手に正しくイメージが伝わらない可能性があります。まして相手は、日本語が話せても日本人ではありません。
そこで活用したいのが、図や絵といった視覚的なものです。パワーポイントやスライド上にワイヤーフレームという画面構成を描き、それをオンラインMTGなどで指さしながら説明することで、相手に視覚的に要件を伝えることができます。
出張などでリアルのMTGを実施するのであれば、ホワイトボードを使ったり、コピー用紙やノートにその場で図や絵を描くのも分かりやすいでしょう。
また最近では生成AI（Gemini、ChatGPT等）を活用することで、誰でも自身が頭の中で描いたイメージを素早く形作れるようになりました。こういったツールで生成した自身のイメージ通りのものを渡すことで、より齟齬は発生しづらくなります。
4-2.ドキュメントの平易化
先ほどの「3-2.会話能力には個人差が大きい」でも述べたようにできるだけ分かりやすい、平易な言葉を使ってドキュメント類を渡すようにする工夫です。例えば、主語と述語を明確にして書くことや、曖昧な表現及び、二重否定を避けるといった点です。
また口頭ではなくChatwork、Slack、Teams、Redmineなどオンラインコミュニケーションツールを活用し文字として依頼内容を残していくことで、言った言わないを避ける事ができます。ただし連絡する際、依頼内容を長々と文章を書くよりも、短く箇条書きで書いた方が正しく伝わりやすいです。
また日本語人材も人によりますが、タスクの量によっては、作業の都合上で一部機械翻訳などを活用することがあります。難解な文章ですとその際に誤訳されるケースもありますし、目的は依頼したソフトウェアを作ることであって彼ら彼女らの日本語能力を試すことではないので、こういった配慮をした方が成功に繋がりやすくなります。
4-3.こまめなアウトプットの確認
何ヶ月もかけて全て出来上がってから確認をすると、意図したものと違った場合、手戻り対応の工数が膨大になり、時間も費用も掛かります。
それよりもこまめにアウトプットを確認していくことで、認識の齟齬があった場合でも早く気が付くことができ、修正も短時間で済むというメリットがあります。
4-4.特定の人物に依存しない
日本語人材といっても様々な人材がおり、すごく優秀な人材が最初からアサインされて順調に開発が進む幸運なケースがあります。
しかしある時、その人物が退職や休職によって別の日本語人材に代わり、その人物に特に問題があるわけでもなくごく普通の日本語人材であったとしても、急にこれまでのやり方、指示の仕方では上手くいかなくなって、結果的に以前は発生しなかった遅延や齟齬が生じたというトラブルに巻き込まれるケースもあります。
誰しもが優秀な日本語人材のアサインを望みますが、そういった人材は業界内でも争奪が激しく、ずっとアサインされ続けるという保証がありません。
現在アサインされている日本語人材がどのレベルなのかの判断がしづらい場合は、依頼先のオフショア開発会社（ベンダー）へ平均的なレベルかどうか、それとも特に優秀なレベルなのかを確認してみるというのも1つの方法でしょう。
確認した結果、特に優秀な人であるなら将来替わる可能性も考慮してその人物の能力に甘えず、既に述べてきたことを徹底することで変更となった場合でも急に上手くいかなくなるというリスクを避ける事に繋がります。
4-5.役割分担の明確化
発注元の会社にもエンジニアがいて、オフショア側のブリッジSEと現地エンジニアとで一緒に開発を進めていく場合、お互いにこの部分は相手がやると考えていたと誤認し、開発が進んでいなかった、作業が抜け漏れていたというトラブルが発生することがあります。
そのようなトラブルを避けるためにも開発を始める前に、誰がどこまでを担当するのかといった役割分担を明確にしておくことが重要です。
4-6.マインドの共有
失敗するプロジェクトの多くには、「これを作って」という「What」しか伝えられていないケースが多く、それが日本語として正しく伝わっていたとしても、「誰のためになぜこの機能が必要なのか」、「なぜこれを作るのか」といった背景や理由「Why」について伝わっていない事が多いです。
これが伝わっていないと、オフショア開発側が言われたことをするだけの単なる作業者となってしまい、本来のパフォーマンスが発揮できないこともあります。
会社や国は違えど、本当の意味での「ワンチーム」を実現するため、「なぜ作るのか」という点から共有し、定期的に再認識してもらうことでより良いソフトウェアの開発に繋がります。
5.結論
日本語人材の必要性は、開発プロジェクトの特性、予算、そして発注元の対応能力によってグラデーションがあると言えます。
そして日本語人材を入れたから大丈夫ではなく、相手が日本にいる日本人ではないことを認識したうえで、既に述べてきたどうしたら齟齬の発生が防げるのかという点で配慮・工夫したコミュニケションを取ることが、オフショア開発の成功に繋がると考えられます。
