1 はじめに
2 コードレビューの概要
3 マージリクエストのレビュー機能紹介
- 3.1 MRの設定
  - 3.1.1 ブランチ保護
  - 3.1.2 Approve必須化
4 レビュアー（レビューする人）の視点
5 レビューイ（レビューしてもらう人）の視点
6 まとめ
7 参考文献

はじめに

前回は、CI/CDの基本から、GitLab Runnerの導入、そしてコンテナイメージのビルド・プッシュ・デプロイまで、一連のワークフローを解説しました。

今回は、マージリクエスト（MR）の重要な役割であるコードレビューに焦点を当てます。コードレビューは、バグの早期発見やコード品質の向上、さらにはチームの知識共有を促す、開発プロセスに欠かせない作業です。

本記事では、GitLabのMR機能を活用し、レビューをスムーズに進めるための具体的な操作方法を、レビュアー（レビューする人）とレビューイ（レビューしてもらう人）の両方の視点から解説します。

コードレビューの概要

コードレビューとは、他の開発者が書いたコードを読み、フィードバックや改善点を議論するプロセスです。これは、単にバグを見つけるだけでなく、チーム全体のコード品質を高め、知識を共有し、開発の一貫性を保つために重要です。

GitLabでは、このコードレビューのプロセスがマージリクエスト（MR）に統合されています。MR上でコードレビューを行う流れは以下のようになります。

レビューイ（レビューしてもらう人）：構文チェック後にMRを作成し、パイプラインの自動テストが完了していることを確認する。
レビューイ：レビュアーを指定してレビュー依頼を出す。
レビュアー（レビューする人）：レビュー依頼を受けたらMR画面を確認し、MRの概要を把握する。
レビュアー：コードの変更点へのコメントをする
レビューイ：MRのレビューを確認し、コードの変更が必要な場合は修正する。
レビュアー：コードの変更点に問題がなければMRを承認する。
レビューイ：MRが承認されたらマージする。

今回はレビューイが承認をもらったら、レビューイ自身でマージする流れで紹介します。

承認に複数名必須な場合もあるので、すべての承認者が承認してからマージするためにレビューイ自身でマージする流れを紹介しましたが、誰がマージするかはチーム文化に依存します。

マージリクエストのレビュー機能紹介

MRの設定

マージリクエスト（MR）を作成する際、タイトルや説明、担当者といった様々な項目を設定できます。

タイトル
- MRの目的を示します。一目で内容がわかるように「feat: 新機能追加」や「fix: バグ修正」といったルール（コミット規約）を適用するのが一般的です。
説明
- 以下の点を意識して記載すると、レビュアーは内容を素早く理解できます。
  - なぜこの変更が必要かといった背景や課題
  - 何を変更したかといった技術的な詳細
  - 何を確認してほしいかといったレビューのポイント
  - 関連するイシュー番号

担当者
- このMRの責任者をアサインします。通常は作成者（レビューイ）自身をアサインします。
レビュアー
- コードレビューを依頼する人を指定します。
マイルストーン
- プロジェクトの特定のフェーズやリリース目標にMRを関連付けます。次のバージョンのリリースに向けたタスクをまとめること等ができます。
ラベル
- MRを分類するためのタグ付け機能です。「バグ」「ドキュメント」「緊急修正」などのラベルをつけて分類します。
マージ開始日時
- マージを特定の日時にスケジュールするための機能です。特定の時間に自動でマージを実行したい場合に利用します。例えば、深夜に自動デプロイを行う際などに便利です。マージを開始するには、CI/CDのテストが成功している状態などのチェックに合格している必要があります。
マージオプション
- MRが承認されたときにソースブランチを削除します。
  - マージ完了後に、不要になった作業用ブランチを自動的に削除します。マージ後にブランチを削除し忘れることがなくなり、リポジトリを整理できます。
- MRが承認されたときにコミットをスカッシュします。
  - マージする際に、複数のコミットを1つの大きなコミットにまとめる機能です。マージ時には1つのコミットとして履歴に記録できます。これにより、mainブランチの履歴を見やすく保てます。

ブランチ保護

以前の記事で解説したように、mainのような重要なブランチは保護設定をすることが推奨されます。これにより、MRを経由しない直接のプッシュを防ぎ、レビューのプロセスを強制します。

Approve必須化

プロジェクトの承認ルールを設定することで、特定のチームメンバーやコードオーナーからの承認をマージに必須できます。例えば、「2人以上のレビューアの承認が必要」といったルールを設定することで、コード品質のチェック体制を強化します。この設定は、Premium, Ultimateのプランで行えます。Free版では1人の承認必須設定が可能です。

参考：https://docs.gitlab.com/user/project/merge_requests/approvals/rules/

レビュアー（レビューする人）の視点

レビュアーとしてMRをアサインされたら、以下のステップでレビューを進めましょう。

MR画面の確認

まず、MRの概要を把握します。

MRの目的、関連するイシュー、変更の概要を確認します。
失敗したCI/CDパイプラインのエラーが未解決の場合は、そこでレビューを中断し、修正を依頼します。
変更されたコードを詳細に確認します。以下の点を意識して確認するとよいと思います。
- コードの品質
- 境界値や大規模データでの計算量が考慮されているか
- プロジェクトのコーディング規約に準拠しているか

変更点へのコメント

特定の変更点にコメントを付けることで、レビューイにフィードバックを伝えます。

変更された特定の行にカーソルを合わせると、コメントアイコンが表示されます。クリックすると、コメント入力欄が現れます。
修正案をコメントで提案できます。
- 「レビューを開始」
  - 複数の箇所にわたるフィードバックを、まとめて一度に投稿したい場合に使うボタンです。このボタンをクリックすると、コメントはすぐに投稿されず、「保留中のコメント」として保存されます。すべてのレビューを終えた後、MRの画面の「Your review」から「レビューを送信」ボタンをクリックすると、保留中のすべてのコメントがまとめて投稿されます。
- 「今すぐコメントを追加」
  - 特定のコード行に対して、すぐに投稿したい単発のコメントに使うボタンです。
- 明確な正解はありませんが、基本的には「レビューを開始」でフィードバックをまとめ、「今すぐコメントを追加」で緊急性の高いシンプルなコメントを送るのが良いと思います。例えば、大きめのリファクタリングでは「レビューを開始」、小さな誤字では「今すぐコメントを追加」といった使い分けができます。
- 「提案」
  - コメント入力欄にある「候補を挿入する」ボタンをクリックし、修正後のコードを記述します。これにより、ワンクリックで修正を適用できるようになります。
  - 記述したら、その他コメントと同様にコメントを追加します。

承認（Approve）

レビューが完了したら、MRを承認します。コードに修正が必要な場合は、レビューイに修正依頼を出し、修正完了の連絡をもらったら再度変更を確認して承認します。

変更が適切であると判断したら、MR画面の「承認」ボタンをクリックします。これは、コードを承認したという意思表示になります。

レビューイ（レビューしてもらう人）の視点

レビューイは、MRを作成してビューを依頼した後、レビュアーからのフィードバックに対応し、変更を完了させます。レビューが完了したらマージを行います。

MRの作成

マージするブランチのコードを確認して、レビュアーに見てもらえる状態にします。以下の点を意識して確認するとよいと思います。

パイプラインのテスト結果が成功しているか
不要なデバッグコードやコメント、一時ファイルが残っていないか

レビュアーを指定してMRを作成します。MRの作成手順は第5回を参考にしてみてください。

コメントへの返信

質問のコメントに対しては意図を説明する返信を行います。議論が必要な場合は、返信で対話を続けます。

感謝の意を常に忘れないようにしましょう。

変更の適用

レビュアーから「提案」を受け取った場合、GitLabの機能を使って簡単に変更を適用できます。しかし、提案をそのまま適用すると1コミット単位で履歴が増えるため、コミットをまとめたい場合はローカルでの修正が必要です。「提案」機能ではコミットの粒度を制御しにくいため、ローカルでの修正との使い分けが必要です。

MRの「変更」タブで、コメントに付いている「変更を適用」ボタンをクリックします。コミットメッセージを入力して「適用」をクリックします。これで、提案された変更をコミットとして追加できます。
表示するコミットを最新バージョンに変更します。
提案された変更が適用されていることが確認できます。これで、簡単に変更を適用できました。