初めてのリモートモブプロ

## はじめに
この記事は[フリューAdvent Calendar 2022](https://qiita.com/advent-calendar/2022/furyu)の23日目の記事となります。

フリューのプリ画像取得サービス、ピクトリンクのフロントエンド開発をしている磯俣です！
私の所属するフロントチームでは、1年ほど前からスクラム開発を導入し、試行錯誤しながらベロシティ向上を目指しています。
今回は全員リモート環境下でのモブプロにトライしてみたのでそのレポートとなります:writing_hand:

## 現状の課題
今年に入ってメンバーの入れ替わりがあり、元々手探りでのスクラム開発だったのがさらにベロシティが不安定に。。。
![スクリーンショット 2022-12-22 19.15.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2961136/bcf7279a-b6f8-1dfd-3a0c-acb107438c10.png)
上の画像はあるスプリントの最終日前日に見たJIRAのスプリントレポートのスクショです:joy:
**不安定どころか、何も終わっていません。**
決して何もしていないわけではなく、各メンバーがタスクをそれぞれ取り実装はほとんど終わっているのですがレビューやテストが大量に溜まって完了にできないままスプリント後半に来ているという状態です。
自分の実装や各種mtgへの参加などでいっぱいいっぱいになってしまいいつも後半バタバタとタスクを完了まで持っていく、もしくは間に合わない状況が続いていました。

また、メンバーの構成としては私含む中堅2名、新規参画3名とまだピクトリンクの仕様がしっかり把握できていないメンバーがいるため、ドメイン知識やチームの設計方針を伝える時間を取りたいけどいつもバタバタの上記の状態なのでレクチャーが遅れ、申し訳ない状態に・・・（私が来年1月に産休をいただくのでそれまでに新メンバーに色々引き継ぎたい・・・！）

## そこでモブプロ
ベロシティの安定と新メンバーのドメイン知識アップのためにはモブプロが良いのではとスクラムマスターからアドバイスをいただきました！
フロントチームはほとんどのメンバーがリモート勤務なので、現状実装で困ったことがあるとslackのhaddle機能で画面共有しながら相談する、というのは頻繁に行っています。ただ、モブプロという意識してはいませんでした。
なので、まずは効果的なモブプロとは？という勉強から・・・

### モブプロとは
まずは勉強会を開催してチームメンバーがモブプロ導入にあたって共通認識を持てるようにしました。

弊社スクラムマスターおすすめの
 [LODEOでモブプロしたら最高だった話](https://developers.cyberagent.co.jp/blog/archives/9576/)
[モブプログラミングという働き方 #DevLOVE](https://speakerdeck.com/takaking22/mobupuroguramingutoiudong-kifang-number-devlove)
こちらを参考に、基本的なモブプロの手法を学んだ上でのイメージは・・・

* まずはメンバー間で打ち解けるのが先？
    * リモート勤務&新メンバーが多いというのもあり、まだお互いの人柄やスキルもわかっていないので発言しにくい？
* 実装は1人でやる方が楽そう
    * 自分のペースで試行錯誤する方が他人に気を使わず楽ではある。
* 効率的にはレビュー省けるなら良い方法かも
    * ここは期待できそう。PRレビューに現状時間を割きすぎている。
* オンラインだと発言しづらそう（発言が被るとやりづらい）
    * これは普段のmtgでもあるある。
* 分かる人だけ話しあって、わからない人は黙って見てるだけ、だとあんまり効果なさそう＆お互い辛くなりそう
    * 2人以上だとその危険性あり
* オンラインモブプロの成功例を見たい
    * 参考記事はオフラインだったので

などなど、少し不安な感想が多い印象。

私たちのチームでやるなら・・・？を想像すると、リモートでの開催なので
[モブプログラミング超入門ライブ ! ~FizzBuzz 編 ~ #AWSDevLiveShow](https://www.youtube.com/watch?v=VQPSG0nLHn8)
こちらの動画を追加で各メンバー空いている時間に見てもらい、事前にざっくりルールを決めて実際にやってみました。

### ルール
* モブプロを行うタスクは事前に細かい粒にし、何を実装すべきかを全員把握しておく
* 新メンバーがいるので、実装前に必要なドメイン知識などは知っておく
* テスト駆動開発（TDD)で実装するためテスト項目だけ事前に用意しておく
* メンバーの表情や呟きを見ながら進めたいのでzoomではカメラ・音声オン
* その場で実装の方針などを決めた場合、後日経緯を忘れてしまうかもしれないのでzoomを録画しておく
* ドライバーは15分で交代する

### 実際やってみた結果
既存機能をvue.jsに移行するタスクを4名でやってみました。
結果、事前の仕様整合が足りず事前に用意していたテスト項目の確認時点で
「この場合、どこに遷移させれば・・・？」「この条件を加えた方がいいのでは」
など実装以前の話し合いで1hほど使ってしまいました:frowning2:

以下、参加メンバーの感想です。

#### 悪かった点
* 事前の仕様整合が足りず、まず仕様の相談で時間をとってしまった
* 一人（私）が喋りすぎ
* 休憩時間を取るのを忘れてしまった
* ドライバーをやってみて、どこまで自分の意思で動けば良いのか迷った（指示待ち時間があった）
* ついていけない部分があった
* どこを見ながら話しているのか分からないことがあった
* 全員がテンションを上げていかないと長時間はしんどそうだと思った
* 技術的思考回路より、コミュニケーションに気を取られてしまった感
* リモートと出社が混ざるとやりにくいかも
#### 良かった点
* 4名で一緒に考えることで共通認識が出来た
* 全部実装をモブプロで終わらせられればPRレビューは不要そう！
* 人の使っている便利そうなツールを知れた
* 実装部分だけでなく仕様の理解にも繋がる
* ショートカットとか手捌きは今後の参考になる
* テスト駆動開発の勉強にもなった
* コードについて話すのが新鮮で楽しい


## まとめ
次に生かしたいこととして、
* ドライバー交代ごとに5分-10分休憩を挟む
* ある程度の仕様は事前に確認しておく
* 「間違っているかも」とか「みんな知っているかも」と思って発言を躊躇しない

などが挙がりました。
最初は一人で実装した方が楽だなー&スクラムマスターからモブプロを真面目にしようとするとしんどい、と脅されていたので決してメンバー全員がノリノリでの実施ではなかったのですが、
実際にやってみて、
「一緒にやるっていいですね〜」
「こんなショートカット、ツールあるんだ〜」
「うふふ、なんかたまにはいいですね」
みたいな感じで改善点はたくさんあるものキャッキャウフフ:blush:しながらやってよかったな感はありました。（個人の感想）

当初心配していた心理的安全性の面では、モブプロを重ねていくことで向上することもありそうだなと感じました。
また、年明けにメンバーの親睦を深めるためのイベントも検討しています。

全てのタスクをモブプロで実装するのは急には難しいですが、サービス主要機能などの実装や、特に新メンバーが入った時期には今後もモブプロを実践していきたいと思います:muscle:（していって欲しいです！）