ペアプログラミングならぬ「ペア・リサーチング」のススメ

２人のプログラマが同じ画面を見て、色々と議論しながら同時にプログラミングを進める「ペアプログラミング」もすっかり市民権を得た感がある。

最近、共同で研究をするときに、２人で研究の各フェーズ（議論、実装、検討）を同時に進めていく「ペア・リサ－チング」的な事をやったら思いのほか良かったのでちょっと書いてみます。

プロセスはこんな感じ：

1. タスクを決めて、関連研究を調べて、だいたいこういう手法で行こう、というのをまず決める。

2. ベースラインでも提案手法でも良いけど、「まずこれをやってみよう」というのを、少なくとも数式レベルではフィックスする。ここまでは相談して行う。

3. 同じ手法を２人で別々に実装する。

4. 入力データを共通にして、動かした中間結果もしくは最終結果を付き合わせる。

5. 結果に食い違いが出たら、食い違いの無い中間結果までフォールバック。実装を直す。これをバグが取れるまでやる。

ポイントは、二人でわざわざ同じ実装を作るというところ。普通の共同研究（共同開発）では、モジュール分けして実装を分担すると思うけど、ここではあえてこの車輪の再発明をしよう、というわけ。これには以下のようなメリットがある：

メリット１：バグがすぐ取れる　—　モジュールごとに分担するとお互いの出力を無条件に信頼してしまい、最終的にうまく行かなかった時に、お互いに「俺のほうに間違いは無いはず・・」的な状況になってしまうことも。同じものを実装して結果を比べれば、どっちが、どこで、どのぐらい間違ってるのかが分かりやすい。

メリット２：手法に関する理解が深まる　—　モジュール分割してると、自分の担当外のところは話が分からなくても進んでいってしまうが、これはけっこう危険。論文では分かったつもりでも、いざ実装してみると「あれ？？」となることがあるし、実装してみて初めて分かる直感的な理解、っていうのは計り知れない。このメリットが大きいかも。

メリット３：実験のスループットが上がる　—　論文の締め切りに追われている時なんかは特に、実験のスループットが重要になってくる。この時に、手法の微調整などの「手戻り」が発生すると、モジュール分担している場合、修正の必要なモジュールの担当者がボトルネックになってしまう。同じ実装を別々にやる場合、自分の実装に対しては完全に主導権があるので、独立に修正を進めることが可能。

研究のプロセスはプログラミングよりも時間スパンが長いので、IMとかでゆるーくつながりながらやるのが良いかも。同じ実装してデータを見ながらあーだこーだ言い合うのはけっこう楽しい。新しいアイデアというのはこういう時に生まれてくることも多い。

もちろん、ペアプログラミングと同じで、ペアを組む２人の実力が同じぐらいで無いと、実力の高いほうが一人でやったほうが早い（比較優位の原則が働く）ことになってしまうので、共同研究は良いパートナーを見つけることが何よりも大事である（と、どちらかと言うと足を引っ張る側の自分が言ってみる）

人がたくさん居る研究室や研究所では当たり前のことかもしれないけど、自分にとっては新鮮だったので紹介してみました。