概要
最近巷で流行ってきているモブプログラミング（以下でモブプロ）を私が所属しているチーム内でやってみました（しています）
私がモブプロを知ったきっかけはDevLove200 Brigdeで楽天の及部さんの「モブプログラミングを通して見たアジャイルの真髄」からでした
これを聞いた時から現状の私のチームで抱えている課題を解決してくれると感じました。そして、モブプロを実施する上での疑問点を「モブプロディスカッション」にぶつけ、さっそく実施してみました
チームの課題
まず、私のチームのミッションは新たなパッケージ製品またはWebサービスの企画です
必要であれば、モックアップの作成と検証も行います
抱えている課題は以下になります
- メンバーのスキルセットに大きな差がある
- 各メンバーが各々の企画と検証（モックアップ）を黙々とやっている
- 週一のチームミーティングでしか進捗がわからない（普段から進捗聞けばいいが）
- 課題で足止めされても誰に聞いていいのかがわからない。聞きづらい。抱え込む。
- モックアップを作った人しかわからない実装（属人化）
- AWS上でインフラ構築をしなければならないが、インフラ経験者が4名中1名
やったこと、工夫したこと
今回のモブプロでは「AWSにモックアップ用環境を構築する」をゴールに設定した
上記の課題にあげたようにインフラ経験者が少ない中、今後各自がインフラ基盤を扱えるようにと学習目的としてこのゴールを設定した
モブプロを実施するための主旨説明（初回のみ）
- モブプロとは何か
- モブプロを実施する目的
- 今回のモブプロのゴール
- チーム内のルールや実施方法
ルール
実施する上で設けたルール
心得
- 楽しく
- 質問・疑問を抱え込まない
- 優しくフォロー
- すぐに質問しよう
実施方法
- ディスプレイ2台、作業PCは1つのみ
- ホワイトボードと付箋を常備
- 作業者はドライバー
- その他はナビゲーター
- 作業時間は基本3時間とする
- 1時間ごとに休憩
- 15分ごとに役割交代
- 一日のゴールを決めてから開始すること
- 終了後に一日のフィードバック
- 改善点は随時取り入れよう
ドライバー
- 作業開始時に「これから○○します」と宣言しましょう
- わからない時は「わかりません」とアピールしましょう
- 15分ごとに役割交代
- 未経験でも怖がらず
ナビゲーター
- 調査用PCの持ち込みはOK
- 適宜に問題提起やフォローをしましょう
- ゴールに対してに合った問題提起
（細かいコード規約は無視とか）
1日ごとのゴールを設定
1日のゴールを設定することで、エンドレスに作業し続けないようにした
また、明確なゴールが設定されていると集中して取り掛かれる
理解できるまで次に進まない
今回のモブプロは学習も大きな目的にしているので、メンバーが理解できなければ次のステップに進まないようにした
メモる時間をきちんと確保した。そうすることで、わからないことを抱え込まずに自然と聞くようになる
各自が作成した学習用メモをメンバー内で共有できる形にした（Evernote）
せっかく記録したメモをメンバー内で共有することで、理解の補足に役立てた
1日やったことを簡単なサマリーにして記録した
休んだ人でも何をしたのかをキャッチアップできるようにした
また、回を重ねるごとに過去にやったことを忘れてしまうので、思い返すためにも使える
※本来のモブプロでは出入り自由なので、このようなことは必要ない
今回は学習に重点を置いていることもあり、キャッチアップできるような方法にした
1hごとに休憩
通常のモブプロは自由に出入りすると思いますが、前述の通り学習に重点を置いていることもあり、明確に休憩時間を設けた
※途中で抜けて分らなくなるので、結果的に誰も休憩しない可能性がある
課題の共有
作業中に発生した課題（進行に直接影響はないが、後回しにしても大丈夫な課題）をホワイトボードに書き出し、次回以降に解決、もしくは各々が調べる
各回の開始前に前回の取りこぼしや課題などを共有
各自の学習においてわからなかったことや前回の課題の振り返りを実施することで、より理解を深めることができた
フィードバック
良かった点
- 一人でやるよりも、説明されながら作業できたので、理解しやすかった
- 初めてのことばっかりだったけど、個人的にはスピード感があった
- 自分で思いつかないことを他人が聞いてくれるので、新たな発見に繋がる
- 黙々と１人で作業するときよりも、みんなで話ながら作業しているときの方が後から振り返るときに、「あの場面であー言っていたな」などと思い出しやすい
- 初めての作業は、自分は何が分かっていないのかも分からないことが多いので、他のメンバーの疑問点や意見を聞くだけでも気付きがあってよかった
- 悩んでいた事実が共有できたのはよかった
- 別途悩みを伝える必要がない
常に悩みが共有されている
悩みを伝えるコミュニケーションコストも減る - 他人の入力方法と操作方法が参考になる
- エラー発生時の対処方法が参考になった
- 原因特定するまでのアプローチが人それぞれだと思うので、他人の解決策を知ることができてよかった
- 全員が理解した上で次に進んでいる
- 全員が参加している感が出ていた
- 集中して作業に取り組める
- 自らが手を動かして作業したほうがより理解できた
- 入力途中から間違いの指摘ができるので、タイムロスが減る
- 調査力は人数 x 倍の速さで実現できる
- 各回ごとにフィードバックを設けるようにしているので、チーム状況を逐次把握するができ、かつ改善につなげられる
今までだとプロジェクト完了時、フェーズ完了時といった大きな単位でしかフィーバックしてこなかったので、改善スピードが向上した - 参加者が積極的に参加するようになった
- メンバー全員で取り掛かることでチームとしての連帯感が出た
- 課題や疑問を常に言える雰囲気になった
改善点
凡例：→は改善点に対しての改善策です
- 講義形式になっていた
→ドライバがわからなかった時は、ナビゲーターが積極的にフォローする。ナビゲーターもわからなかった時はみんなで調べるようにする - ドライバがわからない時の進行スピードが速かった
→全員で理解してから次にいくようにした - 時間管理がちゃんとできていなかった（役割交代のタイマーをかけ忘れていた）
- 画面が見づらかった
→見づらいプロジェクターを使わずに、普通のモニターにした - ドライバがわからない時は積極的にアピールするように
- 後回しにしたコト（課題、詳細）を全員に共有するようにしたほうがいい
→ホワイトボードや付箋に書き出すようにした - 全員で課題解決する時に、1人1台のPCがない
- 自分のキーボードじゃないから操作しづらい
→自分のキーボードを持ってきてOK
気になること
マネージャ層の方からはモブプロだと作業効率上がるの？とよく質問されます
まだ数値的な根拠を示すことはできていないが、少なくとも言えるのは我々が目指していることを実現するためには有効な手段だと思います
繰り返しになりますが、
私のチームのミッションは新たなパッケージ製品またはWebサービスの企画です
このミッションを達成するために仮説検証を繰り返しながら、不確実性を取り除いていかなければならない
速く作れて、速く検証して、早くフィードバックすることが求められます
従来の開発方法だと、課題にもあげたように
- 各メンバーが各々の企画と検証（モックアップ）を黙々とやっている
- 課題で足止めされても誰に聞いていいのかがわからない。聞きづらい。抱え込む。
進捗ミーティングの時点で初めて進捗が芳しくない、わからないことで詰まっていると判明する（早く相談しろっとツッコまれるが）
また、作った人しかわからない仕様だったり、イケてない実装（要件を満たせていない実装）だったりすることがある
結果的に検証できるまでに何週間もかかってしまうことが多々あります（難易度や技術力にもよりけり）
こうした状況にならないために、モブプロのように1つのことにリソースを集中して、速く検証できるようにすることが有効的だと思います（銀の弾丸ではない）
※リクルート黒田樹さんの「フロー効率性とリソース効率性の話」と「事業が対峙する現実からエンジニアリングを俯瞰する」で説明されています
※「事業が対峙する現実からエンジニアリングを俯瞰する」p.87 より抜粋
※「事業が対峙する現実からエンジニアリングを俯瞰する」p.88 より抜粋
コスト効果
- 仕様決め時間の削減
- 仕様、実装の引き継ぎ時間が0になる
- 悩みを伝える時間0になる
- 課題解決力 x 人数倍 速くなる
- 知識量 x 人数分 多くなる
- 戻り量 大幅減
- 打合せ時間（レビュー、仕様会議、進捗会議） 大幅減
- モチベーション 倍増
- 心理的安全性 無限大
番外編
Slerでモブプロは使えるのか？
弊社はSlerの受託開発と製品開発のどちらの部門もあります（私は後者）
社内向けにモブプロの説明すると受託開発部門の方からは導入難しいのよねと言われます
モブプロもアジャイルの導入と同じように顧客の理解が不可欠かと思います
受託開発は基本人月契約になっているため、小さい仕事ではエクセルのマクロ改修とかがあります
このような仕事をモブプロでやるのはナイと思う
どのようなシーンで使えるのか
- 顧客提案用のモックアップの作成
→顧客提案する際にパワポー＋α（モック）で説明したい時用のモックアップ作成 - UI作成
→顧客（エンドユーザー）に参加して頂いてUIを随時修正しながら作っていく