実装スプリント3〜チームコードレビュー

• 日程: Day 13 / セッション 2
• 時間: [9:40-12:20]（途中休憩11:00-11:10を含む）
• 形式: 実習
• ゴール: チームメンバーの実装内容を相互レビューし、改善のフィードバックを1人1件以上出せる
• 学習形式: ハンズオン実習、相互レビュー

今日のテーマはチームコードレビューです。書いたコードをチームに見せ、見せられる側になります。

最初に確認したい原則が1つあります。

レビューは「人格」ではなく「成果物」へのフィードバック。良い点も必ず伝える。

レビュー初心者がやりがちな失敗は2つです。1つ目は人格に踏み込むこと（「Aさんはいつも雑だね」）。2つ目は改善点しか言わないこと（「ここがダメ、あそこもダメ」）。どちらも次のレビューが地獄になります。

レビューはチームでコードを良くするための共同作業です。書いた人を裁判するための場ではありません。

レビューで守る3つの原則です。

NGとOKの対比です。

NG（人格に踏み込む）

「ここの命名、Aさんっぽい雑さが出てるよね」

OK（成果物への具体的な指摘）

「変数名 `d` が何を指すか読み取れません。
`registeredDate` のように内容が分かる名前にすると、
半年後の自分が読んでも迷わないと思います。
他の箇所では `customerName` のように分かりやすいので、
そろえると統一感が出ますね。」

NG（改善点しか言わない）

「ここダメ。ここも直して。あと全体的に読みにくい。」

OK（良い点と改善点をペアで）

【良い点】
入力チェックを関数に切り出していて、テストしやすい構造になっています。

【提案】
チェック関数のエラーメッセージが固定文字列になっています。
将来多言語対応するなら定数化しておくと楽です。
ただ、今は中間発表優先で良いので、メモを残しておけば十分です。

「ただし今は◯◯優先で良い」のような判断ラインも示すと、相手は対応の優先度を決めやすくなります。

• 主語を「あなた」ではなく「このコード」「この変数」にする
• 指摘は「場所・現状・提案・理由」をセットで
• 良い点は必ず1つ以上探して伝える

Googleの社内ガイドラインでは、コードレビューのルールとして「Be kind（親切に）」が最初に書かれています。技術的に正しくても言い方がきつければチームは壊れ、長期的には品質も下がる、という経験則からです。「相手が翌日もう一度レビューに出したくなる」レビューが良いレビュー、と社内では言われているそうです。

「全体的に見て」と言われると人間は何も見られません。観点を5つに分けて見ます。

観点ごとの具体的な見方。

【1. 設計書との整合】
- 機能設計書の入力項目とコードの入力項目が一致しているか
- 画面遷移図通りに遷移するか

【2. 異常系の対応】
- 空入力、極端に長い入力、想定外の文字（記号など）に耐えるか
- データベース接続エラーの処理が入っているか

【3. 読みやすさ】
- 変数名・関数名が内容を表しているか
- 1つの関数が長すぎないか（目安30行）
- コメントが必要な箇所にあるか

【4. 重複と再利用】
- 同じ処理が複数箇所にコピペされていないか
- 共通化できる処理が個別に書かれていないか

【5. セキュリティ】
- パスワードが平文で保存されていないか
- ユーザー入力がそのままSQLに入っていないか（SQLインジェクション）

5つ全部を1人で見るのが大変なら、ペアで観点を分担します。

• 観点を持って見る（漠然と見ない）
• 1コードレビューで全観点を見る必要はない。優先順を決める
• セキュリティ系は新人だけでは見落としがち。AIにも相談する

NASAでは、宇宙機のソフトウェアレビューに「悪魔の代弁者（devil's advocate）」役を必ず置きます。良いところを褒めるのではなく、わざと「ここで失敗したらどうなる?」と疑問を投げ続ける役です。これにより善意の確認漏れを防ぎます。皆さんのチームレビューでも、1人「もし◯◯だったらどうなる?」役を置くと、観点が広がります。

人間のレビューに加えて、AIにもコードを見てもらいます。AIは観点の補完役として優秀です。

AIへのレビュー依頼テンプレ。

以下のコードをレビューしてください。
言語: [言語名・バージョン]
機能: [このコードが実現する機能を1文で]
設計書の該当部分: [画面仕様書または機能設計書を貼る]
コード:
[コードを貼る]

次の観点で見て、それぞれ「良い点」と「改善提案」をペアで出してください。
1. 設計書との整合
2. 異常系の対応
3. 読みやすさ
4. 重複と再利用
5. セキュリティ

改善提案には理由と、優先度（高/中/低）も付けてください。
中間発表が明日なので、優先度の低いものは「後回しでOK」と明記してOKです。

AIの指摘を全部反映する必要はありません。「これは明日のデモまでに必要」「これは発表後でいい」を人間が選別します。

• 人間のレビューの「あと」にAIを使うと観点の漏れを補える
• AIには設計書も一緒に渡す（コードだけだと表面的になる）
• 指摘の取捨選択は人間の仕事。AIの言いなりにならない

コードレビューはもともと1976年にIBMのMichael Fagan氏が提唱した「Faganインスペクション」が起源で、当時から「短時間・少人数・観点指定」が3原則でした。半世紀経った今もこの3原則は変わっていません。AIが加わっても、観点を持って・時間を区切って・全部反映しない、という基本は同じです。

レビューで迷ったらAIに相談。

• 「コードレビューで使える観点を、優先度順に教えて」
• 「『良い点』を探すのが苦手。コツを教えて」
• 「Faganインスペクションの3原則を新人向けに解説して」

朝会で決めた時間配分に沿って、相互レビューを実施してください。

1. セルフレビュー準備（20分）

   • 自分のコードと設計書の対応を整理
   • レビューしてほしい観点をメモ
   • AIに事前レビューを依頼して指摘の傾向を把握
2. 相互レビュー（80分／途中休憩あり）

   • 1人20〜30分でペア組で実施
   • 良い点を必ず1つ以上伝える
   • 指摘は「場所・現状・提案・理由」をセットで
   • 指摘の優先度（高/中/低）を付ける
3. 修正と残実装（50分）

   • 優先度「高」を中心に修正
   • 明日のデモに必要な残実装を仕上げる
4. 明日のデモシナリオ通し確認（10分）

   • 朝会で決めた必達ラインを1回操作
   • 動かない箇所があればチームに即共有

• レビュー済みコード（指摘事項を反映または記録）
• レビュー指摘メモ（次回以降に活かす）
• 中間発表の準備チェックリスト（次セッションで使う）

• 良い点が見つからない → 「動いていること自体」が立派な良い点。1日かけて動かしたこと自体に価値がある
• 指摘が偉そうになりがち → 「私だったら〜してみるかも」「〜してみるとどうですか?」のような言い回しに変える
• 指摘を全部反映する時間がない → 優先度「高」だけ反映。「中・低」はかんばんにタスク追加して後日
• レビューされる側がへこむ → 終わったあと「指摘ありがとう」を口にする。レビュアーも勇気を出して言っている

今回学んだことを一言でまとめると「レビューは成果物への具体的な指摘+良い点。AIは観点の補完」です。

• 人格ではなく成果物に焦点
• 良い点と改善点をペアで
• AIは観点の補完役。最終判断は人間
• 全指摘を反映せず、優先度で選別

次のセッションは終会。中間発表の準備状況を確認します。

• レビューの3原則は?
• レビュー観点を5つ挙げられますか?
• 指摘の優先度を分ける目的は?
• AIにレビューを頼むとき、コード以外に渡すべきものは?

• 参考リンク: 自チームの設計書、レビュー観点チェックリスト
• 発展課題: 今日もらった指摘の中で「優先度低」のものをかんばんのバックログに積み、いつ対応するか決めておく

このセクションは、受講者が理解を深めることをサポートする参考情報です。