コードレビューは「お茶会」！？ 日本人エンジニア、カルチャーショックの洗礼
（※ここから「起」の本文です）
どうも！海外の片隅で、今日もXAMLと格闘しております、C#とWPFが大好きな（たまに憎い）ITエンジニアです。
さて、このブログを読んでくれているってことは、あなたも「いつか海外でエンジニアとして働いてみたい！」とか、「今まさに準備中！」って感じの人、多いんじゃないでしょうか。
わかります、その気持ち。僕もそうでした。
日本にいた頃、毎晩のように技術書を読み漁りました。C#の最新機能（.NETのバージョンアップ、早すぎません？）、WPFのMVVMパターンの「正しい」実装、PrismやDI（Dependency Injection）のベストプラクティス。もちろん、AzureやAWSなんかのクラウド知識も詰め込んで。
そして、なにより「英語」ですよね。TOEICのスコアとにらめっこしたり、オンライン英会話で「I’d like to…」を連発したり。
「これだけやれば、まぁ何とかなるだろう」
「技術（スキル）は裏切らない。コードが俺たちの共通言語だ」
本気でそう思ってました。ええ、あの「洗礼」を受けるまでは。
海外で働き始めて数週間。時差ボケも抜け、ようやく環境にも慣れてきた頃。僕は初めての大きめな機能改修を任され、数日かけて「これぞ！」というプルリクエスト（PR）を投げました。
日本でやっていた頃の知識を総動員です。
WPFの画面（View）はXAMLでクリーンに。ロジックはViewModelにしっかり分離。Modelは疎結合を意識。もちろん、単体テスト（Unit Test）もビシッと書いて、「さあ、レビューしてくれ！」と。
日本では、コードレビューといえば「真剣勝負」でした。
先輩エンジニアから飛んでくる、厳しいツッコミ。「ここのパフォーマンス、考慮してる？」「この命名規則、規約違反じゃない？」「この書き方だと、後で拡張しにくいよ」。
時には（ちょっとだけ）凹むけど、それがコードの品質を上げ、自分を成長させてくれる。それが「正しい」レビューだと思っていました。
だから、僕も「かかってこい！」と身構えていたわけです。
ところが。
翌日設定されたレビューミーティング（というか、ただの集まり）で、僕は度肝を抜かれました。
シニアエンジニアのジョン（仮名）が、僕のPRを開きながら、まず口にしたのは、
「へい、このコーヒーメーカー、新しい豆入れたんだけど、試した？」
……は？
いや、今、僕の渾身のコードが映し出されてますけど？
周りのエンジニアも、マグカップ片手に「お、マジか」「後で淹れよ」なんて雑談してる。
え、何これ。お茶会？
ジョンはコードをざーっとスクロールしながら、「ふむ、いいね。クリーンだ」と一言。
そして、僕が一番悩んだXAMLの複雑なDataTriggerの部分も、一瞬見て「OK、ここ、ちょっとコメント（suggestion）しといたけど、どっちでもいいよ。君の判断に任せる（It’s up to you）」
……え？ どっちでもいい？
僕が「いや、でも、ここの実装はパフォーマンス的に…」と説明しようとすると、「ああ、大丈夫、大丈夫（No worries）。CI（継続的インテグレーション）通ってるし、テストもグリーンだろ？問題ないよ。それより、週末のBBQ、来る？」
……。
……。
これが、レビュー？
僕が日本で学んできた「品質へのこだわり」は、どこへ行ったんでしょう。
僕が書いたコードの「重箱の隅」は？ 命名規則のチェックは？
正直、最初は「こいつら、仕事する気あるのか？」と思いました。
「こんなザルなレビューしてるから、たまに妙なバグが残るんだ」と、ちょっとイラっとしたくらいです。
日本でWPFの設計（Design）から開発（Development）までやっていたプライドが、そう思わせました。
「俺のやり方の方が、絶対に正しい」と。
この「違和感」。
この「え、なんで？」という感覚。
これこそが、海外で働くエンジニアが最初にぶつかる、技術書にもTOEICの教科書にも載っていない、最強の壁なんです。
僕たちは、スキルや言語は「勉強」できても、現場に根付いた「文化」や「空気感」は、現地に来るまで知り得ません。
そして、その「文化」は、一見すると非合理的で、奇妙（Weird）で、間違っているようにさえ見えるんです。
コードレビューがお茶会になる。
厳密な仕様書がなくて、口頭の「こんな感じ」で開発がスタートする。
やたらと定時で帰るのに、なぜかプロジェクトは回っている。
「なんで、こんな『変な』やり方なんだ？」
あなたも、もし海外で働いたら、きっとそう思う日が来ます。
でもね。
このブログで僕が一番伝えたいのは、ここからです。
僕が「間違ってる」と思った、あの「お茶会レビュー」。
あの「奇妙なやり方（Our Weird）」が、実は、僕が日本で学んだどんな設計パターンよりも、このチームを強くしている「理由（Works）」だったんです。
このブログは、海外のIT現場で僕が見つけた「奇妙だけど、なぜか機能している（Weird Works）」な習慣や人生術を、僕自身の実体験（主に失敗談）ベースで解き明かしていくものです。
あなたがもし、技術力だけで海外に挑戦しようとしているなら、ちょっと待ってほしい。
その「完璧なコード」が、もしかしたら現地の「機能するチーム」を壊す原因になるかもしれないから。
今回は「起」として、僕が体験したカルチャーショックの序章をお話ししました。
次回、「承」では、なぜあの「お茶会レビュー」が機能していたのか、その「奇妙さ」の裏に隠された、驚くべき合理性について、深く掘り下げていきます。
これを知っておくだけで、あなたの海外エンジニアライフの「生存率」は、マジで跳ね上がるはずですよ。
なぜ彼らの「奇妙なやり方」は機能するのか？ “Weird”の裏にある合理性
（※ここから「承」の本文です）
前回の「起」では、僕が海外の現場で体験した「お茶会コードレビュー」という衝撃的なカルチャーショックについてお話ししました。
日本で「コードはこうあるべきだ」と叩き込まれてきた僕にとって、シニアエンジニアが僕の渾身のプルリクエスト（PR）を前に、コーヒーの豆の話や週末のBBQの話を優先する姿は、正直「怠慢」にしか見えませんでした。
「こんなレビューで、品質が保てるわけがない」
「俺のWPFのMVVM実装のこだわりを、誰も見てくれないのか！」
そんなフラストレーションで、最初の数週間はイライラしっぱなしでした。
「こいつら、全員シニア（笑）だろ」なんて、心の中で毒づいたりもして。
ですが、結論から言うと、間違っていたのは僕の方でした。
彼らのあの「奇妙な（Weird）」やり方。
一見、不真面目に見えるあの「お茶会」こそが、僕が日本で経験したどんな厳しいレビューよりも、はるかに高度な「チームビルディング」であり、最強の「生産性ハック」だったんです。
「は？ 何言ってるの？」と思いますよね。
僕も、その「カラクリ」に気づくまで、結構時間がかかりました。
きっかけは、皮肉にも、あのレビュー中に誘われた「週末のBBQ」でした。
気が進まないまま参加したBBQで、僕は衝撃の光景を見ます。
あのレビュー担当だったシニアのジョンが、自作の燻製機でプルドポークを振る舞いながら、ジュニアエンジニアのマーク（仮名）と、あるアーキテクチャについてめちゃくちゃ白熱した議論を交わしていたんです。
「君のあの実装、CIは通ってたけど、AzureのFunctionsとの連携部分、ステートレスの原則から外れてないか？」
「いや、ジョン。あそこは意図的にセッションを持たせてて…」
彼らは、ビールの缶を片手に、日本での僕らの「レビュー」なんかより、よっぽど本質的で、高度な技術議論を、笑いながらやっていたんです。
僕は気づきました。
彼らにとって、GitHub上のプルリクエスト（PR）のコメント欄や、会議室でのレビューミーティングは、「技術的な議論をする場所」ではなかったんです。
じゃあ、あの「お茶会レビュー」は一体何だったのか？
あれは、「仲間意識（Connection）」と「心理的安全性（Psychological Safety）」を確認するための「儀式」だったんです。
思い出してみてください。
日本で僕が受けてきたレビューは、「間違い探し」の側面が強かった。
「この書き方は規約違反」「ここは非効率」「ここはバグの温床」。
もちろん、それは品質のためです。でも、同時に何が起きていたか？
レビューされる側は、無意識に「怒られないように」「ツッコまれないように」と、**完璧なコード（に見えるもの）**を書こうと必死になる。
新しい技術や、ちょっと冒険的な実装（例えば、WPFで新しい描画方法を試すとか）を試すことに、臆病になるんです。
なぜなら、**「失敗」＝「レビューで吊るし上げられる」**という恐怖が、どこかにあるから。
でも、彼らのチームは違いました。
ジョンが僕のPRを見て、コーヒーの話をしたのは、「君のコードを攻撃しに来たんじゃないよ」というメッセージでした。
「クリーンだね」「CIも通ってる」とまず褒めたのは、「君の仕事（のアウトプット）は、まず承認（Approve）するよ」という信頼の証でした。
「どっちでもいいよ（It’s up to you）」と言ったのは、「このコードのオーナーは君だ。君の判断を尊重する」という**「権限移譲」**のサインでした。
彼らは、GitHubのコメント欄という「テキスト」でのコミュニケーションが、いかに冷たく、攻撃的になり得るかを、痛いほど知っていたんです。
だからこそ、あえて本質的な議論は、顔を合わせた雑談（お茶会）や、BBQのようなリラックスした場所で行う。
そして、日々の「お茶会レビュー」という名の「承認の儀式」を繰り返すことで、チーム内に圧倒的な「心理的安全性」を構築していました。
「何を書いても、まず受け止めてもらえる」
「CIとテストが通っていれば、細かいスタイルの違いは『個性』として尊重される」
「もし本当にヤバい設計ミスをしたら、ジョンがBBQの時にでも（笑いながら）指摘してくれる」
この信頼関係。
これこそが、彼らの「Weird Works」の正体でした。
この環境では、エンジニアは萎縮しません。
むしろ、「ジョンが『任せる』って言ったんだ。俺が責任持って、この機能を最高のものにしなきゃ」と、「やらされ仕事」から「当事者意識（Ownership）」へとマインドが変わるんです。
僕がこだわっていたWPFの「完璧なMVVMパターン」なんて、正直、チームの生産性から見たら些細なことでした。
それよりも、チーム全員が「失敗を恐れずに新しいコードを書ける」こと。
「重箱の隅をつつく」レビューに時間を浪費せず、「本質的な設計」の議論に時間を使うこと。
あの「お茶会レビュー」は、そのための、驚くほど合理的な「仕組み（ハック）」だったんです。
日本人の僕から見たら「奇妙（Weird）」なそのやり方が、なぜ彼らのチームを「機能（Works）」させていたのか。
その答えは、コードの「正しさ」ではなく、コードを書く「人間」の心理にありました。
この気付きは、僕のエンジニア人生を、文字通りひっくり返すことになります。
技術書だけでは絶対に学べない、海外で働くことの本当の意味。
次回、「転」では、この「心理的安全性」を学んだ僕が、逆に、日本で培った「完璧主義」ゆえに、チームで大きな失敗をやらかしてしまった話。そして、C#の「規約」よりも大切な「暗黙知」について、赤裸々にお話ししようと思います。
C#の「規約」より大切な、WPFチームの「暗黙知」
（※ここから「転」の本文です）
どうも！前回、「承」のパートでは、僕が「怠慢だ！」と憤慨していた「お茶会コードレビュー」が、実は「心理的安全性」と「仲間意識（Connection）」を醸成するための、超合理的な「儀式」だった、という話をしました。
「なるほど！このチームの “Weird Works”（奇妙なやり方）のキモは『性善説』と『信頼』なんだな！」
「細かいコード規約（Coding Standards）より、まず『承認』。本質的な議論はリラックスした場所で。OK、理解した！」
そう思った僕は、正直、ちょっと「わかった気」になっていました。
「ふっ、俺はもう、このチームのやり方をマスターしたぜ」と。
……ええ、見事にやらかしました。
これ、海外で働くエンジニアが100人いたら120人が通る道、「わかった気になって、盛大にコケる」の典型例です。
僕が体験した、C#エンジニアとしてのプライド（と、日本の完璧主義）が木っ端微塵に砕け散った「あの日」の話をします。
事件が起きたのは、あるスプリントの終盤。
リリースを数日後に控えたタイミングで、QA（品質保証）チームからクリティカルなバグ報告が上がってきました。
「特定の操作をすると、WPFアプリケーションのメイン画面がフリーズする」
最悪のやつです。
僕もアサインされ、チームでデバッグを開始。
原因は、すぐに割れました。アプリケーションの心臓部とも言える、巨大なViewModel（XAMLの裏にあるロジック担当ですね）にありました。
それは、長年の改修で「秘伝のタレ」と化した、ヤバいレガシーコードの塊でした。
コンストラクタで重い処理は走ってるわ、View（画面）への依存がベッタリだわ、お世辞にも「クリーンなMVVM」とは言えない代物です。
チームの空気は重い。
「うわぁ、ここかよ…」
「とりあえず、最小限の修正で乗り切れないか？」
みんながそう思っていました。
その時、僕の頭の中で、**「悪魔のささやき」**が聞こえたんです。
（……いや、待てよ）
（このViewModel、根本的におかしい）
（俺なら、俺のWPFの知識なら、この「腐った」部分を、”正しく”リファクタリングできるぞ）
（DI（Dependency Injection）をちゃんと使って、責務を分離して、非同期処理（async/await）もクリーンに書き直せる）
（ここで「最小限の修正」なんていう”妥協”をしたら、また同じバグが再発する。今こそ、俺の「技術力」を見せる時だ！）
そう。僕は、あの「お茶会レビュー」の意味を、致命的に誤解していたんです。
「細かいことは気にしない、性善説のチーム」＝「高品質なリファクタリングを歓迎してくれる」
そう、拡大解釈してしまった。
僕はシニアのジョンに言いました。
「ここ、根本的に直した方がいい。俺に2日くれ。完璧に直してみせる」
ジョンは一瞬、眉をひそめましたが、「…OK。でも、リリースは近いぞ。頼む（Just get it done, but be quick）」とだけ言いました。
ここが、運命の分かれ道でした。
僕は、日本でやってきた「職人エンジニア」モードに突入しました。
ヘッドフォンをつけ、エナジードリンクをキメて、「ゾーン」に入る。
デイリースタンドアップ（朝会）でも、「うん、リファクタリング中。順調」とだけ報告。
僕は、「コミュニケーション」を遮断したんです。
「お茶会レビュー」で学んだはずの「Connection（つながり）」を、自ら断ち切って、**「日本の完璧主義」という名の”洞窟”**に、一人で閉じこもりました。
そして2日後。
僕は、ドヤ顔で、超巨大なプルリクエスト（PR）を提出しました。
変更ファイル、30以上。
あの「秘伝のタレ」ViewModelは、美しいインタフェースに切り出され、複数の小さなクラスに分割され、完璧な単体テストが添えられていました。
我ながら、「C#のお手本」のようなコードでした。
「さあ、みんな！俺の仕事を見てくれ！」
……しかし。
僕が期待していた「賞賛」は、ありませんでした。
Slackでメンションを飛ばしても、反応が鈍い。
それどころか、他のメンバーが、僕のPRに対して「？？？」という顔文字や、「おいおい、これ、俺のタスクとコンフリクト（競合）しまくってるんだけど」という、非難めいたコメントを付け始めたんです。
慌てて僕を呼び出したジョンは、あの「お茶会」の時とは別人のような、厳しい顔をしていました。
「君は、何をやってくれたんだ？」
「え？ バグを直して、リファクタリングを…」
「頼むから、PRの差分（Diff）を見てくれ。君が直したかった『バグ』は、結局、どこだ？」
僕が30以上のファイルを指し示しながら説明しようとすると、ジョンはそれを手で制しました。
「バグは、この1行だろ？」
ジョンが指差したのは、古いコードの、たった1行のロジックミスでした。
「俺たちが欲しかったのは、この**『1行の修正』だ。今すぐに。
でも、君は『完璧なリファクタリング』という名の『爆弾』**を、リリース直前のチームに投げ込んだ」
僕は、言葉を失いました。
「君が『ゾーン』に入っている間、チームの全員がブロックされた。
君が『完璧』にしたせいで、他のメンバーは自分たちの変更をマージ（統合）できなくなった。QAも、君の修正待ちでテストが止まった。
これが、君の言う『完璧な仕事』か？」
……頭をガツンと殴られたような衝撃でした。
彼らの「Weird Works（奇妙なやり方）」は、「品質を軽視する」ことじゃなかった。
それは、**「チームの速度（Velocity）と予測可能性（Predictability）を、個人の『完璧さ』よりも優先する」**という、鉄の掟だったんです。
僕が守るべきだったのは、C#の「SOLID原則」や「クリーンなMVVMパターン」という**「明文化された規約」**ではありませんでした。
僕が守るべきだったのは、
「リリース前は、絶対に巨大な変更を入れるな」
「リファクタリングは、必ず事前にチーム全員と合意しろ」
「一人で洞窟にこもるな。常に進捗を透明化しろ」
という、**「暗黙知（Tacit Knowledge）」**だったんです。
僕が「正しい」と信じて疑わなかった、日本の現場で培った「完璧主義」と「職人気質」。
それが、この海外チームにおいては、**最も「悪」**とされる、「予測不可能なブロッカー」という最悪の振る舞いだった。
この「転」での大失敗が、僕のエンジニアとしての価値観を、根底から変えることになります。
「すごいコード」を書くエンジニアが偉いんじゃない。
**「チームを止めない」**エンジニアこそが、偉大なんだと。
次回、最終回「結」では、この大失敗から僕が学んだ、海外で「本当に」必要とされるエンジニアになるための人生術と、あの「Why Our Weird Works」の本当の結論について、お話ししたいと思います。
「完璧なコード」より「機能するチーム」を。海外で働くための人生術
（※ここから「結」の本文です）
どうも！長かったこのシリーズも、ついに最終回です。
「起」で、僕のプライドを刺激した「お茶会コードレビュー」というカルチャーショック。
「承」で、それが「心理的安全性」を守るための合理的な儀式だったという気付き。
そして「転」で、その気付きを「拡大解釈」した僕が、日本の「完璧主義」を振りかざし、リリース直前に「完璧なリファクタリング」という名の爆弾を投下。チームを停止させ、シニアエンジニアのジョンに本気で叱責された話。
…いやぁ、思い出すだけで胃が痛い（笑）
あの「転」での大失敗。
僕がドヤ顔で提出した、変更ファイル30以上の「美しい」プルリクエスト（PR）。
あれは、僕のエンジニア人生において、最も価値のない、最悪のコードでした。
なぜなら、そのコードは**「チーム（Team）」ではなく、「自分（I）」**のためだけに書かれた、ただの自己満足だったからです。
日本でWPFとC#の技術を磨き、MVVMの「正しさ」を追求してきた僕にとって、「すごいエンジニア」とは、「一人で完璧な実装ができるエンジニア」でした。
でも、あのチーム（そして、多くの海外の現場）で求められていた「すごいエンジニア」は、まったく違ったんです。
彼らにとっての「価値」とは：
- チームのベロシティ（開発速度）を止めないこと。
- 常に「予測可能（Predictable）」であること。
- コミュニケーションを密にし、「暗黙知」を共有すること。
僕がやったことは、この真逆でした。
リリース直前に、誰にも相談せず（＝予測不可能）、チームが依存するコアな部分を勝手にリファクタリングし（＝ベロシティを破壊）、一人で洞窟にこもって（＝コミュニケーション拒否）、チームをブロックした。
僕がどれだけ美しいC#コードを書こうが、どれだけWPFのアーキテクチャに精通していようが、チームにとって僕は「予測不可能なブロッカー」であり、**「害」**でしかなかったんです。
この失敗から、僕は「Why Our Weird Works（なぜ彼らの奇妙なやり方が機能するのか）」の、本当の答えを学びました。
彼らの「奇妙なやり方」――つまり、「お茶会レビュー」で雑談を優先したり、BBQで技術的な議論をしたり、リリース前は（たとえ汚いコードでも）最小限の修正を絶対厳守したりすること――。
それらはすべて、**過去の失敗から学んだ「知恵」**であり、チームの「心理的安全性」と「予測可能性」という、**最も重要な資産（アセット）を守るための「防衛システム」**だったんです。
きっと、昔いたんですよ。
僕みたいに「俺が完璧に直してやる！」と息巻いて、リリース直前に全部ぶっ壊したエンジニアが（笑）
彼らの「Weird（奇妙さ）」は、**「二度とあんな思い（＝チームの崩壊）をしないぞ」**という、血のにじむような教訓から生まれた、最強の「ローカル・ベストプラクティス」だったんです。
この経験は、僕の「人生術」になりました。
これから海外でエンジニアとして働きたい、あるいは今まさに壁にぶつかっているあなたに、僕が「知っててよかった」と心から思う、一番「得する情報」を共有します。
それは、**「あなたの『正しさ』は、現場の『邪魔』かもしれない」**と、常に疑うことです。
僕たちは、エンジニアとして技術書を読み、ベストプラクティスを学びます。C#のSOLID原則、WPFのクリーンなMVVM、DIコンテナの使い方…。それらは確かに「正しい」。
でも、それはあくまで「一般論」です。
現場には、その「一般論」よりも優先されるべき、**「ローカルルール（暗黙知）」**が必ず存在します。
- 「あの機能は、歴史的経緯で誰も触れない」
- 「あのシニアエンジニアは、コードの『美しさ』より『テストカバレッジ』を重視する」
- 「このチームでは、PRは『議論』のためじゃなく『承認』のためにある」
これらは、技術書には載っていません。
これこそが、僕らが学ぶべき「Weird Works」です。
じゃあ、どうやってその「暗黙知」を学ぶのか？
答えは、僕が「起」で馬鹿にしていた、あの「お茶会」と「雑談」の中に全部ありました。
技術（C#やWPF）は、「共通言語」なんかじゃありません。
あれは、最低限知っておくべき**「アルファベット」**です。
本当の「共通言語」は、
「週末のBBQ、楽しかったね」
「あのコーヒー豆、マジで美味かったよ」
という**「Connection（つながり）」から生まれる、「信頼」**です。
信頼関係がない相手からの「技術的な正論」は、ただの「マウンティング」か「攻撃」にしか聞こえません。
でも、BBQで一緒に肉を焼いた仲間（ジョン）からの「あそこの設計、こうした方がよくない？」は、**「愛のあるアドバイス」**として、素直に受け取れます。
海外のエンジニアとして成功するために本当に必要なのは、最新のフレームワークを追いかけること以上に、**「いかに早く、そのチームの『仲間』になり、『Weird』の裏にある『暗黙知』を盗めるか」**です。
だから、もしあなたが海外の現場に行ったら、まずやってほしいこと。
- 「ジャッジ」するな。「なんだこのコード」「非効率だ」と思う前に、まず「なぜ、彼らはこうしているんだろう？」と観察してください。その「Weird」には、あなたより賢い先人たちの「知恵」が詰まっています。
- 雑談にフルコミットしろ。ランチ、コーヒーブレイク、飲み会。それこそが「本番」です。そこで技術の話をする必要はありません。あなたの飼ってる猫の話でも、好きな映画の話でもいい。まず「接続（Connection）」してください。
- 「完璧な個人」より「機能するチーム」を選べ。あなたが書いた「完璧なコード」が、チームの足を引っ張っていませんか？ 常に「俺のこの仕事、チームを止めてないか？」と自問自答してください。それこそが、シニアエンジニアへの第一歩です。
僕のこの大失敗が、あなたのエンジニア人生の「ショートカット」になれば、こんなに嬉しいことはありません。
技術力でマウントを取る「すごいエンジニア」より、チームを円滑にする「愛されるエンジニア」を。
それこそが、海外で長く、楽しく働くための、最強の「人生術」なんだと、僕は信じています。
さて、あなたの職場やコミュニティにも、「外から見たら奇妙だけど、実はすごく機能している」というユニークな習慣（Weird Works）はありませんか？
「うちは、金曜3時は強制的にボードゲーム」とか、「バグを見つけたらお菓子を奢る」とか。
もしあれば、ぜひコメント欄で教えてください！ 他の人の「Weird」を知ることは、めちゃくちゃ勉強になります。
このブログが「知っててよかった！」「面白かった！」と思っていただけたら、ぜひ**「いいね」や「購読（Subscribe）」**をお願いします。
（そして、次の「リアルな失敗談」を見逃さないよう、通知ベルも鳴らしておいてくれると嬉しいです！）
最後まで読んでくれて、ありがとうございました！
コメント