週 40 時間ペアプロ
ここ 3 ヶ月ほど、所属しているチームの開発者全員が常時ペアプログラミングしている。
今やっている開発は、ほぼ、「ケント・ベックの本に書かれている XP」そのまんまのスタイル。*1
プロダクトマネージャが書いたユーザーストーリーを、プロダクトバックログの上から順に、4 人の開発者が週 40 時間労働で、毎日朝から夕方まで常時ペアプログラミング、TDD で開発している。*2
このように日常動作がペアプロなので、自然、ペアプロについてメタ的に考えることがある。
そんな折、ふと「この常時ペアプロするスタイルって初心者向けなのでは？」という考えに至った。
守破離の守
「守破離」という言葉がある。
以下に Wikipedia の記述を引用する。
まずは師匠に言われたこと、型を「守る」ところから修行が始まる。その後、その型を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる型をつくることにより既存の型を「破る」。最終的には師匠の型、そして自分自身が造り出した型の上に立脚した個人は、自分自身と技についてよく理解しているため、型から自由になり、型から「離れ」て自在になることができる。
守破離 - Wikipedia
この「守破離」でいうと、チーム開発において「常時ペアプロする」というのは「守」なのではないか。
言い換えると、チームで生産性の高いソフトウェア開発をしようと思ったときに、「まずは常時ペアプロする」のがいいのではないか？ ということ。
「できるところから」とか「必要なときに」ではなく、いきなり「常時」やる。
逆に言うと、「常時ペアプロする」のはあくまで「初心者の動作」であって、チーム開発が上達するにつれて、やがて「常時ペアプロ」ではない形態に転換していくのではないか？ ということ。
チーム開発に熟達すると、必要なときにペアプロし、そうでないときにはそれ以外のスタイルを取れるようになるのではないか。
XP におけるペアプロ
ところで、ペアプロというプラクティスは、「ケント・ベックの本に書かれている XP」の肝だと思う。
ここのところ、「週 40 時間ペアプロ」する日々のなか、ペアプロを日常動作の中心に据えることで、XP の価値・原則・プラクティスが、美しく統合されることを実感している。
XP の価値である「コミュニケーション」も、「フィードバック」も、「勇気」も、「リスペクト」も、ペアプログラミングというプラクティスからなめらかに導かれるし、ソロであればついつい設計や実装に不要な複雑さを持ち込みがちなところ、ペアで作業していれば「シンプリシティ」も保たれる。
「経済性」という原則については結論を（直感的には）即断できないとしても、「人間性」「多様性」「流れ」「機会」「冗長性」「品質」「責任の引き受け」といった大半の原則が、ペアプログラミングからほとんど直接の効果を得られる。
多くのプラクティスについても、同様のことがいえる。
「常時ペアプログラミング」することで、XP の価値・原則・プラクティスに則ったチーム開発が格段にやりやすくなる。
ペアプロのペイン
ここまで、ペアプロをほとんどべた褒めしてきた。僕はペアプロが好きだ。
でも実は、ペアプロには苦手なところもある。
コードを書くのが速すぎて、ペアの相手がついてきてくれないのである。
これは、僕のプログラミング能力が（チーム内で相対的に）高すぎるのか……そんなことって……、とか考えていたら、実はそうではないようだ、ということに気づいた。
僕は、コードを書くときに「トップスピードで試行錯誤しまくることで最短時間で正解にたどり着く」ようなスタイルを取るのが好きだ。マシンにできることは、マシンにやらせたい。*3
でも、ペアプロのときにこれをやると、実質「ペアの相手はマシン」という状態にになってしまう。僕とマシンのペア。
すると、人間のペアが置いてきぼりになる。
それではまずいので、常に思考を発話し、相手の理解を確かめながら進める。ところが、相手の理解を待っていたら、トップスピードではなくなってしまう。*4
理解を待たないわけにはいかないので、結果として、ソロでやったときよりも、その場の開発スピードは落ちることになる。
もちろん、ペアの相手が僕の知らないことを知っていて、ペアの力で速く進めることもある。これは、ペアプログラミングの重要な利点でもある。
だとしても、その場の開発スピード（の平均値）はソロのときよりも落ちる、というのが偽らざる実感で、そこがペアプロのちょっとだけ苦手なところ。*5
ペアプロの生産性
では、僕がいるチームでは、ペアプロしないほうがいいのか？
「しない」とは言わないまでも、「ペアプロしたり、しなかったり」するほうがいいのか？
そう考えてみても、やっぱり、今は「常時ペアプロする」方がいいと思う。
それは、ペアプロがもたらす価値が、「今コードを書く速さの低下」を補って余りあるから。
定量的に説明するのはちょっと難しいけど、「XP におけるペアプロ」のところで並べ立てた、XP の価値や原則、言い換えると「チーム開発の生産性を高めるための道」をペアプロが導く、ということが、説明になっていると思う。
プログラミングはコミュニケーション
関連する話題をもう一つ。
プログラミングは、コミュニケーションだと思う。
もちろんプログラミングの第一義は機能の実装、価値を届けるために動作するコードを生産することなんだけど、その生産性を高めるためには、「プログラミングはコミュニケーションだ」ということを理解している必要がある。
読みやすいコードも、整然としたアーキテクチャも、チームのメンバーや、将来の自分、そして将来そのコードを読み、使い、変更する人とのコミュニケーションのためにある。
テスト駆動開発によって設計を導くのも、チームメンバーとのコミュニケーションのためであり、理解しやすく変更しやすい設計による将来のコミュニケーションを導くためだ。
なぜコミュニケーションが重要かというと、コミュニケーションのなめらかさが、製品の品質や、生産性に跳ね返ってくるから。
そして、XP は「コミュニケーションとしてのプログラミング」の「先生」であって、ペアプログラミングこそがそれを導くものだと思う。
ペアプログラミングがそれを導くなら、常時やればいい。
プログラミングがコミュニケーションであることが、「今コードを書く速さが落ちるとしても、ペアプログラミングをした方がいい」ことの説明になる。
ペアプロの「破」「離」
ということで、「常時ペアプロ」がチーム開発の「守」にあたる、という話に戻ってくる。
やや乱暴な言い方をすると、常時ペアプロすれば、チームとしての生産性が上がる、とも言える。
「すれば」→「上がる」というのは、まさに「守」だ。いつペアプロすべきか、とか、何をどう工夫すれば、とか、考えなくていいのだ。*6
では「破」「離」はなにか。
それが「いつペアプロすべきか」考えること、そして選ぶこと、なのだと思う。
まだその域に至っていないので、何が「破」で何が「離」にあたるのかはわからないけど、いずれにせよ、「ペアプロするとき、しないとき」を使い分けるのは「上級スキル」だ、という感覚が今はある。
下手に「一人でやったほうが速いから」ということでソロ作業を取り入れると、「速さ」以外の、コミュニケーションにかかわる価値を損なって、結果としてチームとしての生産性（要するに、中長期的な「速さ」！）が低下しかねない。
だから、初心者のうちは、常にペアプロした方がいい。
そうすれば、ペアプロのメリットもデメリットも余さず体感できるし、経験が少ないうちは、下手な工夫でやったりやらなかったりするよりも、チームとしての生産性の平均値は高くなるはず。
とはいえ、いつまでもずっとペアプロを盲信するのではなく、いつか「破」に移行して、また「離」にいけるといいな、と思う。
それはモブプログラミングのような形かもしれないし、もしかしたら、全員がソロに戻るという可能性もある。
結局、常時ペアがいいということになるかもしれないし、それらの間になるかもしれない。
結論
僕は、今いるチームで「全員常時ペアプログラミング」することで、チームの生産性向上を感じている。
チーム開発の初心者や、集まったばかりのチームは、「少しずつ導入」するよりも、むしろ「全員常時ペアプログラミング」を試してみるといいのではないか。
ペアプログラミングは、「コードを書くスピード」が落ちることもあるけど、「コミュニケーションとしてのプログラミング」を強力に推進する。
それはチームとしての生産性の向上を導き、中長期的な生産性にもつながる。だから、やる価値がある。
はじめは「常時ペアプログラミング」して、慣れてきたら、「ペアプログラミングしないとき」について考え始めるといいのではないか、と思う。
補遺
ペアプログラミングには、「誰もが好むわけじゃない」という課題がある。
ペアプログラミングの研究者が書いた本にも書かれていることだし、僕の周りにもペアプログラミングが苦手な人はいる。（もちろん、それは責められるべきことではない）
僕の場合、今のチームには、少なくともペアプログラミングが「すごく苦手」「大嫌い」という人はいなそう。（直接面と向かって「大嫌いですか？」と聞いたことはないけど……）
だから、成り立っている。
もし、チームの中にそういう人がいそうだったら、導入は慎重に。
強制すると、みんな幸せになりません。
*1:ブログ購読者の方向け: 今は、以前スクラムをやっていたチームとは別のチームにいます。以前のチームは、形を変えながらもスクラムによる開発を続けています。ちなみに、モブプログラミングを実践しているみたいです
*2:なお見出しにはわかりやすいように「週 40 時間ペアプロ」と書いたけど、定時が週 37.5 時間なのと、プログラミング以外の時間もあるので、実質は 30 時間くらいだと思う
*3:コンパイル言語でテストも書いてれば、考える時間ってあんまり必要なくて、書かれたストーリーを見て、上からいくか下からいくかだけ仮決めして、あとはIDEとテストの導きに従ってひたすらキーボードを叩いてたら、コードはできあがる。立ち止まって考えるのは、最初と、打鍵しながらと、機能が一通り動いて少し大きめにリファクタリングしようと思ったときだけで十分。
*4:これは能力差の問題というより、非対称性の問題。マシンは人間より桁違いに速いので、正しい入力も間違った入力も、瞬時にフィードバックしてくれる。でも、人間はそうはいかない。相手が僕の 2 倍くらい速い人じゃないと、トップスピードは出せないと思う
*5:これに気づいて（つまり、「僕の開発スタイル」が原因で、「ペアとしての生産性」が最大化できていないようだ、ということに気づいて）、自分の開発スタイルを「ペア用」にチューニングすることを考え始めたのだけど、この記事の本旨とはずれるので、ここでは議論しません
*6:「考えなくていい」というのはもちろん言いすぎで、考えるのはいいことだし、考えたほうがいい。でも、考えながらも、基本動作としては「常にペアプロする」。
