こんな時間ですがパスタを茹でます

Bunch of Spaghetti Code by Tazro Inutano Ohta

[trattoriainutano]

今年買ってよかったもの2021

まあとんでもねえ一年でしたね。来年もこんな感じなんでしょうかね。

2020年の買ってよかったものブログでこんなことを書いていました。案の定でしたね。来年も特に何かに期待することなく淡々と Do the fucking good things の気持ちでやっていきたいと思います。

目次

衣

ナイキ ファントム GT アカデミー MG マルチグラウンド サッカースパイク (Nike)

パジャマ (Calida)

AirTag (Apple)

食

BCAAパウダー (MyProtein)

耐熱ドリッパー (Karita)

四川料理のスゴい人 自宅でつくる本格中華レシピ (三才ブックス)

だいたい1ステップか2ステップ! なのに本格インドカレー (柴田書店)

自作煮干しラーメン

コーヒー豆 (Lucent Coffee)

住

洗濯乾燥機 (Sharp)

Apple TV 4K (Apple)

羽毛布団 (無印良品)

Ulysses | Writing App (Ulysses)

画像をクリックすると商品のページに飛びます。Amazonアフィリエイトリンクの収入は全て僕のお気に入りのビアパブの売上になります。

衣

出かけていなかったので服を買う頻度が減り、いざ出かけようという時に着るものがなく、同じような服ばかり着ていてテンションが上がらない。服探しの旅に出たい。

ナイキ ファントム GT アカデミー MG マルチグラウンド サッカースパイク (Nike)

在宅勤務となり久しく参加していなかった三島の研究所のサッカー部。岡崎の研究所と対抗戦をやるというので遠征に参加させてもらうことに。あれ、スパイクあったっけ。

どれどれと靴箱を開けてみると、学生時代から履いていたスパイクは隅に放置され加水分解してボロボロになっていた。割と気に入っていたのに。ロナウジーニョモデルというあたりにまた時の流れを感じる。

この先履く頻度を考えるとお高い新品を買うのはどうかと思う。だがそれはそれとして、学生時代には買えなかったイカす最新のスパイクを、今なら好きに買えるというのもまた事実である。ジョルジーニョが履いているTiempoの新しいやつでプレーしてみたい。型落ち品がお買い得であるというオンラインショップのアウトレットコーナーで物色した結果、お値段とサイズの在庫の兼ね合いでPhantomになりました。でもモデル名に「アカデミー」ってあるんで、これユースの子のための廉価モデルなんですよね。多分。なんにせよおニューのスパイクはテンションが上がる。久々のフルコートは楽しかったです。

買ってよかった。

パジャマ (Calida)

「良いパジャマを着て寝ると捗る。学生時代の部活のジャージなど着て寝るべきではない」というtipsを昔どこかで見かけた。どこかで見かけてから随分経った。良いパジャマを買った。今ではもう部活のジャージを着て寝ていない。良いパジャマを着て寝る生活である。良いパジャマを着て寝ると捗るかと言われると、それは確かに捗るのだが、それよりも部活のジャージを着て寝ていないという事実の方が、よほど捗る原因である気がしているのだ。

Calidaのカットソーが大変よろしいのでパジャマも大層よろしかろうと思い買ってみたところ、生地感もいいし、形も綺麗だし、洗濯乾燥機に突っ込んで毎日ガンガン洗えるし最高によろしい。一緒に買った下着も非常によろしい。

買ってよかった。

AirTag (Apple)

鍵をどこかにやったとか、財布を電車に落としたとか、ケータイを飲み屋に置いてきたとか、そういう忘れ物はあまりしない方です。しかしAppleが久しぶりに無駄ガジェットを出してきたとなれば、買わないわけにはいきません。今のところ一番役に立ったのはだだっ広いモールの駐車場で車を探すときです。

買ってよかったと言えなくもない。

食

家中心の食生活はどんどん効率化される。しかし効率化してルーチンになると新鮮味がなくなるのがネガティブである。衛生面に気をつけつつ徐々に外食を再開することで、飽きずにやっていけている感がある。徒歩圏内に飲食店が山程ある都心に住んでいて本当によかった。

BCAAパウダー (MyProtein)

BCAAとは Branched Chain Amino Acids の略であり分岐鎖アミノ酸であるロイシン、イソロイシン、バリンの3種の必須アミノ酸の総称です。通常の食生活を送っていればBCAAが不足するということはありません。しかし過去の研究で、運動前にBCAAを摂取し血中のBCAA濃度を高めることで、運動中の筋タンパク質の分解を抑制し、遅発性筋肉痛（翌日以降に来るやつ）を和らげる効果があるという実験結果が示されています (下村2012)。

こういう筋トレ科学みたいなものって、日本語でもググるとたくさん出てくるんですよね。しかも医学系のジャーナルに出ている論文をちゃんと引用したりしていて、サンプルの偏りや実験デザインの不備にまで言及している記事もあります。筋トレへの執念ってすごいですね。科学コミュニケーションかくあるべしというか。結局のところ「理解したい」というモチベーションが全てなのかもしれません。

で、このBCAAパウダーなんですが、ゴールデンの名の通り、なんかドロドロした金箔のようなものが入っており、科学的なエビデンスとかそういう論理をすっ飛ばして「なんかヤベードリンクを飲んでいる」というエモーションに訴えかけてくるやつです。仮にもPh.D.を持っている人間がこんなことをしていていいんでしょうか。罪悪感がすごい。でもいいんです。ゴールデンなので。

今は欠品中だそうです。買ってよかった。

耐熱ドリッパー (Karita)

別になんてことはない普通のドリッパーなのだが、これがなんとCHEMEXのコーヒーメーカーにぴったりなのです。

CHEMEXといえばオシャレ雑貨屋さんに必ず置いてあるこれなんですが、純正のフィルターがやたら高いし、別メーカーの円錐形フィルターを使っていると破れたり落っこちたりと使い勝手が悪い。なんとも具合の悪いやつなんです。でもこのガラスのドリッパーを使えばそんな悩みから解放されるのです。写真の下の黒い部分が外れるので、ガラス部分だけにしてCHEMEXにフィットさせると、円錐形の紙フィルターがピッタリとはまってくれます。

いや、じゃあもうCHEMEX使う意味なくない？普通にこれで淹れればよくない？ってなるんですが、いや実際そうなんですが、でも人生ってそういうものでしょう。いいですか。「いやそもそも」ばかり言うやつは嫌われますからね。わかっているんですよ。わかってはいますけど、非論理的ですけど、それでもこうしたい。そういうしょうもない拘りを大事にしていきたい。CHEMEXにこのドリッパーをセットして毎朝コーヒーを淹れる度に、そういう思いを新たにしています。

買ってよかった。

四川料理のスゴい人 自宅でつくる本格中華レシピ (三才ブックス)

「四川料理のスゴい人」としてメシ通の記事で人気の人長さん。しかし hotpepper の媒体で四川料理がバズるのは正しさがあっていいですね。

以前から麻婆豆腐の極意を極めようと努力しているのですが、麻婆豆腐から派生して色々の四川料理レシピが紹介されており、料理欲を掻き立てられる素晴らしい本です。ぶっちゃけ紙面のデザインはあまりよくなくて、読みやすくはないんですが、それでもレシピに込められた工夫と、「家庭で本気の四川料理をやっていく」という信念をリスペクトしています。いくつか作ってみましたが、担々麺と口水鶏がお気に入りです。四川に行ったことがないのに家で四川料理作ってばかりなのもなんなので、チャンスがあれば現地に行ってオーセンティック四川メシを食べてみたい。

買ってよかった。

だいたい1ステップか2ステップ! なのに本格インドカレー (柴田書店)

泣く子も黙るイナダシュンスケ先生のインドカレー本第二弾。四川料理の本に続き、この本も紙面のデザインがイマイチで読みにくい。いくら企画がよくても紙面のレイアウトデザインをちゃんとしない出版社はダメだと思います。インドカレー本だとマニアにしかウケないので、時短メシ的なコンセプトを前面に出すことで、これまでに届いていない層に届いてほしい、全国民にインドカレーを作ってほしい、という企画の意図はなんとなく伝わってくるのです。しかし手書き風フォントの視認性が悪かったり、実質Nステップ(N>2)なのに2ステップであるかのようにレシピが記載されていたりと、手順を間違えやすいデザインはレシピ本としては致命的だと思います。その点では前作の方が断然よかった。

ただそれらは本当にプレゼンテーションの話であり、コンテンツとしては材料の準備も手順も、前作からさらに効率化されており、その執念を改めて尊敬するところです。ジップロックコンテナのレンチンバスマティライスは我が家の食卓で大活躍しています。ただただ読みにくいのが惜しい。

買ってよかった。

自作煮干しラーメン

写真はありません。写真撮る前に食ってしまうので。

今年は 発酵料理家 真野遥さんの一番簡単な煮干しラーメン を参考に煮干しラーメンばかり作っていた。もちろん麺はパスタマシンで自家製です。ラーメン凪の煮干しラーメンみたいにはせず、おや煮干しの味がするな、くらいの塩梅にしておくのが食べ飽きないです。職場で振る舞ったら「全然期待してなかったけど想像以上に美味かった」と好評を頂けました。これからも日々精進です。

買ってよかった。(パスタマシンを)

コーヒー豆 (Lucent Coffee)

気付けばすっかり浅煎り派です。外食しない代わりに出かけていった先々に好みのコーヒー屋がないかと調べてはテイクアウトで頂いたり豆を買って帰ったりしています。色々のコーヒー屋には色々の良さがあり、一概にどれがということはないのだけれども、ラテの美味しさで言うと浅草〜蔵前エリアに数あるコーヒー屋の中でもこちら Lucent Coffee さんが一番だと思っています。

これまでに飲んだ数々のラテと比べてもあまりにも美味しいので「なんでこんなにラテ美味しいんですか？」とすごく頭の悪い質問をしてしまったんですが、少々困りながらもラテ用に焙煎を工夫している旨を教えていただけました。お店の雰囲気も大変よろしいし、天気がいい日はテイクアウトして蔵前〜かっぱ橋〜浅草〜隅田川と近所を散歩するのもよろしい。本当におすすめです。

お店で焙煎しているコーヒー豆もとても美味しいです。オンラインショップでも買えるそうなのでぜひお試しください。

買ってよかったのでまた買います。

住

たまに住んでいるエリアから遠出すると、都心の便利さと家賃の高さに今なお頭がクラクラします。普通は利便性を妥協して家賃が安いエリアに移るか、ガンガン稼いで都心に住むかの二択なんだと思いますが、魂が怠惰なので「便利エリアなのに安い」というバグ物件を日々探しています。

洗濯乾燥機 (Sharp)

昨年の買ってよかったものリストにIKEAの物干しラックを挙げた。昨年のテキストに曰く「物干しラックがあることでハンガーに洗濯物を干すという日常の非効率さに気付くことができた」と。そこからさらに進んで、洗濯物を干すということ自体の非効率さに気付くまで、そう時間はかからなかった。

ある夜のこと。洗濯機を回したまま干さずに寝落ちしてしまい、夜中の2時ごろにふと目が覚めて洗濯物を干し始めたことがあった。なんとなくTwitterを開いて「洗濯物を干している」と post した。しかしその時にふと気がついた。おれは一体何をしているのだろうかと。そうして翌朝、洗濯乾燥機について調べ始めたのでした。

一昔前は「家電として未完成」などと言われていましたが、各メーカーの努力もあり色々と進歩しているようで、今では新・三種の神器なんて言われております洗濯乾燥機。デザインと値段を検討した結果、Sharpの子がうちにやって来ました。相変わらずプラズマクラスターなるステキ機能がついてるんですね。そういうのはオプションにしてくれませんかね。

洗濯から乾燥まで寝ている間にやってくれるだけでなく、ヒーターでがっつり内部が熱されるおかげで洗濯槽が常に殺菌され、浴室の匂いが変わりました。特に夏場はカビに困っていたのだけど、ソースが1つ減ったのは大変によいことです。

今年の買ってよかったものオブジイヤー。

Apple TV 4K (Apple)

Netflix, Amazon Prime, Disney+ と動画ストリーミングサービスに課金しっぱなしで、観たいと思うコンテンツには事欠かないのに、なんだかんだいつも結局 DAZN でサッカーを観ています。LG の OS にも App が内蔵されていて Netflix も DAZN も観られるんですが Siri Remote (リモコン)の圧倒的な操作性のよさ、iOS 端末から操作できること、AirPods をシームレスに繋げること、などなど Apple TV をわざわざ買う価値は間違いなくある。

少し前のアップデートで Apple TV から AirMac に繋いだ Bose のスピーカーに AirPlay に飛ばせなくなったのが結構ストレスで、こういう形で強制されて HomePod を買うのはなんか嫌だなあと思っています。あとリモコンがしょっちゅうなくなるので Find My で音が鳴るようになってほしい。

買ってよかった。

羽毛布団 (無印良品)

一般的に、人生において買う頻度が少ないものほど、自分の経験も人の意見も、購入の際の役には立たないものです。一般的に人が人生で羽毛布団を購入する頻度はどれほどなのでしょうか。

L.L.Beanの死ぬほど暖かそうな羽毛布団を検討していたんですが、いつの間にか日本での購入不可、北米サイトで買っても配送不可になっていました。グース取り扱いの条約か何かが変わったんでしょうかね。「米国北部の冬の寒い日でもヒーターなしで寝れる」という口コミがすごく魅力的だったのですが。

羽毛布団の値段は青天井で、高いものは数十万円、モノによっては百万円以上するんですが、そしてそれらはきっと間違いなくいいものに違いはないんですが、でも、この先そう買い換えることもなく、従って他のものと比べる機会もなく、そして被せる対象は自分であり、自分に被せる布団の価値とは、果たして己の価値とは、人生とは、と考えはじめてしまうのでもうだめです。そしてそういう時に助けてくれるのはいつだって無印良品です。

どうでもいいものを無印良品で買うと高いなと思うけど、他では高いなと思うものを無印良品で買うとこれでいいんだよなとなります。そういうところがよいのだと思いながら、すごく無印良品テイストな見た目になったベッドにもぐって寝るわけです。

買ってよかった。

Ulysses | Writing App (Ulysses)

長いことクラウドメモとして Evernote を愛用していましたが、使うのをやめてしまいました。発端はエディタのショートカットのバグだったのですが、これをきっかけに作業環境を見直すことに。主に Evernote は以下の用途で使っていました:

日々のスケジュールとtodoの管理

ブログや論文の執筆

ウェブ上の情報をコピーする WebClip

紙媒体の情報のスキャン

これら全てを担い、かつ複数のMacとiPadとiPhoneからスムーズにアクセスできるのがかつては Evernote しかなかったわけです。Dropboxも最近は全部できそうだけど。しかし Evernote はとにかくエディタが壊滅的に使いにくい上にどんどん改悪されていくのです。これは Evernote でテキストを書くなという Evernote 社員からのメッセージに違いないと確信したのでした。

色々のappを試した結果、今では以下のようになっています:

日々のスケジュール, todo, 個人的なメモなど: Notion

ブログや論文のアウトライン、ドラフト、本文執筆: Ulysses

公開して問題ない作業記録や技術メモなど: Scrapbox

WebClip と紙媒体のスキャン: Evernote

その中でも一番気に入ったのがテキストライティングアプリとして有名な Ulysses なのでした。

発表当時から気になっていたんですが、どれくらいの頻度で使うかわからないのに $99 の買い切りというのがネックで導入を見送っていました。それが今やサブスクリプションモデルになり年額$49です。最近はもっぱら技術文書や論文、ブログ、書籍や雑誌の記事など書物に費やす時間が増えているので、噂通りの生産性の高さならとお試しで導入したところ、大変よろしい。Markdownで書けるエディタというのは通常はエディタ部分と書式がレンダリングされたプレビューに分割されるのですが、Ulysses は markup theme を当てることで、エディタとビューワーを両立することに成功しています。iCloudでデバイス間共有がラクだとか、モバイルからでも結構快適に編集できるとか、他にもいろいろと嬉しい機能はあるんですが、一番はやはりシンプルに、書きたいように書けること。本当に捗ります。

本当に買ってよかった。

それではまた来年。みなさまよいお年をお迎えください。

[trattoriainutano]

今年買ってよかったもの2020

まあとんでもねえ一年でしたね。来年もこんな感じなんでしょうかね。

COVID19とそれに伴う諸々により、在宅勤務になって通勤という概念が消滅し、国内外への出張も消滅してオンライン会議になり、友人たちと気軽に飲みに行けなくなり、ホームパーティもできなくなりました。その代わりに家で過ごす時間が増えたので、家でやれる楽しいことをとことん追求した一年でもありました。

毎年色々なひとの「今年買ってよかったもの」を読ませてもらって楽しんでいるので、今年はCOVID19戦時中の生活を記録する意味も込めて、自分でも書いてみることにしました。Amazonのアフィリエイトがところどころ埋めてありますが、ビール一杯分以上の収入があった場合には近所の基幹病院に寄付しますので、遠慮なく買ってくださいね。

目次

リストアップしたらすごい数になったので衣食住にカテゴリ分けしてみた。こういう分類作業をするときにやたら悩んでしまうのは職業病だなあと思う。

衣

服

+Jのカットソー

FALKEの靴下

ビアキチのTシャツ

雑貨

Gonexの折りたたみボストンバッグ

藤高タオルのバスタオル

食

備品

合羽橋の飯田屋がお勧めする揚げ物セット一式

揚げ鍋

温度計

油ポット

バット

網

カス揚げ

パール金属のグリルパン

Cuisinartの業務用フードプロセッサー

KitchenAidのスタンドミキサー

Atlasの製麺機

タニタのキッチンタイマー

消耗品

富澤商店の小麦粉

マヤバザールのスパイスと豆

Antenna Americaのクラフトビール

住

家具

IKEAの物干し

IKEAのスタンディングデスク

ガジェット

AppleのAirPods Pro

Switchbotの温湿度計

カクダイのシャワーヘッド

iRobotのBraava

コンテンツ

機動警察パトレイバー

チェンソーマン

Naturally Tan

Ultras

DIEGO MARADONA

Calendario SSC Napoli 2020

衣

家にいる時間が増えると適当なだらしない格好ばかりする駄目な中年になってしまうのではと心配していたがそうでもなかった。ずっと家にいるからこそ好きな服を着ないとテンションが下がるという事実は意外な発見であった。

+Jのカットソー

いきなりこれかよ。悪い意味でも話題になってしまった+J、ウェブストアで運良くいくつかを手に入れることができたのだが、その中で一番気に入ったのがこちら。安いジルサンダーと思って見ると大したことはないかもしれないが、デザインの優れたユニクロ製品だと思えばこんなにいいものはない。と思う。どの媒体だったか失念してしまって探しても見つからないのだが、ジル・サンダー本人のインタビューで、ユニクロと組んだ理由を「AppleがiPhoneで成し遂げた『優れたデザインを大衆に届ける』ということをファッションでも実現したかった」と言っていたのが本当によかった。じゃあもっと大量に作ってくれよという気もするのだが。いくらブランド戦略とはいえ、普通に試着して普通に買わせてほしい。

しかしユニクロは定番ラインも年々綺麗になっているので本当にすごい。ファストファッションはそれ自体がファッションの価値を下げてしまっているのでそのうち自家中毒で死ぬのだろうけど、ユニクロは生き残りそうだなと思う。

+Jのほとんどの商品はユニクロ店舗の棚からメルカリのサムネイルに瞬間移動してしまったが、ウェブストアでは一部の商品が今も時々在庫が復活している模様。

FALKEの靴下

たとえ家から出る用事が王将のテイクアウト（天津炒飯、京風たれ）を取りに行くだけだったとしても、朝こいつを履くとテンションが上がる。前々から愛用しているのだけれど「良い肌着は沢山買え」という教えに従って一週間分揃えてみたらすこぶる調子がよい。おすすめはもこもこの Walkie Light とスポーティな Run です。

ビアキチのTシャツ

界隈では知られた福岡のイカしたビアパブ、ビアキチのグッズ。COVID19のせいで大変そうだが福岡に行けないのでちまちまグッズを買っている。このイカしたTシャツも夏の間ずっと着ていたのだが、いかんせん人に会わないので話のネタにもならなかった。使い勝手のいいLINEスタンプも売っているのでそれも買ったけど、LINEを普段あまり使わないのでそちらも持て余している。

Gonexの折りたたみボストンバッグ

旅に出るときは身軽でいたいので、荷物はバックパック1つしか持っていかないという信念がある。信念は絶対に曲げたくないが、しかしお土産は大量に買って帰りたいというワガママクソ野郎でもある。そこでこちらを買ってみたところ、往路は折りたたんでバッグに入れておき、復路では広げてお土産でパンパンにして帰るという体験ができて本当によかった。厳密には買ったのは昨年末で、案の定というか今年は全く出番がなかった。ではなぜここで紹介するのかといえば出番がなくても家に置いておくのに全く場所を取らないからである。場所を取らないものはいくらもっておいてもよいのだ。

藤高タオルのバスタオル

いただきものであり買ったものではないのだが、デカくてフワフワのバスタオルが家にあるというのは本当に人生を豊かにしてくれるので紹介させてほしい。めちゃくちゃよかったので両親にもプレゼントした。自分がもらったものよりもランクが一つ下のものを送ったのは、将来プレゼント選びに困ったときに「あのときにあげたやつのさらにいいやつだぞ」と言ってもう一度プレゼントするためであり、他意はない。

今治タオルブランドと言えば外国人実習生を劣悪な環境でこき使っているという報道で大炎上したのが記憶に新しいが、組合傘下の企業ではそのような実態はないということだそうだ。とはいえ下請け、さらにその下請けでは…というのはどこにでもある話で、新疆の件も然り、環境に配慮するよりも前に労働者に配慮しろと思わずにはいられない。誰だってフワフワの気持ちのいいタオルを被っているときに工場で辛い目に遭っている労働者のことを考えたくはないのだ。高い品質を謳うのなら、労働者を薄給でこき使うよりも価格を高くして利益を出してほしい。ということでみなさんも高級タオルを買ったりプレゼントしたりしましょう。

食

元々自炊に凝る方ではあったものの、自宅にこもって他にすることがなくなった結果、あれもやってみようこれもやってみようと収集がつかなくなっている。その様子を見た人々からは「一体どこへ向かっているのだ」と言われる。愚問である。行く先がわからないからこそ料理は面白いのだ。

合羽橋の飯田屋がお勧めする揚げ物セット一式

「自宅で揚げ物はしたくない」と主張するための理由はいくらでもある。キッチンが汚れる。後片付けが面倒。油の処理が面倒。危ない。温度管理が大変。などなど。それらは道具を揃えれば解決する。そう、料理における大抵の問題は道具を揃えれば解決するのだ。合羽橋の有名な道具屋である飯田屋の兄ちゃんの記事を読めばそれがわかる。我が家で導入しているアイテムは以下である。

揚げ物用の鍋

鉄製を買って使っており何ら不満はないが、神田の天丼屋で使っているような銅の鍋が欲しい。カッコいいので。

温度計

鍋に引っ掛けておける温度計は絶対に必要。度々測るのは効率が悪いし、キッチンで効率が悪いということは死を意味する。

油ポット

揚げ油って毎度固めてテンプルで捨てるもんだと思ってました。

バット

シルバーのバットが家にあると俄然テンションが上がる。揚げ物だけでなく色々使える。

網

揚げ方が下手でもバットに載せて油を切っておくだけで揚げ物は美味くなる。インターネットの情報はフェイクばかりですがこれは真実です。

かす揚げ

揚げたあとの油の汚れを掬っておくためのもの。天かすを掬うのは結構楽しい。

どれもAmazonで買えるのだが、キッチンの小物は絶対に物理店舗で買ったほうがいい。行けるものなら合羽橋の道具街に行ってほしい。調理器具は人生においてそう何度も買ったりするものではないので、数少ない購入のチャンスをネットで済ませるのは本当に勿体ない。合羽橋に行け。クソ楽しいので合羽橋に行け。

さて揚げ鍋で何を作っているかといえばナポリのソウルフードであるところのピッツァフリッタである。自作リコッタチーズは簡単だったが、自作モルタデッラはまだ躊躇している。

「ナポリを見て死ね」という有名なフレーズがあるが、これは「人はみないつか死ぬがどうせならナポリに行ってピッツァフリッタを食ってから死ね」という意味である。

パール金属のグリルパン

これ、なにかと云えば家でナポリピッツァを焼くためのものである。もちろん他の用途でも使えるがナポリピッツァを自宅で焼けるという器具にそれ以上の役割を求めるのは野暮である。ピッツァはナポリの職人が手仕事で作ったドーム型の窯でしか焼けない、家庭用のオーブンで焼くなど不可能であると思い込んでいたので、このレシピを見たときには目から鱗であった。家庭の魚焼きグリルからマジモンのナポリピッツァが出てくる光景はかなりシュールなので是非試してみてほしい。

Cuisinartのフードプロセッサー

長年使っていたコンパクトなモデルをハードに使って壊れてしまい、後継を求めたところクソデカいコイツがやってきた。店ならともかく家庭ではそれほど使用頻度は高くないし、業務用と同じサイズのこいつはいかにも過剰だし邪魔なのではと思っていたところ、実際邪魔である。邪魔ではあるが、とにかくパワフルである。みじん切り、スライス、千切り、あらゆる作業が一瞬で終わる。Napolissimiさんで紹介されているナポリの伝統料理であるところのジェノベーゼのように大量のスライス玉ねぎを使うレシピもこいつがあれば楽勝である。パワフルすぎてこいつで材料を切っている時間よりも使い終わったあとに洗っている時間の方が圧倒的に長い。

KitchenAidのスタンドミキサー

今年買ってよかったものリストの中で最も異彩を放っているのがコイツではなかろうか。ロックダウン中にパン作りに目覚め、毎週のようにフィンランドのシナモンロールを焼いていた2020年の夏、パンを手で捏ねるには日本の夏は暑すぎると悟った。その結果がこれ。

色々と調べた結果、パンを捏ねるにはコンパクトでカァイイやつではてんでだめで、最もパワフルなプロ仕様でないとだめだということであった。そこでこいつを購入した。でかい。重い。うるさい。おまけに高い。日本のご家庭で好かれる要素が一切ないが、そもそも日本のご家庭ではそんなにパンを捏ねないのである。そして日本のご家庭でパン捏ねを自動化したいという奴はそんな些細なことは気にしないのである。

混ぜることしか能がないでかいマシンである。だがそれがいい。ボストンバッグのところで書いたことと真逆のことを言っているが、それでいいのだ。スイッチを入れるとグルグル回る機械は正義なのだ。

Atlasのパスタマシン

クイジナートのクソデカフードプロセッサー、キッチンエイドのクソデカスタンドミキサーを買ったあとではパスタマシンも「オッ、ちっこくてカァイイな」という感想になる。人間は比較することでしか物事を評価できないのだ。スイッチはないがハンドルをグルグル回すと製麺できるマシンである。グルグル回すと麺が出てくる。最高に楽しい。パスタだけでなくうどんやラーメンも作れる。というかもっぱらうどん、時々ラーメンである。パスタは乾燥パスタの方が美味しいですからね。

趣味の製麺の伝道師である玉置先生の記事を参考にいつもハンドルをグルグル回している。

タニタのキッチンタイマー

でかくてグルグル回るものしか紹介しないのも馬鹿みたいなのでこちらを紹介したい。キッチンタイマーは最低限の機能があればよいし、実際こいつは最低限の機能しかないのだが、薄くて見た目がカァイイ。こんなに沢山のデカくて重いグルグルマシン共をキッチンに並べておいてなんなのだが、カァイイ道具があるとテンションが上がる。そしてテンションを上げることこそが料理の本質なのだ。

富澤商店の小麦粉

ロックダウン直後は注文が殺到したらしく全然届かなかったが、そんなことはお見通しでロックダウン直前に5kg単位で買っていたので我が家は製パン製麺天国であった。レシピから材料が買えるレシピとストアが連動しているウェブサイトが素晴らしいなと思うのだが、ウェブサイトが重いのがちょっと残念。なんかすごい遅いクエリが後ろで走ってそうな気がするが、まあ製パンは大抵数時間くらいかかるのでサイトのレスポンスが少々遅いくらいは気にならない（そんなことはない）。

ナポリピッツァの要であるところのカプートの小麦粉まで売っている。凄い。

マヤバザールのスパイスと豆

ご多分に漏れず我が家でも稲田先生の教えに従ってカレーを作っているのだが、スパイス類をまとめてネットで買えるので便利。注文をミスってバスマティライスと豆類を各種1kgずつ頼んでしまったのでキッチンの一角が今なお大変なことになっている。

エリックサウスのモダンインディアンコース、大変美味しゅうございました。

Antenna Americaのクラフトビール

泣く子も黙るアンテナアメリカ。ロックダウン直前に品川のバーに飲みに行ったら、店舗の客は激減したものの通販需要が激増して箱詰めばかりしているとのことであった。今年の個人的ヒットは Lone Pine Brewery 。メイン州、行ってみたいけど合衆国に行ける日は一体いつになるのだろうか。

住

東京は家賃相場が高いのがネックだが、今年はずっと家とその近所で過ごしているために相対的に家賃の費用対効果が上がっており、今まで払ってきたクソ高い家賃はこのときのための前払いだったのだと自分に言い聞かせている。

IKEA MULIG (物干しラック)

我が家にあるものはほぼ全てIKEAで買っているのでIKEAであることに大した意味はない。しかしこのタイプの物干しを買って気付いたことは、洗濯物を干すために上腕を肩より上に持ち上げることをこれまでずっと強いられていたのだということである。洗濯機から出した洗濯物をハンガーにかけて物干しにかけるときの動きと、洗濯機からカゴに移してこの物干しにぶら下げるときでは使うエネルギーが段違いである。在宅勤務のおかげで家事について考える時間が増え、その結果として今までの非効率さに気付くことができるという例であった。洗濯物を干そうというアフォーダンスを発揮してくれるという意味でも、これはとてもよい買い物だった。

IKEA KNOTTEN (スタンディングデスク)

首都の小さな賃貸物件には仕事用の部屋など存在しないので、昇降デスクを買ってでかいディスプレイを据えてクールな自宅仕事環境の写真を撮ってSNSにアップしてマウントを取ることができないのを本当に残念に思っている。そんなあなたにこちらのスタンディングデスク、せいぜいラップトップを置いて立って作業するくらいなのだが、専有面積の割にはちゃんと仕事場感を出してくれるので、メンタルの切り替えに貢献してくれている。そんな気がする。

AppleのAirPods Pro

スティーブが死んだあとのAppleはどうなるのだろうと思っていたらイヤフォン屋になってしまった。それ自体は嘆かわしいのだが、イヤフォンはちゃんとしているのがすごい。ワイヤレスイヤフォンに人類が望んでいたのは音質でも軽さでもバッテリの持ちでもなく、デバイスとの接続のスムーズさだったのだなということを気付かせてくれる逸品。

Switchbotの温湿度計

データなくして決断なし、継続的なモニタリングなくしてデータなしということで、室内の温湿度を計測、記録するためのデバイス。このお値段でこれだけちゃんと動いてくれるなら立派でしょう。ハブとか色々あるが単品で買ってモバイルの専用アプリでログを取るだけでも十分使えている。家の中にサーバを立ててBluetoothで自動でデータを取ってきて可視化したりということもできるそうなので、この冬の楽しみにとってあります。

カクダイのシャワーヘッド

据え付けのシャワーヘッドがやたらと水圧が強いのと黒ずみが気になっており、いい機会なので換えてみた。シャワーヘッドってめちゃくちゃ種類あるし価格帯も広いんですね。カートリッジで浄水できることと、手元のボタンで一時止水ができることを基準に選んだら選択肢があまりなかったのでこれにしましたが満足しています。

とはいえシャワーヘッドっていくつも買って比較なんてできないし、そもそも評価は個人の感覚に依存するし、交換前と比較して良くなっているのでまあいいかという感じになってしまいがち。世の中にはもっといいシャワーヘッドがあるのかもしれないが、それを知ることは永遠にないのだ。

iRobotのBraava jet

動物愛護にも配慮され誰でも合法的に飼えるペット。カァイイ。掃除もしてくれる。

機動警察パトレイバー

諸事情により全巻Kindleで買って一気読みしてしまった。テーマの深さとその鮮やかな描き方、30年前の漫画とは思えない未だ色褪せぬ傑作です。アニメで躍動するイングラムに興奮していた子供の頃とは違い、任せるが放置はしない後藤隊長の懐の深さにしみじみ感動してしまうあたりに自らの老いを感じる。

チェンソーマン

今年も色々漫画を読んだけど、一個挙げるならこれ。これが週刊少年ジャンプに載るってすごくないですか。地獄に行くあたりをアリ・アスターに実写で撮って欲しいけど、もし実現しても絶対観たくない。

Naturally Tan (邦題: 僕は僕のままで)

タンの自伝。やっぱりアントニが一番モテるんだなという事実が確認できる。必読。

Ultras

Watch on Netflix

もはや買ったものでもなくNetflixの番組なのだが推しておく。ナポリのウルトラス（サッカーの試合でゴール裏にいるやんちゃな人たちのこと）のメンバーが、ウルトラスとしての生き方と自分自身の人生とに悩む話。ただただしんどい現実を突きつけられるだけで全然ハッピーな話ではない。ナポリのティフォージ（サポーター）の人以外には全くお勧めしないけど、ナポリのティフォージだからと言って観たらスカッとするかというとそんなこともまったくない。

DIEGO MARADONA

Ultras書いてて思い出したけどこれも紹介しておかねばなるまい。公開は昨年で観たのも昨年だが、日本での公開は今年だったはず。まさかディエゴが死んでしまうなんて未だに信じられないが、この映画は広く知られているサッカーの天才マラドーナではなく、アルゼンチンに生まれナポリで愛されたディエゴの姿が当時の映像で語られていてとてもよかった。

Calendario SSC Napoli 2020

これは「今年買ってよかったもの」なのだろうか。SSCナポリというイタリアのサッカーチームが毎年企画して売っている、本体価格は€8なのに日本までの送料で€30取られるという悪夢のようなカレンダー。心なしかその月にフィーチャーされている選手が負傷したり活躍できずファンに罵倒されたり移籍したりと不幸な目に遭っていたような気がする。少し前は所属選手や監督にコスプレさせて愉快なカレンダーに仕上げていたが、今年に引き続き2021年版も真面目路線だそうで、ちょっと惜しい気がする。

[trattoriainutano]

生命科学分野における研究再現性に関する議論

この記事は Open and Reproducible Science Advent Calendar 2020 の8日目の記事です。

「研究再現性」という単語を聞いたとき、プロの研究者の頭に思い浮かぶのは話題を呼んだ 2018年のnatureの特集記事 だったり、そこからの一連の議論だったりするのではないかなと思います。この Advent calendar シリーズもそうですし、その後も様々な議論がなされ「研究結果が再現すると言うためには何が必要なのか」「そもそも再現するとはなんなのか」というトピックはそれだけで学問分野として成立しつつある様子でもあります。

この「研究再現性」という概念を、プロの研究者だけでなく、お茶の間のみなさんに一発で理解してもらうことが可能なのが我が国の特異なところであります。それというのもかの 割烹着を着た研究員の絶叫 の与えたインパクトによって、およそサイエンスの現場から遠いところで日々過ごしておられる人々でもそういった問題があることを理解されておられるのです。「あります」と言えばあるわけではないのです。「ある」と主張するに足る結果と、その結果を導き出すために行った過程が、第三者によって検証可能である状態であってはじめて「ありそう」と言う、それがプロの研究者としての態度であるべきです。多くの人からリスペクトされる偉大な一人のサイエンティストを失った、痛ましい事件でした。これは個人的な見解ですが、あのような事件を二度と起こさないように努力を続けることが、同じ国の同じ分野で活動していく者の責務ではないかと思っています。いやほんとに。マジです。

ところで、あの事件がどのようにしてああいった結末に至ったかということについてもはや覚えている人は少ないかもしれません。色々とありましたが（本当に色々ありましたね…）、最も重要なポイントの1つであったのが、分子生物学、特にゲノム科学における30年来の「生データ公開の原則」でした。自然科学の進歩は即ち測定装置の進歩であり、天文学における望遠鏡のように、ゲノム科学におけるDNAシーケンサーの高解像度化（分子レベルでの測定）、ハイスループット化（1回の測定における測定量の増加）、低価格化によって、かつて見えなかったことが見えるように、できなかったことができるようになったことが、80年代以降の分子生物学のみならず生命科学を支えているのです。そして「研究成果を発表する際には測定されたゲノム塩基配列を指定されたレポジトリで公開し誰でも自由に再利用可能にすること」というヒトゲノム計画時の バミューダ原則 から続くデータ公開原則が、第三者によるデータの 検討 を可能にし、かの事件においても重要な役割を果たしたのでした。

2020年現在、科学誌において発表される研究において用いられた塩基配列データは、日米欧の３研究機関によって運営される 国際塩基配列データベース (International Nucleotide Sequence Database Collaboration, INSDC) への登録が義務付けられています。しかし、国や機関を超え分野としてデータ公開を義務付けるルールがあるにも関わらず、あんな大騒ぎになるわけです（大騒ぎになったのは科学的な問題とは違う要因があったにせよ）。「データを公開すること"だけ"では再現性の担保に十分ではない」と理解するには、十分すぎる出来事でした。

From sample information to Figure

では分野における再現性の議論において、現時点での問題はどこにあるのでしょう。

この図は以前にとあるオンライン学会で僕が発表したときのスライドから取ってきたものです。グッとくるイラストが使われていますが、現代の生命科学の研究はおおむねこういった流れを辿ります。すなわち、まず対象とする生体試料を準備し、次にそれを測定し、計算機で解析し、成果をまとめて論文にする。ゲノム科学のよいところは、測定したデータを公開せよという原則に従っている（でないとほとんどの専門誌で論文は受理されない）ところですが、これだけでは足りないのは前述の通りです。生体試料の情報（メタデータ）も正確かつ必要十分に記述される必要がありますし、計測時の条件や試薬、機械の情報も記録しておかなければいけない。計算機で解析をしたときにどのソフトウェアのどのバージョンを使ったかという情報も必須です。

生データが公開されている前提なので、再現性の議論における問題点はそれを基準に前後2つのフェーズに分けることができます。まずは「サンプル→生データ」のところ。実験室で行う部分、分野ではナマモノを扱うということで「ウェット」と呼ばれます。そして次に「生データ→論文（図表）」のところ。こちらは計算機内で行うものでウェットに比して「ドライ」と呼びます。ウェットもドライも両方できるという人はかつては少なく「両生類」を自称するような人も少なかったのですが、数多くのプログラミング解析指南書が出版され、年々その溝は埋まっている = どちらもできる人が増えている印象です。

ではまず最初の「実験室での物理的操作の再現性」について。こちらは物理的、空間的、時間的な制約がかかるため、「100%再現可能である」と言える状況にもっていくことはそう簡単ではありません。時にウェットにおいては「再現性」をより細かく分類されており、異なる解釈もありますが、個人的には以下の図の分類の説明が分かりやすいと思っています。いつも愉快な愛すべきキャロルのプレゼンから持ってきました。この分類の初出は 図下部にあるようにDrummondらのpaperからです。

前述のようなインシデントを防ぎ、科学的方法に則って新しい知識を得るためには、この図における replicate/reproduce の部分が可能かどうか、を評価する必要があるわけです。しかし現実的に「全く同じ実験を別のラボでやる（replicate）」ことを厳密にやろうとすると、試薬のロットや測定装置などを揃える必要があり、100%完全に同じということはそれなりのコストがかかってしまいます。つまり実際の現場で評価すべきは「同じ実験をある程度同じ設備や試薬で行って同じ結果が出るか」となるでしょう。まあでも現実には左上のrepeatですらうまくいかないものです。というか僕はそれが嫌で修士課程卒業後にウェットからドライに逃げ込んだクチです。あれが僕の手技が下手だったのか実験デザインの問題だったのかはたまたサンプルや試薬が悪かったのか、それは未だにわかりません。あの頃の自分を助けに行くぞというモチベーションでこのトピックをずっと追っている面は少なからずあります。

ともあれ、ウェットのフェーズにおける再現性の向上を目的として取れるアプローチは大きく2つあります。1つ目はプロトコルの記述精度を向上すること。2つ目は実験の過程から作業者やモノなどの空間依存を完全に排除することです。

1つ目は machine readable experimental protocol として取り組まれている protocols.io のようなプロジェクトが代表的です。2つ目は端的に言えば実験の自動化であり、ロボットを用いた実験手技の完全な再現を目指すプロジェクトが数多くあります。実験自動化の問題提議や課題、提案については Robotic Biology Consortium による論文 をどうぞ。

なんか既にすごい長くなってきて今日中に上げられるのか不安になってきた。さくさくいきましょう。

フェーズ2つ目、生の計測データから論文の結果までの部分です。計算機内で完結する分、こちらの状況はウェットよりはマシですが、どっこい問題がないわけではありません。疲れてきたので問題点を箇条書きで挙げます。

生データのメタデータが十分でない問題

測定装置の情報や測定時のパラメータが記述されていないために計算機において正しい処理を行えない

生データのサイズが大きすぎる問題

公開データは誰でも使えるよ！（そんなでかい計算機誰でも持ってるわけないでしょ）

ソフトウェアがシェアウェア

同じことをしたけりゃン十万円のソフトを買えと？

Excelだって無料ソフトではないぞ、使うのを今すぐやめろ

ソフトウェアのバージョンが記述されていない問題

バージョンによって出力が変わるんですが

ソフトウェアのインストールができない問題

自分のマシンではビルドが全く通らない

ソフトウェアの実行時パラメータが分からない問題

色んなオプションがあるんですけどどれ使ったんですか

etc, etc. まだ他にも邪悪な問題はたくさんあります。詳しくは昨年に 日本バイオインフォマティクス学会のニュースレター35号 で再現性の特集が組まれましたので、こちらを読んでいただくとよいかと思います。僕も寄稿しました。このような問題に対するアプローチの研究と開発が最近の僕のメインの仕事なのですが、実践的な解決策としては以下のようなものが挙げられます。

メタデータの標準化

既存の情報にアノテーションをつける

いい感じにメタデータを記述するためのサポートをする

オンデマンドに計算機を調達する

共用スパコンの提供

クラウドコンピューティングの活用

コンテナ仮想化によるソフトウェアのパッケージング

2020年代はツールのインストールをしたら負け

バージョンも固定できる

notebook を使って探索的データ解析のフローを記録する

ワークフロー言語を使って解析フロー丸ごとパッケージング

色んな言語がありますが推しは CWL です

入力パラメータ含めて可搬性を高めます

コンテナ/ワークフロー言語を使った系のデプロイを簡易化するシステム

とかとか。このあたりの話は 以前の記事 - データ解析が再現するということ、あるいは Common Workflow Language が僕らにもたらしてくれるもの でも書いたのでそちらをご参照ください。

書いてるブログ記事がどんどん長くなってくると「これ論文にまとめたほうがいいんじゃね…レビューとか書けんじゃね…」という気持ちになってきますよね。今がそうです。そういう気持ちになってきたときはブログ記事の締め時です。

というわけで

なにがというわけなのか。色々の分野で研究再現性の話題が上がっていて、それらを見に行く（分野を越境するときの表現）のはとても面白いです。分野ごとに共通の課題もあるし、分野固有の問題に、ああこちらの分野ではその発想はなかったなーという視点もあります。色々の分野がそれぞれ情報をオープンに発信していくことで、そういった知見が交換されていくといいなと思います。

ゲノム科学における研究再現性、中でも計算機上における環境構築やソフトウェア実行の再現性について継続的に議論したり開発したりするコミュニティを以下に2つ紹介しておしまいにします。

Pitagora Network

もともとは Galaxy というソフトウェアのユーザコミュニティで、ウェットとドライの垣根を下げるべく情報交換をするコミュニティです。毎月 Meetup というイベントをやっています。今はオンラインです。

Workflow Meetup

Pitagora Network の Meetup に集まったコアなインフラ運用・開発に関するトピックを深く議論するためにスピンアウトしたコミュニティ。こちらも毎月Meetupをやっています。

どちらも slack があります。Pitagora の方は twitter@iNut までお声がけください。といっても遠慮しますよね。遠慮せずどうぞ。Workflow meetupの方は招待コードを発行できるようになっていますので、githubのページをご覧ください。

[trattoriainutano]

パブリックなNGSデータをダウンロードするのにお金がかかるようになる（かも）

タイトルは意図的なミスリーディングを狙っており、それが事実の一部であるとしても、これをタイトルに掲げることは非常に悪質なものです。誤解されそうなタイトルで釣らないとブログに読者を集められないのは、ひとえに書き手の怠慢であり、能力不足であり、卑怯さ、姑息さ、誠意のなさ、低俗さ、魂の汚れ、負け犬根性をこれ以上ないほどに示しており、書き手の信頼を大きく損なうものです。「そうは言ってもこうでもしないと見てもらえないでしょ」というのはテロリストの言い分です。普段から誠実に良質なブログ記事を書き続けて信頼を得ていればこんな煽りタイトルを掲げなくても読者は見てくれます。

ごめんなさいね。懺悔終わり。

ほんとは「パブリックなNGSデータのダウンロードが有料になります」というタイトルでしたが、人間は愚かなのでタイトルだけしか読まず本文を読まないので、少しだけ柔らかい表現にしました。大事な話なので最後までちゃんと読んでほしい。

tl;dr

まじで長くなったので忙しい人向けに三行で解説します：

「NCBIの」SRAがクラウドに移行しました、オンプレと並行で運用するよ

NCBI「データ量多すぎてやってられないので配列データからクオリティ情報(BQS)削るよ」

オンプレにはBQS削ったやつだけ置いとくよ

BQS持ったやつもクラウドに置いとくけど、クラウドからオンプレにダウンロードすると転送料かかるよ

NCBIがこの件でパブコメ募集してるので、みんなの意見を教えてね

パブコメ書くの面倒くせえって人はtwitterで教えてね

EBIとDDBJは今まで通りなのでお金かからないよ

本当にtoo longな解説

Sequence Read Archive (SRA) は大規模DNAシーケンス装置（いわゆるNGS）から得られたデータを登録する公共のレポジトリです。米国NCBI, 欧州EBI, 日本DDBJの3つの組織によって共同で運用しています。詳しくはこちら。

この度その3つのうちの1つ、米国が運用する NCBI SRA において、場合によって、ダウンロードする人がお金を払う必要があるケースが発生するようになる見込みです。このことについて、経緯と概要を説明します。

数年前より米国NIHは、ファンドしている研究プロジェクトで用いられる計算機インフラをクラウドに移行しようとしています。NIH配下のNCBIも、このとんでもなくでかいデータ量を誇るSRAを、一体どんなトリックを使ったのか、全てコマーシャルクラウド上に置くことにして、それが実行されました。ここでいうコマーシャルクラウドとは Amazon Web Service (AWS) と Google Cloud Platform (GCP) です。

コマーシャルクラウドは各社共通して、「クラウド上にデータをアップロードするのは無料」だけれども「クラウドの外にデータを持ち出すためには通信料を払う必要がある」のが特徴です(egress charge, イグレスチャージと呼ばれます)。GBあたりの従量課金制で、事業者によって、また月間のトータルの利用量によって単価が変わります（AWSの場合, GCPの場合）が、だいたい1GBあたり0.1USD前後です。クラウド事業者としては、自社クラウド内で計算機を借りてもらった方がビジネス上都合がいいわけですからね。ここで転送にかかる料金を払うのは「データを置いている人」もしくは「データを外に持っていく人」のどちらかになり、これはデータを置く人が決めます。

つまり、NCBIがSRAのデータをクラウドストレージに置くようになると、利用者がデータをクラウドの外にある、自身の管理するコンピュータにダウンロードする場合「誰かが」お金を払わなくてはいけません。そして、NCBIが利用者全員分の通信量を負担するとなると、とても維持できないので、利用者に負担してもらいます、ということだそうです。通信料を払いたくなければ、データ利用者がAWSないしGCPを使ってクラウド上に計算機を立ち上げ、そこにデータを引っ張ってくるようにしなければいけません。ただしクラウドと言っても、同じ事業者の、同じリージョン（クラウドのデータセンターをまとめる単位）でなければいけません。AWS N. virginia に置かれたSRAデータを転送料なしでダウンロードするには、同じ N. virginia リージョンにEC2インスタンス（仮想サーバ）を立ち上げて、そこにダウンロードして計算する必要があります。いずれにせよ、そうすると今度は計算機を立ち上げた分のお金がかかり、いずれにせよお金がかかります。まじかよ。

え、USの人たちはそれでいいわけ？と思うわけですが、先に述べたようにNIHでは米国内の研究者によるクラウド利用をプッシュしており、徐々にクラウドを利用する人が増えているそうです。今既に2割くらいはクラウドからSRAにアクセスしているという話でした。

これで話が終われば「公共データが有料になるとは何事か！」という話ですが、実はもうちょっと話は複雑です。

そもそも、なんでNIH以下合衆国の組織ががクラウドに移行しているのでしょう。まず、巨大なストレージシステムを自前の計算機環境でメンテナンスするのは非常にコストがかかります。大容量ストレージを構築する、ストレージ機器の故障をモニタリングする、ストレージが故障したときにすぐ対応する、そのための人員を確保して給料を払う、サーバルームの空調を含めて安定した電力を供給するための仕組みを作る、そして電気代を払う、万一故障したときや停電のとき、メンテナンスのときのためのバックアップを構築しておく、ストレージシステムへのアクセスのためのネットワークを整備する、ネットワークの故障に対応する、などなど。大規模な計算機システムのメンテナンスをまるごとアウトソースできるコマーシャルクラウドは、餅は餅屋という意味でも、大きなメリットがあります。金銭的なことだけでなく、メンテナンスのノウハウや、最新機器へのアップデート、適切な人員を見つけて雇用することなど、運用のためのコストは実際に払う金額以上になることは普通です。NGSデータがある日突然なくなることは考えられませんし、このまま増え続けるデータのためのシステムを自前で管理するには限界があります。なので、クラウドに移したい。GoogleとAmazonは米国を基盤とする企業なので、米国政府が運営するNIHとその傘下のNCBIが利用しようと考えるのは自然なことです。

しかし、クラウドにぽんと移せば巨大なデータを抱えるSRAの運用の問題が解決するかというと、そういうわけでもありません。INSDCは配列データを研究活動のエビデンスとして保持し続けなければなりませんが、とにかく大量のデータが出てくるので、できることなら使うストレージの量は節約したい。増え続けるデータをそのままストレージに入れ続けていたら、いくらクラウドと言えど、いずれ（容量的にあるいは経済的に）破綻してしまいます。そこで以前から議論されている2つのポイントが「hot/coldストレージの利用」と「クオリティ情報 (base quality score, BQS)の削除」です。それぞれ解説します。

hot/coldストレージ

「hotストレージ」、すなわちHDDやSSDで構成された、データをすぐに取り出せるストレージと、「coldストレージ」、すなわちデータの取り出しに時間がかかる代わりにHDD/SDDに対して容量あたりの価格を抑えられるテープストレージの2つを使い分けるやり方のことを指します。これはクラウドでなくてもオンプレの環境でも行われているテクニックです。つまり、大量に登録されたSRAのデータの中でも、頻繁に利用されるのはごく一部であり、それらをより高価だがすぐにデータを取り出せるhotストレージに置いておき、あまりアクセスされないデータをcoldストレージに置いてストレージ料金を節約するわけです。AWSの月額料金でいうと、hotストレージ（汎用S3）が0.021-0.023USD/GBなのに対して、coldストレージであるGlacier(グレイシアーと読みます、氷河という意味)では0.004USD/GBです。ちなみに、さらにアクセスが低頻度になり、より取り出しに時間がかかるオプションGlacier Deep Archiveというものもあって、こちらは0.00099USD/GBです。なので、運用側としてはなるべくデータをcoldストレージに置いておいてストレージ料金を抑えたいわけです。ただし、coldストレージはテープからの読み出しにお金がかかります。そこで、このシステムでは何をcoldに入れて、何をhotに入れるかという判断がストレージ料金の節約において重要です。

クオリティ情報 (base quality score, BQS)の削除

文字通り配列データからベースコール精度の情報をなくしてしまうということです。SRAに登録されるデータはFASTQもしくはBAMであり、フラットファイルであるFASTQは1塩基ごとにベースコール精度の情報を持ちます。最大94種類のASCIIで表されるBQSを削って配列だけにできれば、圧縮効率が上がってさらにストレージを節約できます。これまでに、BQSを完全に削除するのではなく、binningしてより少ない文字種で保持するアプローチもいくつか提案されていますが、「コミュニティでのコンセンサスは得られていない」とNCBI SRAのdata working groupは述べています(Wan et al, 2012, Ochoa et al, 2013, Janin et al, 2014, Yu et al, 2015)。また、NCBIではBQSの削除だけでなく、これまでにも行われてきたsratoolkitのアラインメント情報を利用してさらに配列データを圧縮する技術も、引き続き併用していくということです。

今回、hot/cold戦略とBQSの削除、この2つを組み合わせてストレージ料金と利便性のバランスを取るため、NCBI SRAは以下のような方針を立てました。

データは「オリジナル」と「SRA+BQS」と「SRA-BQS」の3種類のフォーマットで提供する

オリジナル: 登録者が送信したオリジナルのフォーマット。FASTQ, BAM, SFFなど

SRA+BQS: NCBIのsratoolkitでBQSを保持したまま圧縮する。利用者はsratoolkitを使ってFASTQやオリジナルなどのフォーマットに変換できる。インデックスを持つので一部のみ取り出しも可能。

SRA-BQS: 同じくsratoolkitで圧縮しているが、BQSは削除されている

ストレージはオンプレとクラウドの両方を使う

オンプレ: これまでと同じNCBIが運用するローカルのストレージ。ユーザはFTPでデータを取得する

クラウド: AWSとGCPのクラウドストレージ。クラウドの外にデータを持ち出す(ダウンロードする)ときにユーザは転送料を払う必要がある。同じリージョンのクラウド上で利用すれば転送料金はかからない

クラウドストレージでは、hot/coldの2種類のストレージを使う

各ストレージに、それぞれ異なるタイプのデータを置く

オンプレ

SRA+BQS (一部のみ: 登録から一定期間が経つと削除される)

SRA-BQS (登録された全てのデータ)

クラウド hotストレージ

SRA-BQS (登録された全てのデータ)

SRA+BQS (利用頻度が高いデータ, 全体の50%)

オリジナル　(1000genomes public datasetのみ、例外的に転送料は事業者持ち)

クラウド coldストレージ

SRA+BQS (利用頻度が高いデータ, 全体の50%)

オリジナル (1000genomes以外全部)

テープからの読み出し料金はNCBIが負担する

無限に負担はできないので、coldストレージからの読み出しはデータ量を制限する

図にするとこんな感じ。

複雑！

ところが事態をもっと複雑にするのは前述の通り SRAはNCBIのみによって運営されるに非ず ということです。はいここテストに出まーす。

NCBI, EBI, DDBJ 3つの組織はそれぞれが配列データの登録を受け付けます。3つのうち1つの窓口から登録されたデータは他の2つにもコピー（ミラー）されます。EBIから登録してもDDBJでダウンロードできるし、DDBJで登録してもNCBIからダウンロードできるし、以下省略。ただし、配列データの圧縮フォーマットに微妙な違いがありますし、タイムラグや組織間の移行に関して技術的なトラブルもあるので常に完璧にミラーされているわけではありません（ここが重要です）。常に100%完璧にミラーができていればいいのですが、無限に人員と資金があるわけではないので、優先順位を付けざるを得ないのが公共サービスを運用する上で難しいところです。

ではEBIとDDBJはどうするんだというと、これまで通りです。 EBIとDDBJはこれまで通りオンプレで運用します。 厳密なことを言うと、EBIはプライベートクラウド環境をインフラに構築しているのですが、コマーシャルクラウドと違って転送料もかかりませんし、利用者から見ると特に何も変わっていないように見えます。余談ですが、EBIのインフラはすごいです。10年かけて(!!)モダンな環境を構築し、データセンターの分散と同期を実現してディザスタリカバリまでできています。我らがDDBJも、資金、人員共に欧米と比較して厳しいリソースで運営していますが、自慢のスパコンシステムにどんどこストレージを増やして対応しています（技術的な問題等々でミラーリングが遅れてしまうこともありますが）。

つまりこういうことになります。

つまり、日本国内のオンプレ環境でSRAデータを利用するユーザ目線で、イグレスチャージ払いたくないぞ！となると、このような感じになります：

BQSが必要？

YES:

DDBJ/EBIに取りに行く。でもミラーリングのタイムラグで最新のものがすぐに取得できないかも。

NCBIのオンプレに取りに行く。登録されたばかりの最新のものしかない。

NO:

DDBJ/EBI/NCBIどこでもOK。

というわけで、考慮すべきは「BQS要るか要らないか」になるわけです。要るならDDBJ/EBIにちゃんとミラーリングされていないと困るし、要らないなら今回の変更は特に影響がない。マッピングやアラインメントでクオリティスコアを考慮するツールやアプリケーションは山程ありますし、RNA-SeqでBQS使ってリードの除去したりも当然するわけなんですが、「多少の精度は落ちるかもしれないけど、ディスクが節約できるメリットを考えたら無視できる」とするケースもあれば「でもBQSないと結果が信頼できない」とするケースもあると思います。

ただし、懸念すべき点はこの

タイムラグや組織間の移行に関して技術的なトラブルもあるので常に完璧にミラーされているわけではありません

という点です。NCBIからちゃんと全部さくさくミラーされていればいいんですが、オペレーションの問題、ネットワークの問題、技術的な問題、データが壊れていた、遺伝研スパコンがメンテで止まっている（メンテいつも長すぎるよね！）、などなどの理由でDDBJからダウンロードができなかった場合、まあEBIに行けばいいんですが、アジアからEBIに繋ぐとネットワーク的に遠くて遅いこともあるし、NCBIに取りに行ったほうが…というケースはままあります。そのときにBQSなくてもいいのか？という話になるわけです。

まとめ

……というような内容がこの Request for Information: Use of Cloud Resources and New File Formats for Sequence Read Archive Data に書いてあります。それを解説するのがこのブログエントリの主旨なのでした。EBI/DDBJの話までは書いてないですが。

個人的な意見を述べると、ストレージの空き領域とネットワークの帯域は何にも代えられないと思っているので、データ量が節約できるならBQSをばっさり落としてもよいと思っています。しかし、ChIP-Atlasのように底引き網方式でSRAのデータを解析している身としては、少なくとも「完全に失敗しているシーケンス」かどうかは見極められないと厳しいなと思います（そういうものがSRAには山程あります。詳しくはおれの力作を読んでくれ）。そういう意味では「SRAのデータ全部FASTQCかけるプロジェクト」ことQuantoの重要性が高まりそうなので、これを構造化したデータとしてメタデータの一部として簡単に取得できるよう改良したいと思っています。（それから、計算が最新の登録に全然追いついていないので、いかにタイムラグをなくすかということも考えていく必要があります）

また、この先もシーケンス装置の進歩は続いていくでしょうから、かつての Oxford Nanopore がそうであったように、リード数やリード長、キャプチャの技術や値段などは非常に優れているが、ベースコール精度を考慮しなければ使えない、という技術がまた出てきたときに、BQSがないとだめ、という状況になることはあるのかなと思います。

というわけで、みなさん是非、日頃SRAのデータを使って研究をする上で（してますよね？）、BQSは絶対にあったほうがいいのか、なくてもまあなんとかなるのか、「NCBIのBQS付きデータが全部クラウド上に行っちゃっても問題ないよ」「いやめっちゃ問題でしょ、DDBJにちゃんとミラーされることが保証されんの？」などなど、ちょっと考えてみてほしいのです。そして、NIHがこのプランについてパブリックコメントを募集していますので、意見を送ってみてください。7/17が〆切です。

Request for Information (RFI): Use of Cloud Resources and New File Formats for Sequence Read Archive Data https://datascience.nih.gov/sra-rfi-submission

RFIでは以下のような質問についての回答を求めています:

研究者がどのようにSRAと関わっているか

SRAデータと一緒に使っているパイプラインやツール

利用している配列データのフォーマット、特にBQSｃを必要とするかどうか

BQSを除去したSRAフォーマットデータの潜在的な利便性

BQSを除去しアラインメントとして保持されるSRAデータの潜在的なユースケース

登録者が送信したオリジナルフォーマットの研究における具体的な価値

SRAデータを利用しているユーザが、SRAデータがクラウドに置かれることによって、クラウドを利用するようになるかどうか

提案されているアプローチが、現在もしくはこの先の研究にどのように影響を与えるか

その他、クラウド上に置かれたSRAデータの価値を最大化するためにNIHが考慮すべきトピック

意見送るの面倒くさいけどBQSいるやろ、あるいはいらんやろという意思を表明したい方は僕宛にtwitterで@を送ってください。代わりにとりまとめて送っときます。

Acknowledgement

DDBJでDRAをリードしてくださっており、いつも大変お世話になっているDDBJデータベース部門コーディネータの児玉さんにこの記事をレビューしてもらいました。どうもありがとうございます。塩基配列データが欧米だけでなく日本にもちゃんとミラーされており、それを30年に渡り維持し、日々運用してくださっているDDBJの人たちがいて、それを使うのに最高な桃月なしこちゃんこと遺伝研スパコンをメンテしてくださる人たちがいて、こんなに恵まれている国で研究開発ができることに感謝して、このエントリを締めたいと思います。

追記: SRA Toolkit の使い勝手はどうなるのか

SRAをこれまで使っている人であれば、SRAからデータをダウンロードするのに sratoolkit を使っているかもしれません。sratoolkitはNCBIのtechチームによって開発されている配列データをsraフォーマットで圧縮/展開するためのツールです。このツールをインストールするとバンドルされている prefetch というコマンドを使ってダウンロードするか、 fastq-dump というコマンドにアクセッション番号を入力として与えて実行し、該当するデータのFASTQデータを手に入れるというのが一般的なやり方になるかと思います。

sratoolkitのwiki によると、2019-08-19にリリースされた 2.10.0 から既にクラウド対応が実装されており vdb-config コマンドでクラウドアカウントのcredential(認証情報)を設定しなければダウンロードできないとなっています。実際に2.10系のsratoolkitをインストールし、起動すると vdb-config --interactive を実行せよと怒られます。ここで AWS や GCP という設定があり、ここにイグレスチャージを支払うかどうかを設定することができるようです（試してないので実際に設定した場合の挙動はわからない）。

vdb-config --interactive を実行するとこんなんが出てきまして、ハイライトされている文字のキーを押すと切り替えられる。AをタイプするとAWSの設定になります。

上記の方針に移行するのは今夏以降と聞いています。実際のところ、この記事を書いている2020-06-10現在では、"accept charges"をチェックしなくても、たとえば DRR000001 (納豆菌ゲノム)のデータはチャージなしでBQS付きのデータがダウンロードできます。

ところで最新のSRAtoolkitはこの vdb-config --interactive を 手動で 実行しないとツールが実行できないようになっています。自動的に使うようにすると 競合状態が発生する可能性があるため、と説明されていますが、コマンドライン上でnon-interactiveに設定できないのは明らかなソフトウェア設計上のミスといえるでしょう。チームもこれを認識はしているようで、対応予定だとしていますが、現時点(2020-06-10)ではまだ対応されておらず、全世界の人がみな手動でポチポチ対応している模様。90年代かよ。「Dockerコンテナを作って配ろうとしてるけど、コンテナとかやったことなくて慣れてなくてね」とそんな誰も信じないことを言われても。アップデートが来るまでは2.9系を使いましょう。

SRAtoolkitのアップデートはめんどくさいので僕は以前よりDockerコンテナ作ってたんですが、このような理由で今はインタラクティブシェルでしか動かないんですけれども、よろしければぜひ→ github.com/inutano/docker-sra-toolkit, quay.io/inutano/sra-toolkit:v2.10.7

ちなみに、fastq-dump が遅いというかねてよりのクレームを受けてNCBIのチームは fasterq-dump というより高速でfastq変換に特化したツールを作っております。まだ fastq-dump を使っている方は是非アップデートしてくださいね。遅すぎるfastq-dumpに業を煮やしてかつて実装した pfastq-dump というラッパーツール もあるんですが、大きなファイルになると fasterq-dump の方が速いかもしれません（小さいファイルだとそんなに変わらない: 600MBの DRR000001.sra を共に30秒ほどで4000万リードのペアエンドFASTQに展開）。ディスクI/Oが顕著に効くので、圧縮と展開は速いディスクの上でやりましょう。遺伝研スパコンだと計算ノードの /data1 にSSDが刺さっているのでそこで作業すると爆速です。

[trattoriainutano]

COVID19 Virtual BioHackathon 2020 をやった

しばらくブログを書いていなかったんですが COVID19 Virtual BioHackathon 2020 というイベントをやりまして、色々と思うところがあったのでブログを書くことにしました。フォーマルな記事を NBDC Blog に寄稿しているので、こちらは裏話です。将来、ああそういえばそんなことあったな、と個人的に振り返るために書いており、客観性を全く考えていませんのでご了承ください。

そもそも BioHackathon (BH) というイベントがあります。Biological science, medical science に携わる開発者たちが一週間ホテルで缶詰になって、一緒にコードを書き、一緒に議論をし、一緒に遊んで、一緒にメシを食って、一緒に風呂に入って、一緒に酒や酒ではない飲み物を飲んだりする、最高の会であります。もう10年以上もやっているので、過去にBHに参加した開発者や研究者はオンラインで繋がっていて、ゆるいコミュニティみたいなものができています。このハッカソンはとても捗るということで毎年来る人もいます。10年もそんなことをやっているとコミュニティというよりはファミリーと呼ぶ方がしっくりきます。とはいえ、オープンデータ・オープンソースを標榜する人が皆そうであるように、誰でもウェルカムでフレンドリーなコミュニティで、毎年新しい人がやってきては溶け込んでいます。増え続けて大家族。おかげで世界中どこのカンファレンスに行っても、関連するトピックのセッションに行けば、必ず誰か友達がいるという状況ができています。極東を拠点にしている身にとっては、他の国に出かけていくのはそれなりに大変なことなので、これはとても有り難いことです。

で、COVID19が蔓延して欧州各国でロックダウンが実施されはじめた2020年3月に、BH常連の一人であるピョーが「COVID19で家から出られんしVirtual BioHackathonやろうぜ」と言い出した。BioHackathonはデータの共有やDBの標準化がメインテーマであって、特定の生命現象に関する研究を深堀りするタイプのコミュニティではありません。なので、この状況に対してどう貢献できるのかというと、実際のところ今ひとつはっきりしませんでした。だけれども、「ある特定のテーマに絞って」「オンラインだけで」「一週間ぶっ通しのBioHackathonフォーマットで」ハッカソンをやるというのは面白そうに思えました。で、世界規模かつオンラインでやるなら、各タイムゾーンにオーガナイザーがいた方がいいんじゃない？アジア担当いないなら手伝おうか？と軽い気持ちでピョーに返事をしたわけです。で、米国にいるピョー、欧州にいるレイラ、そしてアジアにいる僕の三人がメインオーガナイザーを務めることになりました。その時には、まあ集まっても30人くらいだろう、みんなでなにかしらのアウトプットが作れるといいね、くらいの軽い気持ちでおりました。その見込みが甘かった。あれよあれよと参加者が増え、最終的には色々の国、ほぼ全てのタイムゾーンから、合計500人を超える参加者が。ちなみに普段の物理BHは頑張って集まってせいぜい120人くらいです。

なんでそんなに集まったのか。

いくつか思い当たるところがある。まずみんなヒマで、だけれども不安だったのだろう。ただヒマなだけだったらハッカソンやろうぜとはならない。ヒマで、かつ、これからどうなるのかわからない、何かしていないではいられない、という心情があったのではなかろうか。手を動かすハッカソンはある種のセラピーとしてうってつけだったのかもしれない。無心でコードを書いているときの心境はパンを捏ねているときのそれに似ている。

それから「自分にも何かできることがあるはずだ、この事態に対して何か貢献しなければ」という感情がある。正義か、道徳か、文化的背景も皆違うので人それぞれオリジンは違うのかもしれないが、いずれにせよ、高いモチベーションを持った人が多かった。COVID19が引き起こした状況は、自分のことだけでなく全員のことを考えろ、ということを強いたことも関係しているだろう。"Do the right thing"が合言葉だから、「自分ができる正しいこと」を皆が考えたのだと思う。自分は「余計なことして医療従事者の迷惑にならないように大人しく家でパンでも捏ねてますね」と思うタイプだけれども、とはいえ「何かしないではいられない」という人の気持ちも理解できる。「自分がヒーローにならねば」と思う人だっていただろうし、「少しでも役に立てるならなんだってする」と思う人だっていただろう。この事態を解決するにあたって、個々人がそのように高いモチベーションに衝き動かされてその勢いのまま行動することが全て正しいのかどうかはわからないが、そう思うこと自体が悪いことだとも思わない。だからといって慎重さを欠いたアイディアをプレプリントサーバに投稿し喧伝するのはプロとして称賛されるべきムーヴではないと思うけれども。

参加者の心情以外の要因もあるだろう。今回、告知から開催まで2週間くらいの間があった。そのタイミングもまた絶妙だったと思う。開催した4月第二週までの2週間は、次々にバッドニュースが舞い込んで、ああこれは、おれたちは歴史に残る事件の渦中にいるんだなと思い知らされる時期だった。「今が一番悪い時期であってほしい、ここから好転してほしい」という思いは、毎日更新される数字や統計によって、容赦なく裏切られた。「これはもうラッパが鳴ったんじゃなかろうか」と半ば諦めたくなるほどだった。日に日に増幅する不安、裏切られ続ける期待、しかし何もできない無力さと、ヒマさ。時間はあるのに何をしたらいいのかわからない。これが世界で同時に起きて、その結果としてハッカソンにこれほどの人が集まったのだろう。

開催の直前、欧州は大変なことになっていた。自分はその当時、特に酷かったイタリアにいる友人たちが心配で、ニュースを見ては凄まじい状況に絶句するということを繰り返していたので、牧歌的な日本の状況とのギャップに混乱することが多かった。日本もこんなふうになってしまうんだろうか、でも人々は能天気で止める術はなさそうだし、諦めて受け入れるしかないのか、と思っていたところ、何故かそこまで酷い状況にならないまま五月の連休が終わり、誰もその理由がわからないまま何故か感染規模は縮小し、緊急事態宣言は解除され、日本は通常運転に戻りつつあり、今日からもう6月である。

ともあれ。多くの人間が集まって、一週間ハードに仕事をした。事前にプロジェクトを募り、各々がどれかのプロジェクトに自由に参加するBH形式で、自分は workflow と ontology と public sequence server のプロジェクトを主に手伝っていた。

workflow チームではCOVID19関連のワークフローを標準記述形式に変換する試みで、Galaxy, Nextflow, WDL, CWL など違う言語とフレームワークを扱うメンバーが、それぞれの得意な言語で整備をするという、ある種珍しい光景が見られた。別に言語間で仲が悪いわけでもなんでもないのだが、思想が違うので、普段は一緒に飲むことはあっても一緒に仕事をすることはあまりなかったので、今回はちょっと新鮮だった。それぞれの言語のチームの議論や開発スタイルが全部見えたわけではないが、アウトプットから見える「何を大事にするのか」という感覚が少しわかったような気がする。この言語化はまた別の機会にしたい。自分はいくつかのワークフローをコンテナにパッケージング、あるいはCWL化するのを手伝って、作った workflow は public sequence server に搭載される。

ontology チームでの仕事は public sequence server で利用するCOVID19シーケンスデータのサンプルメタデータの記述に用いるオントロジーの選定である。これはレビューを手伝ったくらいであまり手を動かしてはいないのだが、普段BioSampleで鍛えられたおかげで「お前が思っているほどデータ登録者は賢くないぞ」の札を何度か挙げてメンバーの皆に渋い顔をされた。

public sequence server は、その名の通りCOVID19の配列データをアップロードするサーバを作るというプロジェクトである。現状、COVID19の配列データは新型インフルエンザのアウトブレイク時に構築されたプラットフォームGISAIDを用いて共有されているが、これが「データにアクセスするためには登録が必要」「登録すれば誰でもダウンロードできるわけではない（＝ユーザごとにアクセス権限が異なる）上にその基準が不透明」「アクセス権限を申請するとかなり時間がかかる（＝自動ではない、人手で何かしらのフィルタが行われいる可能性がある）」という問題があり、これがデータにアクセスすることを妨げている。「誰でもデータを触れると、データを登録した人が一方的に損だ」という思想が背後にあるらしいというのは聞いた話なので真実はわからないが、もしそうなのだとすればそれは石器時代のデータ共有である。我々がすべきは「誰でもデータにアクセスが可能であり、自由に使うことができるが、データを使った場合は須らくデータを出した人に対するリスペクトと共にciteし、データを出した人が評価されるようにしなければならない、そして研究活動をレビューする人間はその点を厳しくチェックしなければならない」というのが現代のスタンダードである。GISAIDの思想の真意はわからないが、少なくともこの思想に従ってプラットフォームが実装されているようには見えない。NCBI Genbank/EBI ENA/DDBJ連合たるINSDCに登録してくれれば済む話なのだが、何故かそれができない事情を持っている国や組織があるということで、では「データを登録した人にご利益を与えるサーバ」を拵えるのがよかろう、というのが public sequence server の趣旨である。具体的には、メタデータを記述し、COVID19の配列データをアップロードすると、サーバで複数の解析ワークフローが実行され、これまでに登録された配列データと合わせた解析結果が取得できる。目玉としては、最近話題になっている Variation Graph (VG) を使った解析ワークフローもそこに含まれている。現在プレビュー版が公開されており、近々正式リリースされる（はず）。

一番印象に残っているのは Workflow チームのメンバーが日本/欧州/米国東海岸/米国西海岸の4交代制でワークフローの構築をやったことである。凄まじい進捗のスピードであった。世界各地の実力派たちと一緒にモノを作るのはプレッシャーもあったが最高に楽しかった。

しかしハッカソンの語源はマラソンのはずだったのにこれでは駅伝である。金曜には疲労困憊だったし、とても日常的にやれる気はしないが、しかしこれをずっとこなしていると人は進捗お化けになるのかもしれない。

参加者には過去にBHに参加したことがない人も多かった。Twitterで告知を見て参加したらしい。なんだかんだ一緒に仕事をしたのはこれまでのBHで一緒に作業をした友人たちが多かったのが、ちょっと残念だった。自分にとってのBioHackathonの楽しみのひとつは、新しい友人が増えること、色々なバックグランドの彼ら彼女らと一緒に楽しく仕事ができることだ。対面だと仲良くなるのも早いのだけれど、オンラインだとそうもいかないというのが今回の学びである。テキストベースのコミュニケーションがメインだと、初めましての相手とのやり取りは無難になってしまいがちなのだ。ただでさえナイーブな時期なので、下手くそな冗談を言って不快にさせたりしたくもない。実際、vBHが始まる前には参加者同士のミスコミュニケーションによるトラブルもあった。これが対面だと、どこまでぶっこんでいいか、をちゃんと見極められるのだけれども。そもそもぶっこんでいくなという話もあるのだが、場を和ませる冗談ですらオンラインだと迂闊に言いづらい。"こいつは同類だな" という感覚はオンラインでも分かるのだけれども、そこで突っ込んでいって仲良くなれるかというとやはり少し障壁がある。そんなような気がする。

ハッカソンに限らず、初めましての相手とのやりとりはオンラインコミュニケーションの課題だと思う。そういう意味で、今後行われるface-to-faceのカンファレンスは、オンラインコミュニケーションを補完するための物理的接触の機会となる可能性はありそう。

限られたメンバーとだけ仕事をするスタイルならそんなに問題にならないかもしれないが、色々のところに出かけていっては話をして、一緒に問題を見つけて一緒に解決して、というスタイルでやっていると、普段はオンラインでも問題ないのだけれども、全く出かけないというのはなかなか厳しいなと思う。もちろんこれが万人に当てはまるとも思わない。自分がそうだというだけだ。自分は同じテーブルでメシを食って話をすることで相手の微妙な性格を知って、それでスムーズなコミュニケーションのプロトコルを探し当てるようなことを今まで無意識にしていたんだろうなと思う。「この人はこう言ったほうが伝わる」とかそういうのを無意識に見ている。別にその機微がわからないでももちろん一緒に仕事はできるのだ。OSSコミュニティなんか会ったことのない人の方が当然ながら多い。だけれども、それがわかるとよりスムーズにコミュニケーションができて、結果パフォーマンスが上がるのが不思議なところだ。

既に5000字を超えてしまってこのままだといつまで経っても投稿できない気がしてきたのでまずはここまで。パート2に続く。

[trattoriainutano]

CWL-metrics とは

この記事は Common Workflow Language (CWL) Advent Calendar 2018 の12日目の記事です。

Docker や Singularity などのコンテナによってツールのポータビリティが向上し、CWL などのワークフロー言語によって解析環境のポータビリティが向上しました。これによってツールのインストールにハマって stackoverflow を延々と彷徨ったり、ワークフローを走らせようとして前に実行したときの引数がわからなくて焦って .bash_history を延々遡ったり、結果ファイルを共同研究者に渡したあとで使ったツールのバージョンが前回と違うことに気付いて青ざめたり、そういうことがなくなりました。

「同じものがどこでも動く」という安心感は、クラウドという新たな選択肢を与えてくれました。クラウドなら、人間を計算機のメンテナンス作業からも解放してくれます。建物が停電で止まるのでマシンの電源を落とすとか、落雷に備えてUPSを常に管理するとか、共有ディスクが一杯になって死ぬとか、学会の締切前に同僚の間でCPUを奪い合ったりとか、そんな不毛なことはもうしなくていいのです。

必要なときに必要なだけクラウドで計算機を借りて、いつもと同じパイプラインをコマンド一発で走らせる、というのがモダンなデータサイエンスです。データが巨大だとストレージやネットワークの代金が高すぎるという問題もあるのでなんでもかんでもクラウドというわけにはいきませんが、それでも随分と敷居が下がった感があります。しかし、そうすると新たな問題が出てきます。それは、どれくらい大きい計算機を借りないといけないのか、という問題です。

Amazon Web Service でも、Microsoft Azure でも、Google Computing Cloud でも、ユーザは必要に応じてコア数の多いインスタンスや、メモリ量の多いインスタンス、ネットワーク最適化インスタンス、高速ストレージの付属するインスタンス、などなど色々の種類のインスタンス（計算機ユニット）を使うことができます。しかし当然ながらハイパフォーマンスのインスタンスは時間あたりの料金が高い。データ解析は終わったらポイの一時的に借りるだけなので、必要な分だけ借りられるのがよいです。じゃあ、そのワークフロー、どこで走らせるのがいいの？どれくらい並列化するといいの？どれくらいメモリ量がいるの？

そんなあなたの悩みを解決してくれるのが CWL-metrics です。

CWL-metricsは、cwltool で実行されるCWLのワークフローの要求資源量、すなわちどれくらいのメモリ量を消費し、どれくらいのCPUを使い、ディスク書き込みがどれくらい発生し、というような情報をさくっと簡単に集めて分析するためのツールです。内部では Docker daemon から消費リソース量を取得し、cwltoolのログを解析してワークフローに与えられる引数の情報などを統合しています。

CWL-metrics はサマリーを tsv, json などで出力するので、たとえば ggplot2 なんかを使うとこんな感じの図がさくっと描けます。詳しくは最近出たばかりの論文をどうぞ。

Tazro Ohta, Tomoya Tanjo, Osamu Ogasawara, Accumulating computational resource usage of genomic data analysis workflow to optimize cloud computing instance selection, GigaScience, Volume 8, Issue 4, April 2019, giz052, https://doi.org/10.1093/gigascience/giz052

この論文で一番頑張ったので、使ったあらゆるマテリアルを全て適切なライセンスで公開し、誰でも同じことを（わりと）簡単に実行できるようにしたことです。使ったスクリプト群はもちろん、Jupyter notebook も公開していますし、ログやデータも全部 zenodo で公開しました。これらはジャーナルの運用するデータ公開レポジトリ GigaDB でも公開されています。

[trattoriainutano]

CWL workshop で僕らが学んだこと

この記事は Common Workflow Language (CWL) Advent Calendar 2018 の6日目の記事です。

世界的な CWL の盛り上がりに乗り遅れるな！ということで、日本で初めてのCWLのワークショップを開催しました。Co-founder である Michael Crusoe さん をお招きして、CWL とは何か？という紹介からライブ・コーディングによるCWLの書き方まで、濃い半年となりました。直近になってからの開催だったため、会場探しが難航してしまったのですが、快く会場をお貸し頂いた DeNA ライフサイエンス社 久保さんに改めて感謝申し上げます。

会のスケジュールは こちら。

トークは録画しており、統合TV で公開しているので下にリンクを貼っておきます。Michaelの初心者向けCWL入門, 情報研丹生さんによる開発者向けハードコアCWL仕様解説、そして私めによるオレオレ便利ツールの紹介と脈絡のない構成ではありましたが、自由でウェルカムなコミュニティの雰囲気は伝わったのではないでしょうか（伝わっていてほしい）。

当然ながらCWLは完璧で唯一のソリューションではないですが、コミュニティ発のオープンソースプロジェクトということで、誰でも意見を言えて、誰でも変更の提案ができるのがいいところです。GitHub の issue や Gitter では毎日色々の議論がされています。

商用のソフトウェアと違って、「こうしてほしい」に誰かがすぐ対応してくれるということはないですが、その代わり「こうすべきだ」というアイディアを議論し、実装できるのがOSSのいいところだと思います。今はユーザの数が急増しているタイミングなので、議論と実装も滞りがちではありますが。

Introduction to Common Workflow Language

How to develop a workflow engine to run CWL workflows

CWL-metrics: CWL workflow runtime metrics analysis

[trattoriainutano]

メリーギャラクシークリスマス

この記事は、Galaxy Advent Calendar の 25 日目の記事です。

メリークリスマス！みなさん、楽しいホリデーシーズンをお過ごしですか。

元はとある企業による販促のための広告戦略であり、さらにその前はとある宗教が征服した土地の祭事を滅ぼすためにでっちあげたイベントであると言われていますが、「対価なく欲しいものがもらえる」というイベントを喜んで受け入れない理由はありません。 メリークリスマス！ しかしながら当然のことですが対価なく何かを貰えるなんてことはこの世において一切ないということを承知することが求められます。あなたがプレゼントをもらったとき、その代償を誰かが支払っているのです。逆に言えば、あなたが何かタフな仕事をしたときには、きっとどこかの誰かが報われているのです。そう信じなくてはやっていけないのもまたこの世の中です。

さて、この Galaxy Advent Calendar では、Galaxyを使って研究を円滑に進めるために役に立つtipsなどが紹介されてきましたが、そういった「こうすればうまくいくよ」という技術情報の蓄積が有難がられる程度にはGalaxyを高度に使いこなすのは簡単なことではありません。時には大変なこともあるでしょう。経験が浅いと「このエラーは何が原因でどうすれば治るのか分からない」なんて場面に遭遇することもあるかもしれません。エラーの原因を自分で考えて、入力を変えたりツールを変えたり環境を変えたりして試して、それでも分からなくてウェブで調べて、それっぽい事例を見つけて自分の環境で試して、でもうまくいかなくて、誰か助けてくれと他のGalaxyユーザを頼ったら「どっかで見た気がするなー」とだけ返されて、一緒になって悩み、喜び、泣き、笑い、いつしか問題が解決して、あるいは解決しないから自分でツール作って。それがGalaxyを使うことであり、コンピュータを用いてデータを解析するということであり、有象無象の生命科学データから新たな知識を得るということなのです。時間がかかることもあるでしょう。マシンの前でモニターを見つめてドライアイになったり肩こりが酷くなったりします。魂を削られることもあるかもしれません。それらは大きな代償です。とても大きな代償です！ですが、あなたが代償を払うとき、誰かが報われています。 そうです、プレゼントを受け取っているのです！ そしてプレゼントとは論文です。

「専門家によるレビューを受けてコミュニティに信頼される媒体上で成果を発表する」ことが知識を得るための科学の方法であるならば、論文を出すことはそれに最も近い形態を成すもののひとつであり、あなたがGalaxyで、あるいはGalaxyでない何かでデータを解析して、その過程で代償を払ったとき、誰かが報われることが予期されます。つまり論文が出ます。報われる誰かが代償を払った誰かと必ずしも一致しないというのがアカデミアのアカデミアたる所以であり恐ろしいところですが、つらいデバッグの作業の間ずっと「俺はただ日々を穏やかに過ごしたいだけなのに…俺がこんなことをしてどうなるというのだ…これに何の意味があるんだ…人生とは…人間とは…我々はどこから来たのか…我々はどこへ向かうのか…」という気持ちになったときに未来への希望が欲しい。そこで Galaxy を使って解析を行った論文を探してみることにしました。

Galaxy Project に論文リストへのリンクがあります。かつては citeulike で纏められていましたが今は Zotero というサービスでまとめられています。実際のところこの記事を書き始めたときは citeulike を紹介するつもりでしたがいつの間にか変わっていて今とても驚いている。ここでまとめられているのは　Galaxy　を使った、拡張した、あるいは実装したなどのあらゆる形で Galaxy Project に関わった論文、Conference proceedings, 学位論文、書籍などです。トータルで5,300のアイテムが登録されています。5,300件全てが学術論文というわけではないけれども、でもまあそれくらいだということです。なお Citing Galaxy のページを見ると、Galaxyそのものの論文で最も古いのが Galaxy: a platform for interactive large-scale genome analysis で、2005年です。2005年ですよ。12年前です。10年以上前に作られたソフトウェアで今なおメンテされ現役バリバリで使えるものってそうないですよ。すごくないですか。で、2005年から12年で5,300件。年間約440件の発表があるということです。凄い数字ですね。それで、2005年の論文は以下のような書き出しで始まっています。

Accessing and analyzing the exponentially expanding genomic sequence and functional data pose a challenge for biomedical researchers.

今でも同じような文句を論文の冒頭に書きがちですよね？これ、12年前ですよ。454やGAIIxがまともに使えるようになったのが2007年ごろのことと思いますが、それよりも前です。きっと10年後もこんな感じなんでしょう。

なおその論文ではこの後、色々のデータリソースに対してクエリを投げて、それらを統合して可視化する、というシステムの概要と、その本質である履歴管理について述べられています。リソースの統合は現在のRDF統合にも通じるものがありますが（この頃はSADIとか言っていたはず）、ウェブ上に分散したリソースを惑星に見立てて Galaxy という名前になったのでしょう、たぶん。今ではデータが一箇所に集中し動かないのであまりデータ解析の過程でGalaxy感を感じることはなくなりましたが。他にも Galaxy Project の昔の論文を追っかけるのは楽しいです。特にabstractの書き出し。

While most experimental biologists know where to download genomic data, few have a concrete plan on how to analyze it.

Using galaxy to perform large-scale interactive data analyses (2007) のこれとか、

Increased reliance on computational approaches in the life sciences has revealed grave concerns about how accessible and reproducible computation-reliant results truly are.

Galaxy: a comprehensive approach for supporting accessible, reproducible, and transparent computational research in the life sciences (2010) のこれとか。

他にも沢山ありますが、どれも今より前に書かれたものには時代の流れを感じます。スムーズで信頼できるデータ解析を実現するためにその時々の人々がどう考えていたかということが窺い知れますね。いつかこういった書き出しをする必要のないスマートな生命科学が営まれる日が来るのかもしれません。しかし、その日が来るまでには多くの人の努力と正義感と自己犠牲を今以上に積み上げる必要があるのです。

[trattoriainutano]

Galaxy とはなんであるべきなのか

この記事は Galaxy Advent Calendar 2017 の 10日目の記事です。

Galaxy とはなんなのか、どう使うのか、と聞かれたり、聞かれてないのに話したりしてきました。このアドベントカレンダーでも、何ができるとか、こういうことをするならこうやるとか、そういう話がたくさん書いてあるので、参考になります。しかし、「Galaxyってなに？」に対する最も明快な答えは「黒い画面（ターミナル）のようなどうやって使っていいかわからないものではなくて、Microsoft Excelみたいに簡単に使える解析のソフトウェアはないのかね」というコンピュータアレルギーの生物学者からの理不尽な要求に対して先人が答えた結果であります。

同じ問いに対して「コンピュータの扱いを勉強する気がないならそのまま分野ごと滅べ」と返す過激派や、「じゃあ代わりにやってあげますよ」と全てを受け入れる穏健派、「これを使えばできますよ！ただしお値段XXX万円」とニコニコするベンダーの方々とは違い、「ブラウザ操作だけで使えます！オープンソースなんでタダです！」と返したジェームズたちを本当に尊敬しています。それをさらに10年以上も続けているんだから頭が上がりません。

しかし当然のことながら、Galaxyが全ての生命科学系のデータ解析の問題に対して万能であるかというともちろんそんなことはありません。何事も適材適所です。では2017年の今、Galaxyが最も輝くのはどこか、Galaxyは誰にとっての何であるべきか、ということについて考えます。

そのためにはまず、Galaxyが他と比較してどのような特徴をもっているかを把握する必要があります。以下に Galaxy のポジティブな点を挙げてみます。

ブラウザベースのソフトウェアである

コマンド操作なくブラウザの操作だけでデータの解析が完結する

GUIを持つソフトウェアでは数少ないオープンソースのソフトウェアである

無償で利用できる

Public server を利用すればデプロイも必要ない

Toolshed を使ってツールをインストールできる

AppStore のような仕組みで、ツール・パッケージを利用できる

一度定型のワークフローを作ってしまえば繰り返しの実行が容易

実行履歴の管理に優れている

解析手順の履歴管理や共有に優れたインターフェースを持っている

ドキュメントが充実している

トレーニングのための動画なども多い

ユーザコミュニティが活発である

では Galaxy のネガティブな面も以下に挙げます。

インフラの知識がないとセットアップが難しい

特に大規模なサーバにジョブを分散したい場合など

Toolshed にないツールをインストールするのにプログラミングの知識が必要

ツールのパッケージングには一手間かかる

ピタゴラプロジェクト では主に上に挙げたネガティブな面のセットアップを簡単にするための技術開発などをオープンソースで進めています。ともあれ、このような pros/cons を持つソフトウェアの利用シーンとして最適なのはどのような場面でしょうか。

予め Galaxy のセットアップが完了しており、運用に気を遣わなくてよい

データ量やツールのセットに制限がある Public Server でも問題がない場合

Galaxy の面倒を見てくれる人がいる/雇える場合

自分でなんとかできそうな場合

比較的「枯れた」 or メジャーなツールの利用で目的が達成できる

bioRxivに出たばかりのツールのベンチマークなどはやらない

既報論文のワークフローに従えば目的が達成できそうな場合

Toolshed に使いたいツールがある

共同で作業する人との共有を円滑にしたい

作業に加わる人のスキルセットに差がある

e.g. プログラムめっちゃ書ける人とそうでない人が混在

こんな具合でしょうか。逆に向いてない場面はというと

1人でしか作業しないし自分はスクリプトを組む程度のプログラムは書ける

履歴管理は魅力的だけれどパッケージングや運用コストが上回ると思われる

Toolshed にないツールもたくさん使いたい

ツール単位のベンチマークやお試しならコマンドラインでやった方がお手軽

GUIが憎い

はいはい

Galaxy について勉強するのも面倒

たくさん研究費取って然るべき人を雇ってください

このような特徴を踏まえた上で、個人的に Galaxy を使うことを強くおすすめするのは以下のような場面です。

Case 1. 解析の依頼が殺到して困っている人

プログラミングスキル、マシンのセットアップなど自分でできるが、ラボ内や共同研究者からやたら「これやって」「これもやって」「ここちょっと変えて」「このデータの中間データ見たい」「これプロットしてみて」などのリクエストが大量にやってきて辟易している人。

Galaxy の公共サーバを使う、あるいはサーバを建てて、ワークフローを作って共有、最初に「こうやってデータをアップして流せば途中経過含めて全部見れるよ、パラメータ変えたいときは途中でこうするとよいよ」とレクチャーするとよいです。ゲノムブラウザでの可視化、テーブル形式までの変換からプロットを描くことまでできます。Jupyter notebook連携で統計解析、可視化をするにはちょっとテクニックが必要ですが、それでもprocessingの部分を相手に任せられるのは案件によってはかなり時間を稼げるはずです。同様に、自分の作った手法を同僚や共同研究者に試してもらいたい場合などにも有効ではないでしょうか。

Case 2. 短期間でデータ解析の流れを覚えて実践したい人

プログラミングのスキルはないが、対象とするデータ、解析の目的がある、しかしプログラミングを覚えるのに数ヶ月の時間を使えない場合があります。例として、別ラボに短期滞在する場合や、就職が決まっている学生の卒業研究などが挙げられます。このような場合に、指導者が教える、あるいは公式のトレーニングマテリアルを参考にして勉強し、Galaxy上でデータ解析のワークフローを構築することで、データ解析の基本や流れ、データ形式やツールについて学ぶ、さらに実行し結果を出すことができます。

一度 Galaxy 上でデータ解析を行えば、基本の流れやツールについての知識も身につくため、その後コマンドラインでの解析、プログラミングの学習を始める際にも役立つのではないかと思います。

Case 3. ラボで行う解析が定型化しており、かつ年中解析するぐらいサンプルがある場合

スキルのあるバイオインフォの人間もいるし、Linuxマシンもあるが、敢えて Galaxy を使う理由がある場合があります。それは「頻繁にパイプラインの内容を変更しない」「しかし大量に実行する必要がある」場合に、履歴の管理と共有のために Galaxy を使うという選択です。コホート研究や公共データの大規模な再解析など、解析の履歴をトラッキングできるようにしておくのが重要な場合には、将来的にインフォマティクスのスキルがない人が関与した場合でも、Galaxyならそれが容易です。コマンドラインで実行する場合だと、かなり気を遣わなければ実行履歴などの体系だった管理は難しいですし、ましてそれを記録した本人以外が見られるように整えるというコストはなかなかのものです。そうであれば、Galaxyのようなシステムを採用することは、初期の導入コストを考えてもリーズナブルになり得ます。

もちろんこの3つ以外にも Galaxy がフィットする場合はありますが、研究室での実践という視点から考えると代表的なのはこのようなものかなと思っています。Galaxyのネガティブな面、自前のサーバでのセットアップやバージョン管理の大変さ、ツールの新規導入やアップデートの大変さなどはだんだん改善されているので、より広い利用シーンが見られるようになるといいなと思っています。

[trattoriainutano]

データ解析が再現するということ、あるいは Common Workflow Language が僕らにもたらしてくれるもの

データ解析の再現性とはなにか

「入力として与えられたデジタルデータに対して、データの変形、データ型の変換、異なるデータの統合、統計手法の適用などの作業を行い、目的とする情報を得る一連の手順」のことを「データ解析」と称した場合に、「データ解析が再現する」とはどういうことかについて考えたい。

主に科学研究の文脈において「公表された研究を別のグループが追試したところ同じ結論が得られない」ケースが少なくないことから、"Reproducibility Crisis"として科学研究の再現性の問題が指摘されている[1]。ここで注意したいのは、ある研究結果が "Repruducible" であるとされるための要件である。Chris Drummond によれば reproducibility は replicability と混同されがちであるが、両者は異なる概念であり、明確に区別する必要があるとされる[2]。どちらも日本語では「再現性」と翻訳することができるが、replicability が「オリジナルと完全に同一の手順」から「同一の結論を導く」ことを示すのに対し、reproducibility は「オリジナルの手順に従って」「同一の結論を導く」、すなわち作業者や作業環境が異なることで、手順の厳密な正確性が失われた場合でも、同じ結論が得られることを示す概念であるとされている。前述の "Reproducibile Crisis" の文脈で話されているのは、「発表された論文に記載されたとおりに、発表者とは異なる人間が異なる環境でオリジナルの手順に従った場合に、同一の結論が導かれなかった」というケースについてである。

また類似した概念であるが「オリジナルと完全に同一の手順を繰り返すことができる」、すなわち作業者、作業環境も完全に同一である repeatability もこれらと混同されがちであるが明確に異なるものとされる。Carole Goble による ISMB/ECCB 2013 Keynote のスライドでは以下のような図で説明されている。

このような「再現性」という言葉の持つ曖昧さを了解した上で、昨今話題になる「データ解析の再現性」とは何かを考えると、まず最も違和感がないのは "Repeatable data analysis" である。書捨てのワンライナーや、手順を記録しないGUIでの操作によるデータ解析などは最も repeatable でない、と考えることができるし、解析の手順を実行可能なスクリプトとして保存すること、スクリプトの実行に必要なソフトウェアやライブラリをパッケージングすること、環境設定や実行ログの保管などのエンジニアリングによって repeatability は向上する。自然科学における実験、いわば化学物質や生物試料など「モノ」を対象として物理的な作業を行う場合には repeatable であることと replicable であることには操作を行う作業者や道具の違いが寄与するが、通常コンピューターを用いたデータ解析においては、プログラムはそのまま複製が可能であり、さらに作業者の違いは問題にならないので、repeatable であることは replicable であることとほぼ同義であろう。

さらにあるデータ解析が「replicable であるだけでなく reproducible でもある」ために求められるのは「手順がオリジナルとは厳密には同じではないが、オリジナルに従った同様の作業を行って、同じ結論を得ることができる」ことである。すなわち、マシンのOSが異なる、実行される手順をプログラムした言語が異なる、実行制御のためのフレームワークが異なる、ストレージや並列化のためのアーキテクチャが異なる、などの違いがあったとしても、解析の内容が同一であれば、同じ結果を得ることができる状態を実現することで「データ解析が再現する」といえる。クラウドコンピューティングプラットフォームの普及や、ソフトウェアと実行環境を可搬にするコンテナ仮想化の技術が普及したため、OSの違いや再実装の手間などは解消されつつあるが、データ解析においては大規模な計算機環境を用いる場合の実行制御や並列化など、依然として fully reproducible なデータ解析を実現するための課題は多い。

Common Workflow Language の誕生

計測機械の出力の大規模化に伴い、大型計算機でのデータ処理の需要が急激に増したゲノム解析の分野では、同じ機械から得られる同種のデータから、目的ごとに異なるソフトウェアを組み合わせた「ワークフロー」を構築し、生物試料(サンプル)ごとに繰り返し実行し、結果を統合あるいは相互に比較する、というデータ解析が一般的となっている。目的が細分化されているため、データを変換し、外部データを参照して結合し、統計処理を施し、といった多くのステップを実施するために数百のオープンソースソフトウェアが開発されている。データ解析者は必要なソフトウェアを選択し、ワークフローを構築し、大型の計算機で並列に処理するといった日常を過ごしている。この「ワークフローの構築」と「大規模なサンプルに対する効率のよい実行」を容易にするために、ワークフローエンジンと呼ばれるソフトウェア・フレームワークが数多く開発されている。代表的なものは Galaxy, Apache Taberna などが挙げられるが、その他にも数多くのワークフロー実行系が開発、公開されている。しかし、これらのソフトウェアは作業者の負担を減らしてくれる代わりに、異なるワークフローエンジンで同一の解析を実行するための移植コストが増大し、結果 reproducibility が下がってしまうことが問題となった。

2014年にボストンで行われた Open Bioinformatics Foundation (OBF) が主催する Codefest 2014 においてこの問題についての議論があり、異なる処理系の間で同一のワークフローの実行を可能にするために、ワークフローの内容を記述し、実行系の間で交換するための標準形式の策定を目的として Common Workflow Language (CWL) プロジェクトが発足した。毎年行われる Codefest とそれに続く Bioinformatics Opensource Software Conference (BOSC) での議論、さらに有志によるオープンソースでの開発によって、徐々に普及が進んでいる。

CWLの基本的な構造はYAML形式で実行するコマンドとその入出力を記述し、入出力の関係でワークフローの構造を書くというものである。以下に単純なサンプルを示す。

cwlVersion: v1.0 class: CommandLineTool hints: DockerRequirement: dockerPull: ubuntu baseCommand: echo stdout: output.txt inputs: text: type: string inputBinding: position: 1 outputs: message: type: stdout

cwlVersion: v1.0 class: CommandLineTool hints: DockerRequirement: dockerPull: ubuntu baseCommand: [sed, -e, 's:e:o:'] inputs: file: type: File inputBinding: position: 1 outputs: result: type: stdout stdout: result.txt

cwlVersion: v1.0 class: Workflow inputs: text: string outputs: workflow_out: type: File outputSource: sed/result steps: echo: run: echo.cwl in: text: text out: [message] sed: run: sed.cwl in: file: echo/message out: [result]

CWLについての詳しい情報は、CWLに関心がある/開発に参加している日本の有志によって書かれたはじめてのCWL、さらにこの記事から始まるCWL アドベントカレンダーの記事を参照して頂きたい。

CWLが僕らにもたらしてくれるもの

個人的な話をすると、折しも Codefest 2014 をやっているちょうどその頃に、日本の片隅でデータ解析環境の可搬性について訴えるなどしており、さらにJSON形式のオレオレなワークフロー記述言語を設計したりしていたところ、タイミングよくCWLのことを知り、こりゃあいいやとBOSC 2015にCWLを立ち上げた人々に会いに行ったところからの付き合いです。その頃はまだ Draft として仕様が公開されているだけで例も少なく、実運用はあまり現実的ではありませんでした。こりゃあこの先コケることもあるかも分からんねと思ってウォッチを続けていましたが、そのうちに 1.0 がリリースされ、実行系の標準実装も整備され、コミッタも増え、周辺ツールも充実し、CWLのインポート・エクスポートに対応する実行系も増えてきました。個人的にも1.0系になったあたりから実戦投入しながら、CWLが何をするもので、何でないのか、使うことでどんなメリットが得られるのか、あるいはデメリットがあるのかを見極めつつ、ちょっとずつ周りの人に勧めています。

CWLがどんなもので、どんなpros/consがあるかはこのアドベントカレンダーの他の記事に譲るとして、ここで強調しておくべきことは、このプロジェクトがカンファレンスのハッカソンで自然と生まれ、どの組織や企業にも属さないが、しかし色々の組織から多くのコミッタが参加する、オープンソース・コラボレーションプロジェクトとして、数年に渡り継続しているということです。これまでにも各種プログラミング言語のためのバイオデータのためのライブラリである BioPerl, BioRuby, BioPython などなど、バイオインフォマティクスに関連するオープンソースの活動はありましたが、いずれも多かれ少なかれ、同じプログラミング言語を研究に使いたいという意味で目的が一致していたのではないかと思います。しかしCWLは、ワークフローエンジンの開発者たちにとっては、CWLの開発にコミットしたところで自身のプロダクトそれ自体の質が改善するわけでもないし、業績になるかもわからない。今のところ、CWLにコミットしたおかげで随分偉くなったとか、数億のグラントが取れたとか、そういう話は聞きません。ですから、参加する人のモチベーションはただ1つ、「科学とはこうあるべきだ、そのためにこれをしなくてはならないのだ」という loyalty なのではないかと思っています。俺達はなすべきをなしている、と。世界が間違っており、間違った世界は正さなくてはならない。コミッタは研究者だけでなくエンジニアもいますし、大学や研究所だけでなく企業の人間もいます。国籍も人種もタイムゾーンも様々、普段やっている業務もみんな違いますが、そういう同じ想いを持った人が集まっている。アベンジャーズみたいなものです。CWLの本当の価値は、そういった人々が集まって議論ができる、開発ができるコミュニティができていく過程そのものなのだと思います。

「標準を作る」ことはとても難しい作業です。多くの人に受け入れられなければ標準とはなりえない、しかし仕様策定の議論に人が集まれば集まるほど、シンプルでパワフルなものを作ることは困難です。正直、CWLにも微妙だなと思う部分は結構あります。javascriptのexpressionとか頭おかしいんじゃないかと思うし、ループや条件分岐なんかコンテナの中に入れろと思う(ループと分岐はまだ議論されている段階で実装はされてないです)。出来る限り軽量にして、拡張する余地を残すに留めるべきだ、Keep it fucking simple stupid だと何度も伝えましたが、そんなことはみんな分かっていて、でもなるべく多くの人の意見を取り入れていくということも、CWLというコミュニティを育てる上でとても大事なことなのです。だから、短期的には、CWLを使ってみる、CWLの分からないことを質問してみる、必要な仕様について議論する、実装の手伝いをする、ドキュメントを書く、といった貢献が報われるかどうかはわかりません。でも、そこで得られるコミュニティとの関わり、人のつながりは絶対に失われないし、将来の財産になるはずだという実感があります。だからこそ、欧米のコミュニティと距離的時差的にコミュニケーションが取りづらい東アジアの人たちも、もっとこのコミュニティに入ってきて、一緒に議論ができればいいなと思っています。このアドベントカレンダーが目に留まって、ちょっと興味を持った人がいたら、前述のCWL Start Guide JPを読んでみる、プロジェクトのページを見てみる、生命科学系データ解析に携わる人が集まる毎月のイベント Galaxy meetupに来てみる、などなど色々の関わり方があります。一緒に世界を救いましょう。

12/10 追記

内容がポエミイなのでQiitaから移植しました。

Reference

Baker, M. (2015). Irreproducible biology research costs put at $28 billion per year. NATURE News, 9.

Drummond, C. (2009). Replicability is not reproducibility: nor is it good science.

[trattoriainutano]

NGS現場の会 第五回研究会に参加してきました

行ってきました

!!! ブログに書くまでが現場の会です !!!

2017年5月22日から3日間、仙台国際センターで開催された NGS現場の会 第五回研究会 に参加してきました。2年ぶり5回目の今回も現場の会は大盛況。聞くところによると当日参加が200名を越え、参加者合計が800名以上のこれまでで最も規模の大きい会となったそうです。

数字の上では人数が多いものの、会場フロアが広々としているおかげで人の多さを感じない、とてもよい雰囲気でした。仙台国際センター展示棟は展示ブース・ポスターのフロアと講演ホールの広さと距離が絶妙で、一部のセッションでは立ち見が出たりということもありましたが、発表を聞くのも人と話すのも総じて快適。「絶対に過ごしやすい空間を作ってやる」というスタッフの強い意志を感じるコーヒースペースや ”縁側” での講演ホール同時中継など、色々の工夫のおかげと思います。こんな大規模の研究会で「過ごしやすい」と思ったのは初めてではなかろうか。改めてスタッフのみなさま、おつかれさまでした。都合により2日目からの参加だったので、初日から会を満喫した他の参加者が羨ましい。

ちなみに他の参加者の方からもよい評判を頂いていたポスター会場での口頭発表同時中継は、弊所の誇る動画撮影部隊、h_onoさん率いる統合TVチームのサポートによって実現しています。近頃の統合TVはチュートリアル動画だけでなく講演動画も充実しており、泣く子も黙る1大メディアとなった感がある。なお統合TVでは動画の作成編集をお手伝いしてくれる方を募集しています。リモートで空いた時間に作業できるので、学生さんのアルバイトや副業におすすめです。宣伝おわり。

ハンズオンやりました

前回のNGS現場の会では運営スタッフとして参加したので、会期前も会期中もてんてこまいでした。今回はいち参加者として参加するので気が楽だと思っていたら、「ハンズオンのセッションをやりませんか」とお声がけ頂きまして、ならばと普段活動している Galaxy Community Japan のメンバーと協力して、Galaxy の紹介とそれに関連する技術の紹介のハンズオンセッションをしました。

どんな技術レベルの人がどれくらい来るのか事前に全く分からなかったため、全然人が来ないという寂しい事態も想定しつつ準備をしていましたが、蓋を開けてみれば満員立見となる盛況なセッションに。お越し頂いた方に挙手でアンケートをとってみたところ、今回NGS現場の会に初めて参加するという方が多く、なるほどという感じ。

そういうことでセッションの内容も、懇切丁寧手取り足取りあなたも今日からギャラクシー、とすればよかったのかもしれませんが、どっこいここは現場の会です。先鋒わたくしが「Galaxyとはなんぞや」を早口でまくし立て「簡単そうに見えるけど残念案外難しい」と不安を煽る。お次は慶應の鈴木さんによる目的特化型 Public Server の紹介、続いてアスケイド社那須野さんによる “Dockerとはなにか” というコンテナ仮想化技術の話。理研石井さんによる “Galaxy 七転び八起き” と題する 「不満があれば Pull Request を送れ」という強いメッセージの後に、パーシピア社の池田さんが GATK on Galaxy のお話で締めるという、当初予定より随分盛り込んだ内容のセッションとなりました。

セッションの頭の挙手アンケートで Galaxy のことをあまり知らない人が多いと判明したとき、コンテナ仮想化による再現性の話や Galaxy Project にコミットする話とか、マニアックな話をしていいのかなとちょっと心配になったのですが、今ではこれでよかったのだと思っています。

Galaxy に限ったことではないですが、研究におけるデータ解析という責任あるプロセスを行うにあたって、その手法を「大丈夫です簡単です」と無責任に言うのは誠実でなかろうと思うわけです。特にオープンソースコミュニティで維持されるフリーのプロダクトを「簡単にできるのなら…」と安易に使おうとすると、躓いた時に諦めがちです。「簡単にできると言われたけど難しい、これは向いてないんだ」と辞めてしまう人の話をしばしば聞きます。「ちょっと難しそうだけどこれが必要だ、やってみよう」という前向きなスタンスが1番いいのだと思います。そういう思いがセッションで伝わったかどうかは定かではない。伝わっていてほしい。

Galaxy というプロダクトで「何ができるか」、そしてそれを使っている人たちが「何を考えて」「何をしているか」を目の当たりにすれば、必要な人はそれを見て使ってみようとするはずです。自力で調べるだけのドキュメントやその他素材はウェブに転がっていますし、ばら撒いていますし、「調べたり考えたりしないでも簡単にできるのだ」と思わせるような安易な紹介は、聞きにきてくれた方々へのリスペクトを欠くことです。

これからもデータ解析やそれにまつわる諸々について、ドキュメントを書いては公開し、OSSの不具合は黙ってPRしていく活動をやっていきたいと思います。

発表しました

ハンズオンはハンズオン、それとは別にポスター発表をしました。内容は第四回NGS現場の会で企画した「お花見メタゲノム」プロジェクトについてです。お花見企画に参加してくださった方も、そうでない方も発表を聞きにきてくださり、ありがとうございました。

「ブログに書くまでが現場の会」と言いながら、第四回NGS現場の会のブログを何故書いていないかというと、僕の第四回NGS現場の会はまだ終わっていないからです。関係各位、ただいま諸々のアレをアレしておりますのでしばしお待ち頂けますと幸いです。近く「第四回NGS現場の会に行ってきました」ブログを書けるように頑張ります。

ライブシーケンスとYCAM

前回の会の企画をしている時に「開催期間中にシーケンスして解析して論文出すまでできんかな」「やろう」「いやーさすがに無理でしょ」「ライブラリプレップまでしていれば…」「できなくはないけどMiSeq持ってくるわけ？」「運ぶのどうする」「ていうかそんな許可取れるのか」「MinIONは？」「いやーあれはまだなー」なんて会話をしていたのですがたった2年で実現するとは。「ゲノム解読が完了したものだけ材料に弁当」こと「ゲノム弁当」のご当地バージョンである「ゲノム芋煮」を実現するため、里芋のシーケンスをライブでやるという素晴らしい企画が期間中に行われておりまして、ブースに遊びに行ってきました。素晴らしい企画でしたがやはりそう簡単にはいきません。結果里芋のシーケンスは大成功とはいかなかったようです。なお大会最終日の朝にその「ゲノム芋煮」が振る舞われることになっており、おひとつ頂いたのですが「ゲノム読めなかったから里芋入れない」vs「芋煮の伝統」では後者が勝利したようです。

さてその芋煮のシーケンスを手伝ってくださっていたのが山口情報芸術センターことYCAMの方々でした。YCAMとは昨年12月に山口市で BioHackathon 国内版をやった際にコラボ企画をやったご縁がありまして、僕はあの施設に行くためだけに山口市に行く価値があるとあちこちで言って回っているのですが、その魅力の一部が今回の企画と出展で参加者の人にも伝わったのではなかろうか。

YCAMは本当にすごくて、何がすごいのかというと何もかもすごいんですが、YCAM行くためだけに山口にまた行こうと思っているくらいです。YCAMバイオラボとも、また何かご一緒できたらいいなあ。

現場の会の今後

現場の会は熱海、大阪、神戸、つくば、仙台と規模の拡大を続けてきましたが、今回で “この形態での開催は一区切り” とすることがアナウンスされました。その決断に至るまでには、歴代の大会長、これまでの運営に関わったコアメンバー、そしてスポンサーの企業の方々を含む参加者、色々の人の色々な考えがあったことと思います。思いますが、参加者にはそれぞれの現場、それぞれの想いがあるわけで、総意と言えるものもないような気がします。なので、個人的に現場の会に思っていることを書きます。

現場の会には他の会にない様々な特徴があって、たとえば若手が中心の運営、アカデミアや企業の垣根を越えた議論、"情報はギブアンドテイク"を標榜していること、などなど。そのおかげで他にはない魅力のある活発な研究会になったのだと思います。しかし、それらの特徴はあくまで「目標を達成するために必要だったからできたもの」であり、その目標とは、新しい技術を使った新しい研究が次々に出てくる諸外国に伍するため国内で技術と情報を共有すること、だったと思います。NGSが普及し、ネット上には情報が溢れ、書籍も出版され、誰もがNGSの情報にアクセスできるようになった今、その目標は達成された、現場の会の意義はもうない、規模が大きくなり運営が苦しくなった今無理に続けることもない、として前述のような判断になることは自然ではないかと思います。

一方で、まだ現場の会が必要だろうなと思う点もあります。NGSという技術導入のフェーズが変わったことで、これまでの会が「ピークを引き上げる」ための会であったとするなら、「裾野を広げる」ための会が必要な時期に変化したのだと思っています。人を集めるのは大変ですから「NGS現場の会」というブランドを利用しない手はないですし、一旦仕切り直したのちに、異なる目標を持った会として再出発する、というアイディアは悪くないかもしれません。でもそれは、現場の会であって現場の会ではないので、看板だけ借りて、本当に必要とする人たちだけでまたゼロから作る方が絶対によいと思います。「新・劇場版 NGS現場の会」とかどうですか。

熱海で開催された第一回には恐れをなして出向かず、大阪での第二回におっかなびっくり参加し、第三回はキャッキャ楽しみ、第四回では企画に回っててんやわんや、第五回はリラックスして楽しんだというのがわたくしの現場の会遍歴なのですが、最も印象に残ったのは第一回です。参加してないけど。参加してないけど、第一回に参加した人たちは皆、その時の様子を楽しそうに語るのです。手作り感、熱気、尽きない議論、そんなキーワードが6年経った今でも語られます。第二回以降の会は結局のところ、ゼロからこの会を作り上げ、盛り上げた人たちの情熱に寄せられて、人が集まり、コミュニティが出来ていく過程であったのだと思うのです。「あの辺の人たちがワイワイ盛り上がっているらしい」と聞きつけて野次馬的に出かけていった自覚があるだけに、そう思います。

今でもNGSのことなんて何も分かっちゃいませんが、今よりずっと分かっていなかった頃から、現場の会で会った人たちにはとてもよくしてもらっていて、他ではきっとできなかった繋がりができたという意味で、本当に有り難いという気持ちがあります。コアメンバーだけでなく参加者の多くが、それぞれの分野の最前線で文字通り身体を張っている人ばかりで、モチベーションとエネルギーに満ち溢れていて、そんな人たちの研究の話を聞くだけでなく、話を聞いてもらって容赦なくダメ出しをしてもらう、こんな貴重な体験は他ではなかなかできません。なので現場の会には感謝しかないです。ありがとうNGS現場の会。

NGSはコモディティとなり次世代でもなんでもなくなりましたが、きっとまた違う技術を誰かが作って、またお互いに助け合うためのコミュニティが必要となる時が来るはずです。その時にしっかり貢献できるよう、今は自分のやるべきことをしっかりやりたいと思っています。

雑感

恒例の思いついたことを脈絡なく書きなぐる箇条書きのコーナーです。例によってオチはない。御免。

久しぶりの仙台、毎度「思ったより近いな」と思う

仙台駅から国際センターまで行ける地下鉄ができていた

しかし新幹線の改札から地下鉄への経路が分かりづらすぎる

新幹線の改札出て地下鉄に乗るまで迷子になって3回くらいもう帰ろうかと思った

今回は天気がいいなと思ったらやはり最終日に小雨が降った

現場にはいつも雨が降っている

国際センターの展示棟、広いしきれいだった

数百人規模の会は毎度ここでやってほしい

コーヒーがうまい

ミキサーの飯がうまい

ミキサーの酒がうまい

もうそれだけで学会の生産性が上がる

学術研究集会は生産性向上のため須らく質の高い食事と酒を出すことを国に義務付けてほしい

食事代は自腹ですけど

いろいろの人とお話をしていたらあっという間に2日間が終わった

ブースで印象に残ったのはアダチさんの展示

ご本人とゆっくりお話できなかったのが悔やまれる

というか全体的に時間が足りない

セッションの合間に色々の議論やらをしていたら2日とも昼飯を食い損ねた

牛タン弁当とか出ていたらしく本当に後悔している

ランチョンセミナーで余った弁当、売ってほしい

慶應の荒川さんが廊下で突然シーケンスを始めて戸惑う周囲の人を「えっMinION持ってきてないんですか？」と煽っているのが最高だった

サンプリングもそのへんでしたのかと思いきやラボでプレップまでしてきたとのこと

じゃあシーケンスもラボでしてくればよかったのではと突っ込んではいけない

特に野外でやる必要性はないが野外でやると捗るよねというシーケンスを「野点」と呼ぶのはどうか

会場で流血してる人がいたので絆創膏をあげた

現場の会はサバイバル

今回の現場の会の盛り上がりトピックだいたいMinIONで実質MinION現場の会っぽさあった

MinIONのカナ表記はミナイオンというそうです

ミニオンズとの競合を避けてググラビリティを上げるためっぽいがそもそもの名前がどうなのよ

「みにゃおん」とかで猫のロゴにした方がいいんじゃないですか > ご担当者様

どうしても知ってる人と近況報告をして時間がなくなる

初めましてのお友達を作ろうと頑張ったが…

これまでに来ていた人たちと初めてきた人たちとの温度差、断絶みたいなものを感じた

あとスーツ率高くないですか

過去の現場の会を知る人たちから「なんかいつもと雰囲気違いますね」と何度か聞いた

これはもう運営でどうにかなる問題ではないのだなという感じ

締めの大会長講演の前に少なくない人たちが席を立っている様子を見て、ああかつての現場の会はもうないのだ…としみじみしてしまった

個人的な現場の会の今後としては今回の締めに「今回で終わり！以後何もなし！解散！」と荻島大会長が派手に演説してくれることを期待していた

会場でご本人にも拝み倒しましたが「そんなキャラじゃないですから」と丁重に断られました

現場の会は学部生でもPIでも対等に話ができる雰囲気がよい、という話

からの「表面的なことを知っていれば話にはついていけるし、若くて元気な子はそれだけでちやほやされるが、そのせいで自分が偉くなったような気になってしまうとよくない、地に足をつけてやるべきことをやらねばならない」という有り難いお言葉

大いに思い当たるところがある

「表面的なところだけで話についていく」とか

謙虚、謙虚さ

日々やっていきです

そういえば今回は「人生の共同研究者」というワードを聞かなかった

その代わり「現場の会よりも大切なものができた」と言って来ない人がいた

それぞれの人生、それぞれの現場

みんな大切なものができたのです

全ての現場に幸あれ

[trattoriainutano]

第一回 RDF 講習会に参加してきました

毎年10月5日は語呂合わせで「トーゴーの日」、日本国内の生命科学データベース統合に関わる研究者が集まり、研究発表や議論のためのイベントが催されます。今年はそのイベントに合わせて、「第一回 RDF 講習会」が開催されたので、参加してきました。我々 DBCLS が、データベース統合の基盤技術としてデータの整備と周辺技術の開発を継続しているセマンティック・ウェブ技術、その根幹となるデータ表現である RDF と、その標準の問い合わせ言語である SPARQL についての講習会です。

第1回 RDF 講習会 http://wiki.lifesciencedb.jp/mw/RDF-Tutorial1

HTML という文章のネットワークである WWW に対してデータを相互に繋いだネットワークを実現する Linked Open Data (LOD) の考え方、その実装に用いられる RDF, OWL, SPARQL などのセマンティック・ウェブ技術とその応用、このフレームワークを生命科学ドメインに適用することで可能になること、またその技術的詳細についてが語られる、非常に内容の充実した講習会であったと思います。講習会のウェブサイトに講習の内容と当日使われたプレゼン資料の PDF は既にアップロードされています。当日の様子も録画されているため、ほどなくウェブ上で観ることができるようになるそうです。

充実した講習会ではあったのですが、なにぶん「データベース講習会」としてこれまでに DBCLS で主催してきたような講習会とは異なり、少なからず予習を要する内容であったため、 RDF と PDF を空目してしまう程度の馴染み具合ではなかなか太刀打ちできないレベルであったかもしれません。このトピックに限らず、参加者の理解度がまちまちだと全ての人が満足する講習会を開催するのは不可能ですが、とはいえ、考え方や技術の普及のためにも講習会がアップデートされ、第2回, 3回と続いていくといいなと思います。

僕自身はというと、 DBCLS で毎月行われている勉強会 “SPARQLthon” に出入りしているうちに、なんとなくぼんやりとそのコンセプトを理解して、年に1度の BioHackathon で世界各国の Semantic Web advocates と楽しく過ごしているうちに、いつのまにか自分の拵えたデータベースをRDF化していたのでした (https://integbio.jp/rdf/?view=detail&id=quanto)。門前の小僧習わぬ経を読む、飲み会に通えば SPARQL が書ける。もちろん、SPARQLthonに参加されているみなさんのご助言あってこそです。大変ありがたいことです。

そうやって付け焼き刃的というか、OJTというか、実戦に放り込んで生きて帰ってきた奴が訓練された兵士だとか、そういう具合でやってきたものですから、そろそろ体系的に学ぶ必要があるのではないか？と思って今回の講習会にも参加させてもらいました。既存のデータを RDF で表現するためにはどのようにモデリングすればよいか？語彙/オントロジーはどのように選択すればよいか？うまい具合にデータを検索/加工するためにはどう SPARQL を書けばよいか？ などなど、日頃出くわす悩みは多いですが、それらを解決するために知っておくべき考え方や知識を整理することができました。講師のみなさま、どうもありがとうございました。

で、まあ折角 SPARQL を習ったのですから、なにか書いてみましょうということになるわけです。どんな言語でもそうですが、普段使いを続けるうちに自分の身に染みて「言語」となるわけです。以下、題して「あなたとSPARQL 今すぐデータ統合」。それではやっていきましょう。

まあとりあえずなにはともあれ DBpedia に行きましょう。馴染みの日本版です。DBpedia が何か知らない人は自分の無知を恥じて「DBpediaはWikipediaから情報を抽出してLOD (Linked Open Data)として公開するコミュニティプロジェクトです」と百回唱えてください。 http://ja.dbpedia.org

つまるところ、文章の集合でありネットワークでもある wikipedia をデータの集合として、そこから必要な情報を検索したり抽出したりすることができるわけです。で、色々あって楽しいんですが、 SPARQL を書きたいだけなので、何も考えずに日本版 DBpedia の SPARQL endpoint にアクセスします。 http://ja.dbpedia.org/sparql

生命科学分野のデータベースに関わっていると「データベースのページは複雑で何をどう探していいかわからない、Googleみたいに検索窓がひとつしかないシステムは作れないの？」と言われることがありますが、これがその方々が求めている「窓がひとつしかないインターフェース」です。ここに何かしらを入れて下っちょにあるボタンを押すと何かしらが返ってきます。素晴らしいですね。アクセスすると以下のような画面が出て窓の中に呪文が書いてあります。

これとりあえず押してみましょう。 "Run Query” をポチッとな。

なんか返ってきました。URLがたくさんあってよくわかりません。東京都について調べているような気もしますが、東京都について調べたいだけなら Google で「東京都」って打つか、Siri に「東京都」と話しかければいいです。なんで変な呪文を入れたのでしょうか。呪文を見てみましょう。

select distinct * where { <http://ja.dbpedia.org/resource/東京都> ?p ?o . } LIMIT 100

この呪文は以下の3つのパートに分けることができます。

select distinct * where { <http://ja.dbpedia.org/resource/東京都> ?p ?o . } LIMIT 100

select で書かれているのは「取ってきてほしいもの」で、where の後の {} で囲まれた部分が「欲しいものの条件」で、その後は「返し方のお作法」です。1番分かりやすいのは最後の LIMIT 100 で、これは「返すのは多くても100個でいいよ」ということです。条件に合うものが100個以上あっても100個しか返さない。そんなに沢山あっても見られないですからね。数万行あるデータを目で見て確認するなんて知性のある人間のすることではありません。

ちなみに、元の呪文では select distinct where は小文字なのに LIMIT は大文字です。何か意味があるかと思いきや別に大文字でも小文字でもどちらでもいいです。以下の2つはどちらも実行できて、結果も同じです。

select distinct * where { <http://ja.dbpedia.org/resource/東京都> ?p ?o . } limit 100

小文字と、

SELECT DISTINCT * WHERE { <http://ja.dbpedia.org/resource/東京都> ?p ?o . } LIMIT 100

大文字。まあ、よく分からない人はそのあたりあまり深く考えなくてもいいです。でも、LIMIT ってなくても動きそうですよね。試しにこれを削ってみましょう。

select distinct * where { <http://ja.dbpedia.org/resource/東京都> ?p ?o . }

where の手前で改行しても大丈夫です。改行した方が見やすいですね。これで “Run Query” を押すと、ちゃんと結果が返ってきます。多分100件以上になっているんでしょうが、どうでもいいです。

つまり select と where さえあれば SPARQL が書けるわけです。でもまだ呪文っぽいですね。distinct 、これなんでしょう。これは SQL 書いたことがある人なら自明ですが、重複を除くという命令です。そのあとの * (アスタリスク)は「全部」を意味するワイルドカードです。select * で「全部返せ」です。意味分からないですね。アスタリスクを使わないとこんな感じになります。

select distinct ?p ?o where { <http://ja.dbpedia.org/resource/東京都> ?p ?o . }

結果は同じ。じゃあこれでいいじゃないですか。あと「重複を外す」っていうのもなくても動きそうですね。外してみましょう。

select ?p ?o where { <http://ja.dbpedia.org/resource/東京都> ?p ?o . }

だいぶシンプルになった気がします。これで実行してもちゃんと返ってきます。あと呪文っぽいのは ?p と ?o ですね。なんですかこれは。これはですね、変数です。

select ?predicate ?object where { <http://ja.dbpedia.org/resource/東京都> ?predicate ?object . }

「いやだからなんだよ」といいつつもここまで読み進めた勇敢な方のために解説すると、RDFで表現されたデータは

[主語 (subject)] - [述語 (predicate)] - [目的語 (object)]

の三つ組 (トリプルといいます) の形になっています。よく意味がわからなくても、まあそういうもんだと思ってください。SPARQL では、その構造と変数を使って where 句の中に知りたい情報の条件を書いていくわけです。ちなみに . (ピリオド) は「ここまでが三つ組のセットだよ」という印です。

なんとなく分かってきたような気もしますね。この SPARQL は「wikipedia に書いてある情報を全部『主語ー述語ー目的語』に書き換えた時に『主語』が東京都である三つ組の、述語と目的語のセットを全部取ってこい」という命令になります。確かに結果を見てみるとなんとなくそんな感じがするような気がします。SPARQL 書けました。やったね。

しかしだからどうなんだと。別に東京都の情報とか出てきても感動がないです。感動する問い合わせがしたい。感動する例でやってみましょう。dbpedia は元が wikipedia ですから、色々な情報が載っています。普通の女の子の情報とかも載っているわけです。試しに先ほどの例の「東京都」のところを普通の女の子の名前に書き換えて実行してみましょう。（よい子のみんなへ：ここから先は SPARQL を dbpedia の endpoint にコピペして “Run Query” で実行してみてね）

select ?p ?o where { <http://ja.dbpedia.org/resource/上原亜衣> ?p ?o . }

感動しますね。感動しませんか。しますよね。 dbpedia に SPARQL クエリを投げると普通の女の子の情報が返ってくる。セマンティック・ウェブ最高、 LOD はいいぞ (SOD ではない)。

結果を見ると ?p の列に表示されているものは全部 URL ですが、?o の列に表示されているものは URL の他に、数字や引用符で囲まれた文字列があります。厳密には、ここで表示される URL っぽい文字列は、 Location を示しているのではなくデータの ID を示しているので、 Uniform Resource Identifier で URI といいます。SPARQL を書くときは URI を <> で括るのがルールです。そして、三つ組での表現には以下のような決まりがあります。

主語 (subject) は URI で示すこと

述語 (predicate) は URI で示すこと

目的語 (object) は URI もしくは リテラル (数字とか文字列とか) で示すこと

しかし主語に関連する情報だけが表示されても東京都が女の子になっただけで大したことはありません。先ほどの実行結果からそれらしい述語と目的語をピックアップして、今度は主語を変数にしてクエリを実行してみましょう。以下のように。

select ?s where { ?s <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://dbpedia.org/ontology/AdultActor> . }

(ﾟ∀ﾟ)ｷﾀｺﾚ!! ところで、 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> というのは “type”, 「データ型」を示す predicate で、頻繁に使われます。頻繁に使われるのに毎度これを書くのはつらいです。ですので、 a と書けます。a は “is_a” の略です。略し過ぎだろうと思うかもしれませんがそんなものです。つまり以下は上のクエリと同じです。

select ?s where { ?s a <http://dbpedia.org/ontology/AdultActor> . }

実行するとちゃんと返ってきます。ずいぶん簡単に書けるようになりました。しかし SPARQL の本領はここからです。条件を追加していきましょう。

select ?s where { ?s a <http://dbpedia.org/ontology/AdultActor> . ?s <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> . }

where の中に三つ組を追加して条件を書いていきます。だらだら長く書くとわかりにくいので見やすいところで改行します。述語と目的語は沢山あって調べるのが大変なので、先ほどの普通の女の子について検索した結果から選んできました。このクエリを実行すると福岡県出身の女の子のリストが返ってきます。しかし、名前だけ分かってもねえ。これではどうですか。

select ?s ?o where { ?s a <http://dbpedia.org/ontology/AdultActor> . ?s <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> . ?s <http://ja.dbpedia.org/property/生年> ?o . }

どうですか！これであなたも wikipedia に載ってる同い年、同じ出身地の女の子の情報を即座に手に入れることができるわけです。すごいですね SPARQL は。でもこれ、ちょっと結果が見にくいですよね。生まれ年の順番で並べてほしくないですか。

select ?s ?o where { ?s a <http://dbpedia.org/ontology/AdultActor> . ?s <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> . ?s <http://ja.dbpedia.org/property/生年> ?o . } order by ?o

最初の例で LIMIT と書いてあったところに新しいキーワードで条件を書きました。 where の後に order by を付けて、そのあとに変数名を置けばよし。ね、簡単でしょ？しかしこれ、変数名が ?s ?o って味気ないですし、条件が増えていったときになんのこっちゃわからなくなりますね。後で読んだときに分かるように書き換えましょう。

select ?girl ?birthyear where { ?girl a <http://dbpedia.org/ontology/AdultActor> . ?girl <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> . ?girl <http://ja.dbpedia.org/property/生年> ?birthyear . } order by ?birthyear

おおわかりやすい。でも where 句の中に ?girl が沢山あって鬱陶しいですね。 DRY の精神に則ってシンプルにしたいところです。そんなときは、ピリオドの代わりにセミコロンを使って書き換えられます。

select ?girl ?birthyear where { ?girl a <http://dbpedia.org/ontology/AdultActor> ; <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> ; <http://ja.dbpedia.org/property/生年> ?birthyear . } order by ?birthyear

セミコロンで区切ると、次の節は主語を前の節と共通のものとして省略できます。すっきりしました。 数字で並べるとデータも把握しやすいですよね。order by に与える変数は2つ以上あっても大丈夫ですんで、数字増やしてみましょうか。適当な述語をまた選んできましょう。

select ?girl ?birthyear ?bust where { ?girl a <http://dbpedia.org/ontology/AdultActor> ; <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> ; <http://ja.dbpedia.org/property/生年> ?birthyear ; <http://ja.dbpedia.org/property/バスト> ?bust . } order by ?birthyear ?bust

生まれ年と、何か適当な数字で並べ替えてみました。ついでに結果にも数字を出してみました。しかし、ただ数字の順番というのも意味がないですから、意味がありそうな数字にしたいですね。SPARQL では四則演算も簡単ですから、やってみましょう。

select ?girl ?birthyear ?bust ?waist where { ?girl a <http://dbpedia.org/ontology/AdultActor> ; <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> ; <http://ja.dbpedia.org/property/生年> ?birthyear ; <http://ja.dbpedia.org/property/バスト> ?bust ; <http://ja.dbpedia.org/property/ウエスト> ?waist . } order by ?birthyear (?waist - ?bust)

すごいですね。まだまだいきましょう。 SPARQL には optional という文法もあって、「もしあったら返す、なければ別にいいです」という条件が書けます。世の中にはいくつもの名前を使っている女の子がたまにいますから、 optional で別の名前を探してみましょう。

select ?girl ?birthyear ?bust ?waist ?altname where { ?girl a <http://dbpedia.org/ontology/AdultActor> ; <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> ; <http://ja.dbpedia.org/property/生年> ?birthyear ; <http://ja.dbpedia.org/property/バスト> ?bust ; <http://ja.dbpedia.org/property/ウエスト> ?waist . optional { ?girl <http:ja.dbpedia.org/property/別名> ?altname . } } order by ?birthyear (?waist - ?bust)

ウオー！ これ、そろそろクエリが面倒になってきましたね。select の後に変数全部つらつら書かないといけないのは大変だし、URI をいちいち書くのも大変です。ラクに書きたいです。ラクに書きましょう。まずは変数。全部返してくれればいいので、これは最初に出てきた * に置き換えられますね。

select * where { ?girl a <http://dbpedia.org/ontology/AdultActor> ; <http://dbpedia.org/ontology/hometown> <http://ja.dbpedia.org/resource/福岡県> ; <http://ja.dbpedia.org/property/生年> ?birthyear ; <http://ja.dbpedia.org/property/バスト> ?bust ; <http://ja.dbpedia.org/property/ウエスト> ?waist . optional { ?girl <http:ja.dbpedia.org/property/別名> ?altname . } } order by ?birthyear (?waist - ?bust)

次は URI です。URIは長くて見づらいし、同じ文字列が何度も出てきているのは腹立たしい。置き換えましょう。select の前に prefix というキーワードを使います。

prefix onto: <http://dbpedia.org/ontology/> select * where { ?girl a onto:AdultActor ; onto:hometown <http://ja.dbpedia.org/resource/福岡県> ; <http://ja.dbpedia.org/property/生年> ?birthyear ; <http://ja.dbpedia.org/property/バスト> ?bust ; <http://ja.dbpedia.org/property/ウエスト> ?waist . optional { ?girl <http:ja.dbpedia.org/property/別名> ?altname . } } order by ?birthyear (?waist - ?bust)

おっ。

prefix onto: <http://dbpedia.org/ontology/> prefix prop: <http://ja.dbpedia.org/property/> select * where { ?girl a onto:AdultActor ; onto:hometown <http://ja.dbpedia.org/resource/福岡県> ; prop:生年 ?birthyear ; prop:バスト ?bust ; prop:ウエスト ?waist . optional { ?girl prop:別名 ?altname . } } order by ?birthyear (?waist - ?bust)

すっきりした！ prefix の後に、省略後の文字列を適当に決めて、コロン、URI と書くと省略のルールが書けます。まあ、見ての通りです。prefix で指定する URI のスラッシュを忘れないようにしましょう。随分立派な SPARQL が書けるようになってきたんじゃないでしょうか。しかし、これだとあんまり凄い感じはしないですね。別に SPARQL じゃなくてもできそうですよね。 SPARQL じゃないとできない！みたいなクエリを書きたいですよね。こんなのはどうでしょう。

prefix onto: <http://dbpedia.org/ontology/> select * where { ?girl a onto:AdultActor ; onto:wikiPageWikiLink ?girl2 . ?girl2 a onto:AdultActor ; onto:wikiPageWikiLink ?girl . }

ある女の子の項目が wikipedia にあったとき、そのページに別の女の子のページへのリンクがあり、そのページに行くと元の女の子のページへのリンクがある、つまり wikipedia の項目で相互リンク状態にあるものを取ってきます。共演関係にある可能性が高いですね。この関係性にさらに情報を足していくことも簡単にできます。そう、 SPARQL ならね。

prefix onto: <http://dbpedia.org/ontology/> prefix prop: <http://ja.dbpedia.org/property/> select * where { ?g1 a onto:AdultActor; prop:バスト ?b1; onto:wikiPageWikiLink ?g2 . ?g2 a onto:AdultActor; prop:バスト ?b2; onto:wikiPageWikiLink ?g1 . } order by (?b1 - ?b2)

もう解説はやめておきましょうね。これ、何らかの値が入った ?b1 と何らかの値 ?b2 の差分で並べ替えて結果を表示してるんですが、結果にその差分の情報も出してほしいですよね。前は select のところに (?b1 - ?b2) なんて書いてましたけど、select にも order by にも同じことを書くのはださいので、変数に格納しましょう。bind というキーワードを使えばほら簡単。

prefix onto: <http://dbpedia.org/ontology/> prefix prop: <http://ja.dbpedia.org/property/> select * where { ?g1 a onto:AdultActor; prop:バスト ?b1; onto:wikiPageWikiLink ?g2 . ?g2 a onto:AdultActor; prop:バスト ?b2; onto:wikiPageWikiLink ?g1 . bind((?b1 - ?b2) as ?diff) } order by ?diff

こうすると差分が ?diff という変数に入って、 select * で拾ってもらえます。素晴らしい。で、これを実行するとちゃんと結果は返ってくるんですが、よく見ると何かおかしい。まず最初に気になるのは数字が入っているはずの ?b1 や ?b2 に変なデータが入っています。例えば以下のような。

"95.0"^^<http://dbpedia.org/datatype/centimetre>

これは RDF における単位の表現ですね。” で括った値に <> で囲まれた URI で示す単位を ^^ で繋いでいます。SPARQLの中で何も考えずに ?b1 - ?b2 なんてしたものだから、演算が狂っています。?b1 - ?b2 がちゃんと機能するように、型の変換をしましょう。強制的に整数型 integer に変換します。どうやるかというと、こんな感じ。

<http://www.w3.org/2001/XMLSchema#integer>(?b1)

毎度変換する度にこの長い URI を変数の前に置くのはあまりにかっこ悪いので、これも prefix で置き換えましょう。置き換えた後がこんな感じ。

prefix onto: <http://dbpedia.org/ontology/> prefix prop: <http://ja.dbpedia.org/property/> prefix xsd: <http://www.w3.org/2001/XMLSchema#> select * where { ?g1 a onto:AdultActor; prop:バスト ?b1; onto:wikiPageWikiLink ?g2 . ?g2 a onto:AdultActor; prop:バスト ?b2; onto:wikiPageWikiLink ?g1 . bind((xsd:integer(?b1) - xsd:integer(?b2)) as ?diff) } order by ?diff

で、さらに結果を見てみると ?diff が -900 なんて数字を叩き出しているものが上位に来ています。 ?b2 でセットした変数に 1000 という値が入っているデータがあるみたいですね。なんなんですか。テポドンか。こういう明らかにおかしいデータはあらかじめクエリの中で弾いておきましょう。SPARQL の FILTER という機能を使います。

prefix onto: <http://dbpedia.org/ontology/> prefix prop: <http://ja.dbpedia.org/property/> prefix xsd: <http://www.w3.org/2001/XMLSchema#> select * where { ?g1 a onto:AdultActor; prop:バスト ?b1; onto:wikiPageWikiLink ?g2 . ?g2 a onto:AdultActor; prop:バスト ?b2; onto:wikiPageWikiLink ?g1 . bind((xsd:integer(?b1) - xsd:integer(?b2)) as ?diff) filter(?b1 < 100 && ?b2 < 100) } order by ?diff

定数に何らかの意思を感じるかもしれませんが気のせいです。ともあれ、これで非現実的なデータを取り除くことができました。このデータすごいですね、このクエリを実行した結果から読み取れることは「wikipedia の項目上で共演関係にあると考えられる女の子のペアの何らかの数字の差は最大で 28, 最小で 3」ですよ。わかりますか。これがデータベースが新たな知識を生むということです。

他にも SPARQL にはよく使うカウントとかグルーピングとかサブクエリとか便利な機能がいろいろありますし、 dbpedia だけでなく他のエンドポイントにも問い合わせをしてマージするなんてこともできるんですが、この世に1つ無駄な知識を生み出して満足したの今回はここまで。このエントリを読んで RDF や SPARQL をちょっとやってみようかな？と思った方は是非以下の書籍を買って勉強してください。

オープンデータ時代の標準Web API　SPARQL (NextPublishing)

セマンティックWeb プログラミング

Learning SPARQL: Querying and Updating With Sparql 1.1

あと、毎月 SPARQLthon という各々が黙々と SPARQL を書く会もやっていますのでそちらにもご興味のある方はぜひよろしくお願いします。 http://wiki.lifesciencedb.jp/mw/SPARQLthon

[trattoriainutano]

なぜバイオインフォマティクスの解析はタダではないのか

この記事は Why Bioinformatics Analysis Is Not Free - MassGenomics http://massgenomics.org/2015/10/ngs-analysis-not-free.html の日本語訳です。ところどころ意訳していますが、主旨は変えていません。

This article is translated from “Why Bioinformatics Analysis Is Not Free - MassGenomics” http://massgenomics.org/2015/10/ngs-analysis-not-free.html . I would like to thank Dan for his great and important blog post! ==

NGSの発展は遺伝学の分野にとって大きな助けになっています。NGSはCanceer Genome Atlasや1000 Genomes Projectのように、有益な "ビッグ・サイエンス" プロジェクトを支えています。そして2015年、現在のDNAシーケンサーのスループットは多くの人を興奮させています。ハイエンド機、Illumina X Tenは10,000から50,000の全ゲノムをシーケンスするような大規模シーケンシングプロジェクトを手の届くものにしましたし、研究者はより小さなコホート集団でもシーケンスをすることができます。 

研究者と研究費助成機関の両方がこの安くて速いDNAシーケンスに飛びつきました。ですからみなさんに、"$1,xxx" と書かれたシーケンスの値段は消耗品とテクニシャンの雇用分だけしかカバーしていないのだ、とリマインドするのにまだ遅くはないでしょう。その値段では、FASTQフォーマットの生配列データしか手に入れることはできません。我々のような大きなシーケンシングセンターは、リファレンス配列にアラインメントした結果をBAMフォーマットにして渡すでしょうが、でも、普通それだけです。変異解析をしたり、クオリティ・コントロールをしたり、アノテーションをつけたり、データを出す以上のことをするためには、データ解析をしなければいけません。そしてデータ解析はタダではありません。 

NGSデータ解析のコスト

生の配列データの基本的な解析ですら、お金がかかります。普通、シーケンスの値段について話すときには、これらのコストは考慮されていません。 データの長期保存のためのストレージ

30xのヒト全ゲノムシーケンスから得られる1つのBAMファイルはだいたい100ギガバイトのディスクを使用します。まあまあの規模、たとえば500サンプルを用いて研究したとすると、50テラバイトのディスクが、BAMファイルのためだけに必要です。CRAMのようなlossyな圧縮フォーマットでもこの問題は解決できないでしょう。シーケンサが年に18,000ものゲノムをどんどこ出すとなれば、ディスク容量はとんでもない量になります。 

計算機資源

生の配列データの処理、すなわちリファレンス配列へのマッピング、重複の除去、BAM配列の生成には、多くの計算機パワーを必要とします。我々は10,000人以上分の全ゲノムシーケンスを計画していますが、30xで読まれたそれぞれのゲノム配列は90億塩基対になります。変異解析、クオリティの補正や大規模なゲノムデータセットを使ったアノテーションにも、高い計算機性能が要求されます。これらの要求を満たす計算機クラスターをメンテナンスするだけでも非常にお金がかかりますし、クラウドを使ってもそれは同じです。

データ解析にかかる時間

データ解析はバイオインフォマティクスのプロによってなされなければなりません。高度に自動化された解析パイプラインが用意されていたとしても、配列データを出すチームからデータを受け取り、適切な解析 (マッピングツール、リファレンスアセンブリ、変異解析の手法、アノテーションの元となるデータベースなど) を設定し、解析の進捗を管理し、結果を正しくまとめるためには解析者が必要です。解析を行う人はふつう誰かに給料をもらっていますし、その彼らを1つの研究プロジェクトのために数週間から数ヶ月にわたって拘束することになります。 

解析しなかった場合

現在のような研究費の使われ方では、シーケンスコストが急激に下がることによって問題が起きます：誰も解析に対してお金を払いたくないということです。あなたはこれまで、1000ドルゲノムだなんだと聞いていたのに、今度はデータ解析にも同じくらいお金を払わないといけないと言われているわけです。これでは、かみそりを安く買ってはかみそりの刃でお金を取られ、プリンタを安く買ってはインクでお金を取られるのと同じだと思うでしょう。 

そんな直感的な反応にとって、次に挙げる選択肢は魅力的です： 

「いや、解析しなくていいです」

 この道を選ぶと、BAMファイルだけを受け取れます。ある一定の人々にはこれでもいいのでしょう：彼らは解析の技術と人材を持っているからです。その他の人々は、しかしどのみち誰かにお金を払って解析をやってもらうしかないのです。シーケンスをしてくれる人にお金を払うのと同じです。 

それから、NIHにファンドを受けたシーケンスデータは、多くの場合、猶予期間なしに公共データレポジトリに登録しなければいけません。毎日のろのろと解析をしていると、その間に競合のチームにあなたのデータは使われてしまうでしょう。 

「RFA (Request for application) があるから」

 研究費助成機関はいくつかの大規模なプロジェクトにこのやりかたを採用しています。彼らは配列データを出すためにまずRFAを設定します。それから別のRFAをデータ解析のために設定します。このやり方、データを出すこととデータ解析を分けることには何の得もありません。シーケンスデータを出した人たちが、もっとも解析に適しているはずなのです。微妙なニュアンスも分かりますし、dbGaPに出かけて行ってデータを扱う許可を得る必要もありません(これは本当に悪夢です)。 

それに、このやり方は結果を得て解釈をするフェーズを遅らせてしまいます。シーケンスセンターはシーケンサから出てきたデータを解析するために研究費をもらっていませんし、データ解析のセンターはシーケンスが完了するまで何もできません。これは全く効率の悪いやりかたで、私は全く賛同できません。 

「いいよ、じゃあ <ソフトウェアの名前> 買うから」

 研究者や小さいラボ向けに巨大なNGSデータの解析をサポートする商用ソフトウェアが出回っています。私の考えでは、2つの問題があります; まずひとつに、彼らは長い時間を費やして綺麗で使いやすいインターフェースを開発していますが、解析アルゴリズムは私たちが1年前に使っていたものです(*1)。2つめ、とにかく高い。 

「学生かポスドクにやらせるよ」

 いつだって、タダで使える労働力として学生やポスドクを使う誘惑からは逃げられないでしょう。不幸な彼らは、しかし、データ解析に必要とされる技術をまだ持っていません。彼らは2ヶ月を費やしてどうやってBWAを動かすかを学ぶでしょう（しかも我々のような人間に質問しながら）。普段からその仕事をやっているプロに任せて、彼らはその時間を学振や科研費の申請、論文を書くことに使うべきです。 

データ解析に対価を払うメリット

データ解析にかかるお金について書くといつも値段が高すぎて驚かれます。しかし、多くの重要なご利益があるのです。まず第一に、あなたは非常に高いクオリティの結果を、実際に使うことのできる形で得られるでしょう。第二に、その結果は専門家によって選ばれた最適な手法が実行された解析によるものとなるでしょう。それに、他のグループにデータが渡す手間なく解析を始めることができ、in-houseの解析の方が早く結果が得られます。 

そしておそらくもっとも重要なのは、データ解析にきちんと対価を払うことは、プロジェクトがうまくいくということです。シーケンスのエキスパートはシーケンスを、疾患のエキスパートは疾患についてしっかりと貢献することができるからです。全員がそれぞれの強みを活かしているのですから、全員がちゃんと研究費でサポートされるべきです。私の意見では、これが最善な科学のやり方です。 

== 

著者はWashington Univ.の方なので、基本的にはUSの話になっていますが、「シーケンス安いじゃん！っつってデータ出したけどデータ解析にお金かかるなんて聞いてない」という話は東の果ての島国でもよく聞く話です。解析に金をケチるな、プロに任せろ、ということですが、個人的にはこれに「シーケンスする前に解析のプロに相談しろ」ということを加えたいです。「データを出した人がもっともデータのことをよく知っている、だからデータ出した人がデータ解析するのが理想」というのはすなわち「データ解析のことを分からない人はデータを出してはならない」ということです。NO MORE 論文にならないfastqファイルの山。 

しかし現実は非情であり、この国で解析のプロを自認する人々はそれほど多くはない上に、彼らは常に「解析の進捗どうですか？」と追い回されています。データ解析ができる人がラボにいない場合は仕方がないので、以下の2つの書籍を両方購入(*2)して、自分がプロになりましょう。データ解析やコンピュータの扱いに自信がない人も、この2つの書籍を読んで実践すれば、セミプロレベルには間違いなくなれます。おすすめです。 

次世代シークエンサーDRY解析教本

次世代 シークエンス解析スタンダード

*1: 商用ソフトのアルゴリズムが古いというのは言い過ぎで、全てがそうではありません。オープンソースのものよりも性能のよい独自アルゴリズムを採用しているソフトウェアなどもあるので、確認してみましょう。 

*2: アフィリエイトリンクを貼っていますが、もしビール1杯分以上の収入があった場合はシリアの難民のサポートに寄付しますので遠慮無く買ってください。

[trattoriainutano]

落雷からマシンを守る停電装置をつくった

国立遺伝学研究所の所在地である静岡県三島市は雷の影響で停電することが多く国立遺伝学研究所のサーバはそのせいで年に数度止まります。遺伝研の誇るスーパーコンピュータ「逢沢りな」は無停電電源装置がついているので安全に電源を落とすことができますが、それ以外のサーバは常に突然の停電による故障のリスクを抱えています。

無停電電源装置は高いので、雷が落ちる前に勝手にシャットダウンする停電装置「thunderbuddies」をつくりました。

https://github.com/inutano/thunderbuddies

これは元々遺伝研スパコンのSEチームで運用されていたものをほんのちょっと改良してruby gemにしたものです。gem installなどでインストールしたら

$ sudo thunderbuddies halt

というコマンドをcronなどで定期的に実行すると、雷がやばくなるとマシンが落ちます。

何をしているかというと、気象庁の「雷ナウキャスト」から画像を取得して落雷レベルを検知、指定したレベル以上になるとマシンの電源を落とします。今朝も落雷で遺伝研が停電してつらい気持ちになったので勢いで作りました。

勢いで作ったので機能は貧弱で、実行時にロケーションの指定ができるのですが、今のところ指定に関係なく三島の天気に応じてマシンが止まります。指定した場所が東京だろうがアメリカだろうが三島に雷が落ちると問答無用でマシンが止まるため実用性は皆無ですが、悲しみを分かち合ってくれる方は是非導入をご検討ください。

ヒマができたら位置を指定できる機能も追加したいですが、自分の用途にはこれで足りるのでpull requestをお待ちしてます。

なおCLIを用意するためにThorを使っているのでこれを起動すると余計に雷が落ちそうな気もしています。

[trattoriainutano]

ChIP-Seqデータを解析しない

NBDCと東大農アグリバイオインフォマティクス教育研究ユニットによる「次世代シークエンサ(NGS)ハンズオン講習会」にアシスタントとして参加してきました。

http://biosciencedbc.jp/human/human-resources/workshop/h27

BioLinuxのインストールにはじまり、Linuxでのコマンドラインの使い方、スクリプト言語やNGS解析の基礎、代表的なNGSアプリケーションについてそれぞれの解析方法など、約2週間かけて行われるハードコアな講習会です。ハードコアですが、普段からデータ解析にチャレンジしてみたい、でもどこから取りかかればよいか分からないという人にとっては、えいやと時間を取ってみっちりとトレーニングを受ける、絶好の機会ではないかと思います。「全日程参加できる方から優先的に参加を受け付ける」としていたこともあり、他のトレーニングコースに比べてモチベーションのより高い参加者の方が多い印象があります。

しかしこのようなハードな講習会に来られている方の多くは、普段データ解析をするインフォマティシャンやそのテクニックに触れる機会が少ないのではないかと推察されます。そうであればなおのこと、折角時間を取って覚えたことも使わないと忘れてしまいますし、本当に大変なのはトレーニングを受けたあと、いかに学んだことを日々の暮らしに組み込んでいけるかという点だと思います。

その点で、アシスタントといえど軽い気持ちでサポートをするわけにはいきません。たとえば「講師の言う通りにコマンドを打ったけれども動きません」とヘルプを求められたとき「こうすれば動きますよ」と単に直してあげるだけなら簡単です。しかし「なぜ動かなかったのかを推測する」「推測される原因から解決策を探す」その方法を含めて示さないことには、別の場面で応用ができませんし、そうなってしまうと折角のトレーニングの機会が無駄になってしまいます。自分のラボに戻れば講師もアシスタントもいないわけですから、2週間のトレーニングコースを普段からコンピュータを使ってデータを解析している人の習慣や考え方に気付くチャンスとして活用してもらうことで、長く役に立つスキルを持って帰ってもらえるといいのかもしれない、アシスタントをしながらそんなことを考えていました。一言「エラーメッセージをそのままGoogleにコピペして上から全部ドキュメントを読め」というだけといえば、まあそうなんですが。

アシスタントが大変なら講師はもっと大変で、大勢の人を相手にハンズオンをやるというのは、僕自身の経験からも、それはもう本当に大変です。しかし僕が参加したアメリエフ株式会社 服部さんによるPythonのコースと理研森岡さんによるChIP-Seqデータ解析のコースはどちらも充実したよい内容でした。参加者の多いハンズオンは一度に多くの人に対してコースを提供できるメリットと同時に、参加者の興味や技術レベル、リテラシレベルの分散によってはいまいち響かないものになってしまうリスクもあるのですが、お二人のコースに関してはとてもうまくいっていたと思います。興味のある方は、 こちらのページ に資料がアップされていますので、是非チェックしてみてください。

講師のテンションがおかしい

さて久々にエントリを書いたかと思えばお利口さん気取りの感想文だけを置きにきたわけではもちろんありません。ではなんなのかというと、まずは @suimye こと理研森岡さんによる愉快なトークでお届けしたChIP-Seqデータ解析コース、その講習用ページをご覧ください。https://github.com/suimye/NGS_handson2015

ChIP-Seqの原理からはじまりプロットまで、講習の流れが示されているところをざっと見て、ページ一番下の「中級者以上コース（一匹狼たちへの課題）」というリンクに注目してください。括弧内の文言の意味がよくわかりませんがクリックするとこちらのページに飛びます。ページを開いてみてください。https://github.com/suimye/NGS_handson2015/wiki/NGS_senior

控えめに言ってもファンキー過ぎるページですが、僕はこういうの好きなので気にしません。いずれにせよ、1日のトレーニングは朝から夕までおおむねこのテンションで続きました。参加者の方々は始終「こんなときどんな顔をすればいいか分からない」というような表情でいらっしゃったのが傍から見ている分には大変愉快でした。笑えばいいと思うよ。

ともあれ、ウェブページです。何かヤバいクスリでもキメてるんじゃないかというテンションのあたりはとりあえず無視して見ていきますと「問題」という欄があります。

ファイル kaeru.nazo.fastq.gzは、ヒトの細胞を由来とするChIP-seqデータである。実習および講義で教わる操作および独自のアイディアで、このChIP-seqデータの転写因子名を調べよ

つまりChIP-Seqのトレーニングコースは自分でさっさとやってしまった！簡単過ぎるぜ、もっとタフなタスクをよこせ！というマッドな参加者を想定してこのような課題を用意してくださったようです。気が利くんだか、カエルの写真も脈絡がないし単に貼りたかっただけなんじゃねえーかとか、まあ、いいんですけど、こういうの、みなさん好きですよね？

やってみよう

というわけで、この課題にチャレンジしてみます。「素敵なプレゼント」とか、嫌な予感しかしないですけど。どうせカエルのぬいぐるみです。

正攻法でいくと、fqをヒトゲノムにマップしてピークコール、結合領域のモチーフから転写因子を探るなどのやり方がありますが、それだとあまり面白くないので、データベース屋として、データベースだけを駆使して転写因子を当ててみましょう。

まず、fastqをダウンロードして中身を見てみます。gzipで圧縮されていますが、気にせずlessで中身を見ます。

$ less kaeru_nazo.fastq.gz @KAERU.13652678 HWUSI-EAS366_145:6:26:14947:20927/1 TGGCTGGCAACAATAGATACTGGGGACTACTAGACA + #################################### @KAERU.46814293 HWUSI-EAS366_145:6:95:12328:13457/1 AATGGAATTGAATGGAATGGAATTGAATGGAATGGG + ,7>>21?############################# @KAERU.9734561 HWUSI-EAS366_145:6:19:12517:8892/1 TTGAGATGGAGTCTTGCTCTGTCGCCCAGGCTGGAG

おそらく答えとなる転写因子はあまりマニアックすぎないもので、クセのないデータを用意しているのでは、そして自身の研究データはコラボレータとの同意などの手間を考えると使いづらいので、公共DBで公開されたデータを使っているのではないか、公開データだとしたらfastqのリードIDの文字列中にSRAのIDが入っているのではないか…という予想からファイルの中身を見てみましたが、なんか KAERU とか書いてある。芸が細かいというかなんというか。

SRA IDがあればそのIDで検索すればすぐ分かるのですが、今回はそれを許してはくれないようです。残念。しかし一歩前進です。@で始まるID列、”HWUSI..."から始まるこの部分はシーケンサの機械固有のID、レーン番号、タイル番号、クラスタの座標と続く、イルミナのシーケンサから出力されたものだと思われます。そしてこの機種名の前に文字列が入っており、そこをKAERUとわざわざ書き換えているということは、これは元々SRA Run ID (SRR ID)があったものと考えられます。

IDはありませんでしたが、諦めるのはまだ早い。シーケンサの機械固有のID、これをキーにして公共DBから同じ機械によって出された配列データをリストアップすれば何か分かるかもしれません。

このようなシチュエーションにはこれまで遭遇したことがなかったので、各公開データとシーケンサの機械固有IDを紐付けたDBは残念ながら手元にありません。イルミナのシーケンサから得られた全ての公開fastqデータからシーケンサの固有IDを攫うにしても、なんせHiSeq2000だけで56万実験セットとかあるので、ちょっと時間がかかりそう。まあ、ダメ元でgoogleに突っ込んでみましょう。

なんか出た!!

2件ですがヒットしました。どうやら同じことを考えたのか、 @ma_ko というインターネットユーザがこのファイルを見てうんざりしたらしいという情報が2件目に見つかったのも収穫ですが、1件目にヒットしたこれはまさしく公開されたfastqのリードIDの文字列です。しかもURLから見るに、今回と同じNGS講習会の、昨年のテストデータのようです。これは怪しい。「実はこのデータは昨年使ったものでした〜！ワハハ！」みたいな展開、めっちゃありそう。

しかし、検索にヒットしたものはレーン番号が3番で、課題のfqは6番でした。わざわざレーン番号に細工をするというのはちょっと考えにくいので、「同じシーケンサから出た別のデータ」を疑って調べていきます。プロジェクト単位で見るために、この SRR445816 っていうやつを http://sra.dbcls.jp/search で見てみましょう。

手前味噌なんですけど、これはうちで作ってる公開データのレポートを出力する検索システムです。SRAの新しいスキーマにまだ対応していなくて、しばらく新しいデータが更新されておらず、現在システムのアップデート中なのですが。ともあれ、試しに検索してみましょう。

なんかそれっぽいの出た！！

転写因子 Oct4, Sox2, Klf4, c-Myc をゲノム上にマップするプロジェクトにおける一連のシーケンスデータのセットのようです。これは正解に近づいた予感がする。講師も「論文のピークを信じるな、ピークコールのスレッショルドは目的に応じて恣意的に決められるのだから自分の研究に利用したければ元データを再計算しろ」と言っていたし、この論文の再解析を行った可能性はありそう。

同じプロジェクトで得られた Run は全部で7つ。最初のSRR445816がgoogleでヒットした、昨年の講習会でテストデータに使われたデータですね。この下に並んでる中からレーン番号6番でシーケンスされたデータが見つかればそれが一番怪しい。 “FTP” をクリックしてDDBJのFTPに接続して、データをダウンロードして、それぞれのデータを順番に見てみます。

$ less SRR445817.fastq.bz2 @SRR445817.1114 HWUSI-EAS366_145:4:1:5805:1023 length=36 NNNNNNNNNTNNNNNNNNNNNNNNNCNGNNNNNNAN +SRR445817.1114 HWUSI-EAS366_145:4:1:5805:1023 length=36 #################################### @SRR445817.1117 HWUSI-EAS366_145:4:1:5974:1021 length=36 NNNNNNNNNANNNNNNNNNNNNNNNANCNNNNNNAN +SRR445817.1117 HWUSI-EAS366_145:4:1:5974:1021 length=36 #################################### @SRR445817.1118 HWUSI-EAS366_145:4:1:6008:1017 length=36 NNNNNNNNNCNNNNNNNNNNNNNNNTNTNNNNNNCN

4番レーン。ちがう

$ less SRR445818.fastq.bz2 @SRR445818.781 HWUSI-EAS366_145:5:1:1107:1023 length=36 NGTCCNNNNNNNGNNNNGGNAAGAACGNNAAANNNG +SRR445818.781 HWUSI-EAS366_145:5:1:1107:1023 length=36 #################################### @SRR445818.782 HWUSI-EAS366_145:5:1:1156:1021 length=36 NGTATNNNNNNNNNNNNGNNNACTTTGNNNANNNNC +SRR445818.782 HWUSI-EAS366_145:5:1:1156:1021 length=36 #################################### @SRR445818.784 HWUSI-EAS366_145:5:1:1335:1022 length=36 NAAGANNNNNNNNNNNNATNNGGGGGCNNTTTNNNA

5番レーン。ちがう

$ less SRR445819.fastq.bz2 @SRR445819.912 HWUSI-EAS366_145:6:1:1164:1034 length=36 GAGGCNNNNNNANNNNNNNACTGGCACAANATTNAA +SRR445819.912 HWUSI-EAS366_145:6:1:1164:1034 length=36 #################################### @SRR445819.913 HWUSI-EAS366_145:6:1:1323:1025 length=36 NGNNNNNNNNNNNNNNNNNNNNNAANNCNNNNNNNN +SRR445819.913 HWUSI-EAS366_145:6:1:1323:1025 length=36 #################################### @SRR445819.914 HWUSI-EAS366_145:6:1:1420:1030 length=36 NAGGNNNNNNNNNNNNNNNANCGAGGGCNNGANNNN

6番レーンだ!!!

ということでこの SRR445819 が同じシーケンサの機械の同じレーンから得られたデータだと分かりました。もちろん、まだ同一 Run である保証はないので、確かめてみましょう。

まず展開後の kaeru_nazo.fastq が 31,236,448行 (7,809,112 reads), 946MB で SRR445819.fastq が 240,113,360行 (60,028,340 reads), 12GB 。サイズは全然違いますが、ヒト細胞のChIP-Seqで700万リードというのは少ないので、これは実習の難易度 (というか計算時間) を下げるためにreduceしたと考える方が自然です。そうすると、 kaeru_nazo.fastq 中のリードが SRR445819.fastq からも出てくればまあ当たりだと考えていいんじゃないでしょうか。

$ head kaeru_nazo.fastq @KAERU.13652678 HWUSI-EAS366_145:6:26:14947:20927/1 TGGCTGGCAACAATAGATACTGGGGACTACTAGACA + ####################################

$ grep -A 4 'HWUSI-EAS366_145:6:26:14947:20927' SRR445819.fastq @SRR445819.13652678 HWUSI-EAS366_145:6:26:14947:20927 length=36 TGGCTGGCAACAATAGATACTGGGGACTACTAGACA +SRR445819.13652678 HWUSI-EAS366_145:6:26:14947:20927 length=36 ####################################

当たった。

もうちょっとちゃんと確かめた方がいいんだろうけど、まあ、もうこれでいいんじゃないかな…。

kaeru_nazo.fastq は SRR445819 由来ということにします。じゃあこの SRR445819 は先に挙げた論文のシーケンスのうち、どの転写因子の抗体を使ったものなのかを調べれば答えが分かります。通常、Sampleの情報に使った抗体や細胞株を記述してあって欲しいのですが…

書いてなーい。イェーイ。

ご安心ください。よくある話です。別のどこかのDBにこのサンプルのデータが登録/記述されていないか見てみましょう。

SRR445819に対応するサンプルのIDはSRS300774です。今回のデータに関連する一連のIDはSから始まっており、これはNCBIに登録されたデータであることを示しています（ちなみにEから始まるのがEBIが受け付けたデータ、Dから始まるのがDDBJ）。NCBI, EBI, DDBJではさまざまな登録データのサンプル情報を別に管理するBioSampleというDBを運用しており、ここに情報がある可能性が高い。おもむろにNCBI BioSampleにSRSのIDを突っ込んで検索してみます。

雑な検索だけど気にしない。

イエーイ！

c-Mycの抗体を使ったChIP-Seqに使われたSampleの情報が表示されました。つまりこれが先ほどの配列データの元のサンプルの正体です。

無事それっぽい答えにデータベースだけを使って辿りつくことができました。辿りつけましたが、なんかあんまり達成感、ないですね…。fastqを投げ込むと「これだよ」と答えを出してくれるシステムを作ろうかな。

講習終了後、参加者がいなくなってからこっそり講師に「あれc-Mycでしょ」と伝えると「正解―！！！」正解だそうです。「プレゼントあげるよー！！2つあるから2つあげる！！！」

2つももらってしまった。インチキなのに…。まあいいか。何が入っているんでしょう。

なんだこれ……………………………。

オーガナイザのNBDCの方々、アグリバイオの門田さんはじめアシスタントのみなさん、そして偉大な講師のみなさま、お疲れさまでした。おしまい。

[trattoriainutano]

米国全州で屋内のメタゲノム。家の入口のドアの上をswabして集めたデータだとか。1サンプルあたり平均して4700のバクテリア、1700の菌類が見つかったそうな。同じ州の中での都会と田舎の明確な違いというのはなかったとのこと。でも、ノースカロライナの都会(Raleigh)と田舎より、ノースカロライナの都会とNYCの方が似てるから、都会と田舎は微妙に違うのだ、という話がgenomewebで紹介されている。

[trattoriainutano]

オープン・サイエンス・アワードを開催しました

かねてよりオンラインを中心に宣伝をしておりましたオープン・サイエンス・アワードを開催しました。その投票結果を受けて、各部門上位3つ、合計9つのプロダクトについて開発者に生命医薬情報学連合大会のBoFセッションにおいて講演を依頼しまして、7人の方が引き受けてくださいました。学会の２週間前と直前にも関わらず快く引き受けて下さったみなさまには大変感謝しております。また、同時間帯に開催された他のセッションがどれも興味深いものばかりであったところ、我々のセッションにお越し頂いた聴衆のみなさまにも、ここで改めてお礼を申し上げたいと思います。みなさま、どうもありがとうございました。

学会開催直前ということもあり、オンライン要旨集への掲載が間に合わなかったこともあり大会公式ウェブサイトにはセッションの要旨だけが掲載されるという状況でしたので、ここであらためてセットリスト、ならぬセッションのタイムラインを敬称略で掲載させて頂きたいとおもいます(セッションの要旨は大会ウェブサイトに掲載されたものから引用しています)。

オープン・サイエンス・アワード 2014

Chairs 大田達郎 (ライフサイエンス統合データベースセンター) 片山俊明 (ライフサイエンス統合データベースセンター)

オープン・サイエンス・アワードは、国内を中心に開発され、生命医学分野において共有される、自由なライセンスの元、無償で利用できる「オープンな」成果物を、コミュニティによる投票を元に表彰する企画である。インターネットを通じて共有されるツールやデータ、リソースの中には、研究活動を推進するために必要不可欠であるにも関わらず、研究活動を評価する一般的な指標としての論文において、主たる成果として取り上げられることがないものも多い。そこで我々は、広く生命科学のコミュニティにおいて共有される成果物を集め、コミュニティによって投票を行い、得票の多いものを表彰する本企画を立案し、昨年2013年に第一回オープン・サイエンス・アワードを行った。医学生物学分野における研究活動の進歩に対して、新たな情報技術を用いた手法の発展を促進するために、本企画を継続し、第二回オープン・サイエンス・アワードを企画する運びとなった。 第一回と同じく投票対象をデータベース・ソフトウェア・ウェブサイトの3つのカテゴリに区分し、企画ウェブサイト上 (http://2014.openscienceaward.org/) で投票を行う。投票には学生/研究者、ウェット/ドライ、アカデミア/企業などの立場を問わず分野に関わる多くの方に参加を促し、得票の多い成果物については、その開発者に本セッションでの講演を依頼する。

16:20 - 16:25 セッション開催趣旨 - オープン・サイエンス・アワードについて 大田達郎 (ライフサイエンス統合データベースセンター)

16:25 - 16:35 データベース部門第三位 Microbial Genome Database for Comparative Analysis 内山郁夫 (基礎生物学研究所)

16:35 - 16:45 データベース部門第二位 CyanoBase 中村保一 (遺伝研)

16:45 - 16:55 データベース部門第一位 MarineGenomicsDB 川島武士 (沖縄科学技術大学院大学)

16:55 - 17:05 ソフトウェア部門第三位 ピタゴラギャラクシー 芦崎晃一 (理化学研究所)

17:05 - 17:15 ソフトウェア部門第一位 difff «ﾃﾞｭﾌﾌ» 内藤雄樹 (ライフサイエンス統合データベースセンター)

17:15 - 17:25 ウェブ部門第二位 パックマンの挑戦　－　PacBioシークエンサー 大崎研 (トミーデジタルバイオロジー株式会社)

17:25 - 17:35 ウェブ部門第一位 Togo Picture Gallary 比留川治子 (名古屋大学 トランスフォーマティブ生命分子研究所)

17:35 - 17:45 ライフサイエンスQA コミッターアワード 中尾光輝 (エーザイ株式会社)、山田学 (かずさDNA研究所)、大田達郎 (ライフサイエンス統合データベースセンター)

17:45 - 17:50 受賞者表彰式

セッションレポート

参加者は全部で20〜30人くらいだったでしょうか。途中で出たり入ったりされた方、スタッフも合わせれば40人くらい。行きたかったが同時間帯の別のセッションに出かけてたので来られなかったと言ってくださった方と、内心そう思っている方を合わせると多分100人くらいです。総参加者数が300人程度？の会でこれだけ集まれば大盛況と言っていいでしょう。継続して開催するのが肝要であろうとのお言葉を色々な方から頂いておりますので、次回があれば他のセッションのチェアまで見にくるぐらいを目指して工夫していきたいと思っています。

緊張感のある堅いプレゼンというのがへたでして、相変わらずのほほんとした僕の趣旨説明のプレゼンから始まりましたが、どの講演者の方もさすがと言うべきでしょうか、単にプロダクトの紹介をするに留まらず、その歴史であったり、理念であったり、笑える小ネタであったり、人生訓であったり、そういったものを随所に散りばめられており、来ていただいた方はみなさん満足して頂ける内容だったのではないかと思っています。質疑応答の時間でも全てのプロダクトについて質問や議論があり、開発者とユーザという関係でのコミュニケーションを行う場としても機能したのではないかなと考えています。講演には9人お声がけしたところ7名も来て頂き、有り難い限りです。ソフトウェア部門二位のMEGAを開発された首都大学東京の田村先生、ウェブ部門第三位のご自身のウェブサイトで情報を発信されている井上先生は残念ながらご都合がつかずお招きすることができませんでしたが、会では表彰と感謝の意を述べさせて頂きました。

また、生命科学に特化したオンライン質問サイトである「ライフサイエンスQA」において質問したり質問に答えたりと貢献されている方を表彰する「LSQA Commiter Award」も同時に開催させて頂きました。こちらはユーザの方から声が上って急遽企画したものですが、QAサイトで定量的指標として用いられるユーザの「信頼度」が高い方上位三名にお声がけしました。そのお三方、かずさDNA研の山田さんは実際にセッションにお越し頂き、空間的には都合がつかなかったエーザイ株式会社中尾さんにはFaceTimeで前方プロジェクターに大写しになって頂き、空間的にも時間的にも都合のつかなかった藤井さんからはメッセージを頂きまして、10分ほどのパネルディスカッションを行いました。よりLSQAを盛り上げるために、最も貢献されている方々を表彰すると共に、QAシステムで答える人は何を考えているのかということをお聞きしようというものです。回答している人は研究者はもちろん技術者や学生など普通の人であること、公の場で質問することはストレスがかかるので気が引けるけれども、質問者に対して敬意を払われる限りは、誰かが質問をすることで同じ疑問を抱える他の多くの人も救われること、また積極的に回答することで、巡り巡って回答者本人にとってもメリットがあることなどの意見が得られました。また、イベントや学会セッションなどで人が集まった際に皆がそれぞれが分かるLSQA上の質問に答えるAnswerthon的なイベントも開催してはどうかというアイディアがありました。

また、今回受賞者への副賞として景品を提供して頂けるスポンサーを募りましたところ、Amazon Web Servicesを提供しているアマゾンデータサービスジャパン様から技術書とノベルティステッカーをご提供頂きました。DBCLSのノベルティグッズ詰め合わせと共に、受賞者のみなさまにお渡ししました。この場を借りてお礼申し上げます。ありがとうございました。

連合大会の参加者層の中でも日本バイオインフォマティクス学会(JSBi)の会員が多い本会において、JSBiの年会を盛り上げるためにもぜひここで続けてくれないかという大変有り難いお言葉もセッション中に頂戴しました。大変光栄であると思っています。思っていますが、この企画は言い出しっぺの僕が1人でやっているわけではなく、趣旨に賛同して、ノミネートや投票に参加して頂いた方々、口コミで企画について広めて頂いた方々、twitterで言及して下さった方々、そして快く講演を引き受けてくださり仙台までお越し頂いた開発者のみなさまあってのイベントなので、今後ともどうぞよろしくお願いいたします。