エンジニアチームの村山です。

シナップでは今年からいくつかのR&D(研究開発)を立ち上げており、その一つであるスマートフォンのネイティブアプリ開発のR&Dに参加しています。「アプリが開発できるようになる」という大目的の他にも、アジャイル開発方法の一種であるスクラム開発やリーンの考え方、ペアプログラミング等今までシナップでは取り入れていなかった様々な方法を試行しています。

今回の記事ではその中のひとつ、ペアプログラミングの実施について取り上げてみたいと思います。

ペアプログラミング、知ってますか？

Webサイト製作ではペアプログラミングをすることはほとんどないかと思います。 やったことないけど名前は知ってるという方は多いのではないでしょうか？

「それって二人でひとつのソースを開発するんでしょ？」

そんな認識だと思われます。私もその程度の認識からスタートしました。

それをする目的

ペアプログラミングには様々なメリットがあるとされていました。

より良いコードを書く、人に教えることで・教わることで知識を高める、勤労意欲・生産意欲の向上、生産性を高める、コード情報の共有、等々。

特に生産性に関しては様々な研究がされているようで、このあたりに関しては調べてみるといろんな文献が出てきます。

ペアプログラミングの生産性は1人で作業した場合の2倍以上であることが研究によって示されている。エコノミスト誌によると、「ソルトレイクシティ、ユタ大学の Laurie Williams によれば、ペアプログラミングは2人のプログラマが個人で作業した場合に比較して、15% コーディング速度が低下するが、作りこむバグ数も 15% 少なくなる。テストやデバッグにはコーディングよりも時間がかかるので、この調査結果は興味深い」Laurie Williams は現在はノースカロライナ州立大学の准教授である。

Williams 他 (2000) の調査によると、プログラムの正確性は 15% 向上し、時間的には 20 から 40% 程度の削減となり、最終的な成果としては 15 から 60% の効率向上があるとされている。

最近の大規模な研究（Arisholm 他 2007）によると、複雑なシステムではプログラムの正確性が48%向上し、大きな時間の削減は見られなかったとされている。一方、単純なシステムでは時間が 20% 削減され、正確性には大きな変化が見られなかったとされている。全体としては、時間の削減や正確性の向上の傾向は様々だが、最終的な効率は 84% 向上している。

wikipedia: ペアプログラミングの項より引用

ただ今回のプロジェクトは研究開発・R&Dとしてのものなので、生産性を得たいのはもちろんでしたがそれ以上に学習効果やコード情報の共有を行いたかったためにペアプログラミングを実施しました。

とりあえずやってみた

何はともあれまずはやってみようということになり、同じR&Dプロジェクトメンバーの山本とペアプログラミングをやってみました。

こんな感じでやればいいのかな？という手探りな感じで、１回目は内容を「開発済み部分のデザイン改修」、時間を「２時間内」として実施しました。

普段アプリ開発のメインは山本なので、キーボードが私村山で、指示が山本という配役です。

ダメでした

いざ始めてみると、まずコードがよく分からない問題にぶち当たりました。

普段ガリガリ書き進めている山本のコードを、舵取りメインになってる村山が見てもどこに何が書いてあるのかわからない...。そのため改修以前に現状のコード把握から行うこととなりました。

現状コードを書いた山本が「これはここで、これはもっと上の方で、それはデリゲートで...」といった具合に何かを直すためにいろんなところを参照したり説明したりという感じです。 山本にはどこに何があるかわかっているのですが、自分にはどこに何があるのかさっぱりわからずそれを逐次確認しながらの修正作業となりました。

ペアプロってなんかもっとこうきっちりかっちり開発を進めていくイメージだったので、コレジャナイ感を感じました。

でもできました

紆余曲折、大回りしながらもなんとか修正は完了しました。やる内容に対して時間を多めに見ていたこともあって、とりあえず直したかったところの修正はできました。

１回やってみて、

• ソースがすごいことになってる事が把握できた
• (相手のコードを見ながら）そういう考え方もあるのかという発見
• 相談しながらできるからはまらずできる
• 修正作業ってペアプロに向かないんじゃない？
• もしくはコードレビューする時間がいるんじゃない？
• ２時間長くない？

といった感想・反省がありました。

修正は現状把握がきちんとできないと何もできないのでペアプロでやることではないんじゃないかなーというのが個人的には大きかったです。

ペアプロで修正を行うのであれば、まず現状コードのレビューをしてから始める必要があると感じました。

その後も何度もやってみた

フィードバックを反映しながら週１ペースでペアプログラミングを実施しています。

後半になればなるほど新規での開発は少なく、修正がメインになってくるためペアプロする箇所も修正がメインです。

ペアプロで修正を行う時は初回の反省を生かし事前レビューを行いコード状況を整理してから行っています。

序盤でやっておけばよかったなと思いますが、設計をがっちりやってから作り始めるプロジェクトではないためそれは難しかったかもしれません。 またエンジニア2人は初心者状態から始めていたため序盤でペアプロをしていたとしても、お互い内容を理解できずペアプログラミングをやる目的を考えると意味がなかったかもしれないです。

感想的なもの

現場の話をすると、初心者レベルから始めたので「より良いコード」を書くという目的より「相談しながらコーディングできる」というの意味合いが強くなっています。

１回目の感想にも書いたのですが相談しながら書くことで、一人で考えて変なところでハマらずに開発できるのは始めたばかりの状態だとなかなか有用と感じました。（リソースを２倍かけているのでそれはそれという問題もありますが）

コードの共有・レビューにもなるし、R&Dプロジェクトとしてはこれからも続けると思います。

そのほか、調べたり実践するのに参考にした資料など

• ペアプログラミングのやりかた
• ペアプログラミング ホントのところ @t_wada
• グラス片手にアジャイル開発　第6回 － アジャイル開発手法「ペアプログラミング」

現場からは以上です :)