ペアプロ・モブプロでメンバーが驚くほど成長した話

# 1. はじめに
ペアプログラミングは、ベストセラーになった「[レガシーコードからの脱却](https://qiita.com/kojimadev/items/c2f5b4fea1992385c99a)」や [MicrosoftのDevOps開発チームの紹介記事](http://simplearchitect.hatenablog.com/entry/2016/08/22/080010)などでも紹介されている素晴らしいプラクティスです。

私のチームでペアプログラミング(以下、ペアプロ)とモブプログラミング(以下、モブプロ)を実施した結果、手戻りが減り、メンバーが成長し、その後の生産性がアップしました。本稿はその詳細を説明します。
特に、メンバーの育成という点では、ペアプロ・モププロは間違いなく効果的だと思います。私は過去に10人くらい新人育成に携わってきて、新人配属後1年間の開発業務での成果を色々見てきました。その中で、ペアプロ・モププロを活用して新人から育成した今の私のチームの3人は、成果が抜きん出ています。

なお、ペアプロとモププロは、色々と異なる特性がありますが、この記事では共通のメリットを説明する便宜上、まとめています。ご了承ください。

# 2. ペアプロ・モププロについて

- ペアプログラミング
  - ナビゲーター役とドライバー役を決めて2人で一緒に開発することです。詳細は以下の記事を参照ください。  
[ペアプログラミングで「強いエンジニアチーム」を作る！ ヤフーが実践する全てペアプロ開発の手法](https://employment.en-japan.com/engineerhub/entry/2019/11/07/103000)

- モブプログラミング
  - 3人以上で一緒に開発することです。ドライバー役が1人に対して、ナビゲーター役が2人以上になります。詳細は以下の記事を参照ください。  
[明日からできる働き方改革「モブプログラミング」](https://speakerdeck.com/takaking22/mobprogramming-as-work-style-reform?slide=5)  
[モブプログラミングのよくある誤解](https://takaking22.com/2018/mob-advent/)

- リモートワークでのペアプロ・モププロ
  - リモートワークでもペアプロ・モププロは可能です。私のチームではチーム全員リモートワークの中で、Zoomで画面共有して実施しています。リモートワークに関するその他のノウハウは以下を参照ください。  
[今日から使えるリモートワークでのチームビルディングのノウハウ](https://qiita.com/kojimadev/items/9f54d2d1e67d73ccfecb)


# 3. よくある手戻りの原因
以下では、あるタスクの途中で問題が発見され、前の段階に戻ってやり直すことを「手戻り」と記します。
ペアプロとモブプロの効果の説明の前に、私の過去10年の経験上、よくある2種類の手戻りを紹介します。

## 3.1 なんとなく決めて手戻る
設計および実装で「担当者がなんとなく決めた部分」で、よく手戻りが発生しました。__「どうしてそうしたの？」「なんとなくです」という状況__のことです。例えば、以下の内容をなんとなく決めて、レビューで手戻ることがありました。

- クラスおよびメソッドの分割方針
- クラス、メソッド、フィールドなどの命名
- メソッド内の処理順序、処理内容
- 技術課題の解決方法

## 3.2 タスクに没頭して視野が狭くなり手戻る
タスクに没頭して視野が狭くなると、よく手戻りが発生しました。__タスクに没頭すると、普段は発生しないような要因で手戻りが発生__します。例えば、以下のような手戻りが発生しました。

- タスクを進めているうちに本来の目的を忘れてしまい、目的を達成できない成果を作ってしまった。
- 対応方針を相談せずに何時間もタスクを進めた後に、そもそも対応方針が不適であることが分かり、最初からやり直しとなった。
- 思いつく方法でトライ＆エラーで設計/実装したため、その方法が最適かどうか分からない成果を作ってしまった。

これらの問題は開発経験が浅いメンバーに発生することが多いですが、タスクに没頭して視野が狭くなると「誰でも起きる問題」だと思います。過去に、開発経験が豊富なメンバーでも、タスクに没頭すると上記と似たような手戻りが発生したことがありました。

# 4. ペアプロ・モブプロの効果
## 4.1 手戻りの削減
ペアプロ・モブプロを行うと、上記に上げた2種類の手戻りが削減されます。

### なんとなく決める手戻りの削減
ペアプロ・モブプロでは、ナビゲーターが「ここは、XXXの理由で、YYYを使いましょう」という感じに、なんらかの「ロジカルな判断」を入れた上で指示します。
これにより「なんとなく決める」の手戻りが激減します。

### タスクに没頭して視野が狭くなる手戻りの削減
ナビゲーターはドライバーの作業を俯瞰して見られるため、視野が広くなる傾向があります。
そのため「タスクに没頭して視野が狭く」の手戻りも減少します。

## 4.2 メンバーの成長
ペアプロ・モブプロを行うと、以下のようにメンバーが成長します。

### ロジカルな判断の徹底
ナビゲーターで「ロジカルな判断」を繰り返す効果で、一人で作業する時もその意識が高くなり、段々それを徹底するようになります。
なお「ロジカルな判断」をしても、間違った判断で手戻ることはありますが、それは「良い手戻り」なので、問題ないと思います。自分なりの知見を駆使して「ロジカルな判断」をした結果が、間違っていたのであれば、そこで得た新たな知見は必ず成長になります。反対に「なんとなく決めた」ことは、それが正しくても間違っていても、成長に繋がらないと思います。

実際に私のチームの若手3人は、この効果で「ロジカルな判断」を徹底するようになりました。そして、__それはプログラミングだけでなく、あらゆる業務において徹底されるようになり、仕事全般の進め方が改善されました__。

### 客観的な視点
開発経験の浅いメンバー(新しいメンバーなど)は、他の人の成果物をレビューする機会は少ないと思います。
そんなメンバーでも、ペアプロ・モブプロでナビゲーター役になった時に、ドライバー役に指示したり指摘したりなど、他の人の成果物を客観的に見る機会を得ます。すると、客観的な視点で、自分の成果もセルフチェックできるようになり、1人で作成する成果物の品質も上がります。

実際に私のチームの若手3人は、__この効果でとても品質が上がりました。__

### 暗黙知の共有
メンバー間で、暗黙知を共有できます。以下は例です。

- 分からないことがあった場合の調査方法(ググり方を含む)
- 設計・実装する時の思考過程
- 何から優先して行うかなどの判断過程
- 参照した既存資産を使いやすいように随時改善するなどの取り組み姿勢
- 各種ツールの便利な使い方などの小ネタ

# 5. ペアプロ・モブプロが有効なタスク
手戻り削減の効果を活かすために、ペアプロ・モブプロは「対応方針が複数あり、手戻りが発生しやすいタスク」が効果的だと思います。
逆に、「対応方針が決まっており、手戻りが発生しづらいタスク」には不向きです。
（同じ理由で、「常に目的思考で最善の方法で手戻りなく仕事をするスーパーエンジニア」にも不向きだと思います）

# 6. まとめ
ペアプロ・モブプロは、手戻り削減とメンバーの成長に、大きな効果があります。
私はそれらを活用して [こちらのツール](https://www.lightning-review.com/) を開発しています。

また、リモートワークでのチームビルディングのノウハウも以下で公開しています。
[今日から使えるリモートワークでのチームビルディングのノウハウ](https://qiita.com/kojimadev/items/9f54d2d1e67d73ccfecb)

Twitterでも開発に役立つ情報を発信しています → [@kojimadev](https://twitter.com/kojimadev)