チームで最近モブプログラミングをはじめたところ、丁度良いタイミングで出版されたので早速読んでみました。
日経BP社
目次です。
1. なぜモブプログラミングなのか
2. モビングの始め方
3. モビングと人
4. モビングの軌道修正
5. 定期的なモビングのための仕事場の改造
6. モビングを定着させるためのチームへの働きかけ
7. フロー重視の考え方
8. モビング定着後の長期的な展望
モブプログラミングとは
3人以上の人々が、１台のコンピューターでプログラミングをすること、とやることはいたってシンプルです。 また本書ではそれをモビングと呼んでいます。
モブプログラミングでの2つの役割
うちのチームでは、「ドライバー」「ナビゲータ」のようにペアプロと同じように呼んでいました。名前はともかく思っていた役割ともちょっと違いました。
タイピスト
ペアプロでは「ナビゲータ」のサポートの元、「ドライバー」主体でコーディングするイメージですが、モブプロの「タイピスト」はモブに言われた通り素直にタイプするのが役割です。他のモブを信頼して言われたことを素直にコーディングすることで他のモブからノウハウを得ることできます。その他モブへ戻った時に何も意見が言えなくなるので、ただタイプするだけではダメで何をやっているか理解することが重要になります。 スキルの高いタイピストがコーディングしてしまうと他のモブ達はやることがないので、役割を分けるのは良いアプローチだと思いました。また、ベテランメンバーより経験が浅い人をタイピストにした方が良いのかなとも思いました。
その他モブ
ペアプロで言うところの「ナビゲータ」です。筆者はその呼び方が嫌いなので「その他モブ」と呼んでいるそうです。 この役割のときは、チャットやメールをチェックしたり他のことをしてはいけません。話に乗り遅れないように集中力も必要ですし、理解することも仕事ですので質問することも大事になります。
モブプログラミングのメリット
特定の個人に頼らず、品質の高いソフトウェアを早いペースで生み出すことができます。
特定の個人に頼らないというのは、モブプログラミングを通じて自然とノウハウが共有されることで、いわゆる「多能工」が生まれます。それはスクラムのようなアジャイル開発との相性が良いと感じました。
品質が高いのは、いわばコーディングとレビューが同時に走るし、レビュアーも複数人いることになるので一人でレビューするより品質は良くなります。
今までの自分が関わってきた開発チームでは、スキルが低かったりプロジェクトの経験が浅い人には簡単な仕事を、一方、スキルが高い人に難易度が高い作業をアサインしてきました。これではチーム内のスキル差が埋まりにくいし、属人化が進みますし、キーマンが開発のボトルネックになったりチームから抜けられないことが問題になっています。
リソース効率とフロー効率
メリットとして挙げた早いペースというのはフロー効率と言い換えることができます。 対象的なものとしてリソース効率というものがありますが、本書の高速道路の例えが分かりやすかったです。 道路一杯に車を走らせると、同時に走る車の数は多くなるのでリソース効率が高くなるが、渋滞するので到着時間は遅くなる。かたや、走らせる車の量を制限するとリソース効率は悪くなるが到着は早くなります。人的リソースをいかに無駄なく使うかというのが重要視されWBSでクリティカルパスを確認するようなことがされてきた今までの開発とは対象的です。
モビングの始め方
最初は心理的ハードルを下げるため実験として位置づけることが重要。参加者もモビングに興味を持っている3、4人程度に抑える。直属の上司以外のステークホルダーにも理解してもらうことが必要になります。
モビングと人
コードだけではなく人間も大切で、人間関係がうまくいってないチームはモビングもうまく行きません。
相手の目線に立って、人を批判して対立するのではなくコードに目を向けることが大事です。
相手を注目してあげ、話を聞いて、評価してあげることで共感が生まれます。
結局はテクニックよりも人との関係性が重要だということをページを割いて書かれていることが印象的でした。
まあ、それが一番難しいんですけどね。
タイムボックス付きの探求
全員がやり方に詰まった時はモブプログラミングを一時停止して時間を決めて個人がオンラインマニュアルを調べるなり調査したあとで再開させます。このケースは個人での作業に切り替えた方が、効率が良いということです。
継続の仕方
ベテランメンバーはペースの遅さや得るものが少なくなりイライラことも予想されます。 チームのニーズとモブプログラミングを行うことの理由づけがないと継続は難しいということです。 ニーズとマッチしているなら、自然とモビングを始められる流れを作る具体的なテクニックも書いてありました。
終わりに
この本は「ベストプラクティス」というタイトルです。ですが筆者は最後に「モビングについてはすべて取り上げたと言いたいところだが、モビングは発展途上の実践であり、新しい発見が毎日のように現れている」と言っています。筆者の経験に基づいたモブプログラミングの始め方から継続の仕方まで実践的な内容でした。自分のチームで1ターンモブを回してみて幸い好感触を得ているのでチームのみんなに読んでもらいたいと思いました。
モブエリア作ってでかいモニター置きたいなあ。