私がベトナムに来た2012年頃、まだGoogleマップがありませんでした。いや厳密にいうとあったんですけど、まだ使い物にならなかった頃です。
ベトナムではまだ3Gもなかなか繋がらない、iPhoneでいうとiPhone4とかの時代で、地図を持っていても、そもそもベトナム人は地図を使わない。そういう状況の中で使っていたのが、「通り名＋番地」という方法でした。
所在地は、通りの名前と番地を手がかりに進んでいく仕組みです。大通りから細い路地（ヘムといいます）に入り込み、さらに奥へと曲がりながら目的地に近づいていく。番地を追いながら、たまに行き詰まったら誰かに聞く。その繰り返しで、なんとかたどり着く。
そのころにスタッフに教えてもらった言葉があります。
「Đường đi ở miệng（ドゥオン・ディ・オー・ミエン）」
直訳すると「道は口の中にある」。地図は紙の上にあるのではなく、人の中にある。だからとりあえず近くまで行って迷ったら人に聞けばいい、という考え方です。
みんなが、教えてくれる
実際に生活してみると、この言葉の意味がよくわかりました。
ベトナムで道を聞くと、本当によく教えてくれます。忙しそうにしている人も立ち止まって考えてくれる。「私もわからない」と言った人のすぐ横にいた別の誰かが、突然割り込んできて教えてくれることもある。困っている人を放っておかない、という感覚が、自然に根付いているように見えました。
日本にはない種類の温かさで、ベトナムに来たばかりのころはこれがとてもうれしかった記憶があります。
ただ、一つだけ困ることがありました。
その地図は、時々間違っているのです。
「左に曲がってまっすぐ行けばある」と言われた方向に進んだら、全然違う場所だった。「近くにある」と言われたのに、歩いて30分の場所だったりする。そういうことが、何度もありました。
善意の形が、違う
最初の頃、僕は「知らないなら、知らないと言ってくれればいいのに」と思っていました。正確に答えられないなら黙っている。それが相手への誠実さだ、と。
でもこれは、僕の中の「親切」を勝手に基準にしていただけでした。
道を聞かれた人は、困っている相手を放っておけなかった。正確かどうかより、まず目の前の人に向き合う。それが彼らにとっての誠実さです。
僕にとっての親切は「正しい情報を渡すこと」。彼らにとっての親切は「あなたを一人にしないこと」。
どちらかが正しいわけじゃありません。ただ、僕は自分の善意の形を、世界の標準だと思い込んでいた。気づいたのは、それだけのことでした。
そう思えてから、道を間違えても腹が立たなくなりました。
オフショア開発でも、同じことが起きる
たとえば、日本のチームで「来週までに、いい感じで仕上げて」と頼んだとします。
たぶん、それで通じます。締め切りも、求められる品質も、だいたい揃う。ほとんど何も指定していないのに、相手の頭の中に同じ絵が浮かんでいる。
これ、よく考えるとすごいことなんですよね。
僕がホーチミンで働き始めて気づいたのは、これが世界では当たり前じゃない、ということでした。むしろ日本のほうが特殊なんです。
「言わなくてもわかる」「空気を読む」「行間を察する」。日本人同士なら自然にできるこのやり方は、世界の中ではかなりの少数派です。多くの国では、共有されていない前提は、最初から存在しないのと同じ。書いていないことは、伝わっていない。
最初の頃、僕はこれを「相手が察してくれない」と感じていました。でも、逆だったんです。察し合う文化のほうが、世界から見れば珍しい。日本の常識を世界の標準だと思い込んでいたのは、僕のほうでした。
ここまでは、海外と仕事をしたことがある人なら「それ、知ってる」という話かもしれません。
問題は、知っていても繰り返されることです。
仕様書を細かくした。チケットを詳細に切った。確認の頻度を上げた。それでもまた同じことが起きる。「なんでまたか」という場面が、何年経っても出てくる。
なぜか。
たぶん対策が「伝え方」に向いているからだと思う。言語化する、確認する、コミュニケーションを増やす。でも問題はそこじゃなくて、「書いていないことが起きたとき」にある。
日本の仕様書には行間があります。「この状態なら当然エラーにする」「この順番で動くのは当たり前」。書かれていないのに、全員の頭に同じ前提が入っている。でもこれも、同じ文化を共有している人同士だから成り立つこと。前提を持たない相手と仕事をした瞬間、その行間はまるごと消えます。残るのは、書いた文字だけ。
問題の上げ方も同じです。日本では早めに上げることが信頼の行動。ベトナムの現場では「自分たちで解決できないことをクライアントに上げる」という行為に違う重みがかかることがある。プロとして自分たちで先に解決しようとする、その誠実さが、問題を水面下で育てることになる。
悪意じゃないんですよね。プロとしての振る舞いの定義が、違う。
「前提を揃えればいい」は、もうみんな知っている。でも機能しないのは、それを「コミュニケーションの話」として扱っているからだと思っていて。本当は「判断の構造の話」なんですよね。ITチームでよくある5つのコミュニケーション失敗でも、この「判断基準のすれ違い」が何度も登場します。
地図だけでは、目的地に着かない
仕様書は地図です。チケットは道順です。
でも地図が詳細でも、想定外は必ず出てくる。例外が起きる。状況が変わる。判断が必要な場面が来る。
そのとき「誰が決めるか」「何を基準に動くか」が揃っていると、現場は自分で動ける。揃っていないと止まる。あるいは勝手に動いて、後から直すことになる。
僕がずっと大事にしてきたのは、そこです。
「完了」の定義を最初に揃える。受入基準を言語化する。「誰かの頭の中にある当たり前」を、全員が参照できる形にする。それをコミュニケーションで解こうとするから同じことが繰り返される。最初から設計の話として扱う、というのが出発点です。
自分たちの開発体制にそれがあるかどうか、一度確認してみてください。
AIの時代だからこそ
Googleマップが普及して、道を聞く場面は大幅に減りました。今や知識の多くはAIの中にある時代でもあります。
「地図は口の中にある」という文化は、これからも変わっていくでしょう。でも仕事の現場では、変わらない問題が残り続けていると感じます。
相手と同じ前提に立てているかどうか、です。
AIによって情報格差はどんどん縮まっています。でも前提の格差は、自分たちで設計するしか縮まらない。ここは自動化できない部分です。
ベトナムで道を聞くと、みんな親切に教えてくれます。その地図は、時々間違っています。でも僕は、それを笑うことができません。そこには、困っている人を助けようとする善意があるからです。
異文化コミュニケーションで本当に難しいのは、相手の誠実さを疑うことではありません。善意の形が自分たちと違うと理解することです。
オフショア開発も、海外進出も、最後はここに行き着きます。
正しい地図を作ること。そして、同じ地図を見ているかを確認すること。
リノエッジは、単に日本語が通じる開発会社を目指しているわけではありません。日本とベトナムの間にある「前提の違い」を見つけて、整えていく。ベトナムで14年以上仕事をしながら積み上げてきたのは、そういうことです。
地図は口の中にある。でも、その地図は時々間違っている。だからこそ最初に、「どんな地図を使うか」を揃えることから始めます。
よくある質問
ベトナムのオフショア開発で認識のズレが起きるのはなぜですか？
多くの場合、語学力や技術力ではなく「言わなくても伝わる」という前提の違いが原因です。日本の開発では仕様書の行間を全員が共有していますが、これは世界では少数派。前提を共有しない相手と組んだ瞬間、行間は消え、想定外の場面で判断が分かれます。直すべきは伝え方ではなく、判断の基準を最初に設計することです。
仕様書を詳しく書いても、なぜ伝わらないのですか？
仕様書を厚くしても解決しないのは、問題が「書いてあること」ではなく「書いていないことが起きたとき」に発生するからです。日本の仕様書には文化的な行間があり、それは同じ前提を持つ人にしか伝わりません。大切なのは、想定外の場面で「誰が・何を基準に決めるか」を最初に決めておくことです。
オフショア開発で認識のズレを防ぐ最初の一歩は？
「完了」の定義と受入基準を、作業を始める前に全員が見える形で言語化することです。コミュニケーションを増やすより、判断の基準をそろえるほうが効きます。まずは自社の開発体制に前提のズレがないか、セルフチェックで確認してみてください。
東京とベトナムの二拠点で、ITオフショア開発・海外進出支援事業を展開。「気合いより仕組み」を信条に、不透明になりがちな越境ビジネスを構造化する経営者。「個人のスキル」ではなく「再現性のある品質」を組織と顧客へ提供することにコミットしています。