「赤ペン先生」の恐怖——なぜPRのコメント通知に、僕たちは身構えてしまうのか？
こんにちは！ 海外のとある都市で、今日も今日とてVisual Studioと睨めっこしているITエンジニアです。こっちは朝のコーヒーが美味い季節になってきました。
さて、普段僕はC#やWPFを使って、デスクトップアプリの設計・開発をバリバリやっているわけですが……今日はちょっと「コード」そのものよりも、もっとドロドロした（？）、でもエンジニアなら避けて通れない話をしようと思います。
みなさん、「コードレビュー」、好きですか？
正直に言っちゃいましょう。僕は日本にいた頃、これが大の苦手でした。
一生懸命書いたコードをPull Request（PR）に出した瞬間、Slackに飛んでくる通知。「〇〇さんがコメントしました」。
あの瞬間、心拍数が上がりませんか？ GitHubを開くと、そこには真っ赤なDiff（差分）と共に、ズラリと並ぶコメントの嵐。
- 「ここ、nullチェック抜けてます」
- 「MVVMの責務分離が甘いです」
- 「このLINQ、パフォーマンス悪くないですか？」
画面が赤く染まるたびに、まるで自分の人格まで否定されているような、学校でテストの答案用紙に赤ペンでバツをつけられているような……そんな「恐怖」に近い感覚がありました。「うわ、また怒られた」「自分はダメなエンジニアだ」ってね。
特にここ海外に来て最初の頃は、英語のダイレクトな表現も相まって、レビューがまさに「戦場」に見えていたんです。
でもね、こっちでシニアエンジニアたちと働いていて、ある時ふと気づいたんです。
**「あれ？ 優秀なチームほど、レビューの景色が『赤ペン先生』じゃないぞ？」**と。
彼らにとってのコードレビューは、「間違い探し（Error Correction）」の場ではありませんでした。それは驚くべきことに、もっとクリエイティブで、もっとワクワクする「何か」だったんです。
もし今、あなたがレビューのたびに胃を痛めているなら、あるいは「若手のコードをどう指摘すれば伸びるのかわからない」と悩んでいるなら、この話はきっと役に立つはずです。
今日は、僕が海外の現場で叩き込まれた**「Beyond the Red Line（赤い線の向こう側）」**にある、新しい開発の常識についてシェアします。これを読むだけで、明日からのPR作成ボタンを押す指が、少し軽くなることを約束しますよ。
「指摘」ではなく「招待状」——マインドセットをCorrection（訂正）からCo-creation（共創）へ
さて、先ほど話した「恐怖の赤ペン先生」。
なぜ僕たちがレビューを恐れるのか、その根本原因は**「レビュー ＝ テストの採点」**だと思い込んでいるからなんですよね。
書いたコードが「正解」か「不正解」か。レビュアーはそれをジャッジする「審判」。
この構図だと、指摘される側はどうしても「守り」に入ります。「ここは動いてるからいいじゃん」「仕様通りだし」といった言い訳が頭をよぎる。これ、実は日本にいた頃の僕です（苦笑）。
でも、こっちの現場で叩き込まれたのは、全く逆の発想でした。
「Pull Requestは、コードのマージ依頼じゃない。議論への『招待状（Invitation）』だ」
という考え方です。
「訂正」から「共創」へのシフト
ここでキーワードになるのが、今回のテーマでもある “Collaborative Refactoring”（協調的リファクタリング） です。
従来のレビューが Correction（訂正） だとすれば、こっちのエンジニアがやっているのは Co-creation（共創）。
例えば、僕があるWPFの画面で、少し複雑なデータバインディングのロジックを書いたとします。
「Correction」のマインドセットなら、レビュアーはこう言います。
「このコンバーター、メモリリークの可能性があるから直して。あと命名規則が違う」
正論です。でも、これはただの「命令」ですよね。
一方で、「Co-creation」のマインドセットを持った同僚（仮にマイクとしましょう）は、こんな風にコメントをくれます。
「Hey、このバインディングのロジック、面白いアプローチだね！ ただ、将来的にデータ量が増えたときにUIスレッドが重くなるかもしれない。ここで
Task.Runを噛ませて非同期にするか、あるいはReactivePropertyを使ってストリームとして処理するのはどう思う？ 君のアイデアを聞かせてよ」
わかりますか？ この圧倒的な違い。
マイクは僕のコードを「直すべき欠陥品」としてではなく、**「より良くするための叩き台」**として扱っているんです。
彼は正解を押し付けるのではなく、「どう思う？」とボールを投げてくる。こうなると、僕も「守り」に入る必要がなくなります。「なるほど、Rxを使うならこういう書き方もできるかも！」と、脳のスイッチが「弁明モード」から「クリエイティブモード」に切り替わるんです。
ソロプレイの限界を超える
C#で設計していると、どうしても自分の手癖や、「知っている範囲の技術」だけで解決しようとしがちです。
一人で書いていると、それは「動くコード」にはなりますが、「最強のコード」にはなりにくい。
海外のチームが強いのは、この「共創」のプロセスを通じて、コードが書かれた瞬間に、チーム全員の知識が注入されるからです。
レビューの目的は、バグを見つけること（それも大事ですが）以上に、**「二人（あるいはチーム）で、一人では到達できなかった品質のコードを作り上げること」**にあります。
赤字のDiff（差分）は、ミスの証拠ではありません。それは、チームの知恵がコードに染み込んでいく「進化の過程」なんです。
こう考えると、PRを出すのがちょっと楽しみになりませんか？
「俺の書いたこのロジック、あいつならどう料理してくるかな？」
そんな風に思えたら、もうあなたは「赤ペン先生」の呪縛から解放されています。
「でもさ、具体的にどうコメントすればいいの？ 忙しい時にそんな丁寧にやってられないよ」
そう思うかもしれませんね。
そこで次のパートでは、実際にGitHub（あるいはAzure DevOps）上で繰り広げられる**「冷戦状態のレビュー」と「共感型レビュー」**の実例を、実際のコードを交えながらお見せします。
同じバグを指摘するにも、言い方ひとつで、その後の開発スピードもチームの空気も、劇的に変わるんですよ。
【実録】VS Code上の冷戦 vs 共感型レビュー——同じコードでも、これだけ景色が変わる
さて、精神論はここまでにして、現場のリアルな話をしましょう。
「共創」と言われても、実際にどうコメントが変わるのかイメージしづらいですよね。
ここでは、C#のWPF開発でよくある**「重い処理をUIスレッドで走らせてしまう」**という、あちゃーなコード（あるあるですよね？）を例に、「冷戦状態のレビュー」と「共感型レビュー」がどう違うのか、ライブデモ形式でお見せします。
シチュエーション
あなたは後輩エンジニアの書いたコードをレビューしています。
ViewModel内の保存ボタンの処理で、データベースへのアクセスが同期的（Synchronous）に書かれていました。これでは保存中にアプリがフリーズしてしまいます。
【対象コード】
C#
public void SaveCommandExecute()
{
// ダメな例：UIスレッドをブロックしてしまう
_repository.SaveData(_currentUser);
MessageBox.Show("Saved!");
}
ケース1：VS Code上の冷戦（The Cold War）
〜 従来の「正解」を押し付けるレビュー 〜
かつての僕や、多くの現場で見られる「赤ペン先生」スタイルです。
レビュアーのコメント：
❌ “Don’t use blocking calls on the UI thread. Use async/await here. Also, don’t use MessageBox in ViewModel, it breaks MVVM pattern.”
（UIスレッドでブロッキングな呼び出しをしないで。async/awaitを使って。あとViewModelでMessageBoxを使わないで、MVVMパターンが壊れるから。）
【結果と副作用】
これを受け取った後輩はどう思うでしょうか？
「うわ、怒られた……。はいはい、直しますよ（チッ）」
彼は言われた通りに async/await に書き換え、MessageBox を削除するでしょう。コードは「正しく」なります。
しかし、彼は「なぜダメなのか」を深く理解していません。 ただ「先輩に怒られるからやめる」という思考停止ルールが増えただけです。
そして翌週、彼はまた別の場所で同じような同期処理を書いてしまうでしょう。なぜなら、彼の心には**「恐怖」しか残っておらず、「技術的な納得感」**がないからです。
ケース2：共感型レビュー（Empathy-Infused Review）
〜 学びを加速させる「共創」スタイル 〜
これが、僕がこちらのシニアエンジニアたちから学んだスタイルです。
レビュアーのコメント：
✅ “Thanks for the PR! The save logic looks solid. 🚀
One thing to consider: SaveData might take a few seconds if the network is slow. Since this runs on the main thread, the app might look ‘frozen’ to the user during that time.
What do you think about making this async to keep the UI responsive? Let me know if you want to pair on refactoring this part!”
（PRありがとう！保存ロジック、しっかりしてるね。🚀
一点だけ考慮事項なんだけど、ネットワークが遅いと SaveData に数秒かかるかもしれない。これがメインスレッドで走ると、その間ユーザーにはアプリが「フリーズ」したように見えちゃうんだ。
UIの反応を維持するために、ここを async にするのはどう思う？ もしこの部分のリファクタリング、一緒にやりたかったら声かけて！）
【結果と副作用】
どうでしょう？ 景色が全く違いませんか？
- 肯定から入る（Solid/Thanks）： 敵ではないことを示し、心理的防壁を下げる。
- Whyを説明する（User Perspective）： 「ルールだから」ではなく、「ユーザーがフリーズしたと感じるから」という**エンジニアとしての共通の敵（悪いUX）**を提示している。
- 提案と選択権（What do you think?）： 命令ではなく、相談として投げかけている。
- サポートの表明（Pairing）： 突き放さず、助ける用意があることを示している。
このコメントを受け取った後輩はこう思います。
「あ、確かに！ ユーザー目線だとフリーズに見えるのか。それはマズいな。よし、非同期処理をしっかり学んで実装してみよう」
この「差」が未来を変える
ケース1もケース2も、最終的に修正されるコード（async Task SaveAsync...）は全く同じです。
しかし、未来のコストが劇的に変わります。
ケース1では、後輩は「正解」を教わっただけ。応用が利きません。
ケース2では、後輩は「UXの重要性」と「非同期の意義」を学びました。彼は次のタスクで、誰に言われなくても自発的に async を検討するエンジニアに成長しています。
これが冒頭で触れた**「Accelerate Learning（学習の加速）」と「Reduce Future Issues（将来の問題の削減）」**の正体です。
共感型レビューとは、単に「優しくする」ことではありません。
相手のエンジニアとしてのプライドを尊重し、「気付き」を誘発させることで、チーム全体の技術力を底上げする、極めて合理的でROI（投資対効果）の高い戦略なのです。
「優しさ」は、弱さじゃない。最強の技術戦略なんですよ。
優しさのROI（投資対効果）——「心理的安全性」こそが、技術負債を殺す最強の武器になる
ここまで読んでくれたあなたなら、もう気付いているはずです。
僕が言いたいのは「みんなで仲良くお手手繋いで開発しよう」なんていう、ぬるい精神論ではありません。
これは、**徹底的に合理的な「生存戦略」**なんです。
恐怖は「隠ぺい」を生み、共感は「発見」を生む
エンジニアリングの世界には**「技術負債」**という言葉がありますよね。
実は、チーム内の人間関係がギスギスしていると、この利子がとんでもないスピードで膨れ上がるんです。
「あの人にコードを見せると、また嫌味を言われるかも……」
そう思った瞬間、人は無意識に防衛本能が働きます。
わからないことを質問しなくなる。微妙なバグの兆候を見て見ぬふりをする。自分の設計に自信がなくても、とりあえず動くからと黙ってコミットする。
これが積み重なった結果が、リリース直前のデスマーチであり、原因不明の障害です。
逆に、**「心理的安全性（Psychological Safety）」**が高いチーム——つまり、「何を言っても、どんな初歩的な質問をしても、馬鹿にされたり否定されたりしない」と確信できるチームでは、驚くべきことが起きます。
- 「ここ、今のうちに直しておいた方が良くない？」
- 「この設計、自信ないから誰か知恵を貸して！」
こんな声が、廊下やSlackで自然と飛び交うようになる。
バグが「モンスター」に育つ前に、チーム全員の監視網で「ボヤ」のうちに消し止められるんです。
あなたの「1分」が、未来の「10時間」を救う
丁寧なレビューコメントを書くには、確かに時間がかかります。ぶっきらぼうに「直せ」と書くより、1分、あるいは2分多くかかるかもしれない。
でも、その たった数分の投資（Cost） が、メンバーの学習意欲に火をつけ、将来発生するはずだったバグを未然に防ぎ、チームの離職率まで下げるなら……？
これほど ROI（投資対効果） の高い投資は、株やFXを探してもそうそうありませんよ。
今日からできる、小さな革命
海外で働いてみて痛感したのは、「技術力」だけで尊敬される時代は終わったということです。
本当に優秀なエンジニアとは、超絶技巧のコードを書く人ではなく、**「周りのエンジニアのパフォーマンスを最大化できる人」**のことでした。
さあ、次にPRの通知が来たら、深呼吸してみましょう。
キーボードに指を置く前に、一度だけ自問してみてください。
「このコメントは、相手のミスを正そうとしているか？ それとも、より良い未来を共創しようとしているか？」
あなたのその指先から放たれる言葉ひとつで、チームの空気は変えられます。
画面の向こうにいるのは、コンパイラじゃありません。感情を持った、あなたと同じ人間です。
「赤ペン先生」は今日で廃業です。
明日からは、最高のコードを一緒に作り上げる「共創パートナー」として、エディタに向かいましょう。
それでは、Happy Coding!
コメント