ペアプログラミング勉強会で講師をやります。

ペアプログラミング。

先日、TDDBC大阪にTAで参加しました。
その際、「ペアプロ経験者の方」という質問に対し、参加者の殆どが「ペアプロ経験あり」との解凍だったのがとても印象的でした。

しかし、実際にフタを開けると、ペアプロのアンチパターンにはまっている方、正し方法を理解されている方が非常に少なかったように感じました。

---

そもそも「正しいペアプログラミングとは何か？」を定義しなければ、話が進みません。
僕の考える「正しいペアプログラミング」とは、「アジャイル開発の定義に沿っているかどうか」だと考えています。

「アジャイル開発」って、要約すると「高品質なソフトウェアを素早くお客様に提供する」だと理解しています。ペアプログラミングも、その考えに沿っている必要があると考えています。

ここに、「ペアプログラミング十箇条」をご紹介します。
（出典：オブラブ）

---

ペアプログラミング十箇条

1. ドライバー，パートナーは5～10分毎で適当に交代しよう．ドライバーは引き際が肝心．パートナーの助言が多くなったら交代．
2. やることを紙に項目として書き出そう．終わった項目を横線で消そう．
3. コードより先にテストを書こう．テストをパスさせるための最もシンプルな実装をしよう．
4. パートナーは，ツッコミの要領で助言しよう．
5. パートナーは，じれったくなったら「わたしにやらせて！」と言おう．
6. パートナーは，理解できないコードを見たらドライバーに聞こう．「なんでそうなの？」
7. ドライバーは，パートナーの助言にいつでも耳を貸そう．そしてその助言に返事をしよう．
8. ドライバーは，行き詰まったら助けを求めよう．このメソッド，ちょっとお願いできないかな？
9. 腹が減ってはプログラミングはできぬ．一緒にお菓子を食べよう．
10. 楽しくやろう．Enjoy Pair Programming!

---

さて、ペアプロって何のためにやるのでしょうか。

「楽しいから」
「フィードバックをもらえるから」

といった所でしょうか。

アジャイル開発手法とは、確かに「人にフォーカス」して、人を中心においた開発プロセスとなっていますが、それは「人を中心に置くことで、高品質なソフトウェアを素早くお客様に提供できる」からなのだと理解しています。

昔、僕もとあるプロジェクトにペアプロを導入した経験があるのですが、下記思考からペアプロを導入しました。

---

＜目標＞
　・高品質なソフトウェアを素早くお客様に提供したい。

＜現状＞
　・ソフトウェア開発に時間が掛かる（特にレビュー）。
　　→　レビューしなければ、確実に品質が低下する。

＜目標に到達できない原因＞
　・レビューの際、レビュー場所を確保しなければならない。
　・リーダにレビューが集中し、レビューの待ち時間が出来てしまう。
　・レビューの指摘事項を修正し、再レビューしていた。このためレビューに時間が掛かっていた。

＜問題を解決するための課題＞
　・席を移動する時間を減らす。
　・リーダのレビューが集中するのを回避する。
　・レビューの指摘事項を即修正する。
　
＜課題を実現するための施策＞
　・ペアプロを導入する。
　・ペアを信じてレビューを任せる。
　・問題があったら即修正。修正内容はナビゲータが記録する。
　・ペアプロによる生産性が低下してないか確認するため、実施時間を記録する。

---

それまで、コーディング　→　レビュー　→　指摘事項修正　→　再レビュー　→　また修正　……をなんども繰り返していた事もあり、この変更はメンバーに容易に受け入れられました。また、「レビュー待ち」によるロスコストも無くなり、一石二鳥でした。

目標が「高品質なソフトウェアを素早くお客様に提供したい」となっていたため、担当者のペアプロに対する時間の意識はものすごく高かったのを記憶しています。

ペアプロで一定の生産性を叩き出すためには、「休憩」、「交代」、「助言」、「記録」が、絶対必要になります。

この辺り、経験してみないと実感頂けないのではないか、と懸念しています。

3/9, 「男女共同ペアプログラミング勉強会関西」さんのご好意で、上記「ペアプロ」のお話をさせて頂く機会を得ることができました。

興味のある方は、是非ご参加下さい。


■男女共同ペアプログラミング勉強会関西
■第４回勉強会