モブプロは疲れるが役にたつ

# この記事で伝えたいこと
モブプロに興味があり、ついにやれそうな雰囲気だったので実践してみました。何が良かったか、何に気をつけるべきだと感じたのかを綴っていこうと思います。この記事を読んで、モブプロにちょっと興味を持ってもらえたら嬉しいです。

# モブプロを始めたきっかけ
私は新卒で配属されてから1年間以上同じプロジェクトで開発をしていましたが、今年の11月からは別のプロジェクトにアサインされています。
今までとは全く違う設計のコード、プロダクトに触れ、処理の流れや全体像を追うのに苦戦していました。

**正直、気持ちとしては「モブプロやりましょうよ！いいことづくめですよ！」と言いたいところではありました。**

ですが、なんとなく「教えてもらう立場」でありながらその提案をするのってちょっと傲慢なような気がしていて、チームとしてのメリットをちゃんと示せないとモブプロの提案をできないと思っていました。

ですが、チームにモブプロ経験のある方がいらっしゃり、「新しく入る人も多いですし、みんなでやりませんか？」の一言。そして、いいですね、やりましょうという空気感。

**「これはチャンスだ！」と、私はモブプロの支度を始めたのです。**

# モブプロでよくある失敗
個人的には「まずはやってみよう」の精神を大事にしているのですが、モブプロを始める上でいくつか知っておいた方がいいこと、考えておくべきことがあると考えています。

誤解を恐れず言うと、とりあえずで始めてみたモブプロは高確率で失敗すると思っています。

想定される失敗するケースがいくつかありますが、代表的なものをいくつか紹介します。

### コードの書き方がバラバラで噛み合わない
開発を始める時、まずは何から始めますか？レイアウトから？それとも、ロジックから書き始めますか？あるいは、テストから考えるなんてこともあるかもしれないですね。

コードの書き方は千差万別です。最初に認識合わせをしないと意見が上手くまとまらないこともあります。

### 書いたコードを理解しないまま進む
参加者の開発経験や知識量に差があると起こりやすいと思います。参加者がおいてけぼりになって一方的に進んでしまうと、モブプロの恩恵が少なくなってしまうので注意が必要です。

発言に偏りがある場合は、全員が理解できているか確かめながら進めるといいと思います。

### 思ったより上手くいかなかったのでやめる
上記で挙げたような問題が起こったり、続いたりすると「モブプロって思ったより上手くいかないね」と、期待値とのギャップからやめてしまうパターンもあるかと思います。
もちろん、チームの仕事の進め方とモブプロが上手く噛み合わない場合に無理してモブプロを続ける必要はありません。でも、最初の期待値と違っていてモブプロをすぐにやめてしまうのは、やっぱり、なんかこう、

**もったいない！と思ってしまうんです。**

こういった失敗を防ぐために、いくつか工夫できる点があるのでご紹介したいと思います。

# モブプロをやる上での準備
いくつかご紹介します。また、参考にした書籍もはじめに記載しておきます。

https://amzn.asia/d/gk7aKwH

### 期待値を下げておく
モブプロを始めようとすると、ついついメリットにばかり注目してしまいます。当然、3人分の工数を使ってやるからには相応のメリットが必要です。

しかし、モブプロが効果を発揮するのには一定の時間がかかります。最初からすぐ1人で進めるよりも効率が良くなるやり方とは限りません。

そのため、モブプロをやることに対する期待値がめちゃくちゃ高い場合は、ちょっと下げておくべきかもしれません。

期待値を下げると言っても、マイナスなアピールをするのではなく、あくまで「モブプロは実験的な試みで、効果が出るまで時間がかかるけど長い目で見てほしい」ということを説明しておくといいのかなと思います。

### 流れを決めておく
全体の流れを決めておくと進めやすいです。例としてはこんな感じです
| 時間            | アクティビティ          |
|-----------------|-----------------------|
| 10:00 - 10:15  | タスクの認識合わせ      |
| 10:15 - 10:35  | モブプロセッション①     |
| 10:35 - 10:55  | モブプロセッション②     |
| 10:55 - 11:00  | 休憩                  |
| 11:00 - 11:20  | モブプロセッション③     |
| 11:20 - 11:40  | モブプロセッション④     |
| 11:40 - 11:55  | 振り返り              |

個人的に大まかには上記の流れがおすすめで、ポイントは4つあります

**①タスクの認識合わせをする**
まずタスクの内容を全員理解していないとナビゲートされる方も、する方も困ります。
最初に一度読み合わせて、わからないところは質問などをして疑問点を解消しておくとスムーズに進められます。

**②短い時間に区切る**
20分は意外と短いです。一区切りになりそうなところを目指すとすぐに過ぎちゃいます。
だからこそ、短く区切ることによって集中力を保ちやすいと思います。時間が限られていることを強く認識できるので、なにか議論すべきポイントがあっても適切なタイミングで収束させやすくなります。タスクの内容によって何分で区切るのがベストかは変わってくると思いますが、なるべく短くすることをおすすめします。

**③休憩を挟む**
これはあまり知られてないんですが、実は人間って疲れるんですよね。

モブプロは自分のペースでやるわけではないので、いつもより高い集中力が求められます。そんな状態で長い間人と話したり議論するのは疲れるので、定期的に休憩を挟むことで最後まで集中して取り組みやすいです。休憩中は背伸びやマッサージなんかするのが良いと思います。

**④最後に振り返る**
特にモブプロを始めたばかりの時は、やっておくことを強くおすすめします。
振り返りのフォーマットは基本何でも良いです。シンプルにKPTなら始めやすいと思います。
「期待値を下げておく」でも少し触れましたが、最初のモブプロは大体上手くいきません。スキルが噛み合わなかったり、タスクの内容が噛み合わなかったり、ああだのこうだので「思ったより上手くいかなかったね」となることも多いと思います。
また、あっという間に時間が過ぎてしまうので最後は駆け足で終わり、次回も急ぎ足で始まってしまうかもしれません。人間、忙しい時ほど止まれないものです。
意図的に振り返りの時間をセットしておくことで、モブプロをやってみての意見を寄せ合い、少しずつ改善していくことができます。実際に自分たちのチームでやってみても、5回目のモブプロの時は、初回の数倍は早く実装ができるようになったと感じています。

# モブプロをやってよかったこと
実際に感じたメリットを紹介したいと思います。

### ドメイン知識や開発知識、ツールの使い方などを共有できる
画面共有をして指示を受けながらコーディングするので、自分が知らなかった文法やツールの使い方を知る機会がめちゃくちゃ増えました。

文法なんかはレビューをする時に知ることもありますが、エディターの機能なんかは知らないと一生知らないままだったりします。

自分が当たり前に使っている機能が「なんですかそれは！？」という意外性を与えることも多々あります。

また、1つのタスクを全員でやると、開発スピードは落ちるのではないか？という疑問があるかと思います。たしかに、短期的には開発速度が落ちると思います。モブプロに慣れるまでの時間、新しくアサインされた人がいる場合は環境に慣れるまでの時間、その分の時間はかかります。

しかしその一方で、元から開発の速い人がメインの開発を進めて、他の人は難易度の低いタスクをずっと続けることもリスクです。業務を特定のメンバーに依存しすぎると、異動や退職、体調不良などによる欠席などが重大な問題になりかねません。

みんなで集まって進めることで、ドメイン知識や開発知識を極めて実践的かつ効果的に共有することができます。これは、将来的な開発スピードの向上に大きく寄与すると感じています。

### 開発フローや意思決定が早くなる
とはいえ、モブプロをやることで単純に早くなる面もあります。

わかりやすい例で言うと、コードレビューの負担が激減します。なんていったって全員が書いたコードですから、モブプロで取り組んだタスクはレビューなしでマージするという運用のチームもあると思います。

これは、モブプロをしない場合に発生する「コードを読んで理解する」「意図がわからなかったら質問して回答をもらう」というフェースが発生しないからです。

また、コードを書いていてなにか悩むことがあっても、その場で全員の考えをもって対処できるので、そういう意味ではめちゃくちゃスピード感があります。明らかに解決スピードが早いです。

# 最後に、モブプロをするべきか
ここまで、
1. モブプロでよくある失敗
1. モブプロをやる上での準備
1. モブプロのメリット

をまとめました。

基本的には「モブプロにはこんな良いところがあるよ」ってことを伝える内容です。

が…最後に改めて言わせてください。

**モブプロは銀の弾丸ではありません。**

これは私の尊敬する先輩エンジニアからも言われた言葉です。モブプロをすることで問題が解決するわけではありません。

モブプロを通じてドメイン知識や開発知識を共有したり、技術力向上の促進になることで、開発速度の改善や開発チームの成長といった本来の目的につながります。

**モブプロをやりたいという気持ちが先走ってしまうと、本来の目的とはずれて「モブプロのためのモブプロ」となってしまいかねません。**

当然、チームの状況やタスクの内容によってモブプロの向き不向きもあります。
落ち着いて個人作業をするのが好きだったり、その方がパフォーマンスを発揮するタイプの人も多いと思います。

それでも私はやってみてよかったと思いますし、楽しいです。この記事を読んで興味を持っていただけたら、ぜひ一度試してみてほしいです。

# 最後の最後に一言だけ
モブプロ、めっちゃ疲れます。
2時間やって体感4時間くらいなので、実質精神と時の部屋です。