シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。

ペアプログラミング

»

 アジャイル開発のプラクティスの1つにペアプログラミングというものがあります。アジャイル手法で一番有名なエクストリームプログラミングでは、このペアプログラミングを常時使うもので、必須という位置づけです。

 アジャイル開発自体があまり普及していない日本の現場に、実際この方法がそれほど普及しているとは思えませんが、少なくともわたしの今までの開発現場は、ベンチャー企業の社内開発が中心でしたので、いろいろなところで重宝しました。

 考えるに、日本の普通の現場でも、ベテランが新人に教える時などに、ペアプログラミングが使われているのではないでしょうか。もちろん、その頻度は、正式な方法としてペアプログラミングを使われている、と言えるほどのものではないと思います。つまり、プロジェクト管理の中で正式な工数として入れられているものではないでしょう。先輩のプログラマは、自分に割り当てられた仕事の時間を削って、新米プログラマのための技術指導として、ペアプログラミングをしなければなりません。これでは、あまり頻繁には使えません。

 わたしの開発では、堂々と工数としてペアプログラミングを入れてきました。ただし、エクストリームプログラミングのように常時使うものではないです。新たに加わったディベロッパーに、チームの流儀、例えば使用しているフレームワーク、コーディングスタイルを伝授するために最初の数週間行うなどで、主に技術の伝授の手法の1つとして使います。 

 ドキュメントを使ってのコーディングスタイルの伝授も1つの方法です。しかし、それよりコーディングスタイルは、フレームワークをうまく作り、同じコーディングスタイルを使わなければコーディングできないような仕組みを作り、それ以外の、より細かいところは、ペアプログラミングや、コードレビューなどを通じて徹底していく方がよいと、わたしは考えます。こういうスタイルにすると、不合理及び不必要ななコーディングスタイルは最終的に誰も守らなくなるなどして、淘汰されていき、もっとも自然なものだけが残るようになります。コーディングスタイルの目的は、大上段に構えた管理者が独善的に決めたルールを守ること自体が目的ではなく、デベロパー相互でお互いのコードのメインテナンスを容易にすることが本来の目的ですので。

 さて、ペアプログラミングのもう1つの使い道としては、また難しい問題に差しかかったとき、二人いればよいアイデアが出てきやすいだろうと、2人で問題解決に取り組む時などにも使います。さて、このペアプログラミングについて思ったことを書きます。

■異文化デベロパー同士のペアプログラミングに、言葉はあまり重要でない

 口頭での言葉のやり取りでお互いやりたいことを話し合いながら、2人のディベロパーが1つのPCを前に作業することがペアプログラミングです。言葉が通じ合うことが、非常に大事だと思うでしょう。わたしの話す英語は、自分では完璧だと思っているのですが、どうも通じないことが多いようです、特にネイティブでない人は、わたしの英語は理解に苦しむようです。わたしの方も、少しでも訛りが入った英語は、理解に相当苦しみます。わたしの今のシンガポールでの開発では、お互いが外国語である英語を使ってコミュニケーションをとりながら、ペアプログラミングをするわけですが、最初はどうなることかと、思いましたが、実はそれほど困らないのですね。

 たぶん、プログラマ同士、お互いに完璧に理解している共通の言語(つまり、なんのこともないコンピュータ言語ですが)が存在するからでしょう。C# やJavaそしてVB、最近はF#、さらにUMLも強力な共通言語です。もちろん何らかの口頭によりお互いの意図を伝え合う手段、つまり英語によるコミュニケーションは必要ですが、完璧である必要はぜんぜんありません。紙や白板にUML図を書きながら、ブロークン英語で意思の疎通を行い、微妙な所で困ったら、実際にコーディングして見せれば、それで大体通じるのです。

 ということで、口頭によるコミュニケーションに多少の問題があろうと、ペアプログラミングの妨げにはあまりならないということです。しかし、お互いの文化の違いによる、発想の違い、要件に対する解釈の違い、そういうことの方がよっぽど大きな妨げになるものと思います。

■ペアプログラミングのメリット

 刑事ドラマなどを見ると、先輩刑事と新米刑事2人が組になって、聞き込み、張り込みなどをやる風景があります。刑事が2人で行動するという方法は、不正、つまり、悪い組織との癒着を防ぐとか、安全面で2人のほうが安全など、先輩から後輩への技術の伝授以外に他のメリットがあります。

 プログラマの世界でのペアプログラミングも、先輩から後輩への技能の伝授の他にも重要なメリットがあると思います。1つは、設計がわかりやすいものになるということ。2人でコーディングすることにより、1人だと独善的、作った本人にしか分からないようなスパゲッティー化したプログラムになってしまうところを、防ぐことができます。設計を分かりやすいものになるメリットを持つもう1つのソフトウエア開発プラクティスとして、TDD(Test Driven Program)がありますが、これを実践するのは、かなりの準備とトレーニングが必要ですが、ペアプログラミングは簡単にいつでも、どこでもやることが可能です。

 もう1つのメリットとして忘れてはならないのが、孤独になりがちのソフトウエア開発が、よりチーム開発になるということです。プログラマと言う人種の多くは、人より機械が好きというような、英語で”Geek”。日本語ではたぶん『オタク』です。人と付き合うのが苦手なものです。ほっとけばどんどん自分ので世界に入り込む人種です。2人で共同作業をしていれば、その傾向は薄まります。

 ペアで仕事をしていれば、昼休み後の眠たい時間帯でも、眠らずに仕事を続けることができます。その分、疲れるのも早く、長期間残業は難しくなります。9時から6時まで、とにかく集中して、仕事をして、成果を出す。6時以降は、完全にオフにして、次の日の仕事のため、休養する。理想的なプロフェッショナル・ライフです。他の種類のエンジニア、特に機械系のエンジニアの仕事はたぶん、発想のひらめきとかいうような、もっとも創造性が必要な部分は、1人でしかできないものが多いのでないかと思います。プログラマの世界はコンピュータサイエンスの進歩や、その性質からか、言葉でそのひらめきを表現できる部分が多いものです、そのため共同で作業できる部分が多いものです。

 ということで、日本の現場でもペアプログラミングが普及していくことを説に願います。最後にペアプログラミングを行うと、能率が半分になると思っている方。たぶん、プログラマとしての経験が長い方はそういう風には思わないと思いますが、経験のない方のためにちょっとだけ説明します。

 プログラムの実際の作業は、要件を理解して、その方法を調べて、やってみて試して、だめならその理由を突き止め、デバッグ、必要なら別の方法を適用、というような流れです。その中で調べるところや、だめで理由を突き止めるところなど、2人であたれば、2倍以上の効率になります。また、ベテランと初心者を組ませる場合など、ベテランは方式をじっくり考えることに集中。初心者は、繰り返して行うような部分をやるなど、2人のチームでの自然な役割分担ができます。うまくいけば、2人で10倍以上の効率を達成できます。

Comment(6)

コメント

wona

理解が浅かったらすみません。
どうして「ペア設計」や「ペアドキュメンテーション」、「ペアテスト」という
言葉はないのに「ペアプログラミング」という言葉はあるのでしょうか?
他の作業に比べてプログラミングの方がペアでやることによる生産性の向上率が
高いからなのでしょうか?
ペアプログラミングに書いてある効用は、プログラミングに限定した話じゃないと
思うのですが・・・。
それともプログラミングは一人でやるものという、固定観念が他の作業よりこびり
ついていたということなのか・・・。
というようなことを最近考えたりしています。

山本

プログラミングは一人でやると言うイメージが強いことから、そうではない方式を強調するための言葉かと思います。
後、ペアープログラミングはだいたいアジャイルの開発環境で使います。ウォーターフォールで、使う技術をすべて把握したプログラマが、完璧な詳細設計所を見ながらやるような現場では、ペアープログラミングは、それこそ半分の生産性になってしまいます。つまり、設計工程とプログラミング、そしてTDDを採用していれば、テストまをプログラミングの工程で実施することになります。さらに、ドキュメントも、アジャイルのプラクティスを徹底していれば、ほとんどソースコードそのものがドキュメントになっていくわけで、ドキュメントまでが一つの工程となります。そういう意味でペアープログラミングという言葉で、ソフトウエア開発工程すべてをペアーで行うということだと思います。

あとむ

日本でフリーエンジニアをやっているあとむと申します。

コラムにすごく共感しました。
私が現在常駐している現場では大規模webアプリ開発というのもあってか
古き良きウォーターフォール型の開発現場です。
 →余談ですが、日本にはこれが馴染むのかもしれませんが…

個人的にはスピード重視で、チケット駆動開発等で
設計~開発~テストの流れを一連の作業として
逆に単位は機能単位で区切るのが良いと思っています。

私も起業を考えてますが、山本さんもシンガポールでの起業を考えている
とのことで、お互い頑張りましょう!(陰ながら応援しております)

>>wonaさん
「ペアテスト」というのも、ちゃんとありますよ。
ただ、あまり知られていないのが現状だったりします。
また、本来の「ペアテスト」の意味とは違いますが、Aさんがやった結果の妥当性をBさんがチェックするという風にしてやることもあります。
結果の正確性が重要なときに良く使っています。
(ダブルチェックとかクロスレビューって方が正しいですね)
本筋からそれちゃいましたが、参考までに。。。。

wona

山本さん>
ありがとうございました。
やはりここから先は体験しないとわからない世界ですね。
今後、近いうちに一度挑戦してみます。

とものぶさん>
ありがとうございます。「ペアテスト」という言葉もあるんですね。

> Aさんがやった結果の妥当性をBさんがチェックするという風にしてやることもあります。

今のうちのプロジェクトの検証工程の進め方がこのような形です。
知らない間に「ペアテスト」になっていたんですね。

「ペアテスト」の本来の意味では、ペアプログラミングと同じく"Aさんがテストしている内容をBさんが見てる"で、"結果があっていればその場でOK。間違いや不明瞭な箇所があればその場で議論する"だと思います。
その方が、検証する時間が短くなるはずですから。。。。
なので、"Aさんがやった結果の妥当性をBさんがチェックする"は、ダブルチェックやクロスレビュー(お互いにテスト項目を交換して検証)と言う方が正しい表現だとは思います。
あまり拘ることでもないので、簡易版ペアテストということで。。。

コメントを投稿する