チェックポイント

クイズの説明

Step 4「レビューを受ける心構えを知ろう」で学んだ内容の理解度をチェックします。

• 全8問
• 合格ライン: 80%（7問正解）
• 不合格の場合は復習してから再挑戦してください

問題

Q1. コードレビューの本質として最も適切なものはどれですか？

• A) 開発者のミスを指摘して評価する場
• B) 品質を高めるためのチーム協力作業
• C) 上司が部下の作業を管理するための手段
• D) コードを自動的に修正するプロセス

正解: B

コードレビューは品質を高めるためのチーム協力作業です。 「攻撃」や「評価」ではなく、チーム全体で品質を向上させる活動です。

Q2. レビューコメントを受けたときの最初のステップとして正しいものはどれですか？

• A) すぐに修正を開始する
• B) まずレビュアーに感謝を伝える
• C) 指摘が正しいか反論を考える
• D) 上司に報告する

正解: B

レビュー対応の5ステップは「感謝→理解→質問→修正→記録」です。 まずレビュアーの時間を使って品質向上に協力してくれることに感謝しましょう。

Q3. 「Nit」というレビューコメントの意味として正しいものはどれですか？

• A) 必ず修正しなければならない重大なバグ
• B) 些細な指摘で、修正は任意
• C) セキュリティに関する緊急の指摘
• D) 設計上の根本的な問題

正解: B

「Nit」は "nitpick"（些細なこと）の略です。 インデントのずれや軽微な命名の改善など、必須ではないが望ましい修正を示します。

Q4. セルフレビューの目的として最も適切なものはどれですか？

• A) レビュアーを不要にするため
• B) 自分で気づける問題は事前に修正し、レビューを効率化するため
• C) コードを完璧にするため
• D) テストの代わりとするため

正解: B

セルフレビューは「レビュアーの時間を大切にする」ための準備です。 デバッグコードの削除や不要なファイルの除去など、自分で気づけることは事前に対応します。

Q5. PR説明文に含めるべき情報として最も適切でないものはどれですか？

• A) 変更内容の概要
• B) なぜその変更が必要か
• C) コードを書くのにかかった時間
• D) テスト結果や動作確認方法

正解: C

PR説明文には「何を」「なぜ」「どうやってテストしたか」を書きます。 コーディングにかかった時間はレビューに必要な情報ではありません。

Q6. レビュー指摘の内容が理解できない場合、どうすべきですか？

• A) わからないまま適当に修正する
• B) 指摘を無視する
• C) 自分の理解を示しながら質問する
• D) 誰かに代わりに対応してもらう

正解: C

わからないときは「○○という理解で合っていますか？」のように、 自分の理解を示しながら質問しましょう。レビュアーも適切に回答しやすくなります。

Q7. レビューで同じ指摘を繰り返し受けないためにすべきことは何ですか？

• A) レビュアーを変える
• B) 受けた指摘を記録し、自分のチェックリストに追加する
• C) 完璧になるまでPRを出さない
• D) 指摘の多い部分のコードを書かないようにする

正解: B

レビューで受けた指摘を記録し、自分のチェックリストに反映することで、 同じミスを繰り返さなくなります。これが成長の証です。

Q8. レビュアーの提案に別の考えがある場合、最も適切な対応はどれですか？

• A) 黙って自分のアプローチを維持する
• B) 理由を丁寧に説明して議論する
• C) 全てレビュアーの言う通りに従う
• D) PRを取り下げて新しく作り直す

正解: B

提案に対して別の考えがある場合、理由を丁寧に説明して議論します。 建設的な対話を通じて、より良い解決策を見つけることが重要です。

結果

7問以上正解の場合

合格です！おめでとうございます！

Step 4「レビューを受ける心構えを知ろう」を完了しました。 次はStep 5「指摘を活かして修正しよう」に進みましょう。

6問以下の場合

もう少し復習しましょう

間違えた問題の内容を、該当するセクションで復習してください：

Step 4 完了！

お疲れさまでした！

学んだこと

• コードレビューの目的と本質（協力作業）
• セルフレビューとPR説明文の重要性
• レビューコメントへの対応方法（感謝→理解→質問→修正→記録）
• 建設的な議論の進め方

次のステップ

Step 5: 指摘を活かして修正しよう（4時間）

レビュー指摘から学び、同じミスを繰り返さない改善サイクルを身につけます。

推定所要時間: 30分