モブプログラミングけっこうイイんじゃね？ ってことで効果を上げる方法を整理した

僕らのチームはだいたい 1 時間で 1 ネタのモブが終わるか延長戦するかって感じだったんだけど、最近はうまくいくと 1 時間で 3 ネタ ¹ 片付けて、さらにダベる時間までできたんだよね

僕は自分でガンガンやるコーディング大好き人間だったのでモブプロはあんまり好みじゃあなかったけど、「ん、結構よくね？」って気持ちだ

なのでちょっと考察してみた

モブプロの効果と目的

まず、意思決定が早くなる

よく言われるがこれは考えてみれば単純で、待ち時間の大幅な短縮が行われるからだ

各人が別のタスクをしている場合、質問やレビューの相手をしてくれる人を待たなければいけない

けど、誰しも自分の都合の良いタイミングで返事がすぐ欲しいと思うが、自分のタスクは中断したくないだろう（ワガママ！）

チャットを送って返事を確認するのと直接話すの、どっちがスムーズかは想像しやすいだろう

非同期やり取りのイメージ

同卓での同期やり取りのイメージ

また、全員で同じタスクに取りかかることは、必然的にチームの wip ² の数を減らすことにも繋がっている

次に、人の集まりが「チーム」として成立する

モブプロではなく各メンバーのリソース効率（工数と成果と言うとイメージしやすい）を重視してチームの生産性を最大化すると、各自の得意なタスクが各自に割り振られるので、属人度が跳ね上がる

属人度が上がるとベテランが作られ、質問やレビューがベテランに集中し、そこがボトルネックになる

また、チームの生産性はベテランの予定やタスクとのマッチ度でブレまくり、チームの見積もりも何もあったもんじゃあなくなってしまう

さらに、そんな状況でベテランがいなくなったら超やばい

実質ベテランだけが成果を出しているこんな状況が、チームと言えるのだろうか

対してモブプロはリソース効率ではなくフロー効率（ものを継続的に安定して動かすこと）³ を重視し、プロダクトを安定して高速にインクリメントできることを目的としている ⁴

例えばモブプロは「1 人欠けてもできることの種類は減らない、ただ量が減るだけ」という状況をつくり上げることができる

この形が**継続して安定的に**プロダクトをインクリメントできる理由とその効果を上げる方法を、これから僕なりの考えて示したい

モブプロをするときは「どっから」「どこまで」をみんなで共有する

僕らのチームは最近はモブプロをやる前に必ず成果物の認識合わせと準備の時間を設けている ⁵

もう一度言うけど、1 時間で 1 ネタくらいだったモブが 1 時間で 3 ネタくらいになる日もあるんだ
それは、この形でモブプロを積み上げたからだと思っている

ある 3 人の仮想チームのモブプロを想像しながら、それの大事さを整理してみよう

このチームには（左から順に）新入りとベテランと中堅がいて、モブプロをやってみることになったところだ

これはモブプロによってプロダクトをどれくらいインクリメントするつもりかという様な感じの絵だ
青い Ｘ は想定するみんなの事前知識量、矢印の終点はそのモブプロでどこまで作るつもり ⁶ か、をイメージしている

さて、このチームのベテランは上の絵の様に思っているが、実はそれは全然揃っていない...!!

中堅はちょっとずれているし、新入りは果てが見えていない

これに気付かずモブプロをすると、こんな感じの会になる

全然モブプロになってない！

これではそこに 3 人でいただけだ！
実質ベテラン依存から脱却していないね

まずは成果物の認識合わせをして、そのモブプロでどこまでやるかをみんなで揃えよう

「とりあえずクラス図は手書きまで、清書はあとで誰かが預る」とか「外部システム結合の整理には連携キーを明記」とか「エラーパターンは全部列挙するが、個々の処理は次回実装」とか「デプロイして穴開けて疎通確認まで」とかをちゃんと話してモブプロのアウトプットをみんなでイメージする

ただし、誰がは決めない、それは興味の範疇ではないし、誰になっても大丈夫な様に準備をするんだ

注意　どこに合わせるか

---

一番低い人に合わせるのでは集団の知識を活かしてることにならない

あくまでプロダクトをインクリメントする活動の副次効果に学習があるのであって、学習のためにみんなで集まって見守る会であってはならない

「ひとりだと出来ないのでモブプロで」という考えもわからないではないけど、そういうモブプロを経ればひとりでできる様になるかは別だ、というか多分ならない

理想は各々が「ちょっと背伸びする」くらいの箇所だと思う

一番低い人にスピードを合わせるのは良いが品質を合わせるのは要注意だ

---

次に「準備」をはっきりさせよう

「穴開けるってことは既存のネットワーク構成図いるなぁ」「エラーパターンは何みたら列挙できるっけ？」「そういえば昔〜〜なバグがあってなぁ」「単語帳が欲しい」なんて話していると、必要なモブプロのインプットがはっきりしてくる

はっきりしてきたらインプットをみんなで集めて、理解不足があると思う人はモブプロまでに予習をする

注意　どこに合わせるか

---

一番高い人に合わせるのは理想だけど現実的ではないし、知識の交換になってない

メンバ間のやり取りが高速になり知識が共有されるのがモブプロの目的の一つなので「全員全部わかるまで準備しよう」よりは「モブの中で補完し合おう」って方が結果的にチームのフロー効率は上がると思う

少なくとも「必要な資料をはっきりさせてそれは目を通してから集まる」くらいはしたいが、細かい説明を要するものはモブの中でやるくらいが良いと、僕は思う

---

成果物の認識合わせと準備をちゃんとしたモブは、きっとこんな感じの会になる

これなら立派にモブプロだ！
「ただ集まってただけ」なんて感じないだろう！

この緑の部分の経験値は、本当にでかい！

モブプロは積み上げる

さらに大事のはここからだ

モブプロは積み上げるんだ、だってインクリメントだし！

インプットとアウトプットをはっきりさせようと言ったけど、当たり前ながらモブプロのインプットは前のモブプロのアウトプットなんだ
（興味がある人は Process Flow Diaglam とか調べてみよう、超大事な考え方だ）

だから、うまくいかないモブプロを繰り返しているとモブプロはどんどんうまくいかなくなる

けど、みんなで着地点が揃っているモブプロができると、次のモブプロがそこから始められる！

これが繰り返されると、だいたい成果物の認識は揃ってくる
そして何より驚くほど準備が減る

僕らは前は 1 時間のモブの前に 1 人 30 分までの準備時間を計上していたけど、最近は「この間話したあれだよな」って言って準備がほぼ一言二言で終わる様になった！

もちろんモブ自体もどんどんスムーズになっていくので、1 回の時間も減るし属人度も減っていく

こうなってくると「あれ、案外モブプロもいいな」って気にもなるよね

おしまい

「なんとなくモブプロっぽいことをやる」のはすごい簡単なんだ
集まれば良いだけだし

けどそれでうまく行かなかったときに安直に辞めずにチームで考えてよかったなー

モブプロがこの形になってくると「最近早くね？しかも毎週安定してね？」って声が上がり始めるんだ

好調さに驚いて書いた次第、でしたとさ

tips

あとは、普段気をつけていることなんかを軽く紹介する

💡 各種設定は確認しておこう

行番号を表示したり、フォントを大きくしたり

地味だがかなり大事だ

✅ エディタやショートカットキーは自由

モブプロが意思決定や知識共有に重きを置いているなら、道具の制限はないと僕は思う

むしろ小技なんかはどんどん見て盗むなり聞くなりドヤ顔するなりして交換したら良いと思う

👍 必要な情報の予測をしてみよう

「ん、なんか噛み合ってないな」とか「あ、あの話になりそう」みたいな瞬間に誰かがさっと「チャットにあれ送ったぜ」なんて時は、グッとくるものがあるね

ほかに例えば稀にしか使わない文法や関数なんかにぶち当たったときに誰かが先回りして調べておいてある、とかね

💡 休憩はどんどん取る

キリが良ければがんがん休憩したら良いと思う

気分転換するなり、気になってたメッセージの返事をチェックするなり、好きにしたら良い

席を離れるのも良いし、ダベるのも良いと思う

🚫 全てのタスクをモブプロしない

定型作業の様な意思決定が伴わない作業までモブプロしたり全員で打ち合わせに参加して議事録省略の様な発想は、警告サイン

ノウハウ伝達や情報共有の方法は、きっとモブプロより良い方法がたくさんあるはずだ

🚫 ついていけない人を攻撃してはいけない

そんな人がいても、よほどの場合でない限り「事前の準備およびやり方の認識合わせから全員で失敗しちまったんだなぁ」という風に考えよう

そもそも批評して良いのは成果物であって人の批判は絶対に NG だ

それと、批評する時は事実で、だ

「イケてない」とか「難しいから仕方ない」ってのは主観なので、「今後の修正箇所が増える」とか「全く聞いてないお作法だった」みたいに伝えよう

👍 ソロ開発の時間ももちろんあって良い

「じ〜っくり取り組みたいから一人でやりたい」ってのも全然ありだし、「なんか閃きそうな気するから預からせて」「じゃあその下書きできたらモブプロ始めよう、そこで見せて」みたいなのも全然あり

人次第タスク次第で合う合わないは絶対あるし、リソース効率よりフロー効率を重視するスタンスで色々アレンジしたら良いんじゃあないかと思う

1. ちなみにモブプロって言ってるけど、コーディングに限らずインフラ設計やらドメインモデリングやらの設計活動もモブプロとして扱っている　チームでプロダクトをインクリメントすりゃあ、それはモブプロだろ、ってこと ↩

2. work in progress つまりチームの仕掛かりタスク ↩

3. 　 この本ではリソース効率とフロー効率を高速道路と車にたとえて説明している　リソース効率を上げるなら隙間なく車を埋めることになるが、それでは誰かのブレーキが渋滞を生むのは周知の事実だ　だがフロー効率を上げるために車を減らして車間距離を空ければ、どの車も安定して高速を維持できる、と ↩

4. なのでよくある勘違いは「本当に 4 人でやったら 1 時間のタスクが 15 分になるんだろうな」という問い　もちろん 1 時間かからないとは言え、モブプロはコスト削減のための手段ではないことに留意しなければならない ↩

5. ちなみに恥ずかしながら、特にモブプロ導入時に勉強したりはしなかった　とりあえず始めて失敗しつつも見つけた形 ↩

6. テストは書くのか？設計だけか？英語も決めるのか？実装は主要ケースだけか？デプロイと動作確認はするのか？等等等 ↩