40ページの仕様書。その一行一行に従って開発したチーム。そしてデモの場で、お客様が静かにこう言います——「動くけど、これじゃない」。
誰も間違ったことはしていません。それでも両者は3週間を失いました。日本企業様と6年間ご一緒してきて分かったのは、日本向けオフショア開発で起きる問題の多くは、開発チームの技術力ではなく、正確な翻訳では埋まらない情報の隙間から生じるということです。
認識のずれは翻訳の問題ではない
言語だけが原因なら、優秀な通訳を入れれば解決します。しかし実際には、N1レベルの通訳がいてもずれる案件は少なくありません。業務要件において、書かれた文字は最上層にすぎないからです。その下には、記録されないままの3つの層があります。
- 書かれていない要件。「月次の売上レポート」と書かれていても、それが4月始まりの会計年度を指すことは自明の前提とされています。
- 業務の文脈。一見なんの変哲もない項目が、経理部門しか知らない承認フローを支えていることがあります。
- 暗黙の品質期待。4pxずれた画面は「細かい話」ではなく、チーム全体の丁寧さを示すシグナルとして受け取られます。
いずれも資料に書かれていないため、翻訳する対象がありません。誰かが適切な問いを立てたときにだけ、姿を現します。
よくある4つの原因
- 言葉は訳せても業務が分かっていない。お客様が曖昧な表現をされたとき、言語だけの通訳はその曖昧さをそのまま忠実に訳します。誠実ではありますが役に立たず、開発側が空白を自分で埋めてしまいます。BrSEはそこで立ち止まり、「優先度はどの項目で決まりますか」と確認します。
- 共通前提の上に書かれた資料。日本の仕様書は、業務フローや承認者を既に知っている「組織の中の読者」に向けて書かれます。オフショアチームにはその前提が一切ないため、同じ資料から二つの異なるシステムが読み取られます。
- 報告のリズムのずれ。日本の仕事の文化は報告・連絡・相談を重視します。異変があれば、解決策がなくてもすぐ報告する。1週間の沈黙は「順調」ではなく「制御できていない」と読まれます。
- 意思決定が複数の承認層を通る。小さく見える質問でも、稟議を通るのに1週間かかることがあります。対処法は、承認が必要な質問をまとめ、必要な時期より前に送り、待つ間は回答に依存しない部分を進めることです。
BrSEと通訳の違い
| プロジェクト通訳 | BrSE（ブリッジSE） | |
|---|---|---|
| 参加時期 | 会議が設定されたとき | 要件定義フェーズから |
| 成果物 | 翻訳された内容 | 明確化された仕様、結論のある議事録 |
| 要件が曖昧なとき | 曖昧さをそのまま伝える | 実装できる水準まで確認する |
| リスクに気づいたとき | 担当範囲外 | 警告し、代替案を提示する |
| 責任の対象 | 翻訳の正確さ | 両者が同じ理解に至ること |
要点は最後の行です。通訳の仕事は言葉が正確に伝わった時点で完了しますが、BrSEの仕事は両者が本当に同じ理解に至ったときにしか完了しません。
パートナーを見極める3つの質問
- 日本語で直接やり取りするのは誰で、その方に技術的な素養はありますか。「通訳がおります」という回答であれば、要件が誤解されたときの責任は誰が負うのかを続けて確認してください。
- 各会議の後、こちらは何を受け取れますか。良い回答は「結論と未決事項の一覧が記された議事録」です。
- メンバーが離任した場合、業務知識はどう引き継がれますか。
ラボ型がずれを減らす理由
3つ目の質問は、あまり語られない点を突いています。案件ごとに切れる進め方では、開始のたびに業務をゼロから学び直すことになります。ラボ型はまさにそこを解決します。固定メンバーがお客様の一部門のように稼働するため、業務知識がリセットされず蓄積されていきます。2年目にはコミュニケーションコストが下がりますが、それは日本語力が上がったからではなく、説明すべきことが減ったからです。
まとめ
日本向けオフショア開発がずれる原因が開発者の力量不足であることは、ほとんどありません。3つの層の情報が一方から他方へ渡らないことが原因です。そしてそれを運べるのは、業務を理解し、技術を理解し、日本語を話せる人だけです。
CONCRETEでは、BrSEチームが通訳を介さず日本のお客様と直接やり取りし、要件定義フェーズから参加します。東京のARCHIPELAGO Inc.のグループ会社として、日本人PMがベトナムのエンジニアチームと共に参画する体制も可能です。協業モデルをご覧いただくか、お問い合わせください。