今年3月頃から，チームにモブプログラミングを導入している．「スウォーミング（共同作業）」と「フロー効率（着手している作業を最速で終わらせること）」を文化に根付かせることと，技術的な強さを伝播させる狙いで導入して，今のところ多くのメリットを感じられているけど，ベストプラクティス（もしくは基本型）を学んでみたく，Leanpub で購入できる電子書籍「Getting Started with Mob Programming」を読んだ．非常に良かったので，学んだことを整理して紹介したいと思う．
追記 : Code with the Wisdom of the Crowd
本書「Getting Started with Mob Programming」は，2018年末頃に Leanpub で販売中止になってしまった．現在は同じ著者が出版した「Code with the Wisdom of the Crowd」を読むと良さそう．類似した内容になっている．
目次
- Part I - Before you start
- 1 What is Mob Programming?
- 2 Frame Mob Programming as an experiment
- Part II - Getting to your first mob session
- 3 Where to mob first?
- 4 What should you work on?
- 5 How big should the mob be?
- 6 When & how long should the first session be?
- 7 Preparing the development environment
- Part III - Your first mob session
- 8 Outline for the session
- 9 Explain the roles to the group
- 10 Determine the order for rotating typists
- 11 Start the first interval and mob for ten minutes
- 12 Rotate typists and start the next interval
- 13 The closing retrospective
- 14 Forming, storming and conflict
- Part IV - Gaining momentum
- 15 Your next few mobbing sessions
- 16 When only one person knows…
- 17 When nobody knows…
- 18 Getting rhythm with core mobbing time
- 19 A permanent place to mob
- 20 Getting a mob station
- 21 Where to from here?
モブプログラミングのテーマを選ぶときの条件
本書では「全ての仕事がモブプログラミングに適しているわけではない」という前提で，以下の条件を満たすテーマを見極めることが重要と書かれていた．個人的には「フロー効率」を意識しているので，期限も意識していて，ここは言い過ぎないようにしないとなーと感じた．
- It should be interesting（楽しそう）
- Everyone should be able to contribute（貢献したい）
- It should be small, but not too small（小さすぎず，小さく）
- It should not have a tight deadline（タイトな期限がないこと）
- It should not be overly complex or simple（簡単すぎず，難しすぎず）
モブプログラミングに適切な人数
本書では「3-8人」が良いと書かれていて，特に「4人」がベストと書かれていた．理由としては「3人」だと，ミーティング／体調不良などで1人不在になると「ペアプログラミング」になってしまう点が問題で，「5人以上」だと必要以上に「ストーミング」が起きてしまう点が問題だと書かれていた．「ストーミング」とは「タックマンモデル」に出てくるもので，組織の成長に必要な「対立」のことを意味している．必要だからこそ，人数が多すぎると必要以上に「対立」が起きてしまうと書かれていて，個人的には納得できた．
モブプログラミングに必要な役割の名称
一般的には，モブプログラミングの役割は「ドライバー」と「ナビゲーター」と呼ぶけど，本書ではあえて呼ばず，以下の用語で統一されていた．理由としては「メタファーは適切ではないから」と書いてあったけど，個人的にここはあまり納得できていなく，むしろわかりにくくなっているように感じた．なので，記事の中では「ドライバー」と「ナビゲーター」に統一している．
- the typist（ドライバーと同義）
- the rest of the mob（ナビゲーターと同義）
モブセッションの時間
最初は「1時間半」から始めるのが良いと書かれていた．そして「1時間半」を分割するときに，スキルレベルによって時間を短くするのも有効と書かれていた（例えば，新人は「15分」など）．僕のチームでは「ポモドーロ（25分 + 5分）」でモブセッションをローテーションしている．また「時間を守る，時間を伸ばしすぎないこと」も重要と書かれていた．
MDE とは？
モブプログラミングをする環境のことを，本書では MDE (Mob Development Environment) と表現していて，以下の5種類が紹介されていた．
- エディタ
- キーボードショートカット
- コードナビゲーション
- バージョン管理ツール用アカウント
- タイマー
モブプログラミングの基本型では，チームで1台のマシンを使うので，エディタもショートカットも一般的なものに揃えておくと良いと書かれていた．例えば，チーム全員で IntelliJ を使うなど．あと vim の話もあり，他のメンバーの学習コストが高いので，避けるべきと書かれていた．また個人的に興味深かったのは，モブプログラミング用のバージョン管理ツール用アカウントを作るという話だった．確かに GitHub のコミットログを見たときに，モブプログラミングなのに特定のメンバーのコミットになっていると，モチベーションが下がってしまう．
個人的には，エディタも，ショートカットも，キーボードなどの周辺機器も，揃えるのが難しいと考えているので（例えば，僕は HHKB が必須だったりする），僕のチームではモブセッションごとにドライバーのマシンを接続している．ディスプレイに接続するアダプタとして「HDMI / USB-C / Thunderbolt」を用意しておけば，ほぼ大丈夫なので，そこまで強制しなくて良いように思う．
割り込みを排除する
本書で何度も出てくる「モブプログラミングはフローである ( A big aspect of Mob Programming is flow )」という表現がとにかく好きで，だからこそ，そのフローに割り込まないようにするべきという話題もあった．例えば，途中のモブセッションに参加していなかったメンバーが戻ってきたときに「その後どう？」と聞くのはダメで，静かにモブセッションに参加して，状況を読み取るべきと書かれていた．また，スマホの通知を受けるとコンテキストスイッチが起きるので，それも気をつけるべきと書かれていた．僕のチームでは，基本的には Slack を落としてもらう工夫をしている．
まとめ
記事に書いたこと以外にも，モブプログラミングを運営していて気になっていたことを多く学ぶことができた．ベストプラクティス（もしくは基本型）に完全にハマる必要はないので，チームごとにカスタマイズをするべきだと思うけど，だからこそベストプラクティス（もしくは基本型）を学んでおくべきかなと思う．これからモブプログラミングを導入しようと考えている人，モブプログラミングを導入しているけど，うまく運営できていない人，モブプログラミングのファシリテーションを担当している人などにオススメ！
