モブプログラミング・ベストプラクティスを読んだ

マーク・パール「モブプログラミング・ベストプラクティス」を読んだまとめと感想。

モブプロをすすめるにあたって

モブプロってペアプロと比べてどうなの？

・意見が食い違っても、対立による膠着状態になりにくい
・中断しにくい

モブプロは効率が良いの悪いの？

・リソース効率（安さ） ではなく、 フロー効率（早さ）を重視しよう
・属人化を避けて、組織全体としての価値を向上させよう
・常にチームとして活動し、成果物をうみだしつつメンバーの教育もできる
・成果物が必然的にレビューされるので、同時に品質も上がる

そのほか覚えておきたい特徴

・実験という形で導入できるから、心理的ハードルを下げられる
・強制しないことが大切

やってみよう！

まずは準備

・チームは3〜4人
・pc & キーボード & ディスプレイ & ホワイトボード
・時間を測るタイマー

モビングセッションの流れ（2hour）

・30min　コンセプト説明
・90min　モビングインターバル
・every 10min　毎回タイピスト（＝ドライバー）を交代しながらモビング
・last 20min　レトロスペクティブ（ふりかえり）

タイピスト の役割

・モブと対話し、モブの依頼を理解する
・コードを実装する
・モブを信頼し、躊躇せず試す

その他のモブ の役割

・問題に集中し、解決に向けて貢献する
・意見を聞き、質問をする
・必要な情報を予測する
・改善を探す

成果物のコミット

モビングインターバル毎にコミットし、あとで整理しよう
あとでレビュー済みか区別しやすくなるので、誰かのIDでコミットするよりも、チーム専用のIDがあるといいよ

レトロスペクティブの6つのステップ（with シンキングハット法）

4min　シンキングハット法の説明
2min　事実と数字（白）
3min　肯定的感想（黃）
3min　批判的感想（黒）
5min　問題解決（緑）
3min　軌道修正・合意形成

スクラムのレトロスペクティブと同様に、１つだけ次のスプリント（セッション）で改善したいことを決めよう

チームの成長

1st step 個としての成長

・共感しよう（アクティブリスニング）
・対立ではなく識別を、Jadgement ではなく Discern しよう
・チームに貢献したい気持ちを養うことで親近感を持とう

2nd step チームとしての成長

・チームが優先、挨拶・会話・感謝をして、協調的な心構えを身に着けよう
・ただし、過度に協調的になりすぎると、対立を避けるあまり問題解決できなくなるよ
・ビッグ・ファイブ性格特徴モデルを活用しよう
・メンバーの性格・個性タイプについてグループ討議しよう
・相手のことをよく知る努力をしよう

ケーススタディ

チームにエキスパートがいる場合

エキスパートにはナビゲータ（タイピスト以外の役割）に徹してもらうことで、モブがついて行けない状況に陥るのを避けよう

手探りですすめる仕事の場合

進行役を立て、チームの議論を取りまとめるストロングスタイルのモビングで前に進もう

些末な仕事がたくさんある場合

モブプロRPGをやってみよう

職場改善

・機材は買うよりもまずは借りて試してみよう
・固定されたものよりも、可動できるものを使おう
・遠くの場所でやるよりも、近場で開催すると参加率が上がるよ
・それなりに広いスペースでやろう

モブプロを定着させるために

現状の開発プロセスとの親和性ってどうなの？

モビングとその他の開発メソドロジー（スクラム、ウォータフォール、etc）は相性がいいから一緒に進めることができるよ

モビングの時間について

リモートモビングをするときは、コラボレーションアワーを設定して開催しよう
チームお決まりの儀式を決めたりして、モビングを習慣化しよう

モビングは疲れる

必ず定期的に休憩をとろう
疲れてモビングの継続が困難なときは、みんなに自分の状態を知らせよう

モビングはフローを重視する

色々な事情でモビングを中断する場合にも、チームの信頼を失わないことが一番大切なこと

「リソースとフロー」は、「高速道路を走る車とその流れ」に似ている
車を増やしすぎると流れが悪くなる
バランスが大事

その他の要因からフロー効率を守るために

・仕掛りを減らすことで、コンテキストスイッチによるロスを減らす
・バットマン（窓口となる役割）を決めて、割り込みに専属対応する

長期的にモビングを続けて

新メンバーが入ったときに

・デイケアチームにならないよう気をつけつつ、新メンバーの学びを最大限バックアップしよう
・できることなら面接でモビングをやってみよう

まわりが遅いと感じるような不満がでてきたら

・まずはチームで会話しよう
・言いにくいことを言っても反発されない信頼関係を築いておこう

上層部の目がきびしくなってきたら

仕掛品が少ないことや効率に関して指摘を受けたら、フロー効率について見える化しておき、進捗を説明できるようにしておこう

学習と修正をしよう

・同じチーム、同じモブはどこにもいない
・経験が蓄積されてきたら、どんどんモビングを進化させていこう 　

感想

導入からケーススタディ、うまくいかない場合の対処法まで揃っているため、困ったときに確認できて良い。ページ数もそんなに多くないので、これから始めてみるチームはさらっと回し読みするといいのでは。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める