yokaのblog

湖で微生物の研究してます

人生のストーリーを追究したいという非合理なこだわり

学部生時代から一貫して湖で研究を続けているのだけど、事あるごとに「海には興味ないの?」と聞かれてきた。確かに湖よりも海のほうが研究人口が多くて議論も盛んだし、就職での選択肢も多い。地球上の大部分を占める海の研究は単純に湖よりも成果のインパクトが大きいし、自分の技術的にも知識的にも、湖の研究で培ったノウハウを活かして海の研究に鞍替えするハードルは高くない。それでもこれまで、湖一本でやってきた。それは、たまたま環境がそうだったという理由もあるけれど、意図的に海の研究と距離を置いてきた側面も少なからずある。だけど、別に僕は海の研究が嫌いなわけではない。

 むしろ僕は、かつては毎日放課後に海辺で生き物を捕まえて遊ぶ小学生であり、もともと海洋生物の研究者になりたいと思っていた。大学に入って微生物生態学に興味を持ってからも、海の微生物生態学をやりたいと思っていた。ところが残念ながら、所属していた学部には「海」と「微生物生態学」を両方満たす研究室の選択肢が無かった。「琵琶湖」と「微生物生態学」であれば、興味に合いそうな環境があった。そんなきっかけで湖での研究をスタートすることになった。

 そこからは色々と発見に恵まれ、当初捨てきれなかった海の研究への未練も、成果が積みあがるにつれ薄まっていき、今は「湖の研究に出会えてよかった」と心から感じている。確かに湖は、海ほどスケールが大きくなく、研究人口も多くない。だけどその裏返しで、研究規模が手ごろで、競争が激しすぎないというメリットもある。そのおかげで、学生の段階から自分自身の力で最前線を切り拓いていく感覚を味わうことができた。自分で考えたテーマ、自分で考えた研究計画で、自分の好きなように研究をしていたけど、ちゃんと論文として成果を形にできたのは、環境と運に恵まれた側面もあったけど、やはり湖の研究だったからという理由が大きいと思う。海の研究から始めていたら、調べるべき先行研究の数も、調査に必要な資金や手続きの数も桁違いであり、おそらく、大きなプロジェクトの一員として参加させてもらい、与えられたテーマをこなしながら自分の専門性を磨いていくような形でやることになり、湖と同じように自由にやっていては成果がでなかっただろう。早くから自分の裁量で研究領域を開拓でき、自分なりの研究の世界観を持つことができた点については、湖に出会うことができた偶然に感謝するほかない。

 話は変わるけど、僕はこれまでの人生の岐路において、一般的な評価軸に従うことよりも、自分の人生のストーリーを追究することを優先してきた。受験で東大よりも京大を選んだのも、就活で外資コンサルを蹴って国内コンサルを選んだのも、高給会社員を辞めて極貧大学院生に逆戻りしたのも、「みんなが目指す場所に行くこと」よりも「今の自分に至るまでの偶然と考えの積み重ねを反映した選択」を目指した結果だった。今振り返って、これらの選択が合理的で最適解だったとは決して思わない。だけど、もう一度人生があっても同じ選択をしていただろうという点では、後悔のしようがない選択だった。

 同じことが、今の湖の研究に対するこだわりに対しても言えると思う。「海の研究をやればきっと楽しいだろうし、視野も可能性も選択肢もぐっと広まるのだろうな」というのは分かっている。だけど

海はデカいんだからみんなが研究して当たり前であって、今はそれよりも、偶然と運と自分なりの考えを積み重ねてここまで湖一本でやってきた自分のストーリーを追究したい

という非合理なこだわりとプライドが捨てきれない。それで、あえて海の研究には近づきすぎず、湖の研究に自分のリソースを集中させてきた。

 だから、そのこだわりをきちんと活かさなければならない。これはある人に言われて今でも心にとどめているのだけど、

自分の選択やキャリアは活きるものではなく、活かすもの

だ。自ら積極的に可能性に挑戦し、チャンスを拾っていかなければ、「やっぱ一般的な評価軸に従って無難に選択しておくのが正解だったね」という結論になってしまう。湖という研究系の特徴を活かしながら、海には真似できないアプローチで、大発見に繋がる研究を育てていきたい。

 一方で、もっと長期的に考えると、もともと海の研究者になりたかった自分の思いに立ち返るところまでが、自分の人生のストーリーなんじゃないかと思ったりもする。いつか、湖の研究で大成して一通り満足したところで、そのノウハウを引っ提げて海の研究に進出する、というのは面白いストーリーだと思う。なので、その将来を見据えて、今後はもうすこし海の研究にも取り組んでみてもいいのかもしれない。これからも偶然と縁と自分の考えの積み重ねを大事にしながら、この非合理なこだわりを追究していきたい。

申請書書きは嫌いじゃない

科研費シーズンということで来年度の申請書を書いていたのだけど、これまでの申請書類と比較して今回はかなりスムーズに書くことができた。今までは文章を書きながら考えたり文献を探したりということが多かったけど、今回は箇条書き状態でしっかりと煮詰めてロジックを完成させてから、一気に本文を書き上げる手法をとった。こういう方法ができるようになった背景として、経験値が高まってきて、

  • やりたいことがはっきりと分かっている
  • やりたいことに対する問題点(どこまでが分かっていて、どこが突破口になるのか)がはっきりと分かっている
  • 主張の根拠となる文献情報がはっきりと分かっている

状態になったことがあると思う。図表の入れ方に対するスタンスもこれまでの成功体験から自分流のやり方が確立できているので、頭の中にあったイメージを形にする作業時間だけで済んだ(会社員時代はアウトプットイメージを作るところまでが仕事であとは専門のスタッフさんがキレイな図にしてくれる世界だったので、この作業すら自分でやる必要はなかったのだけど)。文章や項目の構造やフォント、行間や罫線や余白の使い方も我流が確立してきた。ちなみに自分は、見た目やページ割をよくするために、行間を細かくいじる。1ポイント行間を変えるだけで余白をかなり捻出/削減できるし、段落前の行間や左右の余白の入れ方も読みやすさに大きく影響する。こういうミニテクを身に着けたことで、文章割りの迷いが少なくなったことも効率化に貢献している。

 日本語表現の使い方や文の切り方も、申請書っぽい言い回しがより自然に出てくるようになった感覚があって、この辺は何度も落とされながらも書き続けてきた経験が活きてきたのかなと感じる。とはいえ、よりシニアな研究者に文章を見てもらうとさらにこなれた表現になって返ってきて感心する経験もよくあるので、まだまだ未熟でこれからも改善余地があるのだろうなと自覚している。

 その他にまだ経験が足りないなと思ったのが、箇条書きを文章化したときの分量の見積もりだ。今回も箇条書きの段階でだいぶ煮詰めたつもりだったけど、文章化すると全然スペースが足りない。なので、そこから箇条書きに戻ってロジックを練り直す手戻りが発生してしまった。この辺はさらに経験を積んで一発で決められるようになりたい。

 申請書は研究の本体ではないのでできるだけ省エネで書き上げたいと思いつつも、なんだかんだで自分の頭を整理する良いきっかけになるし、少しずつ自分の文章テクや作業時間見積もりの正確性が向上していくのも楽しいので、定期的にやっておきたいなと思う。

デスクトップPCを導入した

 これまで2コア4スレッドCPU、8GB RAMの普通のモバイルPCで全ての作業を完結させていたのだけど、今回新たにデスクトップPCを導入して、解析環境を一新した。

 メタゲノム解析をするようになってから、ストレージもCPUもメモリも桁違いに要求されるようになり、今は大掛かりな解析はほぼスパコン上で完結させている。なのでこれまでは「手元のマシンには別にパワーは必要ない」という考えで、機動性を優先してモバイル1台に全てを集約していた。一方で「ローカル環境にももっとパワーが欲しい」と思うことが少なくない頻度であった。例えば

  • エクセルやイラストレーターでヘビーな作業をしたり、 フローサイトメトリーのプロットやゲノムブラウザで大量のデータを描画して流し読みしたいときに、動作がもたつく
  • Webブラウザのタブを大量に開くとすぐメモリが枯渇して動作が重くなる
  • スパコンでやるまでもないちょっとした作業(seqkitでfastaを触ったり、blastnでfasta同士を比較したり、小規模なアンプリコンシーケンス解析をしたり)を手元のWSL上でやるのに、CPUやRAMが物足りないことがある
  • 何より、強制導入させられているMcAfeeが重過ぎて、PCが使い物にならない時間が長すぎる(もはやアンチウイルスソフトではなくウイルスソフトではないかと思っている)

さらに欲を言えば、

  • 高速SSD塩基配列アミノ酸の大規模データベース入れておいて、ちょっとした配列検索くらいだったら手元で素早くできてしまう環境
  • 小規模データ・テストデータのアセンブリマッピングくらいなら手元ですぐに試せる環境

にしたいという考えもあった。

これまでモバイル1台でやってきて、マシンを増やすとデータの同期周りの面倒も発生するので、最初はモバイルを高スペックなもの(モバイルワークステーションと呼ばれるもの)に買い替えて、それ1台で全てを完結させる方向で検討していた。だけど

  • ハイスペックなモバイルはどうしても大型化してしまい、携帯性が損なわれる
  • 所詮モバイルなので電源や冷却やスペースの制約があって、デスクトップPCのスペックには遠く及ばない
  • 高額なモバイルを常に持ち歩くのは破損や盗難のことを考えると怖い

という考えから見送りになった。

 次にデスクトップPCで考え始めたのだけど、今度は困ったのが、モバイルと違ってスペックも金額も青天井なので、「じゃあどこまでの機能を要求するのか?」ということだった。ヘビーな解析はスパコンでやるので、本格的なワークステーションは必要ないし、そもそもそんな予算も無い。だけどせっかくデスクトップにするのだからモバイルワークステーションよりはハイスペックにしたい。一方で色々調べてみて気が付いたのは「デスクトップって思ったよりデカいな」ということだった。デスクスペースはできるだけ節約したいし、大きなケースを足元に置くような場所も無い。「中身は空間だらけなのに、ケースはやたらでかい」というPCはどうしても受け入れがたくて、おのずと「コンパクトとハイスペックの両立」という視点で品定めをするようになった。

 最初に候補に挙がったのはASUSのMini PC ProArt PA90で、タワー型で中身がぎっしりと詰まってそこそこコンパクトで、インテルの1世代前の高スペックCPU(Core i9 9900K)に、静音性の高い水冷のクーラーを搭載しているというのがポイントだった。一方で、自分には必要のないGPUを積んでいる分コストが上がっていること(GPUを使う解析は全てスパコンでやるつもり)と、それを差し引いても、同価格帯で明らかにスペックの高いPCが他に手に入るというコスパの悪さがネックで足踏みをしていた。

 で、さらにいろいろと見て回ったうえで、最終的にたどり着いたのが、LenovoのThinkStation P340 Tinyだった。

f:id:yokazaki:20200924002013j:plain

片手に載るサイズのケースに、10コア20スレッドの最新世代のCPUと、64GB RAM、1TBと512GBの2枚の高速SDDが詰まっている。ポイントは、このサイズのPCに通常使われている省電力タイプ(TDP=35W)のCPUではなく、TDP=65Wの通常のCPU(Core i9 10900)を積んでいるという点。ちなみに、P340にはGPUを搭載するオプションもあるのだけど、GPUを搭載する場合は省電力タイプのCPUしか選べないようになっている。65WのCPUとGPUを同時に冷却するまでのキャパはないということなのだと思う。この「コンパクト化のためにギリギリを攻めている感」も決め手になった。ちなみに、HPやDellからも同様のサイズ・スペックのPCは出ているのだけど、コスパ的にlenovoが圧倒していたことと、昔からLenovo(というかThinkpad)ユーザーということもあって、迷う余地はあまりなかった。これで30万円を切っているのだからすごい。

 導入して1か月くらいが経つけど、全てが高速でとても快適になった。4Kのディスプレイで巨大なエクセルシートを無限スクロールさせても全く引っ掛からないし、リードのマッピングやblast検索を4 threads 4並列で回しながらWebブラウザのタブを大量に開いても何の支障もない。巨大なfastqファイル達をpigzで圧縮するのも、4スレッド時代の5倍以上の速度で終わる。メモリも64GBあれば、単離株のアセンブリとかなら手元で完結するし、シングルスレッドの性能が高いので、同じスレッド数ならXeonを積んだスパコンよりも早く終わる。塩基配列アミノ酸のデータベースも手元の高速SSDに入っているので、ちょっとした配列検索だったらblastのウェブサーバーに繋ぐよりも断然早い。

 心配していた冷却性能だけど、全コア(20 threads)フル稼働している時の挙動を見ていると、最初の数十秒は85Wくらいの消費電力で4.1GHzくらいで動いていて、その後は65W固定で3.6GHzくらいで動いていた。CPUの温度は最初一気に90℃くらいまで行くけど、その後は80℃前後で安定している感じ。使うスレッド数を少なくすれば、4.6GHzくらいで持続的に動くけど、消費電力は65Wで頭打ちになっていて、「CPU自体のスペックにはまだ余力があるけど65Wまでしか使わない」ような制御になっているのだと思う。これらの点で、スペックがさらに制限される35WのCPUにしなくて良かったなと思った。

 小さなファンで全力でCPUを冷却しているので、さすがにフル稼働していると結構うるさくて、ドライヤーを小さくしたような高い音が耳につく。たまにヘビーな解析をするくらいなら全く気にならないけど、長時間フル稼働するような使い方をする場合は静かな居室で使うのは少しためらわれるレベルだと思う。負荷がかかっていないときはもちろん静かで、たくさんウィンドウを開くとすぐにファンがフル稼働していた4threadsモバイルと比べれば、普段使いでの音は全然気にならない。あと、個体差だと思うのだけど、ファンがはずれだったようで、ケースを横置きにして使うと少しカラカラ音がするのが気になっている。そのうちなじんで消えることを期待して、当面は縦置きで使いながら様子を見ている。

 総じて、コンパクトになったことで感じている弱点はフル稼働時のファンの音くらいで、そこさえ気にならなければ、大きなケースのPCを選ぶ必要は一切ないのではと感じた。心配していたモバイルとの同期も、OneDriveが思いのほか優秀で何の問題もなく運用できている。悩んだ甲斐があって良い買い物ができたと思う。

遠くなった琵琶湖

 関西に置いてきた培養サンプルが回収できずにずっと研究が止まっていたのだけど、県外への出張が許されるようになったので、4か月半ぶりの出張に行ってきた。行く途中、4か月半行っていない東京がまだ本当にこの世に存在しているのかをこの目で確かめるのが楽しみだったのだけど、車窓から見える東京では意外に普通に人が歩いているなと感じた。一方、新幹線はガラガラで、まだ元の世界には全然戻っていないのだなと感じた。必要緊急の出張とはいえ、感染者が再び増える中で、絶対にウイルスを持ち込む/持ち帰るわけにはいかないので、直前までどうするか迷ったし、出張中もずっと嫌な緊張感を感じながら過ごさなければならなかった。外出してあちこちに行くことに対するハードルが思った以上に高くなっていて、毎月のように気軽に出張していた去年のような生活は、当分戻ってこないのだろうなというのを改めて実感することになった。帰路につくとき、海外から帰るときのような「もう当分ここには来れないのだろうな」という気持ちになり、関西や琵琶湖がすごく遠いところになってしまったと感じた。

 当分出張しなくても良いように、琵琶湖の水でしか増えてくれないわがままな微生物達のために、琵琶湖水をたっぷり処理して持って帰ってきた。命懸けの出張が報われる結果が出て欲しい。

f:id:yokazaki:20200709120019j:plain

自分が変わらなければならないのか?

 コロナウイルスの自粛期間に入って約3か月が過ぎた。出張はもちろん、出勤すら満足にできない我慢の日々を過ごしている。思い起こせば、2月末に関西出張に行った頃にはもう日本で感染者が確認され始めていて、マスクをしてドアノブや手すりをできるだけ触らないように気を付けてはいた。だけど相変わらず飲み屋も電車も満員で、帰りの新幹線は席がとれなくて仕方なく差額を払ってグリーン車で帰ったほどだった。その頃にはまさかここまでのことになるとは思っていなかったし、それが最後の出張になるとも思っていなかった。

 悪いニュースばかりの中でも、テレワークやテレビ会議といった仕事のオンライン化を歓迎する声は多い。だけど個人的にはそういう風潮は嬉しくない。やる前から分かっていたことだけど、僕は職場と家で、仕事とプライベートをきっちりと区切るスタイルで生きてきたので、家が仕事で汚染されることがかなりのストレスになった。あまりのストレスに体調を崩してしまったので、途中からは家ではあまり根詰めて仕事しすぎないようにセーブしていて、おかげで生産性はものすごく下がっている。

 かたや「テレワーク最高、生産性上がりまくり!」と言っている人達もいるみたいなので、働き方って本当に人それぞれなのだなと思う。自分にはテレワークの何が良いのか、さっぱり分からない。好きなだけお菓子が食べられるとか、昼休みをのんびり家族と過ごせるとかのメリットはあったかもしれないけど、それ以外の圧倒的なデメリットとは比較にならない。個人的には、テレワークが良いと言っている人の多くは、「辛い通勤から解放された」ことや「職場のノイズから解放された」ことが理由になっているように見えるので、通勤や職場に不満が無かった自分は恵まれていたのだなと思いつつ、そういう問題は「テレワークの良さ」とは別に議論して欲しいと思っている。

 オンライン会議やオンラインプレゼン、さらにオンライン飲み会も何度かやってみた。画面共有などを使えば、「やりたいことは大体できるな」とは感じたけど、あくまで「直接会えない場合の代わりの手段」であり、「本来のコミュニケーション手段」としてリアル会話を代替する存在にはなりえないと感じた。今回の出来事をきっかけにオンラインでのミーティングを普及させる動きが加速しているけれど、電話がずっと昔からあるのに毎日新幹線が満員になるほどみんな出張していたことを考えれば、「やっぱり直接会って話さないとダメだよね」という流れに戻っていくのではないかと思っている。

 僕は調査・学会・打ち合わせ等での出張には積極的だったけど、それは国内外の各地に出向いて色々なものを実際に見て、色々な人と実際に会って話すことが、自分にとって大切なことだと考えていたからだ。何より、そうやっていろんなものを見聞きする経験は単純に楽しくて、仕事だけではなく、人生を豊かにしてくれるイベントでもあった。だから、色々なものを積極的にオンライン化していこうとする今の風潮が怖い。仕事の効率だけ考えれば「直接会うなんて古臭い考えはもう止めようよおじさん」となるのかもしれない。だけど自分はまだ、現場に行かないと感じられない、実際に会わないと共有できないものがあると信じている。

 次に学会で海外に行くことができるのはいつになるのだろうか。毎年のように普通に海外出張していた日々は本当に戻ってくるのだろうか。封じ込めに懸命な国と、それを諦めたように見える国がある中で、自由に国を行き来できる日が来ることは当面ないように思う。今後しばらくは、学会(特に国際学会)もオンラインでの開催が中心になるだろう。それは仕方が無いことだと思う。学会が無くなってしまうよりはオンラインでもやったほうが良い。心配なのはそのあとのみんなの反応だ。「やっぱり直接会ってやるのがいいよね」となるのか「オンライン最高!もうずっとこれでいいじゃん」となるのか。後者だとすれば、変わらなければならないのは自分だ。

ポスドク3年目の論文の書き方

学位を取って2年が経ち、今月からポスドク3年目に突入した。学生時代にとった論文化できていなかったデータのうち、3本目となる最後のネタの原稿をようやく書き上げた。調子に乗って広げ散らかした風呂敷達を畳むのに結局2年もかかってしまった。これからは広げる風呂敷を慎重に選ばなければならない。

今回の論文はウェット実験や申請書書きと並行しながらスキマ時間にダラダラ書き進めていたのだけど、その割には大きな手戻りなく、これまでよりはスムーズに書けた気がしている。 Fig作りや文章書き自体に慣れてきたということもあるし、知識や経験が溜まってきて先行研究との関連や分野全体の動向をつかむのに新たに必要となるインプット量が少なくなってきたことも大きい。より経験を積めばより効率的に書けるようになるのだろうけれど、さしあたりポスドク3年目に差し掛かる今の自分の論文の書き方を記録しておきたい。

■基本的な考え方

まずは全体像を可視化することを優先し、細部は後で詰める

論文に限らず、まとまった文章を書くときは、最初から書き進めるのではなく、まずは箇条書きだらけのラフな形で良いので、とにかく頭の中のネタを出し切って、紙面を言いたいことで埋めてみて、自分の主張の全体像を可視化することを優先する。絵を描くときに紙面の端から順番に完成させるのではなくまず下書きして全体のバランスを考えるのと同じイメージだ。そうして初めて、自分の一番強調したいものが何なのか、各主張の粒度や強弱のバランスをどうとるべきかが見えてくる。頭の中で完璧にストーリーを組み立てて、手戻りなしで一筆で完璧な文章を書ける人もいるのだろうけど、自分のような凡人はとにかくまずは形にして、そこから何度も手を加えて完成度を上げていく戦略だ。

良い文章は積み上げではなく削ぎ落しで生まれる

いつも原稿が完成するたびに抱くのが「結局最初に言おうとしていたことの半分くらいしか最後まで残らんかったな」という感想だ。ただそれでも「削った主張は無駄で、最初から無いほうが良かったのか?」と聞かれるとそうは思わない。文章は彫刻のように余計な部分を削りながら完成度を高めていくものであり、冗長な部分があってこそ、重要な部分がどこなのかを浮き彫りにできるし、そこを研ぎ澄まして鋭くする余地が生まれる。なので最初の段階では、的外れかもしれないことや、言えるかどうかわからないけど言えたら面白いことなども含め、思いついたことは忘れる前にどんどん盛り込む。100%の分量を目指していてもどうせ120%くらいになってしまうものなので、最初から「あとで100%に削る前提で150%くらいを目指す」くらいのマインドでやっている。

Figを中心に論文を組み立てる

これは分野や個人の考え方にも依るかもしれないけど、自分の研究は元データが複雑なケースが多いこともあり、とにかく見やすいFigを作って、そのFigに多くを語らせるようにしている。本文のためにFigがあるのではなく、Figのために本文があるという考えだ。なので自分は論文のFigの完成度にはとてもこだわるし、時間もちゃんと使う。ただここでも先の話と同じで、手戻りを避けるためにいきなり図の完成度を高めることはしない。まずは傾向だけ分かる手抜きの図を作っておいて、そのあとで本文の改訂と整合をとりながら完成度を上げていく。

■原稿を完成させるまで

0. 納得いくまでデータを触って結果の全体像をつかんでおく

論文書きに手を付ける前に大事なのが、得られたデータを一通りこねくり回して全体像を理解しておくことだ。見切り発車でFigを作り始めてから重要な切り口に気が付いて手戻りが発生することの無いように、生データをできるだけ見て触って、そこから言えそうなことをしっかり絞り出しておく。とはいうものの、メタゲノム解析のように巨大で複雑なデータが相手だと、切り口は無限にあって完璧に分析しきることは到底不可能だ。なので結局のところ大切なのは「ここまで分析しとけば論文にできそうだし、もし手戻りが起こっても後悔ないな」という納得感が得られるまでデータを触るということなのだと思う。(今回は書かないけど、この「納得感」に至るまでの閾値には結構個人差があり、その人のアウトプットの質や量を左右する重要な要素になっていると思う)

1. Fig, Tableの原型を作る

データの全体像が見えてきたら、本文の前にまずはFigやTableの作成に取り掛かる。結果の傾向を的確かつコンパクトに見せられる方法をイメージしながら、紙に手書きでアウトプットイメージを描いていく。会社員時代だったらこの先は作図と配色のセンスに長けた専門のスタッフにお願いすれば紙に書いたイメージ通りのFigを作ってくれていたのだけど、今はそんな豪華な方法は使えないので、全部自分で描く。まだこの先手戻りの可能性が高いので、この段階では汚くても良いから最低限結果を読み取れるだけの簡単な図を省エネでサクサク作っていく。

2. ストーリーの骨子を日本語の箇条書きで作る

Figの原型が出揃ったら、それを眺めながら日本語の箇条書きで論文での主張を書き出していく。このステップで大切なのはまずとにかく最後まで通しで書ききって全体が見えるようにすることだ。全体のバランスやストーリーの流れは考えず、頭の中で思いつく書けそうなことを忘れないうちにどんどん書き出して可視化する。この段階で、新しいFigや分析が必要になった場合は適宜前のステップに戻ってデータの再分析とFigの追加をする。

3.箇条書きを超ラフな英語原稿にする

箇条書きの内容を参照しながら、英文化していく。前のステップはアイデアの棚卸しが主目的だったので、情報の粒度やストーリーの流れる順序はめちゃくちゃだ。このステップではそこを揃えていくことを意識する。箇条書きから具体的な文章にすることで初めて「こことここは繋がりそうだな」とか「これは言えそうでやっぱり言えないかな」みたいなのが見えてくる。その話の繋がりを頭から離さないように集中しながら書き進めていく。文法や表現の推敲には無駄な集中力を使わない。英語をきれいにするのは後回しでよい。引用文献も、すぐに思いつく主要な論文だけ仮で入れていくにとどめ、とにかくまずは一通り筋の通った英文を書き上げることに集中する。

 ちなみに、このような書き方ができるようになったのは、頭の中の文献情報の蓄積にそれなりに自信が持てるようになってきてからだ。学生時代は、頭の中に先行研究の情報があまり無かったので、関係しそうな文献をしっかりと読み込む作業を済ませてからでないと仮でも文章は書けなかったし、書いたとしても手戻りの嵐に襲われていただろうと思う。

4. 超ラフ英語をまともな英語に仕上げつつ、引用文献を固めていく

ここまでは情報を紙面にどんどんインプットしていく段階だったが、ここからは足しすぎた情報を削っていく段階に入る。前のステップで書いた超ラフ英語の状態で、最終アウトプットの130%くらいの文章量で、このステップで110%くらいにまで減らすイメージだ。一文一文、文法や表現を推敲しながら、言いすぎた事が無いか、冗長なところは無いか、先行文献の読み落としが無いかを確認していく。この段階で、論文全体の長さ(語数)も大体見えてくるので、投稿先の語数制限と比較して、1本の論文に仕上げるために自分がどれくらいの情報を削られなればならないのかも見えてくる。それが見えれば、どのくらい言いたいことまで残せそうかが見えてくるし、メインストーリーに載せきらない部分をSupplementaryに回すという選択も下せるようになる。ここまでくると、文章の構造が大きく変わるような手戻りは少ないと考え、FigやTableの構成を固めて番号を振っていく。Abstractもこの段階で書く。

 このステップでとくに時間がかかるのが引用文献の確認だ。以前書いたように、僕は自分の手持ちの論文を検索性を意識して整理しているので「こんな論文あったはず」という論文にはすぐにたどり着くことができる。一方で大変なのが「こういうこと言っている論文ってあるのかな」「これを否定する論文は出てないよね」という論文の検証だ。Google検索で発見した「5年も前にこんなことを言っている人がいたのか!」という論文をきっかけに芋づる式に未開の関連論文のネットワークが見つかって、その読み込みだけで数日消化、というのも日常茶飯事だ。だけど、こうやって目的を持って論文を読んでいる時こそが、その論文の内容を一番効率よくインプットできる瞬間でもある。よい勉強のきっかけだと考えて、この作業には相当の時間を割り当てることをあらかじめ織り込んでいる。

5. Fig, Tableを清書する

前のステップで固めた文章構成に合わせて、仮で描いていたFigやTableの清書を行う。色遣いや文字のサイズ、スケールの調整や複数パネルのレイアウトなど、主にRとIllustratorを使いながら作業を進める。最初に書いたように、自分は見やすいFigを作ることにとてもこだわっているので、ここでかなり試行錯誤する。Figのデザインに過剰なリソースを割くことを無駄な努力だという人もいるだろうけど、正直半分くらい趣味になっている部分もあって、ここはしっかり時間をかけている。

6. Figと本文の齟齬を埋めていく

Figが固まったことで、改めて本文を読み直しながら、対応する部分の表現を改訂していく。Legendもこのステップで書く。特に情報量が多い複雑なFigに対しては、Fig内、本文、Legendでうまく役割分担しながら最小の分量で理解可能な情報を伝える必要があるので緻密な作業が必要になる。

7. 通しで何周もしながら最終稿に仕上げる

この段階で初めて本文とFig達が完全な状態で出揃う。しばらく他の仕事をして文章を寝かせた後、改めてフレッシュな目で通しで読むことで、収まりや繋がりが悪いところ、冗長なところを炙り出し、修正・削除していく。この段階で丸ごとボツになるパラグラフが発生することもあるし、文章の入れ替えによるFig構成の変化や、引用文献の読み直しで時間がかかることもある。これを何周か繰り返して、110%だった分量を100%に収めこみ、最終稿へと仕上げていく。この作業は、どこまでやっても終わりが無いので、やっぱり最後は「これなら外に出しても大丈夫」という自分の「納得感」が得られるポイントが到達点になるのかなと思う。ちなみに今回書いた原稿では、納得感が得られるまでに4周くらいはこのサイクルを回したと思う。

さらに経験を積めばいくつかのステップを省略してもっと効率的に論文を書けるようになるのだろうけど、自分の今の実力だと、複雑な情報を漏れなくダブりなくコンパクトにまとめつつ手戻りを最小限に抑えるためにはどうしてもこれくらいの手数がかかってしまう。1年に何本もファーストで論文を出している人たちが一体どんな感じで書いているのか知りたい。

Rの作図におけるベストな配色の選び方

論文のFigはほぼRで描いているのだけど、複雑なデータをコンパクトに見せるためにカラフルな図を作ることが多い。そこでいつも悩むのが「いかに効率よく配色するか」ということだ。カスタムの配色セットを作ってみたり、カラーパレットのパッケージをあれこれ試してみたりしたのだけど、自分なりに今落ち着いているのがkhromaとcirclizeという2つのパッケージなので簡単に紹介したい。

khromaはPaul Tol’s Colour Schemesに準じたカラーパレットを出力できるパッケージだ。このカラースキームの特長として、

  • カラーユニバーサル
  • モノクロ印刷した際の視認性も考慮
  • 質データ(Qualitative)、2極データ(Diverging)、連続データ(Sequential)のそれぞれに対応した複数のカラーパレットが準備されている

という点が挙げられる。自分が知る限りでは、最も綿密な考慮の上で選ばれた配色セットであり、色の数や種類に選択肢があるのも嬉しい。詳細は本家のウェブサイトを参照。

一方のcirclizeは、名前の通り環状レイアウトの作図が本来の用途なのだけど、これに入っているcolorRamp2という関数がヒートマップ等の連続データの配色で大活躍する。ちなみに今回は紹介しないけど、circlizeの作者が公開しているパッケージにComplexHeatmapという(その名の通り)複雑なヒートマップを手軽に描ける素晴らしいパッケージもあって、この中でもcolorRamp2の使用が推奨されている。

khromaによるカラーパレットの出力

colourという関数で直接カラーパレットを呼び出すことができる。

require("khroma")
col.pal<-colour("palette名")
col.pal("色数")

ポイントとしては、colourが出力するのは色ではなく、カラーパレットが入った関数であり、色を呼び出すためにはその関数に「色の数」を渡してやる必要があるということだ。palette名にはPaul Tol’s Colour Schemesで示されている名がそのまま使える。具体的には以下の通り。

Qualitative data
bright (7), contrast (3), vibrant (7), muted (9), pale (6), dark (6), light (9).
Diverging data
sunset (11), BuRd (9), PRGn (9).
Sequential data
YlOrBr (9), iridescent (23), discrete rainbow (23), smooth rainbow (34).

ここで、リストの()内は各カラーパレットの色の数を示す。Qualitative (質)データの場合は用意された色数を超える値を設定することはできないけど、Diverging (2極)データとSequential(連続)データにおいては、大きな値を入れると自動的に中間的な色を補ってその数に合わせた色数を返してくれる。具体例としてはこんな感じだ。

col.pal<-colour("bright")
col.pal(7)
#"#4477AA" "#EE6677" "#228833" "#CCBB44" "#66CCEE" "#AA3377" "#BBBBBB"

colour("YlOrBr")(7) #代入を挟まずこれ1行で出力することもできる
#[1] "#FFFFE5" "#FEF0AD" "#FECE65" "#FB9A29" "#E1640E" "#AA3C03" "#662506"

colour("YlOrBr")(20) #上記と同じカラーパレット(YlOrBr)で20色出力
# [1] "#FFFFE5" "#FFFBD3" "#FFF8C2" "#FEF1B0" "#FEE99E" "#FEDF8A" "#FED26E" "#FEC552" "#FCB441" "#FBA231" "#F79124" "#F17F1B" "#EA6E13"
#[14] "#DC5E0B" "#CF4F03" "#BB4402" "#A63A03" "#903104" "#7B2B05" "#662506"

色を確認するにはplot_schemeが使える。

plot_scheme(colour("bright")(7))

f:id:yokazaki:20200325221933j:plain

plot_scheme(colour("YlOrBr")(7))

f:id:yokazaki:20200325222153j:plain

plot_scheme(colour("YlOrBr")(20))

f:id:yokazaki:20200325222225j:plain
その他の例はcolourのヘルプに色々載っている。

circlizeのcolorRamp2を使って配色を数値と対応させる

配色セットが欲しいだけなら上記のcolourで事足りる。このcolorRamp2は二極値や連続値をヒートマップで表現するにあたり「数値と色を対応させる」のに便利な関数だ。特に素晴らしいのが、

  • 整数値でない値も含め、指定した色の中間的な色を連続的に割り当ててくれる
  • どの値にどの色を割り振るか任意に決めることができ、スケーリングが自由自在

という点だ。
例えば、0→3→6と、白→黄→赤と変化する配色を使いたければ

require("circlize")
col.pal1<-colorRamp2(c(0,3,6),c("white","yellow","red"))

とすれば、col.pal1に0から6の連続値を渡したときに対応する色を返してくれる関数が格納される。

col.pal1(c(0,0.5,2.3,4.8))
#[1] "#FFFFFFFF" "#FFFFDFFF" "#FFFF63FF" "#FF8D00FF"

さらに、最大値を黒で表現したければ

col.pal2<-colorRamp2(c(0,2,4,6),c("white","yellow","red","black"))

とでき、黒と白を極端な値のみに割り振りたければ

col.pal3<-colorRamp2(c(0,0.5,5.5,6),c("white","yellow","red","black"))

としてスケールを変えることもできる。
これでも十分なのだけど、これをさらにcolourと組み合わせて、

col.pal4<-colorRamp2(seq(0,6,length.out=23),colour("iridescent")(23))

さらにきめ細かくして、3以上の数字に全て黒を割り当てる(3以下の変化に着目する)のに

col.pal5<-colorRamp2(c(0,seq(0.5,3,length.out=50),3,6),c("white",colour("iridescent")(50),"black","black"))

と書くこともできる。
以上の5つをを比較するとこんな感じ。

win.graph(10,5)
plot(NA,xlim=c(0,6),ylim=c(2.7,0),ann=F,axes=F)
axis(1)
axis(2,at=seq(0.5,2.5,0.5),labels=c("col.pal1","col.pal2","col.pal3","col.pal4","col.pal5"),las=1,lwd=0)
points(seq(0,6,length.out=100),rep(0.5,100),pch=21,cex=5,bg=col.pal1(seq(0,6,length.out=100)))
points(seq(0,6,length.out=100),rep(1,100),pch=21,cex=5,bg=col.pal2(seq(0,6,length.out=100)))
points(seq(0,6,length.out=100),rep(1.5,100),pch=21,cex=5,bg=col.pal3(seq(0,6,length.out=100)))
points(seq(0,6,length.out=100),rep(2,100),pch=21,cex=5,bg=col.pal4(seq(0,6,length.out=100)))
points(seq(0,6,length.out=100),rep(2.5,100),pch=21,cex=5,bg=col.pal5(seq(0,6,length.out=100)))

f:id:yokazaki:20200325235312j:plain
間違いの無い配色に素早くありつけるようになり、情報量満載カラフルfig作りが捗っている。