PFIセミナーで実験プログラム開発方法論について話しました

先日9月25日の社内セミナーにて「実験プログラム開発方法論」というタイトルで発表を行いました。発表資料はSlideShareで公開しています。当日の発表はUstreamのPFIチャンネルから視聴可能です。また、発表に関連する資料群（デモのレポジトリ・実験メモ・発表に関連して書いた文書）などをgoogle docsで公開しています。

以下では発表内容の簡単なまとめ、発表の補足、実験プログラムについて考える経緯について、随筆的に書いていこうと思います。

発表内容について

実験プログラムは造語で、（科学）実験を行うために開発するソフトウェアを意図しています。発表では、実験プログラムが持つ特徴・典型パターン・開発上の課題とその解決策（案）について話しました。一部まとめの繰り返しになりますが、今回の発表での要旨・主張は以下の通りです。

実験プログラム開発にはソフトウェアの開発の方法論が有効。ただし、実験プログラムの開発に適した形で適用する事が必要。
実験プログラムはそれ単体として存在するのではなく、それらへの入力（データセット・設定ファイル）・出力（実験結果・ログ）・実験手順（実験手順プログラム・ドキュメント）・環境など周辺に存在するモジュールにも依存しており、実験プログラムと同様に管理・開発が必要である。
実験プログラムでは実験結果を出すことの優先度が高い点が通常のソフトウェアの開発と異なり、ソフトウェアの品質にかけるコスト（リファクタリング・バージョン管理・関数の汎用性）との優先度の問題がしばしば発生する。
実験結果の再現性を保ち、結果を後になって有効活用するには、生成方法と生成結果はそれらを独立して管理するだけではなく、それらの対応付けを併せて管理する事が重要。

発表の補足

発表中で「パイプラインは実験プログラム固有」という旨の内容を話したのですが、通常のソフトウェア開発でも前のビルド結果を別のプログラムのビルドに利用するということは当たり前のように行いますので、あまり実験プログラムに固有というのは適切ではなかったです。
この発表を考えた当初はもう少し細かなノウハウについてお話をすることを想定していましたが、いざ資料にまとめてみると、そこに至るまでの前提・導入の話が予想以上にあることがわかり、結果的にそれらについてはほとんど触れられませんでした。それらについては、以下の文書も参考にして下さい（前述の資料置き場にもリンクはあります）。
- git, mafを用いた実験プログラム開発方法論
今回は実験結果を得ることを目的としたプログラムが興味対象で、そのプログラムを第三者が利用する事はあまり想定していませんでした。しかしそ、libsvm/liblinearやmecabなどのツールによって関連する分野の発展が加速された事を考えると、ソフトウェアとして第三者に利用されることを想定した実験プログラムを今回の話から除いてしまったのは話半分と言わざるを得ないと思います。これらについてはまた別の問題として気になる話ではあります。

発表のきっかけ

（書いていたら思ったより長文になってしまいました）

今回このような発表を行ったきっかけは、自分がこういう方法論を欲していたというのがあります。仕事やプライベートで論文を読んだり、アルゴリズムを試しに書く事が多いのですが、アルゴリズムそのものの他に効果的なアルゴリズムを開発する方法も自然と問題意識として持っていました。

周りの紹介でソフトウェア開発という分野を知り、関連する書籍やブログなどを読んでみると、コードを書いている時に感じる疑問にまさに答えてくれるようなものが多数でした。例えば、自分がこの会社に来て最初に読んだ本の一つがClean Codeという品質の高いコードを書くための技術についての本です。我流でコードを書いていた時に比べると効率や品質は大分意識できるようになりました（本当にきちんと書けているかどうかは周りに聞いてみないとわからないですが…）。

一方で、これらの手法のうち幾つかは自分のケースにうまく適用できないと感じる事もありました。もちろん自分が手法を十分マスターしていない事も理由の一つだと思いますが、少し身の程をわきまえずに大胆な仮説を立てて、自分が開発しているプログラムは一般のソフトウェアとは要求が異なる部分もあるのではないかと考えてみることにしました。

改めて思い返してみると、公開された場にある実験プログラム開発のノウハウというのはそれほど多くはないように思います。今回自分が紹介したようなジレンマは実験プログラムを開発していれば自然と発生する問題のはずなので、機械学習を研究するグループがこのようなノウハウを持っていないとは考えづらいです。おそらく各研究グループの中でこのようなノウハウは秘伝のタレとして伝えられたり、仲間同士で情報交換されており、外部になかなか現れていないだけだと思います。

また、実験プログラム開発上の課題を課題に思うのは、研究開発という一部の職種の中で、さらにプログラム開発が研究に伴う一部の方々だけであるはずなので、ニーズがなかったとしても不思議ではありません。実際前述の「git, mafを用いた実験プログラム開発方法」の文書も、もともとはノウハウを社内の他のメンバーに共有しようという動機で書き始めました。

もちろん公開の場でのノウハウの共有が全くないとは言えません。例えば機械学習系のライブラリのレポジトリのログで開発の過程を追ったり、githubのissueやgoogle groupではそのようなノウハウが議論される事がしばしばあります。しかし、埋もれていて見えていないノウハウの蓄積というのはもっとあるはずだと推測しています。

ノウハウを方法論として確立する事はメリットは大きいと考えています（少なくとも実験プログラムを書く人間、というか自分はほしいです）。例えば以下の様な効果を期待しています

異なる研究グループの間で共通言語ができ、ノウハウのスムーズな共有・交換につながる
開発ノウハウを身につけることで、その部分で悩むことが少なくなれば、開発内容そのものにリソースを集中する事ができる
方法論としてまとめる事で何も意識せずに開発をしていたら3年かかるようなノウハウの修得が半年でできれば、残った時間をアルゴリズムの研究に費すことができる

方法論を確立することの重要性を強調したいという意図があり、今回の発表では「実験プログラム”方法論”」などという大それたタイトルを付けました。

今回残念だったのは、あまりサーベイや知り合いへのインタビューができず、世の中でのこのような実験プログラムの開発の現状をあまり把握できなかったということです。おそらく世の中は自分が話した内容よりももっと進んでいて、「こんなの知ってる」と言う感想を持っている方も多くいるのではないかと思います。自分の所ではこうしている、もっとここはこう工夫できるのではないかなどの感想がありましたら是非いただければと思います。今回の発表が実験プログラム開発の議論のきっかけになれば幸いです。