ニュース
xtreme labs

ペアプログラミングはとっても有益だ

次の記事

Adobe、売上は10.5億ドルに増加、利益は減少

cockpit

編集者注記: Farhan Thawarは、トロントのXtreme Labsのエンジニアリング担当VPだ。Xtremeのチームに加わる前のFarhanはI Love Rewards(現Achievers)のチーフソフトウェアアーキテクト、Microsoft CanadaのSearch & MSN Platform担当部長、Trilogy Softwareのテクニカルリード、などを歴任した。この記事は、(前にXtremeにいた)Jon EvansのPair Programming Considered Harmful?への反論だ。Evansの記事は、ペアプログラミングのプラス面とマイナス面を論じている。

あなたは今、未舗装の凸凹道を時速100マイルで運転している。カーブは100°のヘアピン、上り下りの急坂が多い。ふつうの車なら、車体が車軸から外れてしまいそうだ。

しかし幸いにも、あなたは一人ではない。パートナーがいる。二人いれば、ゴールに一番で到着するためにやるべきことを、互いに分担できる。

  • ドライバ: ハンドル、アクセル、ブレーキペダル、クラッチの操作に集中。とくに、急ブレーキの正しいタイミングが重要。
  • ナビゲータ: 地図をよく見て方向をドライバに指示、風速とエンジン警告灯に注意、カーブや急坂にさしかかることをドライバに事前に教える。

ペアプログラミングも、基本はこれだ。ワークステーションに意図的に二人のソフトウェアエンジニアを配置し、協同でソフトウェアを書かせる。車のラリー・レースと同じく、ドライバとナビゲータ、2人の目標は同じだ。この場合は、高品質でメンテナンスしやすい実動コードを書くことだ。

それは、どうやるのか?

  • キーボード2つ、マウス2つ
  • 大きなモニタ2つ
  • エンジニア2人
  • コンピュータ1

車のラリーと同じく、ドライバとナビゲータは役割を頻繁に交替してもよい。2人の役割は:

  • ドライバ: ナビゲータがやってくれることを踏まえて、キーボードをせっせと叩く。途中、ナビゲータと代わってもよい。
  • ナビゲータ: エラーチェック、APIの検索、コードのより良い構造を考える、途中で運転を交替してもよい。

なぜペアでプログラミングするのか?。理由はたくさあるが、ここでは上位の3つを説明しよう:

  • 学習が速い: JavaをJames Goslingから、C#をAnders Hejlsbergから学べるとしたら、どう?。それほどではないにしても、ペアを組むことは新しいプラットホームを学ぶ最良の方法だ(もちろん講義形式の勉強のことではないよ)。Javaの名人と新人をペアにすれば、それはどちらにとっても有益だ。名人がナビゲータのときは、新人ドライバが多くを学べる。質問もできる。新人がナビゲータのときも、本を読んだり独学するよりもずっと速く、Javaを学べる。もちろん、車の運転と違って、運転中(プログラミング中)の名人ドライバに質問をしてもかまわない。なぜ、そこは、そう書くの?。
  • 知識と視野を広げる: 古来エンジニアは、たった一つのことが得意な専門馬鹿が多い。たとえば、JavaScriptのコーディングとバックエンドのデータベースの最適化の両方が上手な人は少ない。ペアプログラミングは、お互いに専門馬鹿の知識と視野を広げる。フロントエンドのエンジニアとバックエンドのエンジニアをペアにすると、数か月後には前者がSQLのプリペアドステートメントを書き、後者はHTML5の最適化を楽にできるようになっているだろう。そんな話、信じないって?。自分がこれまでまったくやったことのないシステムで、実際にペアを組んでごらんよ。
  • 集中: 今日このごろは、集中するのが難しい。GoogleとTwitterとFacebookとメールとYouTubeとTumblrとIMとetc., etc.。つきあうサービスが多すぎて、仕事は一体いつしたらいいんだろう?。でもペアの2人がそこそこ、あるいはすばらしく優秀なら、ググったりツイートする代わりに、2人で会話したほうが結論が早いだろう。あるいは、そのときナビゲータをやってる人が、メールやGoogleを利用する役を、一時的にやってもよい。ドライバは、これらのサービスのことを忘れて、プログラミングに集中できる。

メリットは、まだ3つしか挙げてない。このほか、「オープンワーク環境」という難しそうな理論もある。一人よりもペアのほうが、ワークフローの流れが良い、というのだ。優秀なプログラマとふつのプログラマをペアにすると、教育と定着率の両方で高い効果がある、とする説もある(わが社も目下求人中だが)。

Pivotal LabsとXtreme Labsは、職階の階層(段数)がとても浅いことと、社内に官僚主義がないことで知られている。うち(Xtreme)なんか全員、仕事は朝9時から夕方6時まで。在宅勤務は、一人もいない。プログラマという仕事にまつわる、古い神話を一掃しているのだ。

だから、ぼくなんか、ペアプログラミング大歓迎だね!。

次に、いくつかの誤解を叩いておこう:

  • ペアプログラミングは全時間的にやるべし: 不可能だよ。相方がトイレに行ってるときや、故郷(くに)に帰ってるときは、ぼくも仕事を休むのかい?。それはないよ。ペアプログラミングをできるかぎり勧奨するけど、でも、それが最適ではない状況ではやるべきでない。
  • ペアプログラミングは集団思考に陥る: ちょいまち、集団思考の弊害云々は、もっと多人数の集団について言われていることだよ。たった2人のエンジニアでは、逆に、良質な会話が集団思考への傾斜を防いでくれる。The Mythical Man-Monthも言ってる: “いかなるシステムも3名以上の人間が設計してはならない”。つまり、船頭多くして船山に上(のぼ)るのは、船頭が3人以上のときだね。
  • 優秀なエンジニアをペアにすると、どちらも効率が落ちる: それは、ありえないね。

Guy Steeleが、あの超有名なRichard Stallmanとペアプログラミングしたときのことを、語っている:

“ある朝のことだった”、とSteeleは思い出を語る。“私がキーボードを使い、彼は私の横に座っていた。彼はタイピングは完全に私にさせるつもりだったが、しかしまた、何をタイプするかはすべて彼が指示した。

そのプログラミングセッションは10時間続いた。そのあいだずっと、二人は休憩せず、雑談もしなかった。セッションの終わりごろになると、正しく書式化したそのソースコードは100行弱に達していた。私はキーボードにずっと触れていた。でも二人のアイデアはむしろ、画面の上に流れていくようだった。彼が私に何をタイプするか指示し、私はそれをタイプした”。

そのセッションの長さは、SteeleがAI Lab(MITの)をやっと出たときに分かった。545 Tech Squareの建物の外に出ると、驚いたことに、彼は夜の闇に包まれていた。Steeleもプログラマだから、マラソンのようなプログラミングセッションには慣れていたが、そのときだけは、何かが違っていた。Stallmanとペアで仕事をすると、Steeleはすべての外部的刺激を遮断せざるを得なくなり、彼のメンタルなエネルギーのすべてを目の前のコードに注ぎ込んだ。Steeleによれば、Stallmanとのマインドメルド(mind-meld)は、楽しいと同時に怖かった。“あとになって私はこう思った: すばらしい体験だった、ものすごく濃密な時間だった、そしてそれは、私の人生において二度とやりたくないことだ”。

ペアプログラミングは、人と状況を選ぶ、と言えるだろう。

ペアプログラミングには、あまり話題にもならない腹違いの兄弟がいる。それは、横並びプログラミング(side-by-side programming)だ。それには、各人の勤務時間のシフトをうまくやれば、ペアプログラミングの利点の一部(すべてではない)がある。しかも各自が各自のマシンを使うから、エゴの衝突も少ない。ナビゲータの目を必要としないルーチン的な仕事(モバイルアプリの汎用デザインの利用など)では、うちでもそれをよくやる。二人がそれぞれのポータブルなラップトップを持ち寄って仕事を開始するが、互いに相手の画面を見ることはできる。

だから、本格的なペアプログラミングは、すごい集中力とその持続が必要で、有能なエンジニアが高品質なコードを書く必要があるときや、あるいはお互いに相手から学びながら仕事を進めたいときに、やるべきだ。

それ以外では、一日中、蛸壺プログラミングをやるしかない。

画像クレジット: Charles Rincheval, Flickr

[原文へ]
[jpTechCrunch最新記事サムネイル集]
[米TechCrunch最新記事サムネイル集]
(翻訳:iwatani(a.k.a. hiwa))