レビューにお悩みを抱えるエンジニアの皆さん、モブレビューいかがでしょう?

業務フロー改善・効率化を扱うプロダクトでスクラムマスターをやっています、飯野です。
本記事では開発チームの取り組みである、「モブレビュー」について紹介します。

モブレビューとは?

その名の通り、モブプログラミングのレビュー版です。
「モブ」=「群衆」の意で、チーム全員で毎日同じ時間に同じ場所でレビューを行います。

f:id:AdwaysEngineerBlog:20190614142925p:plain
※画像はイメージ(協力して進む子どもたち)です。

モブレビューでは決まった時間に全員でレビュー、問題が無ければその場でマージまで行うので、五月雨にレビューに時間を取られることが無くなり、認識合わせも一発で終わります。

「えっ、対面で毎日全員でレビューするの?その方が工数かかりすぎない?」
という声も聞こえてきそうですが、一方、テキストベースの個人レビューにおける課題とは何でしょう?

個人レビューの難しさ


 

f:id:AdwaysEngineerBlog:20190614144407p:plain:w100 (レビュアー)「あああああ、どんどんレビューが溜まっていく」
f:id:AdwaysEngineerBlog:20190614144534p:plain:w100 (レビューイ)「早くレビューしてくれないかな…」


 

f:id:AdwaysEngineerBlog:20190614144551p:plain:w100 (レビュアー)「めっちゃコード量多い!キー!」
f:id:AdwaysEngineerBlog:20190614144605p:plain:w100 (レビューイ)「何かこのFB怖いんだけど…怒ってるのかな…」


 

上記は大分極端な例ではありますが、個々人でレビューを担当するとレビュー待ちの時間が発生したり、逆にレビューに追われたりと、個人のタスク進捗がチーム全体に影響を及ぼすことがあると思います。
コミット量も人によって異なり時間がかかりすぎるが故に、FBが適切ではなくなってしまったり、テキストによるコミュニケーション齟齬が起きるケースもあるのではないでしょうか。

そんなときどうする?

チーム開発を行うエンジニアにとっては、誰しも一度は感じたことのある課題ではないでしょうか?
「とは言え巷で流行りのモブプロ、ペアプロをすぐに導入するのも難しそうだな…」
そんなエンジニアの皆さん!
やってみましょうモブレビュー!

Let's Try!

必要なもの

全員で覗き込める、

  • 大モニター

これに尽きます。逆に言えば、これさえあればどのチームでも明日から、いや、今日から実行出来ます。

タイムテーブル

時間 やること
〜11:40 出社
個人開発
前日のモブレビュー以降の作業全てをコミット&プッシュ
11:50〜12:00 デイリースクラム
12:00〜13:00 🌟モブレビュー🌟
13:00〜14:00 お昼ごはん
14:00〜17:00 個人開発
17:00〜18:00 モブレビュー (随時)
18:00〜 個人開発
退社

※弊社はコアタイム12〜17時の時差出勤です。
※12〜13時のレビューは毎日必ず実施し、17〜18時(時間自体も可変)は状況によって随時開催しています。

進め方

  1. モブレビュー開始時間前に、前日のレビュー以降の作業全てをコミット&プッシュ
  2. 毎日12時にモニター前に集合
  3. 一人ずつPCをモニターに繋ぎ(モブプロで言うドライバー的な感じ)、変更点を見せながら説明を行う
    1. 変更の意図
    2. 仕様
    3. 注意事項
    4. 相談
    5. TODO 等々
  4. 説明を受ける側(モブプロで言うナビゲーター的な感じ)は、画面を見ながらあれやこれや言う
    1. ここはどういう動き?
    2. XXクラスの処理が参考になるよ!
    3. 変数名悩むね!
    4. この設計アーキテクチャ的にどうなのかな? 等々
  5. 指摘や変更内容があればGitlabのコメントに残す
  6. コードレビュー後、動作確認を行う
  7. コード、動作確認に問題が無ければそのままmasterブランチへマージ
    1. デプロイ完了後はステージングでも動作確認を行う
  8. 人数分回したら終了

f:id:AdwaysEngineerBlog:20190614144927j:plain:w600
※実際のモブレビュー中の様子

モブレビューの効果

チームにモブレビューを導入してもうすぐ2年経ちますので、実感できた効果のほどを。

属人化の解消

毎日全員でレビューを行うので、実装に直接関わっていないタスクの情報も日々得ることが出来ます。
設計→実装→テストコード実行→動作確認の全てにレビューを含むので、実装面でも仕様面でも知識の補完が行えます。
まだ触れていない機能でも取り組むハードルが下がりますし、全員に見てもらえるという安心感にも繋がると思います。

コミュニケーションが増える

テキスト上でのレビューだと感情が伝わりにくい & コードだけだと意図が分からないケースも起こり得ます。
そのため、レビューイがコメントを見てつらくなってしまったり、レビュアーがイライラしてしまうこともあると思います。
対面でのレビューだと疑問点はその場で解消できるし、全員の認識がすぐに合わせられアドバイスも行えるので、コミュニケーションを取りながら前に進むことができます。

また、単純に毎日1h以上のチーム交流が必ずある、という点もメリットだと思います。

手戻りの減少

モブレビュー導入前はコミットの単位がばらばら(1コミットに数十ファイルがざらにある)で、
レビュアーの負担も多く、また、指摘を受けるレビューイも修正ファイルが多ければ多いほど、手戻りが多い状況でした。
前日からの当日までの作業をレビューすることでコミットも小さくなりますし、何よりレビューの密度が格段に濃くなります。

「毎日1h以上全員でレビューなんて効率悪そう」と思うかもしれませんが、結果、マージのスピードは上がり、作業効率は上がっている状況です。

興味を持ってもらえる

これはモブレビューを行ってみてから気付いた効果ですが、大きいモニターでみんなでコードを眺めていると、
「毎日みんなで何してるの?」なんて声を掛けてもらえたり、立ち止まって覗いたりする人が現れました!
あのチーム楽しそうだね!なんて思ってもらえたらチームのブランディングにも繋がりますね。
他のチームにもよい影響が与えられるかもしれません。(実際、モブレビューを導入したチームが増えました)

改善サイクル

モブレビューに限りませんが、定期的なイベントを設定するとチーム内の改善サイクルが回しやすくなります。
私のチームのモブレビューも、振り返りを行っていたことでとても改善が進みました。

  • 動作確認に時間がかかる → ドライバーがテストシナリオを考えよう!
  • 説明に時間がかかる → どんな変更を行ったコミットなのか、テンプレートを作成して完結にまとめておこう!
  • テストコードのメンテナンス忘れてしまう → マージ前に必ずテストを実行しよう!こけたらマージしない!
  • マージ前のテスト実行を忘れてしまうw → ラベルをつけよう!

みんなの作業時間を削ってレビューを行っているので、レビューイも「見てもらう意識」が高まり、
レビュー前に事前に準備するようになったりと、小さな改善を繰り返しながらよりお互いを思いやって開発が出来ていると思います。

まとめ

  • レビューに時間がかかりすぎる
  • コミットの単位がばらばら
  • レビューの手戻りがつらい
  • 仕様の認識ずれが起きがち

等々、レビューにまつわることでお困りの方は、モブレビュー試してみてはいかがでしょう?
「テキスト上でのレビューだと感情が伝わりにくい」と上に書きましたが、対面だと逆に感情が乗りまくるかもしれないので、あくまでも節度を弁えてレビューしましょう!

過去に、組長こと所属部署のマネージャーが書いた下記記事もあるので、合わせて参考にしてみてください。

blog.engineer.adways.net