2007年08月15日

ペアプログラミングを定着させるには

 ペアプログラミングは、よく知られたプラクティスですので、たいていの人は名前くらいは聞いたことがあるのではないでしょうか。
どういうプラクティスなのか簡単に言えば、名前のとおり2人1組のペアでプログラミングするというものです。
アジャイル開発プラクティスのひとつですね。

 ただ、なんのためにわざわざペアを組んでプログラミングするのか、どうやったら効果的に導入することができるのかについては、どうでしょう?
知らない方も、けっこういらっしゃるのではないでしょうか。

 今回は、私がペアプログラミングを現場に導入した経験を振り返って、このあたりのお話をしてみたいと思います。

コンテンツ

  1. 誰が障壁?
  2. なぜイヤなのか?
  3. どうやって克服するか
    1. 品質特性
    2. 品質宣言
    3. コミュニケーション
  4. 開発時間を短縮する
  5. 成功のヒケツ

誰が障壁?

 テスト駆動開発(TDD)については、導入するにあたって技術者の反発が強いというお話をしました。
では、ペアプログラミングでは、導入に難色を示しやすいのは誰でしょう?
答えは…みんなです。

 もし、あなたの会社に品質管理部みたいなものがあるなら、そこに所属する方達だけが、ペアプログラミングに賛成する可能性をもった、唯一の例外です。
でも、けっこうな大会社でなければ、そんな組織は持っていないでしょう。
だから、多くのケースでは、ペアプログラミングを経験済みの方以外は全ての人が障壁となりえます。

 導入を推進する立場からすると、ペアプログラミングは、アジャイル開発プラクティスの中でも、最も導入しやすいもののひとつのように思えます。
たとえば、テスト駆動開発を正しく導入するためには、ユニットテストやバージョン管理システムの導入、そしてテストの自動実行のためのスクリプトの作成など、ある程度手間がかかります。(もっとも、どれもビジネスとしてソフトウェアを開発するのに必須のことではありますが)
それに比べて、ペアプログラミングを実行するためには、なんの準備もいらず、ただペアを作って、一緒にPCの前に座ればいいと。

 しかし、実際には、準備なしでペアプログラミングを導入することはできません。
いや、導入するだけならもちろんできますが、それでは定着させることができないのです。

 ペアプログラミングの導入に必要な準備とは、ペアプログラミングに対する正しい認識です。
ペアプログラミングの狙いは何なのか?
その狙いに対して、どういうやりかたが効果的なのか?
その効果がどれだけ発揮されたのかは、どうやって把握すればいいのか?
ここでは、それをお話ししたいと思います。

なぜイヤなのか?

 導入を説得される立場から考えてみましょう。
なんの予備知識もなしに、いきなり2人1組でプログラミングをしろと言われたら、どう思うでしょうか?
まず考えるのは、チーム全体のコーディングスピードが半減するということでしょう。
例えばチームに4人のコーディングメンバーがいた場合、普通なら並行して4つのコーディングが実行されますが、2人1組でコーディングすると、並行して実行されるコーディングは2つになります。
だから、チーム全体のコーディングスピードは半分になるという、単純な計算です。

 これが最も大きな疑惑だと思いますが、それだけではありません。
たとえば、一人きりでモニターとにらめっこしていることがコーディングだという考えをもった方は、けっこう多いものです。
「2人でおしゃべりばかりしてたら、いったいいつキーボードを打つんだ?」
という、もっともな疑問をもつ方は多いでしょう。
技術者にもこういった考え方の人はいるかと思いますが、経営者やマネージャにはこう考える人がかなり多くいます。

 もっともでささいな疑問は、他にもあります。
実のところ、自分のコードや、その書き方、書く順番を人に見られるのは、ちょっと勇気がいるものです。
自分の考え方の優れた点だけでなく、欠点をもさらけ出すことになるからです。
こういう考え方―自分の欠点を隠したいという考え方自体がハズカシいものですので、この理由を面と向かって誰かに訴える人は、ほとんどいないでしょう。
ですが、実はまさにこの理由のせいで、ペアプログラミングの導入に積極的になれない開発者は、意外と多いのではないでしょうか。

どうやって克服するか

 さて、こういった障害を克服し、ペアプログラミングを導入するにはどうしたらいいのでしょうか?
コーディングという作業に対するちょっとした偏見や、他人と作業を共有することに対する不安など、心理的なものを克服するためには、説明と証拠が必要です。
「それは単なる偏見だ」とか「その感情は正当でない」とか、真正面から指摘してみても、反感をかうだけですので、くれぐれもやめておきましょう。
そういう場合は、相手の非を突いて不必要に刺激するようなことは避け、正当でもっともな説明と、揺るがぬ証拠によって覆すのが一番です。
品質特性
 なぜそうした方がいいのか?なぜそうすべきなのか?という問いに対して、あなたはきちんと答えることができますか?
 ペアプログラミングに対するこういった問いに答えるためには、品質というものを理解していることと、品質と開発効率の関係を知っていることが必要です。
ソフトウェアの品質特性には、大きく分けて、機能性、信頼性、使用性、効率性、保守性、移植性の6つがあると、一般に言われています。
これらの特性は、ばらばらに存在するものでなく、相乗効果をもっていたり、相殺しあったり、お互いに複雑に影響しあっています。
これはこれで、長い話になってしまいますので、詳しくはまた改めてお話ししたいと思います。

 ただ、どの特性が重視され、どの特性がそうでないのかについて、最初から開発メンバー全員が合意している必要があります。
そうでないと、部分部分で品質の傾向が異なる、ちぐはぐなソフトウェアができあがってしまいます。
結果的に、どの品質特性も満足できない、品質の低いソフトウェアになってしまうのです。

 しかし、合意していると言葉で言うのは簡単ですが、実際には難しいことです。
ある品質を重視するというとき、いったいどの程度重視するのでしょうか?
ある品質を犠牲にするとき、実際にはどこまで許されるのでしょうか?
明確に定義する必要があります。
でも、どうやって?
品質宣言
 まず、重視する品質特性はどれなのか、ということは、明確にするべきです。
そして、いくつかの最も重要な点については、具体的にきちんと指針を述べるべきでしょう。
他の細々としたことについては、少し例を挙げてみるのもいいかもしれません。
でも、いずれにしろ、全てについて定義することはできません。
開発が始まる前から、何が起こるのか全て予言するのは不可能ですし、はちきれそうなキングファイルに詰め込まれた、膨大な決めごとの束など、誰もマジメに読もうとは思わないでしょう。
読んだって、覚えきれません。
みんなにきちんと守ってもらうためには、決めごとはできる限り少なくすべきです。

 ですが、単に決めごとを少なくするだけでは、統一などとれませんね。
どうすれば?
話し合うことです。

 プロジェクトのはじめに、全員で議論することが効果的でしょう。
最初に、全員のベクトルを一つに合わせておくのです。
ベクトルを合わせるのは、できる限り早くすべきです。
違う方向に歩き出してしまったら、時間が経てば立つほど、お互いの距離が離れてしまいます。

 プロジェクトの最中も、定期的に議論すべきです。
実際に開発を行うことで出てくる一つ一つの問題について、解決していくのです。
最初に全てを予見しようなどという無謀な試みなどやめて、実際に問題が出てから、それに対処するわけです。
問題の捉え方、対処の仕方が常に筋が通ったものであるならば、その積み重ねによって、メンバーに方針についての共通認識が生まれます。

 人間というのは全く記憶力の弱い生き物で、議論を離れて、コーディングしているときには、それでも迷ってしまいます。
なぜなのでしょう?
覚えておくべきものが、議論の場で交わされた一つ一つの言葉でなく、ニュアンスだからです。
既にお話ししたように、言葉で全てを語り尽くすことはできないのですから。
キングファイルいっぱいの文字を、口でしゃべっても意味はありません。

 だから、ペアプログラミングなのです。
今やっていることは、正しいことなのか?方向を見誤ってはいないか?
常に、お互いに方向修正をしながらプログラミングをするために、ペアが必要なのです。
一つの作業を一緒に行い、常に意見を交換することで、ニュアンスについての共通認識を作り、空気を共有するのです。
こんな考え方は、不安定で信用できませんか?
キングファイルいっぱいの、誰も読まないし、覚えられない決めごと集の方が、これよりマシに思えますか?
コミュニケーション
 開発者同士がテレパシーで考えを共有できるなら別ですが、コミュニケーションをとらなければならないのは、人間の宿命です。
それで、普通は口頭であれ文字であれ、言葉によってコミュニケーションをとるわけですね。
しかし、言葉というのは、あくまで記号でしかありません。
その実際の意味は、それぞれの人の頭の中にあります。
ですから、それぞれの人の個性によって、微妙なニュアンスの違いが生まれてしまいます。
言い間違い、聞き間違いなどによるコミュニケーションギャップ以前に、そういう根本的なギャップがあるのです。

 だから、単に言葉で定義しただけでは、充分にコミュニケーションしたとは言えません。
完全に隅から隅まで、誤解のしようがないように言葉を尽くせば、覚えきれないほどの膨大な量になってしまい、結局伝わりません。
ニュアンスや空気、行間と言われるものを共有することが必要なのです。

 そのためには、共同作業と、絶え間ない意見交換が有効です。
共同作業をすることによって、お互いの考えを理解したり、目標を共有することができたという経験はありませんか?
ペアプログラミングは、言葉にならなかったり、言葉で説明すると大変なことを共有するという、テレパシーのような効果をもたらしてくれるのです。

 ペアプログラミングはプログラミングとレビューを同時に行うものだともいえます。
ペアプログラミングをすれば、レビューは不要という意味ではありませんが、より素早いレビューは、大きな工数削減につながります。
このことは、テスト駆動開発やユニットテストを定着させるにはでお話ししたことと同じです。
自動テストで素早く欠陥を見つけることと、ペアプログラミングで欠陥や誤った方向性を素早く見つけることには、同じ効果があります。

開発時間を短縮する

 ペアプログラミングは、経営者やマネージャの予想に反して、実際には開発時間を短縮します。
例えば、常に相談し合いながらコーディングすることができるので、考え込む時間が減ること。
また、最初から妥当なやりかたで実装できる可能性が増すので、書き直しをする回数が減ること。
欠陥を埋め込む可能性が減るので、デバッグの時間が短縮されることなどが、その理由です。

成功のヒケツ

 こういったペアプログラミングの利点を生かすためには、開発者としての熟練度ができるだけ近い人同士がペアを組むべきです。
片方がもう片方に一方的に説明する状態に終始するのでなく、お互いに意見交換をする状態が、最も考えを共有できるからです。

 それに、もっとおもしろくない理由もあります。
熟練度が低い開発者がフォローされることによるパフォーマンスアップ効果よりも、熟練度が高い開発者がフォローのために時間をとられることによるパフォーマンスダウンの方が、ほとんど常に高くつくことになります。
開発者の熟練度と開発効率は比例しますが、その関係は線形的な倍数のオーダーではないからです。

 Code Complete第2版〈下〉―完全なプログラミングを目指してでは、熟練者と非熟練者で、開発効率に10倍の差があることが指摘されています。
また、デバッグ時の欠陥検出スピードでは実に20倍もの差があることも述べられています。

 ですので、できる限り熟練度が近い人同士がペアを組むのが、最もムダのないやりかたです。
ただし、初心者同士がペアを組むべきではありません。
2人とも解決できない、どうにもならない状況にたやすく陥ってしまうからです。
初心者は、誰かに面倒を見てもらうべきです。
このためにも、また知識を広範囲で共有するためにも、ペアは定期的に交代するといいでしょう。
私は、できれば毎日交代することをオススメします。

 開発プロセスはインクリメンタルであるべきですが、その最小単位として最も効率的な粒度は、1日分の作業です。
ペアを毎日交代するということは、作業自体が1日で終えられる大きさであるべき、ということになりますね。
でないと、毎日新しいパートナーに作業の説明をすることからはじめなければなりません。
このことは、1日分の作業という粒度が適切であることの一つの理由でもあると、私は考えています。
インクリメンタル開発プロセスについても、また機会があったら別にお話ししたいと思います。


 ペアプログラミングを有効なOJTとして活用することもできます。
以下のような条件を満たしていれば、OJTとして成り立つのではないでしょうか。
  • チーム全体がペアプログラミングに慣れている
  • 熟練者がOJTについての基本的な知識を持っている
  • 熟練者の人数と初心者の人数のバランスが適正(初心者の人数が熟練者の人数の1/3以下)
  • チームが、初心者と、ペアとなった熟練者に対してフォローできる体制をもっている
こういった条件を満たしていない場合には、ペアプログラミングをOJTと考えることは逆に危険です。

 Code Complete第2版〈下〉―完全なプログラミングを目指してには、他にもいくつかの細かい注意点が指摘されていますので、そちらも参照されるといいでしょう。

 最後に、ペアプログラミングを実際に導入した後、それを定着させるには、関係者に実効性を証明する必要があるでしょう。
つまり、導入したら、開発効率がどう変化したのかを計測する必要があるのです。
それが、最初にお話しした揺るがぬ証拠となります。
ソフトウェア開発プロセスの状況を捉えるための方法は、初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方を参考にしてみて下さい。
現状を計測するための指標と、その意味などがわかりやすく解説されています。
posted by craftsman at 08:37 | 東京 ☀ | Comment(3) | TrackBack(0) | 発展編
この記事へのコメント
craftsmanさん、こんばんわ
ペアプログラミングの記事、とても参考になりました。
実は、最近スタートしたばかりのプロジェクトでペアプロを導入してみました(メンバーは二人だけなのでペアの交代はできないですが)。
先日、私のブログでcraftsmanさんの記事にトラバを貼らせて頂いた際には、まだチャレンジしないと言っていたのですが、パートナーにTDDやOOを実践的に身に付けてもらうのにペアプロは効果的かなぁと思って取り入れちゃいました^^;
記事中で紹介なされている「Code Complete第2版(下)」、是非読みたいと思います。ちなみに下巻からいきなり読んでも問題ってないでしょうか?(上巻も買う予定ですが、金銭的にすぐに両方は買えないので^^;)
Posted by よこけん at 2007年08月17日 00:29
こんばんわ、よこけんさん。

 交代のメリットは、ペアをいろいろ組み替えることで、プロジェクト全域の知識をメンバーにばらまくことです。
だから、メンバーが2人なら、交代するまでもなく、知識は共有できてますよね。
私は、まったくOKだと思いますよ。

 ただ、パートナーに何かを教えるという意味でペアプログラミングを行うと、どうしても
●よこけんさんが全てコーディングして、パートナーは見てるだけ
●よこけんさんが全て指示して、パートナーは書くだけ
みたいなことに、なりがちです。
できるだけ、パートナーさんにも、積極的に参加してもらえるようにすると、いいかもしれませんね。

 Code Completeは、章ごとにきちんと話題を区切ってあって、お互いに依存性は低くなっています。
ですから、下巻から読んでも、問題ないと思います。

 下巻に、上巻の目次もついてますので、それを見れば、どんなことが書かれているのかがわかります。
上巻を買うときの参考になさると、いいかもしれませんね。
Posted by craftsman at 2007年08月17日 01:18
craftsmanさん、お返事ありがとうございます。

> 私は、まったくOKだと思いますよ。
問題なさそうで良かったです^^;
複数ペアも体験してみたいんですが、経験者が複数人混ざってないときつそうだな、と思いました

> できるだけ、パートナーさんにも、積極的に参加してもらえるようにすると、いいかもしれませんね。
おっしゃる通りです、コーディング中はパートナーの方にも意見を求めるようにはしているのですが、結局私が全て解説しながら進めているという感じです。
相手のコーディング時も、まず考えてもらう時間を設けてはいるのですが、結局私が指示して進むといった感じで、どうしても私がでしゃばっているような構図になってしまってます。
そして、実は充分な理解が得られていないことが後から判明するといった感じです。
まだ始めて間もないので、今後徐々に変化していくだろう、そのためにはこちらも努力しなければ、と考えていますが、中々難しいものですね^^;

> Code Completeは、章ごとにきちんと話題を区切ってあって、お互いに依存性は低くなっています。
> ですから、下巻から読んでも、問題ないと思います。
それを聞いて安心しました、ありがとうございます^^

> 上巻を買うときの参考になさると、いいかもしれませんね。
是非そうさせて頂きます。おそらく上巻の購入も揺ぎ無いものと思われますが(笑)
Posted by よこけん at 2007年08月18日 00:38
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/51354886
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。