モブプログラミングを導入した話 ~自分たちの該当パターン分析~ 後編

はじめに

こんにちは、今年2年目まだまだ新米エンジニアの露木です。
今回、社内プロダクト開発で本格的なモブプログラミングを体験し、その際に「モブプログラミング・パターン」についても学びました。

• 「モブプログラミング・パターン」とは何なのか
• モブプログラミングとの違いはどういったところか
• 実際の体験談（自分たちがどのパターンに当てはまったか）
  を前編後編に分けて書いていきます。

後編は実際にモブプログラミングをした体験談・自分たちをパターンに当てはめてみた結果です。

前編
モブプログラミングを導入した話 ~自分たちの該当パターン分析~ 前編

モブプログラミング進め方の例(私の所属するチームの場合)

事前準備：ルールを決める

私たちが設定したルールは以下

• モブロールの交代は時間が来たら強制的に行う
  • ドライバーがタイマーのスタートを押す
  • 忘れてたら気づいた人が押す
• モブワーク中に途中離脱しない人がGitpodを開始する
  • その人のWorkspaceが閉じたら、皆アクセスできなくなるため
• タスクの起票
  • 青色：未着手
  • 黒色：Done
• パンチリストの消化ルール
  • タスクが終了した時
• 「計画」の時点で、Gitpodの月間使用量の確認をする

実際のモブプロの流れ

①モブタイマーを設定する

MobTime
Driverになった人が基本的にタイマーをスタートする。
設定した時間が来たら強制的にモブロールを交代しなければいけない。
ファシリテータが「この作業を行っている間はモブロールを回さない方が良いな」と感じた場合はモブタイマーをストップする。

②オープニング

アイスブレイクトークでチーム間の心の距離を縮める。
あんまり会話に参加できていない人がいたら、ファシリテータが「◯◯さんはどうですか」と話を振る。
（※オープニングトークの雰囲気）

③タイムボックスの作成

どれくらいの時間で進めていくか大まかに記入する。
この時間が変わるようなら適宜レコーダーが修正する。
この時、途中離席するメンバーがいたらその時間を右側に記入する。

④モブロールを回して計画・作業を行う

4人のチームだったので、以下のモブロールで回していく。
（強力な助っ人①はモブプロの指導・助言をするのにまわるため）

ドライバー

• コーディングする
• タイマーをスタートする
• 最初のドライバーはLiveshare若しくはGitpodを準備する

ナビゲーター

• これから取り組む作業をメンバー全員に説明する
• メンバーが迷っていたらとりまとめの提案を行う

ファシリテーター

• 開始時にオープニングをする
• アイスブレイクトーク(昨日夕飯何食べました等)
• 終了時にクロージングする
• KPTのファシリテータ
• タイマーの残り時間が少ない時に一声知らせる
• 休憩が必要そうだと感じた時にメンバーに声をかける

レコーダー

• 書記
• 変化があった時にmiroやSlackに書き込みを行う
• 作業時間がずれた等

何をすべきか分からなかったり技術的に難しいと感じるメンバーがナビゲーターになったら、「この箇所の実装について分かる方いらっしゃいますでしょうか」とすぐに周りの力を借りる。
ナビゲーターだけが喋る空間にならないようにする。
作業を通して後で必要そうだったり改善の余地があるものは「パンチリスト」に書き出しておく。

⑤クロージング

１分ずつ「よかったこと」「悪かったこと」について記入し、最後に1人１枚KPについて思ったことを述べる。(以下例)

私たちが当てはまると思ったモブプログラミング・パターン(コミュニケーション・ドライバーの行動)

モブプロ開始初期

Ridin' Shotgan（他の人が運転する車の助手席に乗る人の意）
他のナビゲーターを除外して、モブプロの仕事を単独で指示するナビゲーター

ある部分の実装方法が1人しか理解できていない場合、特定のナビゲーターが喋り続けてしまう事象が見られた。

Forced Swap（強制的な交換）
メンバーまたはタイマーに促されて、新しいドライバーに切り替わる

私たちのチームは、切りの良い所まで実装したらそこで自然と入れ替わるNatural Swapとは違い、決められた時間で強制的に交代するルールを設けていた。

Tell me what to write（何を書けばいいか教えて）
ドライバーが助けてもらうために、ナビゲーターに指示を仰ぐ
モブプロのメンバーがドライバーに指示するように誘導する

ドライバーが理解できていなく、ドライバー以外の人が分かっている場合はこのパターンになった。

Driving on Autopilot（自動運転）
他のメンバーからの指示を受けずに進めてしまうドライバー

ある部分の実装方法を理解出来ている人がドライバーだったり、あまり理解できていない人がナビゲーターになるとしばしば起こりえた。

モブプロ開始しばらく後(初期との違い)

開始初期に見られたアンチパターンが改善されて、より良いモブプロになってきた。

Mute your mic（マイクをミュートする）
他のナビゲーターに貢献する機会を与えるために、ナビゲーターとして一時的に沈黙することを選択する
遅いモブプロをキックスタートしたり、一人がモブプロを支配するのを防ぐ方法

ナビゲートするのがあまり得意じゃない人がナビゲーターになった場合、その人が一人前になれるように実装方法を理解していても最初は黙っていることを意識するようになった。
そのナビゲーターから助けを求められたら、他の役割の人も力を貸す。

Thinking Out Loud(考えていることを口に出す)
その場にいる有力な専門家として、あるいは進むべき道を見出すために、ドライバーが現在の考えを明確に述べる

特に理解できているメンバーがドライバーになった場合、今行っている作業を口に出しながら進めることが多くなった。

Plowing Through（耕して進む）
メンバーからのサポートを受けながら、目の前の仕事をできるだけ早く、苦もなく終わらせられるように取り組むドライバーのこと
Thinking Out Loudと組み合わせられることが多い

理解出来ていても、1人でサクサク進めようとせず、他の役職の力を借りながら実装を進められるドライバーが増えた。

実際に行ってみて

どうしても個人の作業になると、やっている大枠は分かるけど内容はいまいち良く分かっていない等、issueが担当者に属人化してしまいがちになっていました。

実際にモブプロを行ってみて、個々でタスクを割り振っていた時よりも当事者意識が出てきたことにより、1人しかこの作業の内容や進捗を理解出来てないという状況が無くなってきたように感じました。

また、当初は作業進捗が遅くなるのではないかという意見もあったのですが、全員がやっている個人のタスクを説明する時間を考えたら、そこまで進捗は遅くないのではないかと考えました。