再現可能性を簡単に

完全に自動化され，そのソースコードが作業の決定的な記録として精査のために手に入るようにする理想的にはこうした方法を再現可能(reproducible)と呼ぶのだろう。

こうした方法が使われていれば，誤りを簡単に見つけて修正できただろうし，どんな科学者でもデータセットとコードをダウンロードすることで，まったく同じ結果を生み出すことができただろう。

コードがその目的を記した記述と一緒になっていれば，もっと良い。

統計ソフトは，このことを可能にするために進歩しつづけてきた。

例えば，Sweaveというツールでは，科学や数学の出版で広く使われている組版システムのLaTeXで書かれた論文の中に，人気のあるＲというプログラミング言語を使って行われた統計の結果を簡単に埋めこむことができる。

結果は普通の科学論文と同じように見えるが、その論文を読んでその手法に興味を持った他の科学者がソースコードをダウンロードすることができる。

そのソースコードにはすべての数値と図がどのように求められたかが書いてある。

しかし，学術誌は複雑な組版・出版システムを使っていて，まだSweaveでの出版を受け入れていない。

だから, Sweaveの使用は限定的だ。

似たようなツールは他のプログラミング言語にも出てきている。

例えば，プログラミング言語のPythonを利用するデータ分析者は, IPython Notebookを使って進捗を記録することができる。

これを使えば，文章による説明，Pythonのコード，そしてPythonのコードから作られた図や画像を一緒に織りこむことができる。

IPython Notebook で作られたノートは，文章をともなうコードによって，データをどう読みこみ，処理し，取捨選択し，分析し，図にしたかという分析過程の物語として読むことができる。

どの段階の誤りでもそれを修正することができ，コードを再度実行すれば新しい結果が得られる。

そして，これで作られたノートは，ウェブページやLaTeX文書に変換することができるので，他の研究者はコードを読むためにIPythonをインストールする必要がない。

何よりもすばらしいことに, IPython Notebook のシステムはＲのような他の言語でも動くように拡張されつつある。

計算生物学や統計学のように，非常に計算機をよく使う分野の学術誌は，分析ソースコードの投稿・公開を推奨するコード共有方針を採用しはじめている。

こうした方針は，まだデータ共有の方針ほど広く受け入れられてはいないが，一般的なものとなりつつある。

再現可能性を保証し，誤りの発見を容易にするためのもっと総合的な戦略としては，生物医学の研究者グループが作成した「計算機を使用した再現可能な研究のための10個の簡単な規則」（Ten Simple Rules for Reproducible Computational Research)に従うことが挙げられるだろう。

これらの規則には，データ操作と形式変更の自動化，分析ソフトとカスタムプログラムに対するすべての変更のソフトウェアバージョンコントロールシステムによる記録，生データすべての保存，一般の分析のためにスクリプト・データを入手可能にすることが含まれている。

どの科学者も論文を読んでいるときに「一体どうやってあの数値を出したのか」と不思議に思い，困惑したことがある。

こうした規則があれば，この質問に答えるのはずっと簡単になる。

こうするのは非常に手間がかかる仕事で，どうやって分析したのかについてすでに知っている科学者にとっては，そうする動機がない。

もっと研究するのではなく，そこから利益を得る他の人が理解しやすいコードを作るために，なぜこれほど多くの時間を割かなくてはならないのだろうか。

実は，多くの利点がある。

自動化されたデータ分析は，新しいデータセットでソフトを試すのが簡単だし，個々の部分が正しく機能しているかを試すのも簡単だ。

バージョンコントロールシステムを使えば，すべての変更を記録できるので，行きづまって「前の火曜日には動いたコードが何で今日は動かないんだ？」と不思議に思うようなことも一切なくなる。

そして，計算とコードを完全に記録することによって，いつでも後から同じことを繰り返すことができる。

私は，前に公刊する論文での図の形式を改めなくてはならなかったときに，とても当惑したことがある。

私が分かったのは，その図を作るためのデータが何だったか思い出せないということだけだった。

自分自身のぐちゃぐちゃな分析のせいで，私は図を作り直そうとするために一日中狼狽した。

しかし，分析を完全に自動化した場合でも科学者はコードを共有したがらない。

これは無理からぬことだ。

もし競争相手の科学者がそれを使ってこちらを出し抜いて，先に発見をしたらどうなるというのか。

もしコード公開が相手に義務づけられていなければ，相手はこちらのコードを使ったことを公開する必要がなくなり，ほとんどこちらの仕事に基づいた発見から学術的な栄誉を得ることができる。

もしコードがプロプライェタリなソフトウェアや商業的ソフトウェアに基づくもので，公開することができなかったらどうなるだろうか。

そして，コードの中には，あまりにも品質が悲惨なため，科学者が共有を恥ずかしがるようなものがある。

マット・マイトが草案を書いたコミュニティ研究学術プログラミングライセンス(Community Research and Academic Programming License: CRAPL）という学術ソフトウェアの使用に関する著作権契約には，「定義」の節として以下のものが載っている。

�@「プログラム」とは，「あなた」に提供されるソースコード・シェルスクリプト・実行可能ファイル・オブジェクト・ライブラリ・ビルドファイルを寄せ集めたもの，あるいは「あなた」による修正がなされたこれらのファイルを指す。〔「プログラム」におけるデザインの見た目はいかなるものも純粋な偶然であり，思慮深いソフトウェア構築の証拠と間違えられるべきではない。〕

�A「あなた」とは，「プログラム」を使用するのに十分なほど勇敢で愚かな個人または複数の人のことを指す。

�B「文書」とは，「プログラム」を指す。

�C「作者」とは，投稿の締切前のわずかな間だけ「プログラム」を動かしたカフェインでおかしくなった大学院生のことを多分指す。

CRAPLは使用者が「『プログラム』中に発見されるその場しのぎの手法，急いで作られた整合性のないもの，証拠なしに信じこむことに関して「作者」が恥ずかしい思いをしたり，困惑したり，嘲られたりしないようにすることに同意する」とも規定している。

CRAPLは法的に非常に厳格な使用許諾文書ではないかもしれないが，学術関連のコードの作者が直面する問題を訴えかけるものではある。

つまり，ソフトウェアを一般の使用のために書くことは，個人的な使用のためにコードを書くより多くの労力を要する。

その労力の中には，例えば，説明する文書を作ったり，ソフトウェアのテストを実施したり，幾晩ものその場しのぎの手法が貯まってしまったのをきれいにしたりすることが含まれる。

こうした余計な仕事は，プログラムを書く人にとってほとんど利益がない。

重要なソフトを書くのに何か月かけたとしても，学術的な栄誉は得られないのだ。

科学者はコードを点検してバグを発見する機会をうまく使うだろうか。

コードの誤字を確かめても，そこから学術的栄誉は得られないのだ。