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