Day 7・チーム開発の作法 — 規約・Gitフロー・レビュー・テスト・秘匿情報
コードレビュー — 何を見て、どう出すか
設計・可読性・テスト・セキュリティの観点と、レビューされる側の作法。
コードレビューの目的
は、マージ前に他のメンバーが変更を読み、問題を早く見つける工程です。目的はバグの発見だけでなく、設計の妥当性の確認、知識の共有、コードの一貫性の維持など多岐にわたります。『間違い探し』ではなく『チームでコードを良くする協働』です。
レビューの観点
- 設計: 責務は適切か。コントローラが太っていないか、ロジックの置き場所は妥当か。
- 可読性: 半年後の人が読んで意図が分かるか。命名は適切か。
- テスト: 変更に対するテストがあるか。壊れやすい箇所が守られているか。
- セキュリティ: 入力検証・認可・エスケープは効いているか。秘匿情報が漏れていないか。
なぜ設計とセキュリティを人が見るのか
書式や単純なミスはツールが見つけられます。しかし『この責務分けは妥当か』『この認可漏れは業務上まずいか』といった判断は、仕様と文脈を理解した人間にしかできません。AIが実装を出せる時代でも、その設計判断とリスク評価こそ人間がレビューで価値を出す部分です。だからレビューは機械に任せられない観点に集中させます。
レビューする側の作法
刺さるレビューコメント
「これはダメ。なんでこう書いたの?」——人格や能力を責め、代案も理由も示さない。相手は萎縮し、議論が進まない。
建設的なレビューコメント
「ここはサービス層に寄せると再利用しやすいと思いますが、いかがでしょう?理由は〜」——対象はコードで、理由と代案を添え、判断を相手に委ねる。
レビューされる側の作法
- PRの説明に『何を・なぜ』変えたかを書き、レビュアーの前提を揃える
- 変更は小さく保つ。巨大なPRはレビューされにくく、見落としも増える
- 指摘は攻撃ではなくコードへの意見として受け取る。ただし鵜呑みにせず、疑問があれば理由を確認する
- 対応した/しない を明示し、しない場合は理由を返す
指摘を鵜呑みにしないことも作法
レビューは対話です。指摘が常に正しいとは限らないので、技術的におかしいと思えば理由を尋ね、根拠を確認します。逆に自分が正しいと思い込まず、相手の意図を確かめる。どちらも『コードを良くする』という同じ目的に向いているという姿勢が大切です。
面接ではこう言う
「レビューでは設計・可読性・テスト・セキュリティを見ます。書式はツールに任せ、人は責務分けや認可漏れのような判断が要る部分に集中します。コメントはコードを対象にして理由と代案を添えます。される側としては、PRを小さく保ち、何をなぜ変えたかを説明し、指摘は鵜呑みにせず理由を確かめるようにしています」
読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。
理解度チェック
答えられれば、面接で説明できる状態に一歩近づきます。
コードレビューで、ツールより人間が見るべき観点として最も重要なものは?
レビューされる側として、どんな作法を心がけますか。
記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。