あなたのチームはどんなモブ？モブプログラミング・フォーメーション！
この記事はモブプログラミング Advent Calendar 2019 ７日目の記事です。
モブプログラミング(以下モブプロ)とは... いつものやつ貼っておきますね。
モブプロが大好きでして、実務でもチームのデフォルトの働き方としてモブプロを採用しています。 今年はXP祭りなどでもモブプロについて発表させていただきました。
開発フォーメーション
あるきっかけで、「カイゼンジャーニー」「正しいものを正しくつくる」の著者である市谷 聡啓(@papanda)さんと「開発フォーメーション」についてお話しさせていただく機会がありました。
そう、フォーメーションです。全然詳しくないんですが、サッカーとかラグビーとかのスポーツにもこういう概念がありますよね？ 攻撃的な陣形！とか。もちろんこんな低解像度の理解でやってないと思いますが...
僕が一番遊んだサッカーゲームといえば「ロックマンズサッカー」ですが、それにも確かあったような。。 まあサッカーでこんなドマイナーゲームが出てくる程度にはスポーツ素人とお考えいただければと思います。
とにかく、フォーメーションは模倣することで意図する効果を引き出しやすくするための "カタ" であり、またそのフォーメーションの意図をチームが理解し、練度が高まれば、フォーメーションが決まれば戦術も決まるという具合に専門家の会話のような効果もあるのかなと思います。 これをソフトウェア開発でもやってみよう、と。
開発フォーメーションは、市谷さんにより「曳光弾開発」や「雁行陣開発」が紹介されています。
モブプロ自体が一つの開発フォーメーションだな、と思う一方、もっと解像度を上げてみると、モブプロをやっているときでもチームやコンテキストによって色々なやり方を取っていることに気が付きました。
フォーメーション、つまり "カタ" を知っておき、その時のコンテキストや対応したい問題に合わせてフォーメーションを選択できるようになれば、先人たちが踏み抜いた地雷 - アンチパタンを無駄に踏むこともなくなり、より良いモブの発展に貢献できるのでは、と。
市谷さんとお話したことを思い出して、（これも詳しくもないのに、、）フォーメーションをパタンの形式でまとめてみることにしました。 これがモブプロのパターンですと言いたいわけではなく、なんとなく直感的にパタンの形式で記述したほうが説明しやすそうだなと感じたのでやってみました。 パタンを抽出できるほどモブの場数を踏んでないですし、フォーメーション間の関連とか全く整理できてないですし、誰とも議論できてないのでパタン・ランゲージでもなんでもないのですが、練習ということでご容赦いただければと思います。
パタンの形式は Learning Pattern と、大好きな Fearless Change を参考にしました。
learningpatterns.sfc.keio.ac.jp
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者:Mary Lynn Manns,Linda Rising
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
コラ！と感じられた方、お手数ですが是非フィードバックをいただければ🙇
なお、モブプログラミングのパタンについては、Agile2019で Harvesting Mob Programming Patterns: Observing how we work1 というExperience Report で報告されています。
ロールなどベーシックなものから、僕たちのチームでも遭遇したことのあるアンチパタンまでモブプロあるあるが集まっており納得感があります。 日本でやっている人たちとも是非、こういう共通点を見つけるような議論をしてみたいです。 スライドも面白かったのでチェックしてみてください。 なんとなく、今回紹介するフォーメーションと関連しそうなパタンもいくつかあったのですが分析不足です。。
前置きが長くなりましたが、これまで発見したモブプロ・フォーメーションをいくつかご紹介します。 タイトルの先頭の数字は人数の振り分けを擬似的に表すものです。フォーメーションぽいかなと思い。 モブプロは最大５〜６人程度でやるのが良いと感じていて、以下は６人あるいは５人の割り振りとお考えいただければと思います。
1 - 5: Smart Input Operator2 / 賢い入力手
チームを正しいことに集中させる
状況
モブプロを始めたい、あるいは始めた。
問題/フォース
ドライバが入力しているのをナビゲータが眺めている。会話が少ない。
- チームが議論に慣れていない
- ドメイン知識/専門性が深い人がずっとドライバ
- 交代時間が長い
- e.g. キリのいいところまでやる
解決
- Strong Style3 のルールに従う by Llewellyn Falco
- "For an idea to go from your head into the computer it MUST go through someone else's hands"
- "アイディアがコンピュータに入力されるためには、誰か他の人の手を介さなければならない"
- ドライバはタイマーで交代する
- ドライバはナビゲータを 信頼 し、議論の結果をコードに落とすことに集中する
- ナビゲータはドライバの理解度に応じて指示の抽象度を上げ下げする
結果状況
オリジナルの論文4で紹介された、最もオーソドックスなフォーメーションであり、この先のすべてのフォーメーションの基本となる。 モブプロで良い結果を出すには、チームメンバー感の信頼関係が土台になる。ドライバはナビゲータの判断に敬意を払い、ナビゲータはお互いを尊重することで、モブは効果を発揮し始める。 複雑なソフトウエアをこれまでにない速度で構築できるようになる。 チームや（いる場合は）ファシリテータがモブの練度が高くない場合に、議論の収集がつかないなどモブを制御できなくなる場合がある。 その場合は、助手席から始めよう。
1 - 1 - 4: Front Passenger Sheet5 / 助手席
助手席に乗った人が一番ナビしやすい
状況
モブプロの経験が浅いチーム/ファシリテーター。 あるいはワークショップなど、モブのスケールアップの必要性に迫られている。
問題/フォース
メンバーの発言回数に極端に偏りが出る。あるいはナビゲータの議論がまとめられず、ドライバが手を動かせない。
- ドメイン知識/専門性が高い/声が大きいメンバがいて、その人ばかりがしゃべる(a/k/a Ridin’ Shotgun Anti-Pattern6)
- 積極的に議論に参加したがらないメンバーがいる
- 理解が薄い
- 内向的
- 大きな規模で開催したい
- チームがモブに慣れていない
解決
主にナビゲーションを行う「プライマリナビゲータ」を置く。
- プライマリナビゲータを置く
- 基本的に指示はプライマリナビゲータが出す
- 他のナビゲータも発言しても良い
- プライマリナビゲータが喋らないと進まないので、発言したがらないメンバーにも発言の機会が与えられる
- ３〜５分など、頻繁に交代する
- '非アクティブ/アイドル' な状況が続くと集中を持続することが難しい
- 一人がひたすら喋る状況を回避する
結果状況
Llewellyn Falco氏のモブプログラミングワークショップセッションでよく見かける。 Agile2019 Conf の際、野良で行われていたモブプロセッションに参加したとき(冒頭の写真)もこの形式だった。 主に発言する人間を置くことで、制御がしやすくなる反面、アイドル時間が増え、リソース効率が悪くなる上、モブ本来の効果が薄まるというデメリットもある。 ファシリテーションのしやすさや、スケールさせやすいというメリットを活かし、導入時やワークショップなどで用いると良い。
6: One Team / ワンチーム
"アイディアがコンピュータに入力されるためには、チームの 合意 を得なければならない"
状況
チームの成熟度が上がってきて、全員がモブプロを効果的に行うために必要なことを理解した。 チームは更に複雑な実装/これまでに経験したことのない技術に取り組もうとしている。
問題/フォース
ドライバの手が頻繁に止まる。
- ナビゲータ全員の知恵/目線を持ってしても原因を特定できない
- チームに現在取り組んでいる領域の専門家がいない
- モブに参加している人数が少なく、意見に多様性がない
解決
ドライバも議論に参加する
- Strong Style の拡張
- "For an idea to go from your head into the computer it MUST go through team's agreement"
- ドライバの権限はたいへん強いため、チームの合意をもって入力する
- 必要に応じて調査を分散して行う。時計を止める必要はないが、止めておいても良い。
- 一番スジの良さそうなものをメイン画面で調査する
- 時間を決めて情報の同期をとる
結果状況
ドライバも議論に加わることで、シンプルにモブの多様性を増加することができる。 ただし多様性が増加する分、制御が難しくなる。 ドライバ/ナビゲータともモブのやり方に精通しており、お互いを尊重すること、ドライバの独壇場にならないようにする必要がある。
3 - 3: Sync-Mob / 同期モブ
同じ場所で、同時に、 違うことを
状況
モブプロにチームが慣れ、リードタイムは定常的にモブプロ導入以前よりも短くなっている。 取り組むタスクの並列数（WIP）が常に１であるため、スループットが上がらない。
問題/フォース
チームのスループットの低下
- 規模の大きなタスクに取り掛かり、他のタスクが進まない
- モブのサイズが大きくなり、リソース効率が低下する
解決
２つのモブを同じ場所で、同時に行う
- ディスプレイ、マシンをそれぞれ準備し、同じ場所で２つのモブ、２つのタスクを実行する
- いつでもモブ間のコミュニケーションを取れるようにする
- 常に同期をとることで、２倍のタスクをこなしつつ１つのモブとして動く
- 同じPBIに対する分割したタスクを実装する
- e.g. 片方のモブでフロント、片方のモブでバックエンド
結果状況
モブプロの利点の一つは場所の局所化によるコミュニケーションコストの最小化である。この方式を崩すことなく並列度を上げることができれば、チームはそれまでの２倍の仕事ができるようになる。 また、同じ場所でコミュニケーションが開けていることで、並列で進める場合の結合リスクも最小限に留めることができる。隣のチームにインターフェースを常に確認しながら進めば良い。 ６人を分けた場合は３-３人となり、モブの最少人数になってしまう。必要に応じてそれぞれでワンチームも併用する。
2 - 1 - 2: Double-Linking / 接続
２人がつらければ、モブを繋いでみよう
状況
スループットの問題を解消するためモブを２つに分けたいが、５人しかメンバーが揃わなかった。
問題/フォース
ペアの方が負荷が高く、モブよりも進捗が悪い
- ペアの負荷がモブと比べて高い
- ドライバが回ってくる頻度が多い
- ナビゲータは喋りっぱなし
- ナビゲータの目線が少ないので、モブ本来の効果が得られない
解決
Linking-Navigator / 接続ナビゲータ を置く
- ナビゲータの一人が、２つのモブを繋ぐ役割をする
- 両方で起こっていることをナビゲーションする
- 擬似的にペアを避ける
- 接続ナビゲータはセッション中はドライバに参加しない
- ２つのモブのドライバ交代時間・セッション終了時間の時計を合わせる
- 接続ナビゲータの負荷が高いため、１セッションごとに交代する
結果状況
接続ナビゲータにより、５人のときでも擬似的に同期と同じ効果が得られる。 ただし接続ナビゲータの負荷が高く、一日中やるには向いていない。 タスクの難易度や重要度によって並列を解除しワンチームへ移行するなど、フォーメーションを柔軟に変更しながら対応しよう。
まとめ
いかがでしょうか。 先に述べたとおり再現性も確認できていないのですが、コミュニティの議論のきっかけになり、モブプロの発展に少しでも貢献できればいいなと思います。
そして、モブプロにはまだまだいろんなフォーメーション/パタンがあると思います。 今考えているところだとスケール、複数のモブチームの協調にもフォーメーションがありそうです。 モブプロを実践していてフォーメーションやパタンを感じたら、ぜひ教えてください！
-
モブプロの創始者 Woody Zuill 氏がドライバーのことを “Smart Input Operator” と呼んでいたことにちなむ。↩
-
The way things work in Llewellyn's world: Llewellyn’s strong-style pairing↩
-
Harvesting Mob Programming Patterns: Observing how we work より↩
