今年を振り返ります

今年を振り返るために、過去のエントリを眺めてみたが、ポケモンGOと食べ物関連のエントリしかなかった。この1年は家であんまりコード書けなかった感じ。職場では結構書いたけど来年はもう少し公開できるようなコードを書ければいいなと思っています。食べることに関しては引き続き美味しいものを開拓していきたい。

ポケモンGOに関しては今1000万XP弱で再開した時点で250万XPくらいだったので、どんだけやったんだ?って感じ。LV40まであと1000万XPなので週末の運動がてら継続したい。

仕事関連

今年は色々と新しい取り組みが出来て良かったと思っている。チームの皆さんに助けられて、大きな前進が幾つかあったし、自分たちのチームのプレゼンスも高められたと思っている。

色々とタイミングが良かったのだろうと思っている。そして企業のなかのチームっていうのはある意味スタートアップみたいなもんだけど、スタートアップと違うのはタイミングよりもチームのほうが重要なんじゃないかなと。良いチームだからうまくタイミングを見極められるのではないのかなーと。実際、全てそうだったしね。下のTEDはためになると思うので一度は聞いておくことをオススメします(7分弱だし)。

それから「誰をバスに乗せるか」はやっぱり重要なんだなーと感じたけど、そういうバスを用意するかというあたりも今後考えなきゃならないんだろうなぁとは感じている。

ProductName ビジョナリー・カンパニー2 飛躍の法則
ジム コリンズ
日経BP社 / ?円 ( 2014-08-29 )


他にはこのあたりを実践して、OSQAと社内twitterを導入してみたところ、色々とつながりも増えたし、よいアイデアやソリューションもシェアリング出来てよかったかなと思った。それからイントラGithubクローン便利すぎ。この1年でシステム周りが改善されて快適にコード書いたり、計算できるようになったかなと。

仕事以外のしごとっぽいこと。

mishima.sykのサイトを作った。これもコミュニティが良いから継続できてていいですね。来年も皆さんで集まれたら良いなと思います。

Bioinformatics関連

Dr. Bonoの生命科学データ解析-読書会に参加してバイオインフォ愛が戻ってきたのと、今後に関してちょっと思うところがあって、余裕があればターゲットファインディング周りも少し手を付けていきたいなぁと思った。open target platformなどのAPIついてるサービスを上手く活用できないとなーと思っている。

ただ、周りの状況を聞いていると、今の状況って僕がバイオインフォをやっていたポストゲノムって言われてた15年くらい前にやっていることと基本変わってないので(だから余裕でついていけるw)機械学習というよりはアブダクション的な手法が求められるのかなーという気はちょっとしている。最近の状況丁寧にサーベイしているわけではないから間違っているかもしれないけど、ターゲットファインディングが相変わらず難しいという状況には変わらないのかなと。

ProductName アブダクション―仮説と発見の論理
米盛 裕二
勁草書房 / 3024円 ( 2007-09-20 )


それではまた来年もよろしくお願いします。

いまさらビッグデータのこと

ビッグデータという5年ぐらい前に流行った言葉が最近この業界で流行っているので、なんだかなーと思いつつ昔買った本を読み直してみた。

ProductName ビッグデータの衝撃
城田 真琴
東洋経済新報社 / ?円 ( 2013-05-02 )


  • 3Vに照らし合わせて、ビッグデータと呼んでもいいねと思える生命科学関連データって実際どんなものがあるのだろうか?
  • データが増えることで、新たな知識の発見に繋がる可能性のあるビッグデータはどのVなのだろうか?
  • pubmedのような自然言語のデータはビッグデータと呼ぶのだろうか?

Wikipediaによると

ビッグデータ [1][2](英: big data)とは、市販されているデータベース管理ツールや従来のデータ処理アプリケーションで処理することが困難なほど巨大で複雑なデータ集合の集積物を表す用語である。

と定義されているのに、publicなデータベースをビッグデータって呼んでみたり、ビッグデータDBとか言っちゃうのはなんだかなーと思うんだよねー

言葉の乱れはサイエンスの乱れというかきちんと理解していない証拠なんだろうけど。

特に新規疾患ターゲット探索で使う手法って僕がゲノム創薬とかいう名目でバイオインフォマティクスやってた頃に比べて、すごく目新しい手法ってあんまり出てない気がするんだけどそういうわけじゃないのかな?っていうあたりが知りたいんですよね。バイオインフォマティクスとかテキストマイニングとか。

もし土曜日に会う人で、「 俺がレクチャーしちゃる 」っていう方がいたらよろしくお願いします。

コンソとかキャリアとか

分かる人にだけ分かればいい話というか駄文です。ちょっとそれ系の話が続いたので、実際転職して今の会社に入って感じたことをメモっておきます。

コンソの意義は何か?

前の会社も、今の会社も普通にコンソーシアムに入ります。ではコンソーシアムの参加意義は何なのでしょう?

たいてい、「先端技術の導入、プレコンペティティブな知識の共有」といったような如何にもなセンテンスが出てきますが実際は違うと思います。

「周回遅れを避ける」

これに尽きると思います。その技術を持っているのであれば「教えて君」的な人達の相手をする暇なんてありません。独自に進んでいくか、先端を走っている同士で共同研究すればいいので船頭は増やす必要はないです。

なので、新規参入でコンソを利用するのはありだけど、それは先頭を走っているというよりはサイエンティストとしては二流の位置にいるということを強く感じたほうがいいでしょう。

キャリア?

キャリアはキャリアブルスキルの略です、意外に認識されていないことが多いですが。つまり、他社に移ってもそのまま使えるスキルのことだと考えて良いでしょう。

他社に移っても使えるかどうかは、他社の現場のヒトに判断されることが多いと思います(当たり前ですが)

なので、外部発表の機会があれば積極的に発表しておくほうが良いと思います。その会社にマッチするかどうかの判断に使うことも出来ますし、何が出来て何が出来ないか明確になるので先方からどういう技術で来て欲しいというような具体的な話にすぐなるのでわかりやすいです。

外部発表しないで自分を認知してもらうというのは結構ハードル高いと思います。論文出すとかはもちろんありますが、なにかあった時に誘ってくれるのはそういうコネクションなので、そこら辺は若いうちから意識しておいたほうがいいと思います。

なにより、他社の優秀な人達とディスカッションするのは楽しいし、刺激になりますしね☆

なので、興味のある人は観光がてら遊びに来るといいと思います。

Mishima.syk #10やります

次回の日程は7/8(sat)に決定しました。参加登録は以下からお願いします。

2回程ハンズオンが続いたので、今回は発表メインでいこうかと思います。思う存分ネタをぶっ込んで下さい。

僕はpymol関連の話かpygamessをRDKitに対応させた話とかそんなのを出来ればいいなと思っているけど、どっちもまだ実装途中なんだよなぁ。

やごみで打ち合わせ

久々にやごみで。

真鯛とホタルイカ

1494534344 1494534347

ネギトロ

1494534349

尚、次回の勉強会は7/8(sat)の予定です。会場押さえてconpassの用意が出来たらまたアナウンスします。 今回はテーマは特に決まってないので好きなことを喋る会になるかもしれません。

「知識管理システムを導入したい」ではうまくいかないのでは?

知識管理システムを導入するだけで全て上手くいくと思っているヒトが多いなぁと。そういうヒト達は「自分たちにはITスキルがないからソフトの導入が出来ない」と言い訳するのもステレオタイプな気がする。

そもそも真の課題は「システムの助けを借りて知識管理する文化を醸成したい」というのが正しい認識だと思うのだが、上記の人達は文化醸成のための努力をする気が全く無いので、ソフトの導入がゴールになってしまい結局うまくいかないのかなぁと思う。

で、うまくいかないのをソフトのせいにして、別のソフトを導入すれば今度こそうまくいくかもとまた夢をみてしまうという負の連鎖が起きているのではないだろうか?

ひなよしで飲んだ

前の職場の同僚という後輩が近所に転職するので、同僚とその転職先知り合いとひなよしで飲んできました。

ちょっとここでは書けないけどどこも困っているんだなぁっていう話とか色々できて楽しかった。 尚、今回は静岡出張無しで帰宅した。

お通し。お酒は一升瓶から注いでくれます。升にこぼして戻すスタイルは賛否両論あるかと思う。

1492034581 1492034584

あんきもと造りの盛り合わせ

1492034587 1492034589

のどぐろは美味しかった

1492034592

そういえば、今の会社の謎メール文化を伝搬させようと出向いたんだけど、ひなよし着いた瞬間にそのこと忘れてしまった。

  • 「謎のスラッシュルール」と転職組に命名されているメール仕様(尚、暗黙w)
  • メールのCcに自分のメールアドレスを入れる風習(たまにうざくてメールを即消すらしいw)
  • フラグを立てずに【重要】とか【読み飛ばし禁止】とか書いてある

久々のgawa mishima

久しぶりのgawaです。前職の同僚と飲んできました。

1488805962

お店のポリシーで料理の写真は撮れないので。でんでんという魚とエゾシカとメインで頂きました。あとデザートは相変わらず最高でした。僕はショコラテリーヌ一押しです。でもガワを話題に出すとスイカのショートケーキを推す人が非常に多いですね、「お前もかー」って突っ込みたくなるw

別件ですが、イズシカレーが微妙だったのは自分のテクのせいらしいということを再確認してちょっと凹んだ。まぁわかってはいたのだけど。次は上手に作りたいところ。

それからなんつーか、自分の作った基幹系のうち一つは廃棄するっていうから引き継ぎしなかったのに方針が変わって未だに動かしてるってのには笑った、というかあれは廃棄できないだろうと思っていたからそうなんだろうなと。

あと、システムはやっぱり使ってくれるヒトがいて初めて生きるんだよなーと再確認。辞める時500ターゲット追いかけてたのは把握してたけど、週末聞いたら700ターゲットに増えてたw

一人で500ターゲット以上の動向を追いかけるシステムと人間が存在するっていう話を聞いたら、今の会社の企画のヒトは多少なりとも自分の存在意義に対してもやっとするんだろうか?

会社を辞めるときにはノックアウトインフラを試してみたいと思っていたけど、実際辞めてみると関わってなくても基幹システムはちゃんと動き続けて欲しいなぁと思うのと、お守りの人間が同僚なので意外と過激なことはできないもんだなぁと思った次第です。

みなさんまた飲みましょう。twitterとかでアクセスしていただければ普通につながるので気楽に連絡してください。

PPSF(Pull Push Stock Flow)

この前の話をもうちょっとちゃんと書いてみる。

情報伝達とその重要度の軸としてはpush-pull,stock-flowというものがあって、pull,flow象限に対応する媒体に周知事項を流すとかpush,stock象限に対応する媒体にブロードキャスティングなお知らせ情報を送りつけるとかは良くない。

1485427799

あともう一つ、data-knowledge,stock-flowという軸も考えられる。知識ベースを作りたいという欲求はどの組織にもあると思うんだけど、そういう場合基本的にpullな媒体を使うことになると思う。

1485427801

はてブのブックマーク自体は単にデータだし、コメント昨日は単なる意見の集合体だから知識とは言えない気がする。 あとtwitterも似たような感じだけど、なんとなくフォロワーを選べば知識に近い情報が流れてくることが多いのでまぁ有意義かなと思う。

掲示板システムみたいなのは議論が発散しがちだし、まとまらないのであんまり好きじゃない。

お手軽に書き込める掲示板システムみたいなもので知識ベースを作りたいっていうニーズを良く聞くんだけど、結局うまく行ったものを見たことないのは、データしか流れなくて知識の蓄積というところまでいかないせいだと思う。あの仕組みで上手くやるためにはキュレーター(かモデレーター)が必要なんだろうなぁと。

でもそれってキュレーターの主観とかはいるし、togetterはそういう部分透けて見える時があるから、ああいうのは本質的に難しいんだろう(査読論文も一緒だと思うし)

というわけで、今のところsofの仕組みが良く出来ているなぁと思うわけだが、母数が大きくないとあの仕組みがうまく動かないのが悩ましいところ。イントラQAシステム入れて、1000人以下の規模でも上手く動いている例があったら知りたい

創薬プロジェクトの進捗をどう測るのがよいのかということを年末年始に考えていた

結論は出ていないけど、面白いかなと思うのでメモっておく。まともなコードを書ける人が何人もいるところに移ったのでアウトプット(プロダクト)に対するフィードバックも早く且つ適切なので自分の生産性も非常にいい感じだし、考えるための材料もどんどん溜まって楽しい(イマココ)。

今のところ足りないのはせっかく電車通勤に変えたのに健全な往復をしているところ。もっと寄り道して飲んだり、飲みながらハックしないといけないと思っているw。

さて、創薬プロジェクトの進捗の把握のためのシステムを考えた場合、 とりあえず先行しているソフトウェア業界のベストプラクティスを製薬業界に応用するのが自然かと思う。

普通に考えると構造最適化プロジェクトってのは典型的なTDDだと思う。スクリーニングフローがまずあって、それをパスするようにケミストは構造最適化を行い、全てのアッセイをパスするものが前臨床に進んでいく。だからパスしないアッセイをリスクと捉えてリスクゼロの化合物の取得を目指すのがプロジェクトの意味だ。

プロジェクトを外側から評価する立場としては全く持って正しいし、そういう方向で見える化するべきだと思っていたが、実際にある程度実装してみたら異なる意見が出てきてなるほどなーと感じた。

きっかけは、テストしてない構造がfailになっているのがおかしいのでは?というケミストからのメールだった。TDDやアッセイをリスク払拭と考える立場だと、passしない限り全てfailと考えるのは正しい。彼らの言い分は明らかにパスするようなアッセイ系なのでスキップしているので、failにされるとプロジェクトの進捗が実際よりも悪く見えて気持ち悪いという話であった。もう一点はゼロに近づくほどいいという指標は如何なものか?という意見。

まぁ、確かにと思ったので、ここら辺に関してよく考えてみた。

スクリーニングフロー

ソフトウェア開発では通すべきテストをきちんと書いて、それをパスするコードが正しいのだろうけど、スクリーニングフロー自体にはそこまでの強さはない。地図に対するコンパスのようなものか?つまりスクリーニングフローはケミストが進むべき方向を指し示すものといったニュアンスが強く、柔軟に対応すべきものと考えるべきなのであろう。だからアッセイしてない化合物がfailになることに対して気持ち悪さを感じるのかな。

リスクをゼロにするという考え方

ケミストは「よりよい化合物を作ってそれを次のステージ(前臨床)に送り出す」という感覚が強いように思う。そうだと、リスクゼロの化合物が前臨床入りするという価値基準では合わないような気がする。スコアが高いほどよい構造だという指標を導入したほうが納得性が増すのではなかろうか?でもそういう指標ってぱっとは思いつかない。

以上、メモだけど今後考えていくべきことの一つかなとは思う。上手い答えが出せればいいなぁ。