結構な時間をかけて、最近のコンピューターサイエンスの論文を読み漁っている。
自分のチームのプロダクトを改善してくれそうな、アルゴリズム的な物を何でも探しているのだ。
これも Indeed のミッションである Help People Get Jobs のため。成果はまちまちで、 Indeed では活用できそうにない美しい数式しか見つからないこともしょっちゅうある。
でも、コンピューターサイエンスの文献を読み込むことで、得られるものは沢山ある。
もっと多くのソフトウェア開発者が、文献を活用して腕を磨いてもいいんじゃないだろうか。
コンピューターサイエンスの論文を読む理由とは
「何で？」－ そもそも、こう思うんじゃないだろうか。
現役で仕事をしている開発者は、やはり論文なんか読まないだろう。
事実、僕が文献サーチを勧めると、何人もの優秀な開発者にぽかんとした顔つきで見られた。
「え？ StackOverflowを見ろってことかい？」という具合に。
理由を簡潔に答えるなら、それは問題解決で優位に立つためだ。
（場合によっては競合会社や、同僚から抜きんでるため、でもあるだろう。）
一部の研究者は、君の抱える課題がより深く一般化された問題について研究している。彼らは問題解決に対して（場合によっては研究費用確保という意味でも）ハングリーで、ソリューションをタダでくれる。
また、大学の終身雇用枠候補から追い出されないように、彼らはものすごいペースで論文を発表している。
研究者は、きちんとした実装可能なアプローチを考えだし、それを気前よく無料でくれるのだ。
そして 一番クレイジーなのは、この事実を、ほとんどの人が知らないし、気に掛けてもいないってこと。
でも、賢い開発者なら、このクレイジーな状況をしっかりと活用して成果をあげられるんじゃないだろうか。
肝心なのは、文献から自分に役立つものを見つけて、研究者が言わんとしていることを読み解くことだ。
役立つ論文の見つけ方
何千ものコンピューターサイエンスの論文が、毎年発表される。
その中から、読むに値する論文を探すには一体どうすればいいか？
今世紀の多くの問題と同じく、ここでも Google が答えを持っている。
それは、 Google Scholar だ。
僕の知る限りでは、 Google Scholar は現存する研究論文をほとんど全て提供している。しかも無料で。アラン・チューリングの時代からのコンピューターサイエンスの論文を、ほぼ全て読むことができるのだ。
Google Scholar は、これまでどんな会社が無償で提供したサービスの中でも、最も素晴らしいものの一つだ。
一部のリンクには有料の論文も含まれているけれど、たいていの場合は、そこにも無料の論文への追加リンクがある。
僕はこれまで何百もの論文を読んできたが、一度としてお金を払ったことはない。
Google はこれをマネタイズしようともしていないのだ。
scholar.google.com というサイトを聞いたことがある人は、一般市民では殆ど誰もいないだろう。さらに驚くことに、 Google 関係者の話によると、 グーグラー（Google 社員）ですら、この存在を知る人はあまり多くないそうだ。
Google Scholar のおかげで、「興味深い論文を探す」という課題は、これでクリアできた。
論文の見分け方
次の課題は、「見つけてきた面白そうな文献を振り分け、優先順位をつける」ということ。
Google Scholar の探索アルゴリズムは強力だけれど、万能というわけではない。
自分の持つ検索スキルを駆使しても、読み切れないほどの、そして理解しきれないほどの論文が引っかかってくるだろう。
手に取った論文が、君の課題に一番役に立つものだという可能性は低い。
最も関連性の高いものを、簡単に見つけるコツはこうだ。
まず、論文の発表年月日を見つけ出す。
簡単にわかるメタデータの一部に見えるけれど、実は、論文自体に日付は滅多に書かれていない。そうする代わりに、 Google Scholar の中でヒントを探そう。
参考文献リストの中で、最新の日付を持つ論文の出版年月日から２年後くらいが論文の発表時期だと推測するのも良いだろう。これは雑なようでいて、かなり効果的な方法なのだ。発表から １５ 年以上経っているコンピューターサイエンスの論文は、歴史的興味以上の価値が殆どない。
その上で、論文の初めのパラグラフを読む。
ここで、研究者は取り組んだ問題と、その重要性を述べている。
自分の抱える問題と似ていれば、ラッキー！
自分の問題に似ていない場合、論文の結果そのものが君の興味をくすぐる、などがなければ、読むのを止めて、次の論文にうつろう。
もし、関連性が期待できそうな内容なら、 ２ パラグラフ目まで読み進めよう。
２ パラグラフ目では、どんな調査をしたか、制約、そして結果の概要を教えてくれる。
自分の環境で彼らが行った事を再現できて、制約を受け入れられて、結果が良ければ、ビンゴ！
どうやら読む価値ありの論文のようだ。
論文の読み方
研究論文を読む上で一番の秘訣とは何か。
それは「どこを読んで、どこを読まないようにするかを理解しておく」 ことだ。
学術論文は、 ソネット （１４行詩） の厳密な構造よりも、やや柔軟くらいな構造に従って書かれている。一見すると内容理解に役立ちそうな箇所が、かえって混乱させるだけだったりする。反対に、一見すると要領の得ない、不明瞭な箇所が、論文の深い意味をくみ取る鍵を持っていたりする。
さて、僕の論文へのアプローチはこんな感じである。
要約を読まない。
要約は、同じ分野の研究者たちに向けて書かれた論文の要旨だ。
過去 １０ 年くらい同じような問題にずっと取り組んできた、いわば同業者たちに向けて書かれている。君は、まだそのレベルには達していないだろう。
要約を読んでも混乱するだけだし、かえって意気消沈してしまうかもしれない。
要約はトピックの理解を助けてはくれない。
キーワードも読まない。
論文にキーワードを盛り込むのは、依然として残っている悪しき慣習だ。キーワードは誤解を招くことが多いし、新しい情報はまず含まない。飛ばしてしまおう。紙面の無駄なのだ。
論文の本文はしっかり読む。
中学生の時に、先生から叩きこまれた研究テクニックを覚えているだろうか？ それをフル活用しよう。
君がやろうとしていることは、研究者が行ったこと、その手段をリバースエンジニアリングすることだ。これは、工夫を要する作業かもしれない。
まず論文には、研究の裏側で共有された沢山の仮定や、詳細や、小さなつまずき等が省略されている。一字一句読み込もう。
また、知らない言い回しや単語は調べよう。 Wikipedia が、だいたいの場合役に立つはずだ。
そして疑問を書きだそう。研究者が行った事だけでなく、行わなかった事と、その理由も考えてみよう。
コードを読まない。
これは、直観に反するように聞こえるかもしれない。
ソフトウェアの開発者にとっての一番のコミュニケーション手段は、コードだからだ。
理想をいえば、ドキュメンテーション、バージョン履歴、相互参照、テストケース、レビュー・コメントなどもあると尚良い。
研究者は、そうは思っていない。大雑把に言うと、研究論文の中のコードは無価値だ。上質なコードを書くのに必要なスキルは、興味深い学術論文を書くのに必要なスキルと直交するか、はっきりと対立している。
研究の中で使用されたコードの殆どが、レビューを受けておらず、バージョン管理されておらず、テストケースを持たず、そしてデバッグも 「ほぼクラッシュしなかったね。今日のところは。」 というレベルでしかされていない。
そんな事実も、研究者にしてみれば取るに足らないことなのだ。それですら、まだ良いほうだ。
ひどいコードは、単純に無効だったり、論文が発表された時には、もう削除されていたりする。（これは本当にひどい。コンピューターサイエンスの分野ですら、この有様なのだ。）
等式は読む。
研究者は、数学のことは熟知している。
彼らの書く等式は、開発者が、優れたソフトウェアに見出す美徳を全て兼ね備えている。
つまり、精度、正確さ、簡潔さを持ち、示唆に富んでいるのだ。
さらには、その等式にすら欠点を必死に探そうと、賢い人々の集まりが、苦心して等式をレビューしている。
反対に、論文内のコードは、ちょっと暇な大学院生が書いており、誰も読まない類のものだ。
結論部分は読まない。
ここに新しい情報は特にない。
論文を活用して、さらなる探索を
研究論文は他の論文を参照することで、コンテクスチュアル・データの恩恵を与えてくれる。 Google Scholar は、論文を探すことに秀でている。それでもやはり、一番有益なのは、研究者が参照した論文を実際に追いかけることだろう。
関連研究内の引用を追う。
「関連研究」 の節で、執筆者は自身の研究に重要な他の研究に対し、示唆に富んだ説明を書く。これは、彼らの研究を紐解く際におもしろい対比となる。ある意味、この箇所は、最も重要な他の研究との関連性を記録しているからだ。
参考文献内の引用を追う。
HTML のおかげでハイパーテキストが広まるずっと前から、研究論文は、相互参照という大きな森を抱えていた。つまり、引用のことである。
最も優れた研究でも、その価値の半分は本文にあり、もう半分はリンクにある。
論文の中の引用は （まだ） クリックして飛べるものではないけれど、 Google Scholar を使えば引用を追う事はそう難しくないはずだ。
古い論文が頻繁に引用されているなら、それはきっと、その分野では重要なもので、文脈に有益である可能性が高い。
新しい論文が頻繁に引用されているなら、その問題への取り組みの軌跡を洞察しているのではないだろうか。
また、問題とのつながりが一見すると不明瞭で不思議な引用論文は、仮説を立てる時など一旦距離を置いて考えることに役立つはずだ。
これが全部できたら…
あとはコードを書くだけ。さあ、やろう！
デイブ・グリフィスは Indeed のソフトウェアエンジニアで、ソフトウェアシステムの開発に 20 年以上携わっています。