ペアプログラミングってどうなの？という方へ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/6841446c-3ae8-b08a-321c-3ddb53938d98.png)

## はじめに

本記事はUzabase Advent Calendar 2023の6日目の記事です

https://qiita.com/advent-calendar/2023/uzabase

転職を経て、業務中のプログラミングは、**ペアプログラミング**(ペアプロ)中心となりました。
このブログでは、ペアプロの実践を通じて感じたメリットとデメリット、そして心得について共有します。

## ペアプとは

ペアプロは、二人の開発者が一緒にコードを書く開発手法です。
一人がコードを書く（ドライバー）、もう一人がそれをレビューし、提案をする（ナビゲーター）という役割分担が特徴です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/6595f108-ea1d-2f57-4c32-ada525586de4.png)

## よく言われること

<font color="red">**「二人で開発すると時間かかりすぎじゃない？」**</font>

これはよく言われますし、私自身も経験する前はちょっと思っていました。

ペアプロのコストと利点についての論文`The Costs and Benefits of Pair Programming`を読みながら考えてみます

https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

:::note warn
大学生ぶりに英訳しているので、ちょっと下手かもしれませんがご容赦ください
:::

### コストは倍になるのか

論文の中で、アメリカのユタ大学で行われた対照実験について書かれた箇所にその答えがありました。

> After the initial adjustment period in the first program (the “jelling” assignment), together the pairs only spent about 15% more time on the program than the individuals [4]. Development costs certainly do not double with pair programming!
> 
> 意訳) 最初の課題の調整時期(ジェリイング課題）の後、ペアプログラミングのみで課題に取り組んだペアは、一人で取り組んでいる生徒に比べて約15%しか多くの時間がかからなかった。ペアプログラミングによってコストが2倍になるわけではなかったのだ！
> ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/ec95c03d-68f4-48cf-ef5a-c1d4adfb36e0.png)

つまりペアプログラミングによるコストは、一人でやるプログラミングに比べて<font color="red">**倍になるのではなく、約15%だけ増える**</font>ということでした。

### 品質はどうなのか

こちらも同じ対照実験の結果に答えがありました。

> Significantly, the resulting code has about 15% fewer defects [4]. (These results are statistically significant.) Figure 2 shows the postdevelopment test cases the students passed for each program – essentially the percentage of the instructor’s test cases passed.
> 
> 意訳）結果としてコードの欠陥は15%減少しました。（これらの結果は統計的に有意です。）図2は、各課題開発後のテストケースをPassした割合を表しています。
> ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/308d1df2-c7b0-379e-26b2-197551e82cb1.png)

ペアプログラミングを行うと<font color="green">**品質が15%向上する**</font>ということですね！

### <font color="red">でも15%工数が増えて、品質が15%向上ってどうなの？</font>

当然その疑問は出てくると思います。
これも論文の中に答えが書いてありました。

(ちょっと長いです)

> The initial 15% increase in code development expense is recovered in the reduction in defects, as the following example illustrates. Let a program of 50,000 lines of code (LOC) be developed by a group of individual programmers and by a group of collaborative programmers. At a typical rate of 50 LOC/hour, the individuals will develop this code in 1000 hours. It will  take the pairs 15% longer or 1150 hours -- a cost of 150 hours. Based on representative statistics reported in [7], programmers inject 100 defects per thousand lines of code. A thorough development process removes approximately 70% of these defects. Therefore, the individuals would be expected to have 1,500 defects remaining in their program; collaborators would have 15% less or 1,275 – 225 less defects.
> In some organizations, developers’ code is passed to a test or quality assurance department, which finds and fixes many of the remaining defects. Typically, in systems test it takes between four [7] and 16 [8] hours per defect. Using a fairly conservative factor of 10 hours/defect, if testing finds these “extra” 225 defects they will spend 2,250 hours – fifteen times more than the collaborators “extra” 150 hours!
> 
> 意訳）開発工数の15%の増加は、次の例が示すように、欠陥の減少(品質の向上)によって回収されます。例えば、50,000行のコード(LOC)のプログラミングを一人で開発するグループと、ペアプログラミングで開発するグループに分けるとします。50LOC/hで開発が進むとすると、個人で開発する場合は1000時間で開発することになります。ペアプログラミングの場合は15%長い1,150時間(150時間のコスト増)がかかることになります。一般的な統計によると、プログラマーは1,000行のコードにつき100個の欠陥を注入します。開発プロセスの中でこれらの約70%が除去されます。したがって、個人で開発する場合は1,500個の欠陥が残ると予想され、ペアプログラミングの場合は15%少ない、1,275個(225個少ない)の欠陥が残ると予想されます。
> いくつかの組織では、開発者のコードはテスト部門や品質向上部門に渡され、残りの欠陥を発見、修正されます。一般的にシステムテストの中で、欠陥一つにつき4時間から16時間の時間を必要とします。1つの欠陥につき10時間の必要を要するとすると、225個の欠陥は2250時間の時間を必要とし、これは増加した工数(150時間)の15倍になる！

つまり中長期的に見たら<font color="green">**15%の品質増加は15%の工数増加のデメリットを大きく上回るメリットになる**</font>ということですね！

## ペアプロのメリット

- 一人で開発するよりも<font color="green">**楽しい**</font>
- 一人で開発するよりも<font color="green">**速い**</font>
- 一人で開発するよりも<font color="green">**リスクが低い**</font>
- 一人で開発するよりも<font color="green">**学びが得られる**</font>
- 一人で開発するよりも<font color="green">**コミュニケーション**</font>が取れる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/3c715308-630d-2e6a-ec97-b67cc7e589cd.png)

## ペアプロのデメリット
- <font color="red">**特にない!!**</font>と書きたいところですが、気を付けるポイントはあると思います

### ◇ 気を付けるポイント

**なんでもかんでもペアプログラミングにしない**

先ほど説明したように15%の工数が増えます。単純なタスクで、だれがやっても欠陥が出ないようなものであれば一人で進めてもよいでしょう。
（ただしその判断はチームで行うべきです）

## ペアプロの心得（特に新人）


### 心得1: 分からないならばドライバーは譲るな

私は変数定義の方法すら知らない言語でもドライバーをやります。
知らない技術ほど積極的にドライバーとして参加することで学びを早く深めることができます。

### 心得2: 傍観者になるな

ナビゲーターはただ見ているだけでなく、ドライバーをサポートするべきです。
「はい。じゃあ次書いて」と言われてすぐ書き始められるような参加の仕方をするとよいと思います。

### 心得3: 疑問を残すな

ちょっとの疑問も残さないようにしましょう。
:no_entry_sign: 「ちょっとわからなかったから後で調べよう」はNGです。
その場で解消し、パートナーとともに成長しましょう。
説明する側も新しい発見があるものです。


### 心得4: コミュニケーションを徹底する

ペアプロはコミュニケーションが鍵です。
常に意見を交換しましょう。
話し過ぎて疲れるくらいがベストだと思います。

## 最後に

ペアプロは単なる開発手法以上の効果があると思います。
高品質なコード、チームワーク、コミュニケーションスキルの向上など、多くの利益をもたらします。

個人で開発をしているチームは試しに一つの機能の開発をペアプログラミングで進めてみるのはいかがでしょうか？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/bc6f82a3-11ee-fb06-07f9-569ea27ddea4.png)