ペアプログラミング再考 ２

続きを書いてみます。

今日は、ペアプログラミングを行えるようなチームを作るにはどうしたらよいのか、ということです。

もともと、僕がペアプログラミングを始めるきっかけになったのは、ICPCです。ICPCには、大学１年のころから、大学院の１年まで、５年間出場しました。最初の年は、大学一年のとき。ICPCは、３人でチームを組んで参加します。１年生のころは、特にペアプログラミングの存在すら知らなくて、３人でばらばらに解法を考えて、ばらばらに解いていました。当時は、そんなに国内予選の問題は難しくなくて、予選通過もそんな難しいハードルではなかったです。だから、三人でばらばらに解いても、最初の年は予選は通過することができました。ただ、当時は実力不足で、アジア大会を通過することはできませんでした。３人で３題を解くのがやっとで、非常に悔しい思いをしたのを覚えています。

次の年は、１人メンバーは入れ替わったのですが、また参加しました。でも、２年生のときも、３年生の時も、突然通過のハードルが高くなって、国内予選すら通過できなかった。練習は、そこそこはしていました。でも、３人は学科が違っていたので、なかなか練習時間を割くことができない。予選前に４回ぐらい練習する程度でした。いま考えると、その程度の練習量で通過できるほうがおかしかったような気がします。

で、４年生の時は、ちょっと気合を入れて練習。でも、２週間に一回ぐらいだったかな。僕は、学科の方がいそがしくて、ほかの２人も情報系とはまったくことなる学科だったので、なかなか時間が取れない。アルゴリズムなどは勉強したり、ある程度ライブラリも整備していましたが、やはり練習時間の少なさはどうにもならない。

で、迎えた国内予選。６題出題されて、４題目までは簡単で、順調にとけた。で、５題目は、実装系の問題だったので、実装系が得意な僕がとくことに。ただ、最後の部分で、どうしてもうまいアルゴリズムが思いつかない。さすがに５問目は、一筋縄ではいきません。で、ＧＵＳさんと相談しながら解いていたのですが、僕のすごい苦手な部分だったので、それまでずっと僕が解いている様子をみていたＧＵＳさんが、僕の代わりにコードを書く。僕は、それを見ながら、きになる点があれば指摘したり一緒に考えたりでコーディング。そのときがはじめてのペアプログラミングの経験でした。結果、５問目を解くことができて、国内予選は２位で通過することができました。その後のアジア予選では、あまりふるわない成績でしたが、このときに僕は初めてペアプログラミングのすごさを実感しました。

次の年は、１週間に１回は練習会をするようにして、特にペアでのプログラムを意識した練習スタイルに切り替えました。どうしても練習時間を大幅に増やすことはできない。で、３人の得意分野も違う。逆に言うと、うちのチームは、３人の得意分野が大きく違っていて、それぞれ強みをもっている分野がありました。僕は実装系と、バグとり。ちゅんさんはなんといってもグラフ。ＧＵＳさんは幾何とダイナミックプログラミングの神。ICPCは、国内予選の難しい問題や、アジア大会レベルを超えてくると、複合的な知識が要求される問題が数多く出題されます。入力データも、かなりきわどいものも入力され、細かいバグに悩まされることもしばしば。

だから、１つの分野だけに強くても、問題を解くことができない。僕らは、ペアプログラミングという手法を通じて、お互いのプログラミングの様子を深く観察して、相手の能力を限られた時間で最大限吸収することに注力しました。練習会が終わった後も、問題に関して３時間ぐらい議論して、どういうところが解く際にポイントだったのか、そして、解法の肝になっている部分はどこだったのか。

また、練習量が他のチームに比べて圧倒的に少ないというのもあり、スタミナ不足もチームとしての問題でした。前回のエントリで書いたように、複雑なプログラムを組むことは、かなり精神を消耗するプロセスです。５時間で８問、９問とかなければいけない状況では、かなり精神的な疲労がきます。僕らは、その問題を解決するべく、うまくペアをいれかえて、で、実装もローテーションしながら進めていくことによってそれを解決しました。といっても、完全に解決できたわけではなく、時にはうまくいかないことも多かったです。ただ、別々にとくよりかは、圧倒的に最後までスタミナを保ちつつ戦うことができました。その理由を考えてみると、実装役→観察役→思考役、と、役割を切り替えることによって、気分を変えることができます。ただ、ひといきついてしまうと、頭が休止モードに入っています。あくまで、気分を変えつつ、頭の活性はとめない、それがよかったのだと思います。

で、大学１年のときは、国内予選では、１位をとることができました。最後の問題は、２人だけでなく、３人で解いていました。最後に１問だけのこってしまうと、というか最後は１問しか残らないですけど、どうしても周りの様子が気になってしまいます。他のチームに抜かれたらどうしよう、とか、他のチームがもう解かなければ優勝だ、とか余計なことを考えてしまう。かなり、集中力としても限界にきています。そういう時に、自分に役割があって、３人で問題を解く、という感覚があると、最後までだれずに問題を解くことができます。たんに、解法を一緒に考えるというだけでなく、問題を解くというプロセスを共有することによって、いつでもバトンタッチできるし、頭やすまることなく進めることができます。ペアプログラミングというかなり深いところを共有する創造プロセスだからこそのことだと思います。

マニラ大会では、ペアプログラミングはかなりうまく行きました。結果的には、１位のチームに負けてしまったのですが（そのチームとは仲良くなりましたし、今でもたまにチャットとかします。）。世界大会に行くチャンスは最後という、ものすごいプレッシャーの中、全問解くことができたのは、かなり深いレベルで３人が協力しあっていたからだ、と思います。でも、２位だったのはやっぱり悔しくて、大学に入ってからあんなに泣いたのは、初めてぐらいの勢いでありました。

なんだかICPCの昔話みたいな感じになってしまいましたが、僕がここで強調したいのは、最初からペアプログラミングがうまくできるチームってのは、余程のことがないかぎりないということと、だから、まず信頼できるチームをつくって、そこでペアプログラミングを用いてチームを育てていけばよい、ということです。

信頼できるチームの存在は必須です。ペアプログラミングは、かなりお互いが深くかかわりあうプロセスです。だって、自分の書いていたコードを途中から相手に書いてもらうこともあれば、相手のコードのバグを隅からすみまでその場でみつけなければいけないこともあるわけですから。単に、プログラミング手法として考えても、うまくいかないのではないか。そこそこはうまくいくと思いますけど、もともと相当複雑に頭を働かせるプロセスなのだから、頭の半分を相手にわたしちゃうぐらい、徹底的にコミュニケーションはとらないといけない。技術的なコミュニケーションもそうですが、お互いのポリシーや考え方・興味とか、そういう細かい部分も実は影響してきます。性格の把握、とでもいいましょうか。

信頼できるチームは、すぐにできる、というわけではないです。だから、ペアプログラミングは即戦力にはほとんどのケースではならないと思っています。信頼できるチームがすでにあるときだけ、即戦力になります。信頼できるチームを育てていくには、時間がかかります。信頼できるチームを作るのに必要なことは、ひとつに、お互いが尊敬できる存在であること。もう一つには、同じ目的を共有していること。目的は、何年もその目的にささげられるぐらい、強く、確固たる目的でなければならないということ。逆に、これさえそろえば、今の時点での実力はあんまり関係ないように思えます。お互いが尊敬できる、ということは、相手に対して、自分よりも優れている点を見いだせていることに他ならないと考えています。その時点で、チームとして各個人が独特の強みを持っているということは明らかです。

どうやってそのようなメンバーを見つければいいのでしょうか？僕は、自分の興味を多いにさらけだせばよいのではないかと思います。自分の持っているプログラミングに対する情熱、というのがあれば、自然と相手は見つかる気がします。情熱をかくしてしまったり、カッコつけたりしたらもったいない。たとえば、未踏プロジェクトとかで、自分のやりたいことをアピールしまくると、自然と人はそこに惹かれます。なんでしょうかね、他にもメンバーを見つける方法ってのはいろいろあると思いますけれども、少なくともビジョンを共有しないとはじまらない。だから、自分の理想とするビジョンをアピールしまくって、ビジョンに共感できる人に認めてもらうしかない。会社の経営でも同じことは言えると思いますが、ペアプログラミングでもおんなじです。

で、チームができたら、あとは、ペアプログラミングを手法として用い、お互いの強みを相手に伝搬させる。これだけです。勉強会をやったりするより、ずっと効率がよい。脳がくっついたような気分。言葉では伝えられない部分も、コーディングを通じて伝わってくる。ようするに、信頼できるチームができたら、ペアプログラミングを用いてチームを育てていけば、自然とペアプログラミングに最も適したチームができる、と僕は思います。

コンテストだけじゃなくて、会社という組織でも、当然有効だと思っています。会社だって、ひとつのプロジェクトは、小さいチームを構成して進めていきます（すくなくとも、僕はそういう手法が一番だと思っています）。そのときに、同じようにチームを育てていけば、自然と生産性の高いチームができるのではないかと。PFIでは、たとえば、何かプロジェクトをやるときは、まったく違うバックグラウンドをもったメンバーが３人ぐらいでチームを組みます。プロジェクトが終わるころには、いつのまにか、アルゴリズムだけでなくサーバーもばりばり書けるようになっていることもよくあります。その過程を通じて、自分自身の強みに対する意識もますます明確になっていきます。

PFIを設立したのは、僕以外の創業メンバー５人と出会って、ICPCのチームと同じようなオーラーを感じたのも一つの要因になっていると、今では思います。僕は、むずかしいアルゴリズムはなかなかかけない。プログラミング言語の細部までに思いを至らせることができない。でも、僕はコンピュータに対してはものすごいよくばりだから、全部しりたい。全部しりたいし、自分のしっていることも全部つたえたい。そういう思いがつよかったのだと思います。

もし、信頼できるチームがすでにあるなら、ぜひ、一度一緒にコードを組んでみてください。遠慮してしまったら損です。１かける１は１ですが、そんなルールを破壊して１００にするぞ、ぐらいのイメージで取り組んでみたら、絶対に損はしないと思います。

もし、チームが見つからないけれども、プログラミングを通じて、コンピュータを通じて世界を変えたい！と思ったら、PFIに遊びに来て下さい。僕らは、いろいろなバックグラウンドをもったメンバーが集まっているので、コンピュータサイエンスのそこそこの範囲はカバーしていると思います。でも、あくまでそこそこです。知らない世界のほうがずっと大きい。そういう世界を僕たちは知りたいし、逆に僕たちが知っている世界を伝えたいです。それで、一緒に新しい技術を生み出すことができたら、それはとても楽しいことです。