「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」をよみました
「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」を読みました。
## モブプロにプラクティスはあるのか？
本書を読む前、モブプロについては「エンジニアが会議室に集まって、1つのモニターを見ながらワイワイコーディングをする」くらいのイメージしかありませんでした。ひょんなことからモブプロを始めることになり、インターネットで情報収集を進めるうちに本書にたどり着きました。アジャイルと一緒で、まずはベスプラを学ぶことが大事だと考え、読んでみました。モブプロ実践にあたり役に立ちそうなポイントを並べてみたいと思います。
## モビングセッションのタイムテーブル
1回のモビングセッションは約2時間です。初回のモビングセッションではモビングの意義や役割分担の説明時間が取られますが、ここでは割愛します。
モビングインターバル（1時間30分）
1回のインターバルは10分です。各インターバルが終わるごとに、キーボード前に座る人「タイピスト」と周りの共同作業者「その他のモブ」が入れ替わります（1つのインターバルがかなり短い印象ですね）。タイピストはプログラマーではなく、その名の通り、周囲のモブの発言を実装するスマートアシスタントに例えられます。タイピストが自分で考えて実装していき、その他のモブがタイピストの実装の様子を眺めるわけではないことに注意してください。
モブレトロスペクティブ（20分）
モビングセッションで実施された内容についてふりかえり、将来のセッションをどう改良できるかについて話し合います。スクラムフレームワークで実施されるスプリントレトロスペクティブはモビングセッションに閉じないチーム全体のふりかえりであるのに対して、モブレトロスペクティブはあくまでモビングセッションについてのふりかえりです。本書ではモビングに慣れてきて、モブレトロスペクティブをオーバーヘッドに感じ始めたらモブレトロスペクティブは廃止してもよいとしています。
## デイリースクラムを廃止すべきか？
本書では、毎日1日中チーム全員がモビングに参加している状況であれば廃止を検討してもよいとしていますが、基本的にはデイリースクラムの廃止は推奨されていません。一方で、モビングによってチームの共通認識が増えるため、デイリースクラムでの問いを以下の2つに絞ることがすすめられています。
- 今日済ませなければならない最も大切なことは何か？
- そのためにどうするか？
スクラムフレームワークで定められたチームとのコミュニケーションの機会は基本的に削減しないというのが本書の基本的なスタンスであると考えられます。もちろん時間経過にともなって、イベントを簡略化していくことは問題ありません。
## バットマン = スクラムマスター
チームメンバーがモビングに集中するために、外部からの妨害を防ぐための役割としてバットマン（アメコミヒーローではなく、将校の雑用係の兵隊を示す軍隊用語）を置くことを推奨しています。このバットマンがチームの連絡係となり、モビング中のチームへの連絡などはすべてバットマンに集約されます。スクラムを実践しているチームであれば、スクラムマスターがこの役割を担うのがスムーズでしょう。
## エキスパートがいるモビング
チームの中に一人だけエキスパートがいる場合、エキスパートがタイピストを担うことで、他のチームメンバーを置き去りにしてコーディングを進めてしまい、結果としてモビングが形骸化する危険があります。このような場合、エキスパートには意図的にタイピストの役割を回さず、初心者の中でタイピストの役割を回すことが望ましいとされています。また、モブとなったエキスパートは、タイピストの作業を一人で細かく指示しすぎないように注意する必要もあります。
## さいごに
今回は特にモビングの進め方を中心に解説しましたが、本書ではモビングを実施する際の考え方も含めて、シチュエーション毎に解説されています。チームでモビングを始める際の指南書として手元に置いておきたい1冊です。
