コンソとかキャリアとか

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

コンソの意義は何か?

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

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

「周回遅れを避ける」

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

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

キャリア?

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

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

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

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

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

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

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になることに対して気持ち悪さを感じるのかな。

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

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

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

最近読んだ本(20170104)

頑張れば何とかなる系。元気が出る系ともいう。悪くはなかったが、ハッピーすぎるだろうw

ProductName 記者はつらいよ―中央新聞坂巻班 (ハルキ文庫)
仙川 環
角川春樹事務所 / 670円 ( 2015-12 )


久しぶりに読んだビジネス本。読んだというより流し読みにちかいけど。主張したいことは、企業の業績を伸ばすためにはまず会議に手を付けるべきで「良い会議」というのはどういうものかを自分たちでよく考えるべきだというものだった。

昔、労働時間の内訳を測ったことがあって、(実際に測ってみると)会議時間の多さにびっくりしたのとそのコスパの悪さに唖然としたことがあったので著者の言いたいことはもっともだと思った。

しかしながら、提案しているソリューションが古臭くてちょっと自分には合わなかった。もうちょっといい感じのツールを使っているし、ITの利便性を最大限に発揮しているよなぁと感じてしまって流し読みモードになってしまったけど、そういうあたりを考えたことのない人にとってはためになる本だと思う。

とある製薬会社を退職しました

どうでもいいことなので書く必要があるのかどうか悩んだけど、SNSでつながっていなくてblogをチェックしているヒトが何人もいるので一応こっちにも書いておきます。

尚、ウィッシュリストはこちらです

今日から久しぶりの電車通勤をしているので沿線沿いの方々飲みに誘ってください。そしてmacbookを抱えて通勤するのでアルコール注入しながらのハックをしましょう。