ベトナムのチームとのコミュニケーションとフィードバックをマスターする「イエス・パラドックス」

オフショアのベトナムのソフトウェア開発チームを管理したことがあるなら、「イエス・パラドックス」に遭遇したことがあるかもしれません。複雑な機能を金曜日までに納品できるかどうかを開発者に尋ねると、彼らは笑顔でうなずき「はい」と答えます。金曜日になり、機能は欠落し、あなたは正直さか能力に問題があったのかと疑問に思うことになります。

シリコンバレーの製品サイクルと東南アジアのエンジニアリングハブの両方に精通している私は、どちらでもないと断言できます。あなたが遭遇したのは、「メンツを守る」（giữ thể diện）として知られる洗練された文化的アルゴリズムでした。グローバルITのハイステークスな世界では、このパラドックスを理解することが、プロジェクトが拡大するか、停滞するかの違いです。

「イエス」の解読：ハイコンテクストとローコンテクスト

オフショアITチームを効果的に管理するには、人類学者のエドワード・T・ホールによるハイコンテクスト文化とローコンテクスト文化の研究を理解する必要があります。西洋文化（米国、オーストラリア、ドイツ）は「ローコンテクスト」です。私たちは明確な口頭指示を優先します。私たちは自分の言いたいことを正確に言います。

ベトナムは「ハイコンテクスト」文化です。コミュニケーションは多層的です。「はい」は、多くの場合、「そのタスクが金曜日までに技術的に実行可能であることに同意します」という意味ではありません。それはしばしば、以下を意味します。

• 「承知しました」
   

• 「リーダーとしてのあなたの権威を尊重します」
   

• 「この会議での調和を保ちたい」

このフレームワークでは、公の場で「いいえ」と言うことは、開発者（無能に見える）とマネージャー（不合理な要求をしたように見える）の両方にとって「メンツを失う」ことと見なされます。このアウトソーシングにおけるコミュニケーションのギャップを埋めるには、何をお願いするかだけでなく、どのように尋ねるかを変える必要があります。

「何」から「どのように」へ：三つのルール

「イエス・パラドックス」を回避するために私が実装した最も効果的な戦略の1つは、三つのルールです。「これできますか？」という二元的な質問をする代わりに、3つの異なる実行パスを求めます。

例：「これが可能かどうかを教えてもらうのではなく、このアーキテクチャにアプローチできる3つの方法を教えてもらえますか？1つは「高速」な方法、1つは「スケーラブル」な方法、もう1つは「理想的」な方法です。」

「はい/いいえ」の二元論から、複数の選択肢がある技術的な議論に焦点を移すことで、「メンツを守る」という社会的圧力を取り除きます。開発者に、リスクを「トレードオフを評価する」という口実の下で強調する心理的安全性を与えます。これは、ベトナムのアジャイルに完全に合致しており、その目的は、正直な技術的フィードバックに基づいた迅速な反復です。

コードレビューにおける心理的安全性の確保

多くのベトナムの教育システムでは、階層が厳格に尊重されています。これは、若い開発者が上司のコードの欠陥を指摘することをためらう「年功序列バイアス」につながる可能性があります。現代のIT労働力では、これは技術的負債の温床です。

これを解決するために、プロのチームは非同期かつ匿名のフィードバックループを採用しています。GitHubのプルリクエストシステムのようなツールは、ここで非常に役立ちます。フィードバックが口頭ではなく書面で、そして「人への批判」ではなく「コードのレビュー」として構成されると、直接的なコミュニケーションに対する文化的障壁は消滅します。

専門家による洞察：「公で褒め、個人的に修正する」というルールを使用してください。厳しいフィードバックを伝えなければならない場合は、1対1の状況で行ってください。10人のいるZoom会議で開発者を公に修正すると、彼らは自分の社会的地位を守るために「シャットダウン」することになります。

よくある質問（FAQ）

「イエス・パラドックス」は、チームの締め切りを信用できないという意味ですか？

全く違います。それは、「はい」をデータで検証する必要があるという意味です。Jiraのバーンダウンチャートと自動化されたスプリントレポートを「真実の情報源」として使用します。データによるとタスクが遅れているのに、開発者が「はい」と言った場合は、データを中立的な第三者として会話を開始するために使用します：「チャートは私たちが40％にいることを示していますが、これをどのようにブロック解除できますか？」

ベトナム人開発者が会議で発言することをどのように奨励すればよいですか？

会議を構造化します。「質問がある人はいませんか？」と尋ねる代わりに、特定の技術的インプットのために個人を名前で呼びます：「Longさん、APIでのあなたの仕事に基づいて、ここで最大の危険性は何だと思いますか？」 開発者に明示的に「発言の機会」を与えることで、知識を共有することは「邪魔をする」行為ではなく、彼らの責任となります。

英語力は、これらのコミュニケーションギャップの根本原因ですか？

めったにありません。ベトナムの英語力は着実に向上していますが、「イエス・パラドックス」は流暢な話者の間でも存在します。これは言語的なものではなく、社会的なオペレーティングシステムです。語彙だけでなく、フィードバックのプロセスに焦点を当ててください。

締め切りに間に合わなかった場合は、どのように対処するのが最善ですか？

「非難の言葉」を避けてください。「なぜ遅れていることを教えてくれなかったのか？」の代わりに、「タイムラインが変更されました。予想以上に時間がかかった技術的な依存関係は何でしたか？」を使用してください。これにより、個人的な弁明ではなく、技術的な事後分析が促されます。

結論：イノベーションパートナーへの移行

ベトナムのコミュニケーションのニュアンスをマスターすると、あなたのチームは「実行者」ではなくなり、イノベーションパートナーになります。心理的安全性の文化を創造し、適切な管理フレームワークを使用することで、ここで議論した「数学的DNA」の全力を解き放ちます。