【翻訳】コンピュータを用いた再現可能な研究のための10個の簡潔なルール

この翻訳について

本稿は、以下の論文の全訳である。

• Sandve, G. K., Nekrutenko, A., Taylor, J., & Hollister, Hovig. E. (2013). Ten Simple Rules for Reproducible Computational Research. PLoS Computational Biology, 9(10), e1003285. https://doi.org/10.1371/journal.pcbi.1003285

学術研究の多くの分野において再現は非常に重要である。すなわち、ある研究者が実施した研究に対し、誰かが同じ手続きを踏むことで同様の結果を得られるかどうかを検証することが、知識の信頼性を担保する基盤となる。

現在、さまざまな分野においてコンピュータによるデータ解析などを含む研究が行われている。こうした研究において、それを再現するには元のデータやプログラムなどを用いて解析する必要がある。しかし、データやプログラムの管理をしっかりとしておかないと、再現は困難になる。

このような状況を踏まえ、コンピュータを用いた研究を再現可能にするためにどのようなことに注意すべきかをまとめたのが、今回翻訳した論文である。この論文は、PLoS Computational Biology 誌に掲載されたもので、計算生物学の分野を念頭に置いているものの、その考えは他のどの分野にも適用可能である。

訳文

再現性は累積的な科学研究の礎である [1]。しかし、新しいツールと技術、膨大なデータ、学際的なアプローチ、そして問われる問題の複雑さが、研究を前に進めたいという科学者のプレッシャーの高まり [2] とあいまって、再現性の取り組みを複雑なものにしている。独立して収集されたデータに基づく研究を完全に再現することがしばしば実現不可能となっている。このことから、最近では科学的主張の価値を評価するために到達可能な最低基準として、再現可能な研究が求められている [3]。したがって、実験科学の論文は次のようなことが求められる。すなわち、結果を記述することに加えて、オリジナルのデータに基づく解析の繰り返しや拡張を可能にするような十分に明確なプロトコルを提供することが求められる [4]。

近年の研究を通じて、再現と再現可能性の重要さが例証されている。具体的には、科学論文の多くが再現に不可欠な実験の詳細を記載していないことを示す研究 [5]、発表された実験結果の再現が困難であることを示す研究 [6]、撤回される論文の増加 [7]、そして多くの臨床試験が失敗していること [8], [9] などが挙げられる。これらを受けて、個々の研究者・研究機関・資金提供機関・学術誌が透明性と再現可能性を高める慣行をどのように確立できるかについての議論が進んでいる。このような側面を促進するため、科学界にコンピュータを用いた科学のための「再現可能性の文化」を醸成し、公刊された主張に対してそれを求めることが必要だとの見解が示されている [3]。

ここで強調したいのは、再現可能性が科学分野における倫理的責務というだけでなく、再現可能性の欠如が個々の研究者にとっても負担となりうるという点である。例えば、以前に開発した方法論を新しいデータに効果的に適用したり、新しいプロジェクトのためにコードや結果を再利用したりするには、再現可能性に関する優れた実践が欠かせない。言い換えれば、再現可能性に関する優れた習慣は、長期的に見れば時間の節約につながる可能性があるということだ。

さらに指摘しておきたいのは、再現可能性とは単に再現可能性のある研究を保証する習慣の問題であると同時に、これらの過程を効率的かつ現実的にする技術の問題でもあるということだ。以下に挙げる10個のルールはそれぞれ、再現可能性の特定の側面を捉えたものであり、情報を管理したり手順をたどったりする観点から必要な事項を論じたものである。バイオインフォマティクス解析において必要最小限の取り組み方、すなわちコマンドラインからさまざまなカスタムスクリプトを実行する場合、これら1つ1つのルールを明示的に処理する必要があるだろう。一方、統合フレームワーク（GenePattern [10], Galaxy [11], LONI Pipeline [12], Taverna [13] など）を用いて解析を行う場合、システムがこれらのルールのほとんどに対して完全なサポートまたは部分的なサポートを提供している可能性がある。この場合、研究者に求められるのは、これら既存の選択肢を活用する方法についての知識のみである。

現実的な研究環境においては、公刊することのプレッシャーや締切に直面した場合に、再現可能性の理想と、研究がまだ旬のうちに成果を外に出す必要性との間でトレードオフが生じることがある。試行される解析の大部分が結局成果に結びつかないことを考えると、このトレードオフはより重要になる。しかし、後の祭りとなった時点で、再現可能性を確保する機会を逃したことを後悔することがしばしばある。記憶の中から必要なメモを引き出すにはすでに手遅れであるからだ（あるいは、少なくとも研究進行中に実施するよりもはるかに困難である）。我々は再現性がもたらす利益が、行き止まりだと分かった解析の注釈付き一覧を作るのに貴重な時間を費やしたリスクを十分に補えると確信している。

最低限の要件として、少なくとも自分自身で結果を再現できる能力は備えておくべきである。最低限の要件として、少なくとも自分自身で結果を再現できるべきである。これは健全な研究の最も基本的な要件を満たすものである。そして、これにより、将来その研究に本質的な疑義が呈されたときに、正確な説明で応えられるようになる。これは非常に緩い要件のように聞こえるかもしれない。だが、このレベルの再現可能性でさえ、満たすためには相応の注意を要することが多い。と言うのも、特定の解析に対して、ソフトウェアのバージョン、パラメータ値、前処理ステップなどの組み合わせで可能なものは指数関数的に増えるため、メモを取らなければ、正確な再現が実質的に不可能になる可能性がある。

この基本的水準の再現可能性が確保できた上で、さらに望めることは多い。明らかな拡張の方向としては、批判されている状況で結果を再現できる水準から、過去の作業を実用的かつ日常的に再利用し生産性を向上できる水準へと進むことが挙げられる。もう1つの拡張の方向としては、研究者仲間が実際に結果を再現する可能性を確保することが挙げられる。これにより自身の研究に対する信頼、関心、引用の増加につながる可能性がある [6], [14]。

我々はここに計算機を用いた研究の再現可能性のための10個の簡潔なルールを提示する。これらのルールは、研究成果をより広く共有したい場合――研究者仲間にせよ将来の自分自身にせよ――いつでも活用できるものである。

ルール1：どの結果についても、それがどう生み出されたかを記録する

潜在的に関心を引きうる結果が得られたときは、それがどう生み出されたかを必ず記録すること。これをしてみると、生データから最終結果に至るまでには、多くの場合複数の相互に関連したステップ（単一コマンド、スクリプト、プログラム）が関わっていることに気づくだろう。このような一連のステップを、たとえ自動化されていようと手動であろうと、我々は解析ワークフローと呼ぶ。解析の本質的な部分はそれらのステップのうち1つだけにしばしば表出するものだが、達成された結果に至るには前処理や後処理の全ステップがしばしば不可欠である。関与するすべてのステップについて、ステップの実行に影響を与える可能性のあるすべての詳細を確実に記録しなくてはならない。コンピュータプログラムによって実行されるステップの場合、重要な詳細としては、プログラムの名称とバージョン番号、および使用された厳密なパラメータやインプットの値が挙げられる。

一連のステップを正確に手動で記録しても解析を再現することはできるが、このように文書化されたものは最終版で実際に行われた解析方法から容易に乖離してしまうことがある。代わりに、直接実行可能な形式で完全な解析ワークフローを記述しておけば、記述内容が実際の解析作業と一致することを保証でき、さらに自身や他者による自動的な再現を可能にすることも保証できる。このような実行可能な記述 [10] としては、コマンドラインでの単純なシェルスクリプトや makefile [15], [16]、あるいはワークフロー管理システムに保存されたワークフロー [10], [11], [13], [17], [18] の形式が想定される。

最低限、1年ほど後でも自身が結果をおおよそ再現できるよう、プログラム、パラメータ、手動の操作手順について詳細を十分に記録しておくべきである。

ルール2：手動のデータ操作ステップを避ける

可能なかぎり、データ修正には手動の操作ではなく、プログラムの実行を利用すること。このような手動の操作は効率的でない上に、エラーが発生しやすく、再現も困難である。UNIXコマンドラインで作業する場合、ファイルの手動の修正は通常、標準的なUNIXコマンドや小規模のカスタムスクリプトの使用に置き換え可能である。統合フレームワークを使用する場合、普通は、データ操作用のコンポーネントが豊富に用意されている。例えば、フォーマット互換性を確保するためのデータファイルの手動による調整は、実行可能なワークフローに組み込んで再現できるフォーマット変換ツールに置き換えるべきである。また、文書間でのコピーアンドペーストといった他の手動の操作も可能なかぎり避けるべきである。どうしても手動の操作が避けられない場合は、最低限、どのデータファイルをどんな目的で変更または移動したかを記録しておくこと。

ルール3：すべての外部プログラムについて実際に用いたバージョンのものを保管しておく

特定の結果を正確に再現するためには、元々用いたものとまったく同じバージョンのプログラムを用いる必要がある場合がある。また、インプット・アウトプットの形式はバージョン間で変更されうるため、新しいバージョンではインプットを修正しないかぎり実行すらできない場合がある。たとえ使用したプログラムのバージョンを記録していたとしても、現在のバージョン以外のプログラムを入手するのは必ずしも容易ではない。したがって、実際に用いたバージョンのプログラムを保管しておけば、後々の段階でのわずらわしさを大幅に軽減しうる。場合によっては、単一の実行可能ファイルやソースコードファイルを保管しておくだけで足りる。しかし、特定のプログラムについて、他にインストールされているプログラムやパッケージに特定の必要条件があったり、特定のオペレーティングシステムコンポーネントへの依存関係がある場合もある。それゆえに、将来の利用可能性を確保する唯一の現実的解決策は、オペレーティングシステムとプログラムの完全な仮想マシンイメージを保管しておくことかもしれない。最低限、自身が使用する主要なプログラムの正確な名称とバージョン番号を記録しておくべきである。

ルール4：すべてのカスタムスクリプトをバージョン管理する

意図したものであれ予期せぬものであれ、コンピュータプログラムをわずかに変更するだけで重大な影響が生じる可能性がある。継続的に開発されるコード（典型的には小規模のスクリプト）を用いて特定の結果を生成した場合、同じインプットデータとパラメータを与えたとしても、それと厳密に同じ状態のスクリプトしか厳密に同じアウトプットにならないということがある。ルール3と6でも論じるように、状況によっては結果の厳密な再現が不可欠になる可能性がある。コンピュータコードの開発の進展を体系的に記録していない場合、特定の結果をもたらしたコードの状態にさかのぼることが絶望的となりうる。このことは過去の結果に疑義を生じさせうる。なぜなら、過去の結果の一部がバグやその他好ましくない挙動からもたらされたのかを知るすべがなくなる可能性があるからだ。

コードの開発の進展をたどるための標準的な解決策として、Subversion, Git, Mercurial などのバージョン管理システム [15] を用いることが挙げられる。これらのシステムは比較的容易に導入・運用可能で、開発プロセスのあらゆる段階でコードの状態を任意の望む時間的粒度で体系的に保存するために使用できる。

最低限、スクリプトのコピーを時々保存しておくべきである。これにより、開発過程でコードがたどったさまざまな状態について、大まかな記録を保持できる。

ルール5：すべての中間結果を記録し、可能であれば標準化された形式で保存する

原理的には、特定の結果を生み出すために用いられたプロセス全体をたどれるかぎり、中間データはすべて再生成できる。しかし実務的には、すぐにアクセス可能な中間結果を保持しておくことは非常に価値がある可能性がある。中間結果をざっと見ることで、想定との不一致を明らかにできる。そして、最終結果からは見えないバグや誤った解釈を見つけ出せる。第二に、そうすることで、個々のステップにおける代替プログラムやパラメータ選択の影響をより直接的に示せる。第三に、そうすることで、プロセス全体が直ちに実行可能でない場合でも、プロセスの一部だけを再実行することが可能になる。第四に、そうすることで、結果を再現する際に不整合が生じた場合に、その問題が発生しているステップまで正確にたどっていくことが可能になる。第五に、そうすることで、すべての実行可能ファイルを稼働させなくとも、結果の背後にあるプロセス全体を批判的に検証することが可能になる。可能であればこのような中間結果は標準化された形式で保存すること。少なくとも、解析実行時に生成される中間結果ファイル（ただし必要なストレージ容量が過大にならない範囲で）はすべて保存しておこう。

ルール6：ランダム性を含む解析では、基礎となる乱数シードを記録する

解析・予測の多くに、何らかのランダム性の要素が含まれる。そのため、同じプログラムであっても（そしてたとえインプットとパラメータとして与えたものが同じであったとしても）、実行するたびにわずかに異なる結果が返されるのが普通である。しかし同じ初期シードを設定しておけば、解析で使用されるすべての乱数は同一となり、その結果も毎回完全に一致する。結果が完全に再現される場合と、おおよそ同じ結果しか得られない場合との間には大きな違いがある。同一の結果が得られれば、手順が厳密に再現されたことの強い示唆になるが、おおよその一致しか得られない場合には、何か結論を出すことはしばしば困難である。つまり、乱数を含む解析の場合、乱数シードを記録しておくべきである。こうしておけば、将来の実行時に同じシード値を乱数生成器に指定することで、結果を完全に再現することが可能となる。最低限、どの解析のステップがランダム性を含むかを記録しておくこと。これにより、結果を再現する際にある程度の不一致が生じることを予期できるようになる。

ルール7：グラフのもととなる生データを必ず保存する

図が初めて生成されてから公刊論文の一部になるまで、図はしばしば何度も修正される。場合によっては、このような修正は可読性を向上させたり、図同士の見た目の一貫性を確保したりするための単なる見た目の調整にとどまる。図のもととなる生データが体系的に保存され、任意の図に対応する生データが容易に取り出せるようになっていれば、解析全体をやりなおす代わりに、単に作図手順だけを修正すればよい。加えて、こうすることの利点として、図中の細かな値を本当に読み取りたい場合に生の数値が参照できるということもある。グラフの作成において単に基礎となる数値を直接可視化する以上の処理を伴う場合、基礎となるデータと直接の可視化対象となる処理済みの数値の両方を保存することが有用である。このことの例として、ヒストグラムの作成において、階級に分ける前の数値（オリジナルのデータ）と各階級に属するデータの数（可視化される棒の高さ）の両方を保存することが考えられる。Rのようなコマンドベースのシステムで作図を行う場合には、作図に用いたコードもあわせて保存しておくと便利である。そうすれば、グラフをゼロから指定するのではなく、これらのコマンドにわずかな修正を加えるだけで済む。最低限、与えられたグラフの基礎となったデータが何であったか、またそのデータをどのようにして再構築できるかを記録しておくべきである。

ルール8：階層的解析アウトプットを生成し、より細部まで各階層を精査できるようにする

論文になる最終的な結果は、グラフにせよ表にせよ、高度に要約されたデータとして表されることがしばしばある。例えば、曲線に沿った値のそれぞれは、さらにその背後にある分布からの代表値を表している可能性があるといった具合だ。主要な結果を検証し完全に理解するには、その要約の元となる詳細な値を精査することが有効となることが多い。こうするための一般的だが非実用的な方法としては、スクリプトやプログラムのソースコードにさまざまなデバッグのアウトプットを組み込む方法がある。しかし、ストレージ環境が許すなら、主要な結果を生成する際に、特定の要約された値の元となっているデータ全体を容易に見つけられる体系的な命名規則を用いて、元となるデータすべてを恒久的にアウトプットする方が望ましくなる。特にハイパーテキスト形式（すなわち、HTMLファイルのアウトプット）がこの目的のために極めて有用であると我々は考えている。これにより、要約された結果とともに、それぞれの要約された値の元となる完全なデータへ非常に便利な形で（単にクリックするだけで）たどれるリンクを生成することが可能になる。要約された結果を扱う際には、最低限でも少なくとも一度は要約の元となる詳細な値を生成し、精査し、その妥当性を確認することが求められる。

ルール9：テキストによる記述をその元となる結果と関連付ける

典型的な研究プロジェクトの過程では、さまざまな解析が試行され、それらの結果に対する解釈がなされる。解析結果とそれに対応するテキストによる解釈は、概念的には明確に相互関連付けられている。しかし、実際の表現形態としては完全に分離しがちである。結果は主にサーバーや個人用コンピュータ上のデータ領域に保存されるのに対し、解釈は個人のメモや共同研究者への電子メールといったテキスト文書の形で存在することが多い。このようなテキストによる解釈は結果の単なる影ではなく、他の理論や結果と照らしあわせながら結果を解釈したものである場合が多い。そのため、追加的な情報を含んでいると同時に、特定の結果を基盤として成立しているという性質も有している。

過去の解釈を再評価したい場合や、科学論文で主張した内容について研究者仲間に独自の評価を行わせたい場合には、特定のテキストによる記述（解釈・主張・結論）をそれの基盤となっている元の結果そのものと明確に関連付ける必要がある。必要になってからこの関連付けを行うのは難しく、誤りを生みやすい可能性がある。なぜなら、さまざまなバージョンが存在する非常に多種多様の解析の中から、記述の元となって基盤となる結果そのものを特定するのは困難と考えられるためである。

テキストによる記述の背後にある詳細を効率よく取り出せるようにするには、記述が（例えばノートや電子メールにおいて）最初に形成される時点から、その記述を元になる結果に関連付けておくべきだろう。このような関連付けは、例えば詳細な結果への単純なファイルパスや、解析フレームワーク内の結果IDをテキスト自体に埋め込む形で実現できる。さらに密接に統合したければ、再現可能な解析をテキスト文書に直接統合するのを助けるツール（Sweave [19]、GenePattern Word アドイン [4]、Galaxy Pages [20] など）が利用できる。これらの解決方法は、次のルールで説明するように、後で論文を発表するときにも活用できる。

最低限、元となる結果そのもの、あるいは少なくとも関連する結果を後々でもたどれるように、テキストによる解釈に十分な詳細情報を添えておくべきである。

ルール10：スクリプト・実行履歴・結果に対して公開アクセスを与える

最後にこれだけは触れておきたい。すべてのインプットデータ・スクリプト・バージョン情報・パラメータ・中間結果は、一般公開され、かつ容易にアクセス可能な状態にしておくべきである。現在、遺伝子発現データ [21]–[23] などの特定分野において、データ共有をより便利で標準化され、アクセス可能なものにするためのさまざまな解決策が利用可能となっている。ほとんどの学術誌では論文にオンラインの補足資料を添付することを許可している。さらにデータとコードを論文とより統合的に扱うための取り組みを開始している学術誌もある [3], [24]。最低限、主要なデータとソースコードは補足資料として提出し、研究者仲間からの追加データや方法論の詳細に関する要求には応えられる状態にしておくべきである。

研究者仲間による研究の再現可能性を現実的な可能性として示すことは、品質・信頼性・透明性の高さを強力に示すシグナルとなる。これにより、自身の研究に対する査読プロセスの質と速度が向上し、論文が掲載される可能性が高まり、さらに論文発表後も他の研究者によって研究が発展させられ引用される可能性が高まる [25]。

参考文献

1. Crocker J, Cooper ML (2011) Addressing scientific fraud. Science 334: 1182.
2. Jasny BR, Chin G, Chong L, Vignieri S (2011) Data replication & reproducibility. Again, and again, and again…. Introduction. Science 334: 1225.
3. Peng RD (2011) Reproducible research in computational science. Science 334: 1226–1227.
4. Mesirov JP (2010) Computer science. Accessible reproducible research. Science 327: 415–416.
5. Nekrutenko A, Taylor J (2012) Next-generation sequencing data interpretation: enhancing reproducibility and accessibility. Nat Rev Genet 13: 667–672.
6. Ioannidis JP, Allison DB, Ball CA, Coulibaly I, Cui X, et al. (2009) Repeatability of published microarray gene expression analyses. Nat Genet 41: 149–155.
7. Steen RG (2011) Retractions in the scientific literature: is the incidence of research fraud increasing? J Med Ethics 37: 249–253.
8. Prinz F, Schlange T, Asadullah K (2011) Believe it or not: how much can we rely on published data on potential drug targets? Nat Rev Drug Discov 10: 712.
9. Begley CG, Ellis LM (2012) Drug development: raise standards for preclinical cancer research. Nature 483: 531–533.
10. Reich M, Liefeld T, Gould J, Lerner J, Tamayo P, et al. (2006) GenePattern 2.0. Nat Genet 38: 500–501.
11. Giardine B, Riemer C, Hardison RC, Burhans R, Elnitski L, et al. (2005) Galaxy: a platform for interactive large-scale genome analysis. Genome Res 15: 1451–1455.
12. Rex DE, Ma JQ, Toga AW (2003) The LONI Pipeline Processing Environment. Neuroimage 19: 1033–1048.
13. Oinn T, Addis M, Ferris J, Marvin D, Senger M, et al. (2004) Taverna: a tool for the composition and enactment of bioinformatics workflows. Bioinformatics 20: 3045–3054.
14. Piwowar HA, Day RS, Fridsma DB (2007) Sharing detailed research data is associated with increased citation rate. PLoS ONE 2: e308.
15. Heroux MA, Willenbring JM (2009) Barely sufficient software engineering: 10 practices to improve your cse software. In: 2009 ICSE Workshop on Software Engineering for Computational Science and Engineering. pp. 15–21.
16. Schwab M, Karrenbach M, Claerbout J (2000) Making scientific computations reproducible. Comput Sci Eng 2: 61–67.
17. Goble CA, Bhagat J, Aleksejevs S, Cruickshank D, Michaelides D, et al. (2010) myExperiment: a repository and social network for the sharing of bioinformatics workflows. Nucleic Acids Res 38: W677–682.
18. Deelman E, Singh G, Su M-H, Blythe J, Gil Y, et al. (2005) Pegasus: a framework for mapping complex scientific workflows onto distributed systems. Scientific Programming Journal 13: 219–237.
19. Leisch F (2002) Sweave: dynamic generation of statistical reports using literate data analysis. In: Härdle W, Rönz B, editors. Compstat: proceedings in computational statistics. Heidelberg, Germany: Physika Verlag. pp. 575–580.
20. Goecks J, Nekrutenko A, Taylor J (2010) Galaxy: a comprehensive approach for supporting accessible, reproducible, and transparent computational research in the life sciences. Genome Biol 11: R86.
21. Brazma A, Hingamp P, Quackenbush J, Sherlock G, Spellman P, et al. (2001) Minimum information about a microarray experiment (MIAME)-toward standards for microarray data. Nat Genet 29: 365–371.
22. Brazma A, Parkinson H, Sarkans U, Shojatalab M, Vilo J, et al. (2003) ArrayExpress–a public repository for microarray gene expression data at the EBI. Nucleic Acids Res 31: 68–71.
23. Edgar R, Domrachev M, Lash AE (2002) Gene Expression Omnibus: NCBI gene expression and hybridization array data repository. Nucleic Acids Res 30: 207–210.
24. Sneddon TP, Li P, Edmunds SC (2012) GigaDB: announcing the GigaScience database. Gigascience 1: 11.
25. Prlić A, Procter JB (2012) Ten simple rules for the open development of scientific software. PLoS Comput Biol 8: e1002802.