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

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

最初、モブプログラミングとモブプログラミング・パターンの違いについても良く分からなかったモブプロど素人の私でしたが、現在ではそれぞれの違いも良く分かり、パターンに当てはめて自分たちのチームを客観視・分析出来るようになりました。

この記事を読んでくださっている皆さんもモブプログラミングのことは勿論、パターンを理解して実際にチームで当てはめてみても面白いのではないかと思います。

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


前編は主にモブプログラミングとモブプログラミング・パターンの概要についてです。

__後編__
[モブプログラミングを導入した話 ~自分たちの該当パターン分析~ 後編](https://qiita.com/ntsuyuki/items/ac643da6d8cad3fc0f16)



# きっかけ

**強力な助っ人①「来週からモブプロで進めてみましょう」**

　　
モブプロって3人以上の人数で開発するのだっけ？
ペアプロの人数多いバージョンかな？

というのが、当初の私のイメージでした。

　　
まず、私のチームがモブプロを始めることになった背景は以下の通りです。

* 社内プロダクト開発チーム
    * メンバーは社内開発よりも業務開発を優先しなければならない
    * 1週間の内、決まった曜日に3時間ほど集まり各自で作業を進めていた

* 力量に差のあるメンバー構成
    * 強力な助っ人①
    * 強力な助っ人②
    * 既存メンバー①
        * 分からないことは強力な助っ人に質問する
    * 既存メンバー②
        * 分からないことは強力な助っ人に質問する
    * 新規参画メンバー（私）
        * 右も左も分からない
![スクリーンショット (2124).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2303304/65165a67-1ef8-ca60-1819-7fc139cfc227.png)





個人で実装タスクをこなすには限界があり、質問に答えてくれる人が業務で離席してしまうことも少なくありません。
また、参画時期がバラバラなので仕様理解にも差がありました。



* 個人でタスクに取り掛かるよりも、皆で作業するので当事者意識を持つことが出来る
* スキル差がある方がモブプログラミングの効果的な結果を得ることが出来る
* 新規参画メンバーがいても、引き継ぎの時間を取らなくて良く、分からないことはその場ですぐに聞くことが出来る

以上のメリットがあるモブプロは私の所属するチームには持ってこいの開発手法でした。
　　

# モブプログラミングとモブプログラミング・パターンの違い

__モブプログラミング__ 

チーム全体が同時に同じことを体験しながら作業をする方法で、XP開発の時代(1990年代後半から2000年代初頭)からある手法。



__モブプログラミング・パターン__

モブプログラミングで発生する典型的なベストプラクティスとバッドプラクティスをパターン化して、フレームワーク化したもの。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2303304/1ab9f466-f21a-7387-12f6-f559bd7015ed.png)



## モブプログラミング・パターンの詳細

以下https://github.com/michaelkeeling/mob-programming-patterns を一部訳したもの

### 役割

**Facilitator（ファシリテーター）**

* グループの集中力を維持し、意見の相違を解決するのを支援する
* 通常、ドライバーはこの役割を果たさない

**Recorder（レコーダー）**

* 仲間に代わって状況や設計上の決定事項などのメモを取る

**Researcher（リサーチャー）**

* モブプロが前進するために必要な情報をリアルタイムで探す

**Navigator（ナビゲーター）**

* ドライバーに何をすべきかを指示する
* ドライバーではないモブプロのメンバーは、ナビゲーターであると見なされる
* ナビゲーターは多くの方法でモブプロに貢献することが出来る

**Driver（ドライバー）**

* 全員が特定の問題を解決するために作業しているときに、キーボードを操作する人
* ナビゲーターの考えを汲み取る

**Devil's Advocate(悪魔の代弁者)**

* モブプロの設計をより強くするのを助けるために逆の立場をとるナビゲーター


### コラボレーションのパターン
**Punch List（パンチリスト）**

* メンバーが作業項目を追跡し、次に作業するものを選択するために使用するタスクリスト
* パンチリストにはテキストベースのものとグラフィカルなものがある

**Splinter Group（スプリンターグループ）**

* 日常業務を完了するためにメイングループから離れるモブプロの1人以上のメンバー
* スプリンターグループは、モブプロメンバー全体が検討するための代替案を調査することもできる

**Ridin' Shotgun（他の人が運転する車の助手席に乗る人の意）**

* 他のナビゲーターを除外して、モブプロの仕事を単独で指示するナビゲーター
* 西部開拓時代、アメリカでは敵から身を守る為に用心棒を雇っており、その用心棒が銃をもって助手席に座るのが慣習だったためこの名が付けられた

**Mute your mic（マイクをミュートする）**

* 他のナビゲーターに貢献する機会を与えるために、ナビゲーターとして一時的に沈黙することを選択する
* 遅いモブプロをキックスタートしたり、一人がモブプロを支配するのを防ぐ方法として使用される

**Fight Club（ファイトクラブ）**

* 2人以上のメンバーが相互に尊重や配慮をする指針を完全に無視して、モブプロの方向をめぐって争う状況
* モブプロにとって非常に有害であり、アンチパターンと見なされる

**Natural Swap（自然な交換）**

* テストやリファクタリングが完了したときなど、作業の「自然な」区切りでメンバーやタイマーに促されることなく、新しいドライバーに切り替わる

**Forced Swap（強制的な交換）**

* メンバーまたはタイマーに促されて、新しいドライバーに切り替わる

**Distracted non-Participant（注意散漫な非当事者）**

* モブプロにいるが、他の仕事に気を取られていて参加しないナビゲーター

 

### ドライバーの行動パターン
**Thinking Out Loud(考えていることを口に出す)**

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

**Tell me what to write（何を書けばいいか教えて）**

* ドライバーが助けてもらうために、ナビゲーターに指示を仰ぐ
* モブプロのメンバーがドライバーに指示するように誘導する

**Driving on Autopilot（自動運転）**

* 他のメンバーからの指示を受けずに進めてしまうドライバー

**Plowing Through（耕して進む）**

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



:::note info

後編では、上記のモブプログラミング・パターンを参考に実際に私たちのチームで実施してみたことについて書いていきます。

[モブプログラミングを導入した話 ~自分たちの該当パターン分析~ 後編](https://qiita.com/ntsuyuki/items/ac643da6d8cad3fc0f16)

:::