「巷で噂のモブプログラミングってどうなんだろう？」と興味を集まったメンバーで集まって、実際にモブプロをしてみました。参考までに簡単にまとめておきます。
モブプログラミングとは
モブプログラミングは、2012年頃にHunter Industies社で取り組みが始まりました。そこで得た知見をWoody Zuillさん達がカンファレンス等で紹介することで広まっていきました。
以下の動画を見ると、実際にモブプログラミングをしている様子を見ることができます。
さらに2016年の様子のビデオが下記です。複数のモブが動いている様子を見ることができます。
[![A day of Mob Programming 2016]
(http://img.youtube.com/vi/dVqUcNKVbYg/0.jpg)]
(https://www.youtube.com/watch?v=dVqUcNKVbYg)
モブプロは簡単に言うと、みんなで画面をみながらわいわいプログラミング（またはそれに準じた作業）をすることです。基本的な進め方・コツ・現場で出てきそうな問題点は、ペアプログラミングと似ていると思います。
実際にやってみた
用意したもの
- 場所：モニターのある会議室
- 環境：プログラミングするためのPC
- お題：牛尾さんが公開されている ゼロから始める DevOps
- メンバー：愉快な仲間たち（全5名）
進め方
- お題の動画を見ながら実装する
- ドライバー以外はみんなナビゲーター
- ドライバー交代は特に取り決めせずに流れに任せる
- 終わった後にふりかえり
結果
- お題のデモ作成成功！！
ふりかえり
Y（やったこと）
モブプログラミング
牛尾さんのデモ（VSTSを使って.NETのアプリケーションをAzure WebAppsに自動デプロイする）を実際につくる
W（わかったこと）
- 入れ替わりのタイミングがわからない
- 志村うしろうしろ問題がよく起こる
- 志村うしろうしろ問題とは、ドライバー以外がガヤ芸人のように「もうちょい上！！」「右上！！」「うしろ！！」と指示しまくる現象のこと
- 得意なことを補完し合いながら進められるのがよい
- 一方でチームが変なテンションになってこだわってドハマリをしてしまうことがあった
- 現場でやる場合はメンバーの組み合わせ次第で工夫が必要そう
T（次にやること）
- ファシリテーターを明確に立てる
- 実際の現場でできそうなところからやってみる
実際の現場で実施する場合
体験後に実際に現場でやってみる場合について議論をしました。結論はないですが、参考までに個人的に思ったことも含めて以下にまとめておきます。
問題になりそうなこと
- 生産性が下がるのではないか問題
- ペアプロで出てくる問題と同じ
- 手戻り・レビュー・テストを含めてホントにそうなんだろうか
- モブプログラミングをすることでチームのムードが悪くなる
- これはモブプログラミングの問題ではなさそう
- ふりかえりやコードレビューと同じで未来志向で進められるとよさそう
- 批判・否定してもよい結果は絶対に生まれないのでNo Blameで進める
- 参加するメンバーの組み合わせによる問題
- 発言しなくなってしまいそうな人にはドライバーをやってもらう
- 無理に全員でやる必要はなさそう
- できるところからはじめる
どこからはじめるとよさそうか
- 体験の共有に価値があること、全員が理解・実施可能になったほうがよいこと
- Continuous Deliveryの初期設定
- フレームワークの設定・初期開発
- 意思決定を行いながら進めたほうがよいこと
- 重要な機能の実装
- 難しい問題・バグにぶち当たった時
気をつけた方がよさそうなこと
- 最低限のルール（マナー）を定義する
- No Blame
- 否定ではなく提案をする（✕「それはないわー」◯「こうやったらどう？」）
- 最初にその日の作業の流れを書き出してからはじめる
- ファシリテーターを置く
- タイムキーピング
- 作業の流れを定期的に確認する
- 毎回ふりかえりを実施する
Let's モブモブ！！
【更新】モブプログラミング関連リンク
ここで得た知見をもとにいろんなアウトプットをしているのでリンクだけ紹介しておきます。