最近モブレビュー取り入れたいと感じていて、なんで取り入れたいかなどについて書いてみました。
モブレビュー自体まだ 2, 3 回しかやってないので説得力にかけますが、ご容赦ください。
- チームは 6 人以下
- Pull Request (以下 PR) をマージするには必ず他の誰かが approve しないといけない
- チーム内の情報共有
- 属人化の解消
- 退職や異動などによる情報の喪失(誰も分からない状態)を防ぐ
- チーム外の人とのコミュニケーションにも活用できる
- レビュー待ちの短縮
- レビューの品質の改善
- 仕事を評価してもらうことで承認欲求を満たす
- オンボーディングの改善
- レビューを通じて必要な知識を吸収してもらう
- オンボーディングに限ったことではないが、オンボーディングにも有効ではないか
- 最後までやりきる
箇条書した内容を補足します。
情報共有
属人化の解消は結構重要だと自分は思っていて、特定の人じゃないと出来ないこと、わからないことというのは
ボトルネックや技術的負債だったり、障害対応時に致命的になりかねません(深夜に障害が起こってAさんに聞かないとわからないのに、Aさんと連絡が取れないとか最悪)。
チーム全員とはいかなくても 3 人ぐらいは出来る・分かってる必要があるかなと思います。
まぁ、当初は 3 人ぐらい分かってても、時間が経って異動やら退職やらで気づいたら分かっている人いなくなってたというのは
ありえなくないので、そういったリスクをどうやって防ぐかというのは考える必要がありますが、今回の話とは外れるので割愛します。
また、チーム外の人とのコミュニケーションにも活用できると思っていて、
例えばランチや飲み会でチーム外の人とのコミュニケーションを取る際に自分のチームの他の人が対応した件とかが話題に上がったときに
ちゃんと情報共有できてないと、自分は担当外なので分かりませんとなってしまうでしょう。
知っていればむしろ自分から話題にできるかもしれません。
そこから発展して更に新しいタスクの話もできるかもしれません。
レビューの改善
せっかくいい仕事をしても中々レビューしてもらえないとなると不満がたまります。
モブレビューを実施することでレビューを促進し、レビュー待ちの時間を短くできることを期待します。
レビューしたくても良くわからなくてレビューできないというパターンもあると思うので、
わからない部分をモブレビューで解消されてレビューが進むと良いですね。
また、ちゃんと複数人でレビューすることで目先の問題を解決するだけの本質的でない問題解決を防ぐことが出来ることもあると思います。
「いや、それそもそもPRの前提がおかしくない？前提となっている仕様を見直すべきなのでは」
みたいなこともあるかもしれません。
仕事を評価してもらうことで承認欲求を満たす
いい仕事したら他の人にも知ってもらいたいというのは自然なことでしょう。
いい仕事を褒めるのは良いチーム・環境であり働きやすさというところにつながるのではないでしょうか。
ちなみに現職だと Slack で他のチームにも共有して emoji で褒め称えるというのが結構やられていて
気持ちのいい環境だなと思っています。
オンボーディングへの活用
そもそもオンボーディングというものをちゃんと受けたのが現職が初めてで、
現職でもオンボーディングについてはまだまだ検討中であり、「何をもってオンボーディングは終わりと言えるのか」みたいな議論が Slack でされてたりして、
自分もよくわかってないのですが、モブレビューがオンボーディングにも活用できるんじゃないかなという気がしています。
色々なにも分かってない状態の New Joiner でも理解できるように、背景とかを説明したりすることで
会社固有のドメイン知識などを補い、戦力化を促すことが出来るんじゃないかなと思います。
会社固有の略語などが当たり前に使われてたりすると New Joiner には理解できないのですが、そういうのも含めてフォローしてあげる良い機会になると思います。
マイクロサービス化なんかをやっていると New Joiner には名前を聞いただけでは理解できないものも出てきますしね。
まぁあまり細かな話までしだすとそれはまだ New Joiner には早いということにもなるので、ケースバイケースかもしれません。
最後までやりきる
PR を投げた後、レビューしてもらえない、説明を書いているのに読んでもらえないといったときに
- 自分はやるべきことをやっている
- レビューしない人たちが悪い
- 説明を読まない人たちが悪い
としてそれ以上なにもしないというのはもったいないと思います。
「結果がすべて」だと考えると説明を書いても読んでもらえなかったらそれは書いてないと同じなので
モブレビューという形で読んでもらう努力をするのがより建設的なのでしょう。
モブレビューしてみたら「レビューしようと思ったけど、ここが良くわからなくてやめちゃったんだよね」ということもあったので、
自分の説明も足りてなかったんだなと見直す良い機会にもなります。
解決したい課題
- 他の人が何やってるのかよくわからない
- 他の人のをレビューしようとしても良くわからなくてそっとタブを閉じてしまう
- 分からないことを理解する成長チャンスを無駄にしているのでは
- レビュー待ちが長い
- 細かく PR を投げたくても前のがマージされてないと先に進めない
- マージされないまま master が更新されて逐一 rebase しないといけない
- レビューの品質の低下
- よくわからないけどマージしてしまえ: レビューの意味がない
- issue や PR の説明やコメントが足りてない
- 説明を英語で書かないといけないとかだと、説明不足になりやすい
- モブレビューで口頭で説明してみると、 issue や PR に書いてない情報が出てくる
その情報を追記することで(口頭で説明するだけではだめ。後からその場にいなかった人も見返すもの)改善できる
実施方法
定例を組むのもありですが、個人的には予定を押さえなくても場所を確保できるのなら(フリースペースとかにモニターがあってサッと出来るなら理想的)不定期がいいと思います。
やりたくなったらその旨を Slack でサッと共有し、その場で直ぐできるならやり、
できない場合カレンダー見て空いてそうな枠を見つけて予定を押さえるか、Slackのリマインダーをセットします。
モブレビューで話している内容や、質疑応答などは Slack のスレッドにでもメモっておくと良さそうです。
issue や PR の説明に書いてないことが出てきたら、説明を修正して追記すると良いでしょう。
定期的に予定をいれる懸念点
- 定例は少ないほうが良い
- 形式的になる
- 定例まで待たなくて良いのでは
- 定例までレビューしないというモチベーションが働く場合もあるのでは
やりたくなったらやる場合の懸念点
- カレンダーをチェックするのが面倒くさい(コストがかかる)
- 人によっては躊躇してしまう
- 場所を確保できないかも
懸念点
- 複数人の時間を拘束して実施することのコスト
- 口頭で説明することに甘えてちゃんと issue や PR に書かなくなる
- 場所を押さえられるか
- モブレビューの意義を共有できるか
- 人によっては時間の無駄と思う人がいてもおかしくない
- 不満や提案があったときにちゃんとそれを言える環境でありたい
ちゃんと文章化するのをめんどくさがって口頭での説明で済ましたがるようになったらよろしくないですね。
自分の反省点
ここまで書いて出てきた自分の反省点としては、 issue や PR の説明でちゃんと Context や Background をもっとちゃんと書かないと駄目かなということです。
口頭で説明する際にはそのへんを最初に意識して話すようにしていますが、説明には書いてないことが少なくないのでちゃんと書くようにしようと思いました。
むすび
今回モブレビューについてあれこれ考えてみました。
まだモブレビューは 2, 3 回やった程度なので、ちゃんと取り組んでみて PDCA 回して改善出来たら良いなと思います。
例えば、今の所定期ではやりたくないと思ってますが、やってみたらちゃんと定期じゃないと駄目だったということもあるかもしれませんし、
モブレビューは目的じゃなくて手段なので、他にもっとよい手段があってモブレビュー不要だったということもあるかもしれません。
やらないと始まらないのでやれたらいいかなと思います。
