FlexBusのテスタで，テストに関するブログを執筆しているLisi Hocke氏は先日，ブラチスバラで開催されたTesting Unitedカンファレンスで講演し，部分的にモブプログラミングを使用した"全チームアプローチ(whole-team-approach)"をテストに適用することが，協力的な開発環境の構築に有用であった自身の経験を語った。その中でHocke氏は，ペアリングのドライバとナビゲータの関係をより規模の大きなモブへと拡大することによって，最大限の積極的な参加を実現した方法について説明した。"Mob Programming Guidebook"の著者であるMaaret Pyhäjärvi氏と，"Pragmatic Unit Testing in Java"の著者で，Robert Martin氏の"esteemed Clean Code"でもいくつかの章を執筆しているJeff Langr氏も先頃，モブプログラミングの効果を最大化するための独自のパターンに関する記事を書いている。
Hocke氏は最初，自身のチームで"定石通りの"モブプログラミングを試行して，その効果を確認したという。ペアリングはともすれば，知識を持った者がキーボートを独占する状況に陥りがちだ。それを回避するためにモブプログラミングでは，ドライバ-ナビゲータパターンを強く意識している。氏はそれを、"強いスタイル(strong-style)のペアリング"と表現している。要は，"アイデアをコンピュータに投入するためには，誰かの手を借りなければならない"、ということだ。そのための合理的な行動として，氏のチームは、オンデマンドのモブを選択した。必要であれは，"事前のモブのストーリを決めておく"こともある。Hocke氏によると、モブは明示的および暗示的な知識を顕在化し、共有する手段であると同時に，"全員の知恵を寄せ合うことで，難しい問題を"解決する上でも有効な方法なのだ。
Langr氏は先頃，"Solo Programming, Pairing, and Mobbing: Which Is Right for You?"と題した記事を執筆し，2018 Agile and DevOps Eastで自身が行った講演のテーマを引き続き論じている。記事の中で氏は，ソロプログラミング，ペアプログラミング，モブプログラミングという3つのパターンを取り上げた。ソロプログラミングとペアプログラミングには，いずれもコミュニケーションと知識共有に関わる問題を含んでいる，と氏は言う。開発者とテスタが、"無数のインタラクションを伴うシステム"を構築している状況においては、あらゆる分離が"頭痛とコスト上昇"の原因となり得る、と氏は記事で述べている。
ソロプログラミングにおいては、これがコスト上昇とコミュニケーションの遅れや、調整不足による退行の要因になる、というのが氏の意見だ。ペアプログラミングに関しても、氏は、チーム内におけるサブサイロの形成や、複数のペアを効率的に管理する上でのオーバーヘッドから発生する同様の問題を指摘する。これは、ひとつのソフトウェアインクリメントを協力的かつ同時に作業するという、チーム規模のモブプログラミングの持つメリットとは対照的なものなのだ。Langr氏はこれを、モブプログラミングが、他の状況で見られるいくつかの障害を取り除いた結果だと見る。モブプログラミングのメリットとして氏が挙げるのは、次のようなものだ。
- "誰と誰がペアになるのか？"という問題に対する調整や個人的偏見の除去。
- "同じ部屋にいるため、全員が事態を理解している"ことによる、意見調整の必要性の除去。
- 共同作業や教育に付きものの儀式的行為が少なくて済むこと。これらはモブプログラミングでは絶えず行われているためだ。
Pyhäjärvi氏の記事も同様に、テスタが目標とする、あるいは参加することの可能なコラボレーションモデルとして、個人作業、従来型のペアリング、強力なスタイルのペアリング、モブテストについて論じている。強力なスタイルのペアリングは"モブプログラミングの基盤"だ、と氏は言う。すなわち、
このスタイルの開発では、ひとつのタスクをグループが担当して、メンバが順番にコンピュータに向かいます。アイデアはコンピュータ上にはなく、参加メンバが出すのです。こうすることで、全員のベストを引き出して、行っている仕事に注ぎ込むのです。メンバ全員が順番にキーボードに向かいます。そのタスクに詳しくないメンバがいれば、他のメンバ(モブ)が適切な抽象レベルに導く手助けをしてくれます。
Hocke氏も同じように、氏のチームにおけるモブへの合意が強力なスタイルをサポートしていることを説明した上で、ドライバによるアイデア提案を促しはするが、"グループに追いつくように急がせることはしない"、と述べている。さらに氏は、全員参加でないモブを許容することにより、個々人がモブ以外の作業に参加することを奨励する一方で、それが終われば急いでモブに戻る、という彼らの熱意についても言及している。
Pyhäjärvi氏とHocke氏はともに、モブプログラミングが結果として効果的なペアリングを実現している点を指摘する。Hocke氏は、"さまざまな集団の"中において、"モブの副産物として、ペアの形成が突然多くなっている"と述べている。またPyhäjärvi氏は、強力なスタイルのモブテストを使用することによって、ペアリングのシナリオにによるコラボレーションが容易になったことを挙げている。
私にとって，強いスタイルに慣れるというのは，フラストレーションを感じていたペアリングが、楽しく学ぶ場になったということです。これは私自身が望んでいたものなのです。モブも同じです。モブはペアリングの入り口であって，チームメイトの誰かと2 人だけでいるよりも，グループの中にいる方がで安心できます。
Hocke氏は，チームが向上を続ける上で，チームの枠を越えたモブやテストを行ってみたい、という希望を述べている。Langr氏もまた，管理上のオーバヘッドに注意を促しながらも，局所的なバイアスの増大を防ぐ上で，ペアのスワッピングを行うことを望ましいプラクティスとして推奨している。
2人の頭の方が1人よりも優れているのですから，ペアはより品質の高く，メンテナンスコストの低いソリューションを生み出すことができるはずですが、そうであっても，できの悪い設計で開発が無駄になる可能性はゼロではありません。ですから，頻繁にペアを入れ替えるのはよいプラクティスです。ペアが代わるということは，問題のあるソリューションが運用まで到達してしまうのを回避するチャンスになります。
講演の中でHocke氏は，自身のチームにおいて、席の配置やツールへの習熟度や包括性の違いといったモブの問題を解決する中で，一般的な問題に影響されることはなかった，と述べている。氏の言う一般的な問題とは，"メンバ自身のことを話題にする"，"初心者のアイデアを取り上げない"，個人に対して"話す機会をまったく与えない"、といった類のものだ。
Langr氏は最後に，すべてのパターンに状況に応じた相応しい場所がある、という点を指摘して，自身の記事を締め括っている。
ソロプログラミング，ペアリング，そしてモブ – コラボレーションの価値の順に並べたこれらの開発モデルそれぞれに，現代のソフトウェア開発現場における位置付けがあります。いずれのモデルにも，それが有効な課題があるのです。