【ソロ・ペア・モブ】各開発形態の特徴と活用場面について

現在、私が所属しているチームでは、「ソロ、ペア、モブを使いこなせるチームになる！」ということを掲げています。
その一環として、メンバー全員が全形態のプログラミングを経験した後、そのメリットとデメリットを話し合う機会を設けました。本稿ではその内容をまとめながら、各形態をよりうまく活用するためにどうすればよいかを考えていきます。

時々の開発にあたって、**どの形態のメリットを取り入れたいのか、デメリットをどう補うのか**を考えるときの参考にしていただけると幸いです。

### 前提
・開発手法：アジャイルスクラム
・チームメンバー：5名(新人を含む)

(注)文中の「モブ」は、明示していない場合、チーム全員で行うモブを想定する。

## 0. 目次
1. ソロ・ペア・モブの特徴
2. 各形態の使い分け方
・軽いPBIはソロ！
・学習効果を狙うならペア！
・難易度の高いPBIはモブ！

3. 各形態のデメリットの補い方
・ソロはモブレビューすべし！
・ペアは組み合わせ効果を振り返るべし！
・モブは独り言のように発言し、リアクションを大きくすべし！

4. おわりに

## 1. ソロ・ペア・モブの特徴

まずは、各形態のメリットとデメリットを表にまとめたいと思います。

<font color="OrangeRed">＜メリットまとめ＞</font>
| ソロ | ペア | モブ |
|:-:|:-:|:-:|
|ベロシティが高まる(早く、多くの価値を届けられる。)|トラックナンバー問題が発生しにくい|全員のモブの場合レビューが不要|
|デッドラインを守ろうと、集中して作業する|分からないところで立ち止まりやすい|トラックナンバーが発生しにくい|
|分からないところで立ち止まりやすい|主体的に取り組めたと感じれば達成感が高くなる|時間の積み増しが起こりにくい|
|理解度が高い|主体的に取り組めば、没頭できる|好ましいモブであれば、分からないところで立ち止まりやすい|
|達成感が高い|意思決定の速度と質が少し高まる|好ましいモブであれば、理解度が高くなる|
|没頭できる|組み合わせによっては学習効果が高い|主体的に取り組めたと感じれば達成感が高くなる|
|1人で完走できる力/自信をつけられる|ベロシティが少し高まる|好ましいモブであれば没頭できる|
|   |自省が促進される|意思決定の速度と質が高い|
|   |   |ショートカットなどの小技を学べる|
|   |   |他の人の作業手順を見ることができる|
|   |   |知識の伝播が速く、広い|

<br>
<font color="SteelBlue">＜デメリットまとめ＞</font>

| ソロ | ペア | モブ |
|:-:|:-:|:-:|
|レビューコストが高い|レビューコストが発生する|ベロシティが低い|
|バグを埋め込んでいる可能性が他の形態より高い|バグを埋め込んでいる可能性が少し高い|デッドライン効果が薄い（デッドラインを守ルためにとギアを入れる、という意識が低くなる）|
|トラックナンバーが発生する|受動的に取り組めば、達成感を感じにくい|好ましくないモブであれば、分からないところで立ち止まりにくい|
|デッドライン効果が高く、休みに仕事をしてしまいがち|受動的に取り組めば、没頭しにくい|好ましくないモブであれば、理解度が低いメンバーがいる可能性がある|
|便利ツールを知る機会がない|組み合わせによってメリットに波がある|受動的に取り組めば、達成感を感じにくい|
|非効率な学びになる可能性がある|休憩を取るのを忘れがち|受動的に取り組めば、没頭しにくい|
|   |   |トラブルシューティングの力がつきにくい|
|   |   |モブの熟練度が低く、好ましくないモブの場合、メリットが減ってデメリットが増えるリスクがある|

＊好ましくないモブ：メンバー（1人でも）が発言しにくい、問題を指摘しにくいと感じている状態のモブ


## 2. 各形態の使い分け方 

数あるメリットのうち、各形態で私が最もメリットだと感じる項目を深掘りしながら、どのような場面でメリットが増幅するか、どういう時にどの形態を取るべきなのかを考察したいと思います。

### 軽いPBIはソロ！
私が思う、**ソロ最大のメリットは「ベロシティが高まる(早く、多くの価値を届けられる）」こと**です。
ソロでは、1人で1つのPBIに取り組むため、複数人で1つのPBIに取り組んでいる場合に比べて、チーム全体として取り組めるPBIの数が増えます。したがって、自然とベロシティが上がり、早く多くの価値をユーザーに届けられるようになります。
しかし、ソロのデメリットである「レビューコストが高い」や「バグを埋め込んでいる可能性が他の形態より高い」を下げないとソロのメリットが最大化されるとは言えないと思います。
このことから、比較的レビューコストとバグの可能性が低くなるような、**難易度の低いPBIであれば、ソロのメリットが最大化する**のではないかと思います。

### 学習効果を狙うならペア！
私が思う、**ペア最大のメリットは「自省が促進される」こと**です。
ペアでは、ドライバーモードだけではなく、俯瞰してペアにコードの内容を説明するモードになる機会が多くあります。少なくとも、私（新人）は、説明するモードの際にコードのミスを発見したり、自分の勘違いに気づくことが多くあります。
ソロでは黙々とコードを書くことが多く、中々説明モードになりませんし、モブでは（特に新人は）コードの内容を他の人に説明する機会が少なく、自省する前にメンバーから指摘されることがほとんどです。
そのため、ペアという形態をとることで、（新人であっても）俯瞰して自分のコードを眺め、自分でミスを発見する力を養うことが出来るのではないでしょうか。
したがって、**ソロで自分のミスに中々気付けない人や新人の学習という観点では、ペアのメリットが大きい**と言えるのではないでしょうか。

### 難易度の高いPBIはモブ！
私が思う、**モブ最大のメリットは「意思決定の速度と質が高い」こと**です。
モブでは、全員がその場にいるため、複数人の知恵をすぐにかき集めることができます。これによって「命名どうしようか」「どの範囲までリファクタするか」などの意思決定を早く行うことができ、コードの質も良くなります。（また、急遽デイリーの時間をずらすなども容易に対応でき、チーム運営も楽になります。）
よって、**特に複数人の知恵を集める必要がある難易度の高いPBI**、**チーム内の技術差が大きく、少数で取り組むと手戻りが発生する可能性が高いPBI**ではモブのメリットが強く感じられるのではないかと思います。


## 3. 各形態のデメリットの補い方

各形態で私が最もデメリットに感じる項目について深掘りし、どのようにデメリットを軽減させるかを考えていきたいと思います！

### ソロはモブレビューすべし！
私が思う、**ソロ最大のデメリットは「レビューコストが高い」こと**です。
有効なレビューをするには、レビュワーはレビュイーと同じかそれ以上の仕様理解、コード理解が必要です。しかし、自分の書いていないコードに対してそれをするコストは高いと考えられます。そして、ソロの場合は、1人の目しか通していないため、特に厚いレビューが必要になります。
この問題はソロでは避けて通れないものですが、私のチームではプルリクエストではなく、**モブレビューを行う**ようにしています。モブレビューでは、画面操作だけでなく、コードの説明も行います。これによってプルリクエストで見てコメントするより、コードを追いやすいですし、気になるところを気軽に聞いたり、提案することが出来ます。（因みに、レビューをモブることで、新人はベテランのレビュー観点を学ぶことが出来るため、レビューの仕方を学ぶという意味でもおすすめです。）

### ペアは組み合わせ効果を振り返るべし！
私が思う、**ペア最大のデメリットは「組み合わせによってメリットに波がある」こと**です。
ペアでは、常に誰と誰が組むのかということを考える必要があります。例えば、「新人とベテランのペア」であれば、ベテランの使うショートカットや考え方を新人が学ぶことが出来ますが、「新人と新人のペア」であれば、相互に学ぶことは少ないでしょう。また、「命名が雑な2人のペア」であれば、出来上がるコードの命名はやはり雑でしょう。もしかしたら、1人の時より雑かもしれません（「こんなもんでいいか」と低いレベルで満足してしまうかも。）
このように、誰と誰が組むのかによってコードの質や学習効果に波が出ます。
したがって、ペアを行う場合には、**ペアの振り返りなどを通してどういう特性があるペアかを意識的に調べる必要がある**と思います。それを繰り返して、良いペアを見つければ、このデメリットは軽減されていくのではないでしょうか。

### モブは独り言の如く発言し、リアクションを大きくすべし！
私が思う、**モブ最大のデメリットは「モブの熟練度が低く、好ましくないモブの場合、メリットが減ってデメリットが増えるリスクがある」こと**です。
モブは、全メンバーが主体的に取り組み、発言できている状態でなければ、メリットが少なく、デメリットが大きくなってしまいます。しかし、ペアプロや普段のコミュニケーションに比べて「モブでは発言しづらい」と感じるメンバーは数名おり、好ましいモブの状態にするのは一筋縄ではいきません。
モブで発言しにくいという感じるのは、普通の集団会話で用いられるような非言語的なコミュニケーションがモブではできないことが原因であるように思います。通常、円滑な会話の交代には、視線やその他の非言語要素が多いに寄与しています。しかし、モブプログラミングでは、参加者が全員画面側を向いている状態であるため、他の参加者に非言語要素を送ることも、受け取ることもできません。これによって、自分が今話して良いのかや、自分の発話が相手に十分伝わっているか確証が持てないと感じる人もいると考えられます。
そのため、モブでは**視線などの非言語要素を用いた円滑な会話交代ができないことを認識し、発言のタイミングをあまり察ろうとせずに発言すること**。また、**人の発言に対して大きめのリアクションをして、自分の理解をわかりやすく示そうとする一人一人の意識**が重要であり、それを通してチームの熟練度を上げていく必要があると思います。


## 4. おわりに
今回はソロ、ペア、モブの特徴をまとめて、各形態の使い分けについて考えてみました。
ソロ、ペア、モブのメリットを有効に活用し、良い開発ライフを過ごしましょう！