こんにちは、フォースタートアップス株式会社のエンジニアの八巻（@hachimaki37）です。主にタレントエージェンシー支援システム（SFA/CRM）のシステム開発を担当しております。

チームの新たな取り組みとして、モブレビューを今年に入ってから実施しています。今日までに8回ほどモブレビューを開催し、徐々にチームのイベント事になってきているのではないかと感じております。

今回の記事では、モブレビューとは何かをはじめ、どんな目的で、どのようにチームで進めているのかについて紹介していきたいと思います。

前提

チーム

• PdM: 1名
• Engineer: 3名
• SRE: 1名
• Designer: 2名

計7名のチームです。小規模なチームのため、PdMが開発 Issue を取ったり、エンジニアがプロジェクトをリードしたり、SREがフロントエンドの Issue を取ったりと、ポジションはあれど横断的に開発を進めています。

Pull Request レビューからマージまでのフロー

Pull Request のレビュアーには、Designerを除くメンバー1名をランダムにアサインする形をとっています。Pull Request のレビュアーにアサインされた方は、Pull Request のレビューに責任を待ち、Approveまでを担当します。Approve後、Pull Request を Main Branch にマージします。

現状

• 大々的にリファクタリングの時間を取ることは難しい。そのため、開発者の善意（ボーイスカウト・ルールなど）で適宜リファクタリングは実施されている
• Main Branch へのマージスピードと品質はバランスを考慮している。つまり、場合により優先順位が入れ替わる
• 細かな技術ナレッジの共有機会は少ない
• 基本的に Pull Request は、レビュアーとレビューイの1対1で行われる

モブレビュー実施のきっかけ

プロダクトフェーズにもよると考えますが、プロダクト開発を行う上で、技術的負債を少なくして高品質のソフトウェアを作成および保守していくことは重要だと考えています。なぜなら、日常業務が難しすぎる場合、プロダクトのスケールやイノベーションなどは間違いなく困難になるからです。

プロダクトの将来を見据え、今よりもチームは成長し、スケール・変化へ適応し易いアプリケーションにしていけたらいいなと思っていた時にこちらの記事に出会いました。

Chatworkフロントエンドが品質を保つために行なっているモブレビューについてのお話 - Chatwork Creator's Note

こちらの記事を参考に、チームの状況を鑑みながらモブレビューを計画し実施に至りました。

概要

モブレビューとは何か

ペアプログラミングやモブプログラミングは、聞き馴染みのあるプラクティスかと思います。モブレビューでは、「1つの Pull Request をメンバー全員でレビューを行う場」と定義し進めています。

モブレビューの場では、機能に対するレビューを行うのではなく、あくまで「ソースコードに対しての疑問点や改善点」を絞り出すことに焦点を置き、Designerを除くメンバーでモブレビューを実施しています。

心得

方向性や心理的安全性を高めるため、「心がけること」を定義しています。

• プロダクトの未来をチームで作る
  • どのようなソースコードであれば、「開発し易くなるのか」「保守し易いソースコードになるのか」「バグの少ないソースコードになるのか」を考えモブレビューを行う
• Re.special（チームのコアバリュー：「互いのリスペクトと個々のスペシャルが、チームの価値を最大化させる」といった意味）
  • 紆余曲折があり、今のプロダクトが稼働しています。過去のスペシャリティをリスペクトしながら、人ではなくソースコードに対して言及しモブレビューを行う

目的

現在のチームの状況を鑑みて、以下目的を定義しています。

• ソースコードの保守性(変更容易性および理解容易性)を高める
• ソースコードレビューによる知見/観点の共有およびチームの成長

参加者

• Designerを除くメンバー

開催

• 隔週1H（1PR/回）
  • 初回：キックオフ
    • 目的、意義、やり方などをチームに共有しました
  • 一回目：チームにイメージを伝えるため、私が用意した Pull Request にて進めました
• オフラインで実施
  • 極力リアルタイムでコミュニケーションを取れるようにしています

担当

• メンバー全員に担当が回ってくるように順番を決めています
• レビューの題材となる Pull Request の定義は、チームにレビューして欲しい・したい・した方が良い「すでに Main Branch にマージ済みの Pull Request」を対象にしています
  • すでに Main Branch にマージ済みの Pull Request であれば、自分以外の Pull Request でもOKとしています

タイムスケジュール

• 題材となる Pull Request の共有：5分
• Pull Request のソースコードレビュー：15~20分
• Pull Request にレビューしたコメントを各自共有：5分
• Issue にするか否かを議論：15~20分
• モブレビューのふりかえり：2分
  • 次回の運営に活かすため、どうだったかをふりかえっています
• 次回の担当者を決める

一例

モブレビューにて、ソースコードをレビューした Pull Request の一部を紹介いたします。

• 一つ目：

• 二つ目：

• 三つ目：

• 四つ目：

• 五つ目：

• 六つ目：

• 七つ目：

チームの声

毎回モブレビューのふりかえりを行っています。どのようなふりかえりがあるのかを一部紹介いたします。

• 数分間では、Pull Request をレビューし切れないので、Pull Request のソースコード量は少量の方が良さそうです
• ソースコード量（1000行くらい）がちょうど良さそうでした
• 変更行数やソースコード量が少なくてもちょうどいい場合がある（触れてないドメイン・技術の場合など）
• コメント数が多すぎるとモブレビュー内で議論し切れない
• レビューのコメントに上がった tips をぜひ残していきたい
• Issue 化するレビューのコメントには、🚀スタンプを押しましょう
• 直近開発している Pull Request が題材だと仕様理解にもなるのでいいなと思いました
• Pull Request に対するレビューのコメントが少ない方が議論しやすい
• Pull Request のレビュー時間を10分に縮めても良いかも（おかわりありで）
• レガシーなソースコードの Pull Request をモブレビューに持ってきても良いかも
• 時間がなくて議論できなかったレビューのコメントも話せると良い

モブレビューの別の使い方

本来の目的とは少し異なりますが、毎回のふりかえりから以下のような使い方にもモブレビューは適応できそうに思いました。

• 仕様、ソースコードの理解
• 新しい技術のインプット
• レガシーなソースコードの改修のきっかけ
• コーディングルールや Tips の共有

まとめ

今日までに、8回ほどモブレビューを開催してきました。全体のレビューコメント数は93件。言い換えれば、93件分の知識や観点を共有する機会をチームに作れています。またモブレビューを通して、Issue 化されたリファクタリングチケットは14件。うち9件が改修され、Main Branch にマージされています。

モブレビュー自体は、何かすぐに効果のでるプラクティスではないかと考えておりますが、保守し易いアプリケーションになっていくこと、チーム全体の技術力アップに繋がっていくことで、Jカーブのような効果が期待できるプラクティスなのではないかと感じています。

これからも意味のあるプラクティスにしていけるよう、チームで試行錯誤しながら進めていきたいと思います。

あとがき

最後に採用情報です。

当社では、更なるサービスグロースを加速させるべく、エンジニアを積極的に募集しております。ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。

採用ページはこちら。（冒頭のTwitterにDM頂いてもOKです！）