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

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

実装も3日目。それぞれの機能が形になってきたところで、今日は新しい武器を手に入れます。コードレビューです。

ここで少し考えてみてください。
「自分の書いた文章の誤字は、なぜ自分では見つけにくいのでしょうか？」

人は自分の書いたものを「書いたつもりの内容」で読んでしまうからです。コードも同じです。書いた本人は「動くはず」という思い込みで読むので、抜けや勘違いに気づきにくい。だからこそ、他人の目（そしてAIの目）を借りるのです。

昨日までは「設計書と実装の突き合わせ」で品質を守ってきました。今日はそこに「チームの相互レビュー」を加えます。そして明日は中間発表。レビューで磨いたコードと「動くデモ」を持って臨みましょう。

コードレビューとは、他のメンバーが書いたコードを読み、改善点や良い点をフィードバックする活動です。

たとえるなら、健康診断のようなものです。診断で「血圧が高めです」と言われても、それはあなたの人格を否定されたわけではありませんよね。体の状態という「事実」への指摘であり、早く見つかるほど対処は簡単です。コードレビューもまったく同じで、指摘されるのは「コードの状態」であって「あなた」ではありません。

ここで大事な原則を3つ確認します。

• レビューは「人格」ではなく「成果物」へのフィードバック

  • 「このコードは変数名から処理が想像しにくい」は成果物への指摘に該当します
  • 「君はセンスがない」は人格への攻撃であり、レビューには該当しません。改善につながる情報がゼロだからです
• 良い点も必ず伝える

  • 直すべき点だけを並べると、レビューが「ダメ出し大会」になり、チームがコードを見せたがらなくなります
  • 「このエラーメッセージは親切で良い」のような指摘は、チームの「良い書き方」を共有する効果もあります
• 指摘は提案の形で、理由とセットで

  • 「なぜそうした方が良いのか」まで添えると、受け手は学びとして受け取れます

レビューの流れを図にすると次の通りです。

レビューで設計とのずれが見つかったら、Day 12と同じルールです。勝手に変えず、チームに報告して設計書を更新します。

レビューで何を見ればよいか。今日は次の観点チェックリストを使います。

• レビューの目的は「犯人探し」ではなく「チームの製品の品質向上」。見つかった欠陥はチームの勝利
• 観点を決めずに読むと「なんとなく眺めて終わり」になる。チェックリストを持って読む
• よくある間違い: 完璧になってからレビューに出そうとする。正しくは「動いた時点で早めに出す」。手戻りが小さいうちに直せる

コードレビューの効果を世界に知らしめたのは、1976年にIBMのマイケル・ファガンが発表した「インスペクション」という手法です。彼の調査では、レビューによって欠陥の6〜9割をテスト前に発見できたと報告されています。テストで見つけるよりずっと安上がりだったのです。ちなみにソフトウェア業界には「バグは発見が遅れるほど修正コストが何倍にも膨らむ」という有名な経験則があります。明日の中間発表のデモ中にバグが見つかるのと、今日のレビューで見つかるのと、どちらが幸せかは言うまでもありませんね。

同じ問題を指摘するのでも、言い方ひとつで「学び」にも「ケンカ」にもなります。対比で見てみましょう。

ケース1: 変数名が分かりにくい

• 悪い例: 「変数名が雑。やる気ある？」

  • 人格への評価が混ざり、どう直せばよいかの情報がない
• 良い例: 「変数 d だと何のデータか読み取れませんでした。予約日なら reservation_date のように内容が分かる名前にしませんか？ 1週間後の自分でも読めるコードになります」

  • 困った事実＋提案＋理由がそろっている

ケース2: 入力チェックが漏れている

• 悪い例: 「バグってる」

  • どこで何が起きるのかが分からず、言われた側は調査から始めることになる
• 良い例: 「名前を空欄のまま登録ボタンを押すと、空のデータが保存されました。機能設計書では必須チェックありなので、保存前にチェックを追加すると設計と一致すると思います」

  • 再現手順＋設計書という根拠＋修正方針がそろっている

ケース3: 良い点を伝える

• 悪い例: （何も言わない）

  • 良い書き方がチームに広まらず、レビュー＝ダメ出しの場になってしまう
• 良い例: 「エラーメッセージに『どう直せばよいか』まで書いてあるのが親切ですね。他の画面でもこの書き方に揃えたいです」

  • 良い点が「チームの標準」に昇格する

ここで考えてみてください。
「『ここ直して』とだけ書かれたコメントは、良いレビューコメントに該当するでしょうか？」

該当しません。場所も理由も方針もないため、受け手は質問し返すしかなく、往復の時間が無駄になります。「どこが・なぜ・どうすると良いか」の3点セットが良いコメントの条件です。

• 良いコメントの型: 「（事実・再現手順）＋（理由・根拠）＋（提案）」
• 主語を「あなた」ではなく「コード」にする。「あなたが間違えた」ではなく「このコードはこう動く」
• 指摘を受ける側の作法も大切: まず「見てくれてありがとう」。指摘は提案なので、納得できなければ理由を聞いて議論してよい

世界中の開発者が使うGoogleのコードレビューガイドには、面白いルールがあります。「コメントには敬意を込めること。ただし褒め言葉に説明責任はない」。つまり改善要求には必ず理由が必要ですが、「いいね！」は理由なしで送ってよいのです。また、オープンソースの世界では、レビューコメントの口調がきつすぎて開発者が去ってしまう問題が長年議論され、Linuxの生みの親リーナス・トーバルズが2018年に「自分の攻撃的な言葉づかいを反省して一時休養する」と宣言したのは有名な事件です。世界一のプログラマでも、レビューの言葉選びは修行が必要なのです。

今日はチームメンバーのレビューに加えて、AIにもコードレビューを依頼します。

人間とAIではレビューの得意分野が違います。

• 人間（チームメンバー）が得意なこと

  • 設計書・チームの決め事との照合（AIは自チームの背景を知らない）
  • 「ペルソナにとって使いやすいか」という文脈の判断
• AIが得意なこと

  • 文法ミス・典型的なバグパターンの網羅的なチェック
  • 一般的なベストプラクティスとの比較
  • 何度聞いても疲れない・気まずくならない

つまりAIは「もう一人の、文脈を知らないが博識なレビュアー」です。両方を使うことで観点が補完されます。

AIへの依頼の仕方の例:

• 「このコードをレビューして。特に入力チェックの漏れとエラー処理の観点で」
• 「この関数のバグの可能性と、読みやすくする改善案を挙げて」
• 「初心者が書いたコードとしてレビューし、良い点と改善点を3つずつ教えて」

ただし注意があります。AIの指摘を鵜呑みにして全部直すのは正しい姿ではありません。AIは自チームの設計書を知らないため、設計と矛盾する提案をすることがあります。AIの指摘も「提案」として受け取り、採用するかはチームが判断する。これは人間のレビューとまったく同じ作法です。

• 順番のおすすめ: まずAIレビューで機械的な指摘を潰す → 人間レビューは設計との整合と使いやすさに集中
• AIの指摘を採用したら、なぜ直したかをチームに共有する（勝手な変更にしない）
• よくある間違い: AIに「コードを全部書き直して」と頼む。正しくは指摘をもらい、自分が理解して直す

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「コードレビューの指摘がきつく聞こえない言い換え例を5つ教えて」
• 「このレビューコメントは良いコメント？ 改善するならどう書く？」
• 「レビューで意見が割れたとき、チームはどう決めればいい？」

朝会で決めた時間配分に従い、実装とチームコードレビューを行います。

1. 実装タイム（前半・目安60分）

   • かんばんのタスクに従って実装を進める
   • 中間発表でデモする機能を最優先で「動く状態」にする
   • 行き詰まったらエラー全文をAIに貼り付けて相談する
2. AIレビュー（レビュータイムの最初・目安15分）

   • 自分の担当コードをAIに渡し、観点を指定してレビューを依頼する
   • 指摘のうち納得できたものを修正する（設計と矛盾する指摘は採用しない）
3. チーム相互レビュー（目安30分）

   • ペアまたは持ち回りで、お互いのコードをレビューする
   • 本編の観点チェックリスト（設計との一致・動作・読みやすさ・安全性）を使う
   • 1人1件以上の改善フィードバック＋1件以上の良い点を必ず出す
   • 指摘は「事実＋理由＋提案」の型で伝える
4. 修正と反映（目安15分）

   • 受けた指摘から今日直すものを選び、修正する
   • 設計書とずれが見つかった場合は、チームに報告して設計書側も更新する

• レビュー済みコード（指摘を反映したもの）
• レビュー記録（誰が・どのコードに・どんな指摘をしたかの簡単なメモ。明日の中間発表で「品質向上の取り組み」として報告できる）
• 更新済みかんばん

• レビュー依頼するときは「特にここを見てほしい」と伝えると、レビューの質が上がります
• 指摘の言い方に迷ったら、AIに「この指摘を相手が受け取りやすい言い方にして」と相談できます
• エラーが出たら、AIに「〜という操作をしたら〜というエラーが出た」と状況ごと伝えると解決が早いです
• 直す時間がない指摘は、捨てずにかんばんのTodoに積みましょう。明日以降の計画材料になります
• レビューが脱線して雑談になったら、チェックリストに戻る合図を決めておくと便利です

今回学んだことを一言でまとめると、**「レビューは成果物への贈り物であり、人間とAIの両方の目でコードの品質を高める」**です。

• 指摘は「事実＋理由＋提案」の型で、良い点も必ず添える
• 指摘されたコードの欠陥は、明日見つかるより今日見つかった方がずっと安い
• AIレビューで機械的な観点を、人間レビューで設計と文脈の観点をカバーする

次回（本日セッション3）は終会です。明日の中間発表に向けて、報告内容とデモの分担を決めます。

以下の問いに答えられるか確認してみましょう：

• コードレビューで指摘する対象は「人格」と「成果物」のどちらですか？ それはなぜ？
• 良いレビューコメントの3点セット（型）を言えますか？
• 人間のレビューとAIのレビュー、それぞれの得意分野は何ですか？
• 今日、自分はどんな指摘を出し、どんな指摘を受けましたか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: 「Google コードレビュー ガイドライン」「コードレビュー 観点」で検索
• 発展課題: 今日受けた指摘のうち1つをAIに見せて、「同じ間違いを防ぐ習慣やチェック方法」を提案してもらいましょう

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