モブレビューで、チームのコード品質向上を目指す

2023/03/22に公開

執筆背景

チームのコード品質を向上させる方法として、「モブレビュー」を導入してみました。前職でも経験があったのですが、改めてとても良い試みだと思ったので、記事にして残します。
モブレビューでは、チームメンバー全員で一つのコードをレビューすることで、コード品質の向上や相互理解を促進し、欠陥の発見やプロダクトの改善を目指します。
本記事では、モブレビューの目的、方法、役割、アジェンダを紹介します。ぜひモブレビューを試してみてください!

モブレビューの目的

モブレビューを実施する目的は以下の通りです。

  1. コードや設計観点において、改善点を発見したり、チームで学習したりする。
  2. レビューする際、レビューを受ける際にどういう観点を確認すれば良いかの相互理解を狙う。
  3. 自分、そしてチームのコード品質の向上を図る。
  4. 欠陥の発見、プロダクトの改善、異なる実装の検討、標準や仕様への準拠の評価を目的とする。

方法

モブレビューの方法は、ウォークスルーを基本とし、参加者が画面を見ながら意見を交換する形式で行います。
実装者が開催を呼びかけ、自分自身の作っている機能に関するプルリクエストを持ち込み、それをもとに参加者がワイワイガヤガヤと機能や対象のプルリクエストに対してレビューしていきます。

はじめは、以下に記載のようなアジェンダをもとに形式的に実施するのが良いと思いますが、参加者の熟達に応じて非形式的に実施しても良いかもしれません🙆

方法についてはこちらの記事に記載されていた方法を多く参考にさせていただきました。

通常のレビューとの比較

完全に主観ではありますが、以下のように違いをまとめてみました。

- 通常レビュー モブレビュー
レビューする人数 1人 or 2人 参加者に応じて(大体3-4人以上)
レビュープロセス 非同期的 同期的
主目的 実装の改善・欠陥の検知 チームの学習
重視するもの 正しさ 多様性

役割

  1. ファシリテータ
    • 明確なファシリテータを設けても良いですが、経験上は実装者が担うことが多いです。
  2. タイムキーパー
    • 議論が白熱すると、時間が伸び伸びになってしまいがちです。うまくコントロールしましょう。
  3. 書記
    • 展開が早く追いつかない場合は、他の人に手伝ってもらってもよいでしょう。

グランドルール

大切なことは、"正しさ"にこだわリ過ぎないことです。

  1. レビューだからといって、何かを”修正すべきこと”の指摘や、”正しい”意見を言う必要性はありません。
  2. また、"正しさ"にこだわりすぎて、他の参加者の意見をむやみに否定したり、自分自身の考えを押し付けたりしないようにしましょう。

一番の目的は、チームの学習を促進することです。

アジェンダ

モブレビューのアジェンダは以下の通りです。最大60分の時間の中でやることを推奨します。
()内の時間は目安として記載していますが、時間を厳密に守る必要はありません。

  1. レビュー観点や決まりごとを読み合わせする。(5分)
    • もし、チームにレビューの観点や決まり事等があれば認識を合わせる良い機会です🐎
  2. 実装者が画面を見せながら説明する。デモができると尚良し。(10分)
    • デモはとってもパワフルなツールなので、是非活用することをおすすめします。
  3. 参加者が画面を見ながら意見を交換する。(20~30分)
    • ファシリテータは、発言の偏りが生まれないように全員の意見を引き出すことを心掛けてください。
  4. 指摘や議論の内容はそのまま、GitHubのPRにコメントとして書記が書いていく。
    • こうすることで、後ほどPRの修正や対応がすぐ可能になる。
  5. 学びや気付きを参加者から収集する。(5分)
  6. その場での決定事項があれば全員で確認して、終了。(3分)

その他

  1. 仕様がすべて決まりきっており、実装が全て完成している状態が望ましいですが、フィードバックの収集や学習を促進したい場合には、完成以前でもモブレビューを実施しても良いと思います。
  2. マージ前に実施するほうが、レビューも兼ねられるため望ましいですが、マージ後に実施しても構いません。

参加者の感想(一部抜粋)

  1. 参加者からは、他の人がどのように考えているかを知ることができ、新しい発見があった。
  2. 実装について色々な議論ができたことが良かった。
  3. モブレビューの開催タイミングが難しい。定期リリースがある中で、どのタイミングで実施すると良いのか悩ましい。
  4. 適切な粒度や、少し毛色の違った実装や機能のPRが用意されていれば、異なる議論ができそう。

このように、フィードバックを受けて、モブレビューを改善することで、より効果的な学習やコード品質向上が期待できると思います。参加者の意見を踏まえて、適切な開催タイミングやPRの粒度を考慮し、チーム全体で効果的なモブレビューを実施してみてください。

まとめ

モブレビューを取り入れることで、チームのコード品質向上を促進し、メンバー間の相互理解を深めることが可能になります。レビューを通じて、異なる視点やアプローチを共有し合い、チーム全体で学習を促すことが大切です。

チームでモブレビューを試してみて、ぜひ効果を実感してください!一人ひとりが主体的に参加し、お互いに教え合い、学び合うことで、チーム全体が成長できる環境を作れることを願っています。

Discussion