『伝わるコードレビュー』著者が教える、開発チームの生産性を劇的に向上させるコミュニケーション術

私のキャリアが直接的に結びつくわけではないのですが、コミュニケーションで大切なのは、結局「相手の視点に立って、どういう情報が欠けているか」「どういう順番で情報を出せばいいか」を整理する能力だと思うんです。

その点では、例えば小説を読んでいろんな視点の切り替えに慣れていたり、「言葉を綴る」という行為、つまり「相手にどう受け取られるか」を常に計算したりしてきた経験は、エンジニアとしてのコミュニケーションにも生きているかもしれません。

実は、この本はもともと「テキストコミュニケーション全般」についての本だったんです。それを最終的にコードレビューに絞ったという経緯があります。

執筆の背景には、弊社（株式会社万葉）に新しく入ってきたメンバーに対して、テキストコミュニケーションの作法や期待するレベル感を毎回繰り返し教えている状況があり、「これはもうまとめた方が効率的だよね」という課題感がありました。

まず大前提として、自分の書いたコードにダメ出しをされて落ち込んでしまうのは、それだけ真剣に仕事へ向き合っている証拠であり、ある意味で当たり前の感情だとは思うんです。 その上で構造的な話をすると、レビューする側とされる側の「目線」が合っていないことが大きな原因だと考えています。

はい。レビュアーは「相手（レビュイー）」を評価しているのではなく、「コード」と「プロダクトとして本来あってほしい姿」との差分について話しているんだ、という意識が重要です。

関係性がうまくいかないときは「自分 vs 相手」の対立構造になりがちです。そうではなく、二人ともが並んで「問題（コード・プロダクト）」に向き合う、「問題 vs 私たち」という構図を作ることが、信頼関係の第一歩になります。

ただ、こうした「コード＝自分ではない」という前提は、教えられないと分からないことでもあります。ですから、例えばフィードバックの最初に「これはプロダクトを良くするためなんだけど」と一言添えるだけでも、受け取られ方はかなり違ってくると思いますね。

「この言葉を選べば大丈夫」という鉄板の言葉があるわけではなく、すべては「信頼関係の構築度合い」による、というのが答えになります。

例えば、チームに入ったばかりでまだ関係性ができていない段階なら、「これは人格否定ではなく、あくまでコードの話ですよ」という前置きを丁寧に置くべきです。でも、お互いに「プロダクトのために言っている」という信頼関係が醸成されていれば、「ここ違いますよ」と簡潔に伝えても問題ないわけです。

その通りです。もし自分がすごく気を使った遠回しな言い回しをしないと伝わらないと感じていたり、相手がそういう態度を取っていたりするなら、それは「信頼関係がまだ醸成されていない」というサインなんです。

そういうサインを察知したら、言葉を濁してやり過ごすのではなく、「なぜその指摘をするのか」という前提を改めてすり合わせることが必要です。例えば、「意地悪で言っているわけではなく、私たちのチームでは保守性という価値観を大事にしているから、あえてこの点を指摘しているんです」と言葉にして伝えてみましょう。

まず「決めつけない」ことです。 たとえば、相手のコードに不備があったとき、「こんな初歩的なことを知らないはずがない、手を抜いているんだ」と決めつけるのはいいやり方ではありません。実際は単にその仕様を知らなかっただけかもしれません。「相手には悪意や怠惰がある」という思い込みを捨て、まずは事実を確認する姿勢が大切です。

次に、「お互いの前提知識を揃える」ことです。 自分にとっての当たり前が、相手にとっても当たり前とは限りません。 たとえば「インターフェース」という言葉一つとっても、バックエンドのクラス構造の話なのか、画面のUI（ユーザーインターフェース）の話なのか、人によって想起するものは違います。

切り分けのポイントはシンプルで、「ルールベースで判断できるかどうか」です。 インデントや記法統一などは、もう機械（LintやCI）に任せてしまう。一方で、設計思想やロジックの妥当性など、言語化してルール化するのが難しい部分は、人間が注力すべき領域になります。

ただし、Lintツールの警告を思考停止で修正するのはNGです。なぜそのルールがあるのか、文脈を考慮してそのルールを遵守するか、ルールを見直すかという判断を人間が責任を持って行うことも大切です。

人間なので、日によってコンディションが悪い日もあります。そんな時でも、PRのテンプレートやチェックリストといった「仕組み」があれば、個人の活動を下支えし、一定の品質を保つことができます。「個人の頑張り」に頼るのではなく、チームの「仕組み」で解決していく視点を持っていただきたいですね。

一番大事なのは「ルールの定期的な見直し」です。 特に新メンバーが加入したタイミングは、形骸化したルールを見つけるチャンスだと捉えるのが良いかもしれません。

というのも、新しいメンバーは、まだチームの常識に染まっていません。だから純粋に「この作業にはどういう意味があるんですか？」と聞いてくれます。その時、既存メンバーが「あれ、なんでだっけ……？」と答えに詰まるなら、それはもう今のチームには不要なルールの可能性が高いのです。

ルールには必ず「維持するコスト」と「得られるメリット」があります。 振り返りの場でこのバランスを問い直し、「コストが上回っているなら廃止する」、あるいは「Must（必須）からWant（任意）に緩める」といった判断を、チーム全員で合意していく勇気が必要です。

やはり「コーディングに着手する前」のすり合わせですね。 全部作り終わってから見せるのではなく、「こういう設計方針でいこうと思います」という段階で一度共有し、合意を取るんです。

この時重要なのが、その合意を「あくまでドラフト」と捉えておくことです。「絶対にこの通りに作らなきゃいけない」とガチガチに決めてしまうと、逆に身動きが取れなくなってしまいますから。

実際にコードを書き始めると、「やっぱりこっちの実装の方が効率的だ」と気づくことはよくありますよね。その時、「仮案」だからといって勝手に変えてしまうと、後で「話が違う」となってしまいます。

だから、「やってみたら違ったので、方針を変えます」と一言相談する。 この「小さな合意」をこまめに積み重ねていくことが、結果として「ちゃぶ台返し」のような大きな手戻りを防ぐ一番の近道なんです。

メンバーの納得感を醸成するためには、「今回はここまでやる」というラインを、以下の3段階で明確に示すことが大事です。

1. 目指すべき理想のライン 「本来であれば、ここまで実装するのがベストだよね」という理想像をまず共有する。
2.妥協できるラインと、その理由 「でも今回はリリース優先だから、影響範囲が限定的なここまでは許容しよう」という現実的なラインを引く。
3.後工程でのリカバリ計画 「その代わり、来月の改修のタイミングで、〇〇さんがここを解消しよう」という未来の約束をする。

こうやって順を追って説明すれば、「頑張ったのに無駄にさせられた」とはなりません。「今回は戦略的にここで妥協するんだ」というポジティブな合意形成ができるようになり、モチベーション維持と技術的負債の管理が両立できるんです。

そうですね、例えば「このコードの問題点がわかりますか？」といった「クイズ」は、相手を試す行為であり、無駄な権力差を生んでしまいます。これでは相手は「正解を当てなきゃ」と萎縮してしまい、本来の目的である「コードの改善」がおろそかになってしまいます。

ここでも大事なのは「率直さ」です。ただし、率直さとは「無神経になんでも言うこと」ではありません。以下の3つの要素が揃うことで、信頼される「率直さ」が成り立ちます。

1.明確さ：感情や余計な情報を交えず、事実と要点を伝える。
2.敬意：相手を尊重し、丁寧な言葉遣いを選ぶ。
3.冷静さ：イライラや焦りをぶつけず、フラットに接する。

この3つさえ守れていれば、「チームとしてはこのレベルに到達してほしい」「そのために今ここが不足している」というギャップは、遠慮せずに伝えていいんです。変にオブラートに包むよりも、具体的な学習ステップを示してあげる方が、新人にとっても誠実なコミュニケーションになります。

ベテラン同士の対立は、コードの書き方という「How（どう実装するか）」の話をしているようで、実はその根底にある「Why（何を重視するか）」が食い違っていることが多いんです。

たとえば、Aさんは「将来の変更に耐えられる拡張性」を重視しているけれど、Bさんは「バグが出ない堅牢性」や「今のリリース速度」を最優先に考えている、といったケースです。この「価値観の軸」がズレたままでは、いくらコードの話をしても議論は噛み合いません。

折衷案を提示するのではなく、「なぜその実装にこだわるのですか？」と問いかけて、互いの背景にある「Why」を解きほぐしてあげるのがPL/PMの役割です。

それぞれの正義がぶつかっているだけなので、最終的には「今、私たちのチームでは何を最優先すべきか？」という原点に立ち返って、優先順位を決めてあげる。そうすれば、「じゃあ今回はスピード優先でB案にしよう」と、双方が納得して着地できるはずです。

先日、AIを使ったプログラミングコンテストの審査員をしたのですが、そこで見えてきたのは、人間がAIに「振り回される」リスクです。 AIはそれっぽいコードを書くのは得意ですが、設計思想や構造化の一貫性が欠けていることがよくあります。

書籍では、「あの人（ベテラン）が言っているから大丈夫」とレビュイーが思考停止してしまう事例を紹介していますが、これからの時代はその対象がAIに変わっていきます。「AIが書いたから大丈夫」ではなく、最終的なコードの責任は人間が持つ。設計思想や一貫性を人間がグリップし、AIのアウトプットを適切に評価・修正する能力が一層求められます。

一番のおすすめは、チームで「読書会」をしてみることです。もちろん、この本を選んでいただけたら嬉しいですが、本自体は何でも構いません。大事なのは、チーム内で「共通言語」と「共通の価値観」を持つことです。

「あの本のこのページにこう書いてあったから」という共通の基準ができると、不毛な論争が減り、合意形成が圧倒的にスムーズになります。まずは「同じ言葉で話せる状況」を作ってみることから始めてみてはいかがでしょうか。