「あ、それ、言わなくても分かりますよね？」
日本でC#のコードを書いていた頃、僕はよくこの感覚で仕事をしていました。仕様書の記述が少し曖昧でも、チーム全体の「空気」を読めば、クライアントが何を望んでいるか、上司がどの程度のクオリティを求めているか、なんとなく察することができた。それが「デキるエンジニア」の条件だと思っていた節すらあります。
でも、ベルリンのテック企業に飛び込んで、その価値観は一瞬で粉砕されました。
東京の「1」を聞いて「10」を知る文化の危うさ
東京での開発現場を思い返すと、コミュニケーションの多くが「行間」で行われていたことに気づきます。「このUI、いい感じにリファクタリングしておいて」と言われれば、今までのプロジェクトの傾向から、MVVMパターンのこの部分を修正し、XAMLのスタイルを共通化し、ユニットテストを追加する……という「期待値」を、阿吽の呼吸で察知していたわけです。
これを文化人類学の言葉では**「ハイコンテキスト（高文脈）文化」と呼びます。共有している背景情報が多いから、言葉にしなくても伝わる。効率的だし、調和も取れる。しかし、ここベルリン（あるいは多くの欧米の拠点）は、その対極にある「ローコンテキスト（低文脈）文化」**の総本山です。
ドイツ人の同僚や世界中から集まった多国籍なメンバーにとって、「いい感じに」なんて言葉は、コンパイルの通らない構文エラーと同じです。彼らが求めているのは、空気感ではなく、「Explicit（明示的）」な要件。それだけです。
ベルリンのエンジニアが突きつける「Why Not Explicit?」
ある時、WPFでの複雑なデータグリッドの実装を任されたときのことです。Jiraのチケットには、大まかな機能要件しか書かれていませんでした。僕は「まあ、これまでの設計の流れからして、こういう実装を求めているんだろうな」と勝手に解釈し、良かれと思ってパフォーマンス最適化のための仮想化ロジックを独自に組み込んでPR（プルリクエスト）を出したんです。
結果は、散々でした。
- 「なぜチケットに書いていない実装を追加したんだ？」
- 「このロジックが必要だという合意はどこにある？」
- 「もしこれが必要なら、なぜ事前にアーキテクチャの議論をしなかった？」
東京なら「気を利かせてくれてありがとう！」と言われるような行動が、ベルリンでは「予測不可能なノイズ」として扱われたんです。彼らにとって、チケットに書かれていないことは「存在しないこと」であり、勝手な解釈は「リスク」でしかない。この時、僕は痛感しました。ここでは「空気を読む」という高度なスキルは、単に**「要件を曖昧にするバグ」**として処理されるのだと。
「明文化の儀式」がもたらす驚きのスピード
最初は戸惑いました。「いちいち全部言葉にするなんて、なんて効率が悪いんだ」と。でも、しばらく働いてみて気づいたんです。実は、すべてを明文化する文化の方が、結果として開発スピードが安定することに。
ベルリンのエンジニアたちは、コードを書く前に「儀式」をします。
- このタスクのゴールは何か？
- どのクラスをどう変更するのか？
- 成功の定義（Definition of Done）は何か？
これらを徹底的にテキストで残し、合意を取ります。最初は「議論ばかりしてないで手を動かせよ」と思ったりもしましたが、いざコーディングが始まると、迷いがないから速い。そして、できたコードに対して「思っていたのと違う」という手戻りが、驚くほど少ないんです。
「行間」に頼る東京のスタイルは、全員が同じコンテキストを共有している間は最強です。しかし、一人が違う解釈をした瞬間に、プロジェクト全体が迷走し始めます。一方で、ローコンテキストなベルリンスタイルは、誰がいつチームに入ってきても、書かれた「言葉」さえ追えば正解に辿り着ける。この「情報の非対称性」を嫌う徹底した姿勢こそが、グローバルな開発チームを支えるOSのようなものなんだな、と今は理解しています。
沈黙は「同意」か「熟考」か：多国籍チームを揺るがす『サイレント・ミスクライシス』
エンジニアの仕事は、コードを書いている時間だけではありません。むしろ、設計の打ち合わせやレビューで「どう作るか」を議論している時間の方が、脳のリソースを食う。そこで発生するのが、コミュニケーションの**「デッドロック」**です。
日本の「沈黙」はリスペクト、ベルリンの「沈黙」は……
日本で会議に出ているとき、誰かが熱心に説明している間、僕たちは静かに聞きますよね。相槌を打つのも控えめに、相手の話を最後まで咀嚼しようとする。これは「あなたの話を真剣に聞いていますよ」というリスペクトの表現です。
でも、ここベルリンの多国籍チームでこれをやると、100%誤解されます。彼らにとって、議論の場での沈黙は**「完全に同意した（I totally agree）」か、あるいは「何も付加価値を提供できない（I have nothing to contribute）」**のどちらかと見なされるからです。
僕が今のチームに入って数ヶ月経った頃、WPFアプリケーションの新しいデータ通信レイヤーの設計会議がありました。リードエンジニアがMiroを使いながら、かなり複雑なReactive Extensions（Rx）を駆使したアーキテクチャを提案していました。
僕は正直、「お、これはかなり複雑だな。C#の標準的な async/await で組んだほうがメンテナンス性が高いんじゃないか？」と頭の中で検討していました。メリットとデメリットを天秤にかけていたからこそ、僕は静かに画面を見つめていました。
会議の最後に、リードが言いました。 「よし、誰も異論はないね？ このプランで行こう。サトシ、実装よろしく！」
僕は「えっ、ちょっと待って……」と思いましたが、もう会議は終了。彼らにとって、僕の沈黙は「完璧な設計ですね、異議なし！」というサインとして受け取られていたんです。
「Task.Delay」している間に「Return True」と判断される恐怖
これをエンジニア的なメタファーで言うなら、僕の中では**「熟考という重い非同期処理（Task.Delay）」が走っていただけなのに、周りからは「即座に承認フラグ（Return True）」**が返ってきたと判定されてしまったわけです。
結局、その実装は進みましたが、案の定、後からメンテナンス性の問題が噴出しました。そのときチームメイトに「なんであの時言わなかったんだ？」と聞かれ、「いや、あの時は考えていたんだ」と答えたら、こう返されました。
「考えているなら、『考えている』と言ってくれ。黙っていたら、君がいないのと同じだぞ」
多国籍チームにおいて、発言しない人間は「議論に参加していない」と見なされます。「空気を読んで、後で個別に話せばいいや」なんていう日本的な配慮は、チーム全体の意思決定プロセスを歪ませるバグでしかないんです。
「サイレント・ミスクライシス」を回避する技術
じゃあ、英語が完璧じゃない僕たちが、爆速で進む議論の中でどうやって「沈黙の誤解」を防げばいいのか。
- 「考えるための時間」を予約する 「It’s a complex topic. Let me think for a minute.（複雑なトピックだね。1分考えさせて）」これだけでOKです。これさえ言えば、あなたの沈黙は「合意」ではなく「プロフェッショナルとしての精査」に変わります。
- 独り言を「実況中継」する 「I’m thinking about the trade-off between performance and maintainability…」結論が出ていなくても、思考の過程をダンプする。これによって、周りはあなたの脳内コンテキストにアクセスできるようになります。
- チャットを活用する 会議中に口頭で割り込むのが難しいなら、ZoomやTeamsのチャット欄に一言投げておく。これで、あなたの存在は議論に刻まれます。
「沈黙は金」ということわざがありますが、海外のエンジニアリングの現場では「沈黙はリスク」です。C#でいうところの進捗報告（IProgress）を出すような感覚で、こまめに自分のステータスを言葉にして外に出す。これが、文化のギャップによってプロジェクトが炎上するのを防ぐ、唯一にして最強の防御策になります。
PRレビューが止まる本当の理由：曖昧な指示が招くデプロイ速度の致命的低下
「文化の違い」という理論が、いかにして「プロジェクトの遅延」という牙を剥くのか。PR（プルリクエスト）のレビューサイクルやデプロイの速度をじわじわと蝕んでいく実態について深掘りしましょう。
「意図の推測」を許さないPRレビュー
日本での開発を思い返すと、PRの説明が多少短くても、「まあ、今のスプリントの文脈からして、この修正はあのバグ対応だろうな」と、レビュアーが「忖度」して読み取ってくれることがよくありました。しかし、こちらでは違います。
僕がベルリンに来て間もない頃、WPFのカスタムコントロールのスタイルを一部修正するPRを出しました。説明欄には一言、”Fixing UI glitch in DataGrid.” とだけ書きました。前日のミーティングで話題になった「特定の解像度で線が消える問題」のことだと分かっていたからです。
ところが、返ってきたのは大量の疑問符でした。
- 「どのチケットに関連しているんだ？」
- 「Before/Afterのスクリーンショットは？」
- 「なぜこのプロパティを書き換えた？ 他のViewへの影響は検証したのか？」
彼らにとって、説明のないコードは「意図不明のノイズ」です。僕が「空気を読んで分かってくれるだろう」と省略した行間は、彼らにとっては**「埋めるべき巨大な穴」**として映り、その穴を埋めるための質疑応答だけで丸一日が潰れてしまったんです。
PRの「ピンポン」がデプロイ速度を殺す
このコンテキスト・ギャップが最も恐ろしいのは、**「コミュニケーションの往復（ピンポン）」**を爆発的に増やしてしまうことです。
- 僕：PRを出す（説明が不十分）。
- レビュアー：「これ何？」とコメント。
- 僕：6時間後に返信。「あ、あれのことだよ」。
- レビュアー：「なるほど。でも、それならこの実装は不適切じゃないか？」と再コメント。
この一往復ごとに、デプロイまでの時間は24時間単位で遅れていきます。日本国内で机を並べていれば数分で済む「阿吽の呼吸」が、国境を越えた瞬間に「致命的な遅延」へと姿を変えるわけです。情報の同期コストでプロジェクトが窒息してしまう。
「察する」エンジニアが招くオーバーエンジニアリング
指示が曖昧なとき、日本のエンジニアは「きっと将来的にこういう拡張も必要になるだろうから、汎用的に作っておこう」と気を利かせがちです。これがハイコンテキスト文化における「加点対象」だからです。
しかし、明示的な要件を重視するベルリンのチームでは、これは**YAGNI（You Ain’t Gonna Need It）**の対象になります。「なぜ聞かれてもいない拡張性を持たせたんだ？」「その分のテスト工数は誰が払うんだ？」——良かれと思ってやった「行間を埋める行為」が、結果として「無駄な作業」と見なされ、さらにPRの差し戻しを増やす。
結局のところ、「空気」という不確かなものに頼って開発を進めることは、不確定要素をリポジトリにコミットしているのと同じなんです。
『エクスプリシット（明示的）』なエンジニアであれ：世界のどこでも通用する最強の生存戦略
「じゃあ、僕たちはもう『日本人らしさ』を捨てて、マシンのようにすべてを言葉にする欧米人になりきるしかないの？」
答えはNOです。実は、ハイコンテキストな文化で育った僕たちだからこそ、ローコンテキストな環境に「最強のスパイス」を加えられる方法があります。それは、「日本的な気遣い（Context-awareness）」を、「欧米的な明示（Explicit Communication）」の形に変換して出力することです。
ベルリンで数々の炎上を乗り越えてたどり着いた、3つの生存戦略を共有します。
1. 「書かれていないこと」を「質問」に変える技術
日本的な「察する能力」は、実は**「バグの予兆を見つける能力」**に変換できます。 仕様書を読んで「ここ、多分こういうケースで困るよな……」と察したとき、日本では黙ってそのケースも考慮して実装していましたが、海外ではそれを「質問」としてチケットに投げてください。
「この要件には書かれていないけれど、例外系として○○が起きた時の挙動はどうしますか？ A案とB案があると思います」
こうして言語化することで、あなたの「察する力」は、チーム全体にメリットをもたらす**「明示的なリスク管理能力」**へと昇華されます。
2. 「確認のコスト」を「信頼の貯金」と考える
海外で働いていると、英語が不自由なこともあって「何度も聞き返すのは申し訳ないな」と沈黙を選んでしまいがちです。でも、これは逆効果。
「Do I understand correctly that…?（私の理解は〜で合っていますか？）」 「Just to be clear, our goal is…（念のため確認ですが、我々のゴールは〜ですよね？）」
この一言を挟むだけで、後の手戻りが10時間、20時間と減るんです。何度も確認するエンジニアは、海外では「慎重で責任感があるプロ」として信頼されます。
3. 「意図」のログを資産にする
PRの説明、ADR（設計決定記録）、コードコメント……これらを**「他者が自分の脳内を同期するためのAPI」**だと思って充実させてください。
特に、C# / WPFのように、ViewとViewModel、データバインディング、非同期処理が複雑に絡み合う開発では、あなたの「なぜ（Why）」という説明こそが、時差を超え、国境を超えて仲間を助けるガイドになります。
最後に：エンジニアリングは「対話」である
「コンテキスト・ギャップ」は、決して敵ではありません。それは、異なる背景を持つ人間が集まって、一つの目標に向かう過程で必ず発生する「仕様」です。
もし君が、日本での「察する美徳」を持ちながら、海外での「明示する文化」を身につけたなら、それは世界中のどの企業も欲しがる**「ハイブリッドな最強エンジニア」**になったということです。
ベルリンの空の下、僕も毎日「あ、また言葉足らずだったな」と反省しつつ、キーボードを叩いています。君がいつか、海外のどこのチームでも「お前の説明、最高に分かりやすいよ！」と言われる日が来ることを、心から応援しています。
Happy Coding, and be Explicit!
コメント