ペアプログラミングがなかなか浸透しない理由

ソフトの受託開発をしている環境に長年いるが、自分の周りの人たちを見て、ペアプログラミングをしているところは今まで見たことがない。

ペアプログラミングは文字通り一人ではコードを書かず、誰かと一緒に書くことを意味する。ペアを組む人の技能差とか人間関係とかの要因で上手くいかないのかなと思っていたが、別の要因もあるかも知れないと最近思うようになった。

結論から言うと…

プログラム開発工程では悩むという時間は考慮していない。すなわち、上流工程の成果物に基づき、手を動かすだけでプログラムが実装できるプロセスモデルに則った考え方なのだ。

だからなのか、この考え方に基づいた人から大抵このような反応が返ってくる。

「ペアで一つのプログラムを書くとコストが倍になるよね？」

自分もかつてペアプログラミングをやってみようと提案した時にそう言われた事がある。生産効率が良くなるよ、とか説明しても「定量的に効率がどのぐらい上がるか示してよ。工数はあきらかに倍でしょ？」と躱されてしまう。この時の自分はまだ説得する為の熱量を持っていなかったので、結局断念してしまった。

実は見積もりの時も同じことを経験した

開発案件の見積もりをする際に、一人で工数見積もりせずに複数人で同時にやればいいんじゃね？と思い立ったことがある。いわゆる見積もりポーカーである。この時は実際素早く見積もることもできたし、事前の懸案事項も洗い出せたし、一定の効果があったと感じていた。そこで、当時の上司にこの手法を提案したところ「見積もりにかける工数が倍どころの騒ぎじゃない」と一蹴されたのである。

本当に効率が上がらないのか？

そんなことはない。今時案件が始まる時に顧客の要求ががっちり決まっていて、既存の技術を使うだけでよく、設計ー製造ーテストを順に流していく類はほとんど存在しない。むしろ、技術の発展スピードがハンパないので、競合に勝つためにも早く実証実験してみたいという要求が多い。この手のプロジェクトは手を動かすよりも考える時間も多くなる。そこで「考える時間」をチームで共有した方が一人で悩むよりも絶対に効率的だと思う。これは見積もり時も設計開発時も同じだ。
悩む時間よりも課題を早く終わらせて、みんなで新しい技術について話し合う時間に当てた方がまだ健全的だと思う。もちろん飲みに行ってもいいし、家に帰って好きなことをしても良い。

とりあえずやり続けて成果を出し続けてみよう

幸運なことに、自分は一定数のメンバーをチームとして抱えられる立場になったので、一旦周りへの説得は諦めて、とにかくやってみようと思った。余程のことが起きない限り外からの介入はないだろうし。

気になるのはペアプログラミングだけではなくモブプログラミング（Mob Programming)も試してみたい。日本には「三人寄れば文殊の知恵」という言葉がある通り、みんなで取り組んだ方が早く課題が解決するときが多い。チーム編成を気にするのはリーダーの仕事だが……。「Mob Programming」はWeb検索したら色々と出てくるので、興味のある方はそちらも参照すると良いだろう。いつか実験レポートをここに残したい。