オフショア開発のコミュニケーション対策5つ

01はじめに｜この記事でわかること

要点：オフショア開発のコミュニケーションでつまずく場面を整理し、発注する側が明日から動かせる対策を5つご紹介します。そもそもの仕組みからご確認でしたら、先にオフショア開発の基本をお読みください。

「言葉が通じないから、うまくいかないのではないか」。オフショア開発を検討されている方から、いちばん多くいただくご心配です。

ただ、案件が止まる場面を並べてみると、原因が語学だったことはほとんどありません。止まっているのは、たいてい日本側です。質問が来たのに答える人が決まっていない、決めたはずのことが翌週ひっくり返る。どれも日本語だけで進めていても起きることです。

そこでこの記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、ベトナムのチームと案件を動かしてきた立場から、対策を仕組みの側から整理します。読み終えるころには、「うちはどこが詰まっているのか」が言えるようになります。

まずは全体像を、動画で押さえておきましょう。

02コミュニケーションの問題は「言葉」ではありません

要点：オフショア開発でコミュニケーションが問題になるとき、実際に起きているのは「伝わらない」ではなく「決まらない」「戻らない」です。翻訳を厚くしても、決める人が空席のままなら止まります。ベトナムオフショア開発の体制を見るときも、まずここを確認してください。

日本語が達者なブリッジSEを立てても、案件が滞ることはあります。逆に、日本語がたどたどしいチームでも、驚くほど順調に進むことがあります。この差はどこから来るのでしょうか。

違いは、決める速さです。開発チームが手を止めるのは、質問の意味がわからなかったときではなく、質問への答えが返ってこないときです。相手は待つしかありませんから、その間の工数は空回りします。

ここを取り違えると、対策の方向が丸ごとずれます。通訳を増やす、翻訳ツールを入れる、異文化研修を受ける。どれも悪くはありませんが、決裁に2週間かかる会社では効きません。

開発チームが止まるのは、言葉がわからないときではなく、答えが返ってこないときです。

ですから、これからご紹介する5つは語学の話ではありません。誰が決めるか、何をもとに決めるか、決めた記録をどこに残すか。すべて日本側で今日から変えられます。

03つまずく場面と、その本当の原因

要点：よく挙がる原因（言語・時差・文化）と、現場で実際に起きていることはずれています。5つの典型的な場面を並べると、原因のほとんどが日本側の運用に寄っていることが見えてきます。詳しい失敗の形はオフショア開発の失敗事例でも扱っています。

案件が止まりやすい場面を5つに分け、表面上の理由と実際の原因を並べてみます。

5つのうち4つが、日本側の運用で説明できます。ベンダーを替えても直らない種類の問題です。

04対策1｜決める人を1人にして、権限を渡す

要点：開発チームからの質問に答える人を1人に決め、その場で決められる範囲をあらかじめ渡してください。窓口が2人以上いると、質問は必ず滞留します。窓口の役割についてはブリッジSEの役割もあわせてご覧ください。

これがいちばん効きます。そして、いちばん実行されません。

窓口の話をすると、多くの会社から「担当は決めています」と返ってきます。ただ、よく伺うとその担当者に決裁権がありません。質問のたびに部長へ相談し、部長は役員会を待つ。開発チームから見れば、答えが4日後に返ってくる相手です。

公的なガイドラインでも、同じ考え方が採られています。IPAのアジャイル開発版 情報システム・モデル取引・契約書では、発注側がプロダクトオーナーを選任し、そこへ権限を委譲できるかを契約前のチェック項目に挙げています。開発を止めないために、決める人を決めておく。契約書の設計思想がそうなっているということです。

具体的には、次の3点を先に紙に書いておくと機能します。

• その場で決めていい金額の上限。追加工数3人日までは窓口の判断で進める、といった形です。
• 持ち帰る場合の返答期限。上限を超えた質問は何営業日以内に返すか、先に約束します。
• 窓口が不在のときの代理。出張や休暇の間、誰が同じ権限を持つかを名前で決めます。

この3行があるだけで、滞留は目に見えて減ります。逆にこれがないと、体制図に何人並んでいても窓口は空席のままです。

05対策2｜言葉ではなく、画面と数字で渡す

要点：仕様を文章で書くほど、解釈の幅が広がります。判定できる数字と、指させる画面に置き換えてください。この考え方は国内案件でも同じで、要件定義の進め方の土台になります。

「具体的に書きましょう」という助言はよく見かけます。ただ、何をもって具体的と言えるのかまでは書かれていません。基準は1つで、その文だけで合否を判定できるかどうかです。

「一覧はサクサク動くように」「デザインはいい感じで」。この2文は判定できません。受け取った側は悪気なく自分の基準で作り、完成品を見た日本側が「思っていたのと違う」と言う。語学の話に見えて、日本語の時点で判定できなかっただけです。

置き換え方は単純です。次のように書き直してください。

• 速さは秒で。「サクサク」ではなく「1,000件の一覧を2秒以内に表示」。
• 見た目は既存画面で。「いい感じ」ではなく「既存の受注管理画面と同じ配置・配色」。
• 件数と桁は数字で。「たくさん」ではなく「同時利用50人、1日の登録3,000件」。
• 例外は具体例で。「エラー処理をきちんと」ではなく、実際の失敗データを1件添付します。

とくに効果的なのが実データの添付です。文章を100行書くより、実際の伝票を1枚見せるほうが認識のずれは減ります。品質面での効き方はオフショア開発の品質でも扱っています。

06対策3｜質問が止まっている時間を測る

要点：未回答の質問を1枚のリストにまとめ、経過日数を毎日見えるようにしてください。件数ではなく「いちばん古い質問が何日待っているか」を指標にすると、遅れの兆候が先に見えます。

開発の遅れは、ある日突然起きるものではありません。回答待ちの質問が少しずつ積もり、それが実装の待ち行列になって、数週間後に納期として表面化します。

ですから、見るべき数字は進捗率ではなく質問の滞留です。表計算1枚に、次の4列だけ作ってください。

1. 質問の内容。1行で足ります。長い説明は元のチャットへのリンクで十分です。
2. 誰の回答待ちか。会社名ではなく個人名で。ここが空欄の質問は必ず滞ります。
3. 質問が出た日。回答日ではなく、出た日を起点にします。
4. 経過日数。今日との差を自動計算にしておきます。

あわせて、質問の入口も1か所に絞ってください。チャットにも課題管理にもメールにも散っている状態では、リストを作っても書き漏れます。ツールを増やすより、まず寄せるほうが効きます。

そのうえで、朝いちばんに最古の1件だけ見ます。3日を超えたら、その日のうちに片づける。これだけで後半のドタバタはかなり減ります。見積もりから納品までの進め方のなかでも、滞留の管理は開発期間ずっと続く作業です。

07回答待ちの長さと、手直し工数の関係

要点：回答が遅れるほど、あとの手直しは増えます。開発チームは待てないので、仮の解釈で実装を進めるからです。待ち日数が2〜3日を超えたあたりから、手直し工数の伸び方が変わります。

回答待ちが怖いのは、その間も開発が完全には止まらないからです。多くの場合、チームは「たぶんこういう意味だろう」と仮置きして先へ進みます。あとで解釈が違えば、その分がまるごと作り直しになります。

当日中と6営業日以上では、手直しの重さがまるで違います。3日を境に色を変えているのは、ここが実務上の分かれ目だからです。

工数の考え方はシステム開発の見積もりの見方と同じで、人日が積み上がれば費用に直結します。回答の速さは、そのまま予算の話でもあります。

08対策4｜定例会議を「報告」から「判断」に変える

要点：週次の定例から報告を外し、判断だけを議題にしてください。進捗の共有は事前に文書で済ませ、会議の時間は決めることに使います。動くものを画面で見る時間も、必ず確保します。

週1回の定例を開いているのに手応えがない、というご相談をよくいただきます。議事録を拝見すると、たいてい8割が報告です。「先週はこれを実装しました」「今週はここを進めます」。聞いて終わりの情報が並んでいます。

報告は、会議の前に読める形で渡してもらえば足ります。会議の時間は次の3つに絞ってください。

• 動くものを見る。資料ではなく実際の画面を共有してもらいます。触れる状態が理想です。
• 未回答の質問を片づける。対策3のリストを開き、古いものから順に決めます。
• 次の2週間で決めることを確認する。日本側が用意するものを、名前つきで割り当てます。

この形にすると会議は短くなります。60分が30分になった例は珍しくありません。それでいて決まる量は増えます。目的が「知る」から「決める」に変わるからです。長期で同じチームと組むラボ型開発では、この定例の質がそのまま成果に響きます。

09日本時間の何時なら、その日のうちに返るか

要点：ベトナムと日本の時差は2時間です。日本時間の午前10時から午後4時台に投げた質問は当日中に返りやすく、夕方以降は翌日回しになります。送る時間帯を変えるだけで、待ち時間は縮みます。

時差はよく問題に挙げられますが、ベトナムとの2時間はむしろ扱いやすい部類です。問題は時差そのものではなく、送る時間帯を意識していないことにあります。

読み方はかんたんです。重い判断を要する質問は午前中に、軽い共有は夕方へ回す。それだけで待ち日数の平均は縮みます。夕方にまとめて質問を投げる習慣がある会社は、毎回1日を捨てていることになります。国内委託との違いはニアショアとオフショアの比較でも整理しています。

10対策5｜議事録ではなく、決定ログを残す

要点：会話の記録ではなく、決まったことだけを1枚に積み上げてください。日付・決めた内容・決めた人・根拠の4つがあれば十分です。検収の場での「言った言わない」は、ここでほぼ防げます。

議事録は、あとから読み返されません。長すぎるからです。半年前の判断を確認したい人が、90分の会話記録を最後まで読むことはまずありません。代わりに残すのが決定ログで、1行1決定、次の4項目だけ書きます。

• 日付。いつ決めたかがわかれば、前後関係をたどれます。
• 決めた内容。「検索は部分一致にする」のように1文で言い切ります。
• 決めた人。会社名ではなく個人名で。責任の所在ではなく、確認先として使います。
• 根拠。「現場の入力ミスが多いため」など理由を一言。後日の見直しが早く済みます。

この4列は、開発チームも書き込める場所に置いてください。日本側だけが管理するファイルにすると、相手が書けず更新が止まります。

覆りやすい決定の代表は、追加費用が絡むものです。契約上の扱いは、IPAの情報システム・モデル取引・契約書（第二版）が工程ごとの考え方を示していますので、契約前に目を通しておくと安心です。

11体制の違いで、決まるまでの日数はどう変わるか

要点：仕様変更が決まるまでの日数は、体制で3倍以上変わります。差を生むのは開発側の速さではなく、日本側の社内決裁です。窓口が案件ごとに分散している会社が、いちばん時間を使っています。

ここまでの対策がどれだけ効くのか、体制別に日数を分解します。開発チームから質問が出てから、正式に決定が伝わるまでの期間です。

注目したいのは右から2列目です。開発側とのやりとりはどの体制でも0.5〜2.5日ですが、社内決裁は1.5日から5.0日まで開きます。遅れの大部分は、日本の会議室で生まれています。会社選びの段階では、オフショア開発会社の選び方のうち日本人窓口の権限をとくに確認してください。

12直接指示のしすぎは、偽装請負の論点になります

要点：やりとりを密にするあまり、発注側が開発メンバー個々へ作業を直接指示すると、契約形態によっては偽装請負を指摘されるおそれがあります。指示は窓口を通し、記録を残す形にしてください。

ここは、コミュニケーションの記事であまり触れられない論点です。「密に話しましょう」という助言をそのまま実行すると、越えてはいけない線に近づくことがあります。

請負契約や準委任契約で外部に委託している場合、発注側が相手の従業員へ直接、日々の作業指示を出すと、労働者派遣に近い実態と見なされる可能性があります。厚生労働省は、この線引きについて労働者派遣事業と請負により行われる事業との区分に関する基準の疑義応答集を公開しています。

実務では、次の3つを守っておけば、まず問題になりません。

• 作業指示は窓口へ。個々の開発メンバーへ直接割り振らず、先方の責任者を通します。
• 伝えるのは目的と条件。「誰が何時間かけるか」ではなく「何を満たせば完成か」を伝えます。
• 勤務管理には踏み込まない。始業時刻や残業の指示、休暇の可否には関与しません。

この3つは、対策1の窓口設計とそのまま重なります。窓口を1人に決めるのは、速さのためだけでなく契約の健全さのためでもあります。

135つの対策を、来週から始める順番

要点：5つを同時に始める必要はありません。窓口の権限を決める、未回答リストを作る、定例の議題を変える、決定ログを始める、伝え方を数値に直す。この順で1週ずつ進めるのが現実的です。

コミュニケーション対策の始め方

すでに動いている案件でも、途中から導入できます。効果が早い順に並べました。

1. 窓口の権限を3行で決める。その場で決めていい金額の上限、持ち帰り時の返答期限、不在時の代理を書いて共有します。
2. 未回答リストを1枚作る。内容・回答待ちの個人名・質問日・経過日数の4列だけ。既存の質問を書き写して始めます。
3. 次の定例から議題を入れ替える。報告を事前配布に回し、会議は動くものの確認と未回答の処理に使います。
4. 決定ログを開始する。日付・内容・決めた人・根拠の4列を、開発チームも書き込める場所に置きます。
5. 次に渡す仕様から数値に直す。速さは秒、件数は数字、見た目は既存画面の指定に置き換えます。

1週間に1つずつでも、5週間でそろいます。過去の案件を振り返っても、最初の2つを入れた時点で滞留はかなり落ち着きます。

14まとめ｜決まる速さが、品質を決めます

要点：オフショア開発のコミュニケーション対策は、語学ではなく意思決定の設計です。決める人を1人にし、判定できる形で渡し、滞留を測り、会議を判断の場に変え、決定を記録する。この5つで、多くの問題は起きなくなります。

ご紹介した5つは、どれも特別な道具を必要としません。表計算1枚と、社内で決めた3行のルールがあれば始められます。それでも効くのは、オフショア開発の遅れがほとんど日本側の待ち時間の積み重ねだからです。海外のチームは、指示が明確なら止まりません。

費用の全体像はオフショア開発の費用相場と国別の比較もご参考になります。

15よくある質問

要点：オフショア開発のコミュニケーションについて、ご相談の場でよくいただく質問をまとめました。英語力の要否、担当者の負担、ツールの選び方などを扱っています。

1. 英語やベトナム語ができないと難しいですか

日本人窓口のある会社であれば、日本語だけで進められます。必要なのは語学より、社内で即答できる状態を作ることです。

2. 窓口の担当者は専任でないといけませんか

兼任でも問題ありません。ただし、日に一度は必ず未回答リストを見る時間を確保してください。専任かどうかより、確認の頻度が結果を左右します。

3. チャットツールは何を使うのがよいですか

先方がすでに使っているものに合わせるのが確実です。大切なのは種類より、質問の入口を1か所に絞ることです。

4. 定例会議は週1回で足りますか

要件定義の期間は週2回、実装が進んだら週1回が目安です。会議を増やすより、未回答の質問をその日のうちに片づけるほうが効きます。

5. すでに走っている案件でも、途中から変えられますか

変えられます。未回答リストは、今ある質問を書き写すだけで今日から始められます。窓口の権限も、社内で決めれば翌日から運用できます。