DMTAがいいのかそれともTADMがいいのか?

PDCAに対応するものとして創薬の文脈の中ではDMTA(Design-Make-Test-Analysis)が語られるわけだが、昨日ケミストの方にTADMでサイクルを回すのはどう思うか?と聞かれ、直感的に「それは逃げなんじゃないかなぁ、結局ランダムスクリーニングを肯定することになるじゃん」と否定的に答えてしまったのだけど、後から考えてみると根拠があまりないわなと、もう少し深く考えてみた。

DMTA(PDCA)は仮説駆動サイクルですね、これはまぁ自明。じゃぁ、CAPD(TADM)っていうのはなんなんだ?って考えてみるにこれはテスト駆動サイクルかなと思っていたのだけど、CAPDサイクルでググッてみるに、どちらかと言うと探索駆動サイクルの意味合いが強そうだ。昨日はすっかり忘れていたが、これはちょっと前に考えたことがあった

創薬系においては、そもそもテストにあたるもの(アッセイ系)を構築するのに非常にコストがかかる。同様にDoに対応するMakeにも人件費が大いにかかるため、ランダムな合成というのはリスキーだ。さらに探索という側面がある。そのため、仮説なしに合成する(これをケミストは情報取りのための合成としばしば呼ぶわけだが)、ランダムな合成をして有意義な情報が取れたことが経験上ほとんどない。

という事情もあって、昨日の質問に(半ば短絡的に)否定的な返答をしたのだと思う。

でも実際にはlead optimizationはまず間違いなくDMTAをまわすべきだけど、lead generation (finding)にはTADMサイクルをまわすべきなのだと思う。そのためには探索手法(なにを探索したいのかそのためにはどういう測定系が必要か?さらにはどういう化合物セットを揃える必要があるか?)に精通した人間(またはチーム)が必要なんだろうなぁと。残念なことに僕はそういう探索特化型のメディシナルケミストと一緒に仕事をしたことがないという背景が否定的な結論を導いたのかなと思っている。

そういうヒトと一緒に仕事を出来ればハッピーだろうなぁと思いますね。

というわけで色々考えていたら、DMTAサイクルをまわす能力よりもTADMをまわす能力のほうがずっとレアかなと。昨日の主張はちょっと短絡的だったなと反省した。

長距離索敵陣形

ProductName 進撃の巨人(5) (講談社コミックス)
諫山 創
講談社 / 450円 ( 2011-08-09 )


新社会人のための「チケット駆動議事録」

新社会人のための「チケット駆動議事録」というキャッチーなタイトルにしてもうすこしポップな内容にすればよかった。

あとは、よく言われる「重要×緊急でない」 デキる人の秘密は「第二領域」なんてみんな知っているんだから、もうこっちにシフトしてると思うんだけど、これもキャッチーなタイトルつけときゃよかった。

本文を解析してキャッチーなタイトルを考えくれるサービスないかなぁ。

なければ作ってみようかな。

Zabbixでweb監視

Zabbixのweb監視はトリガーの設定がちょっと面倒くさい。hostに紐付けなきゃいけないけど、なぜそうしないといけないの?っていう。まぁ歴史的経緯の賜物なんだろうなぁということはすぐ分かったけど、コンフィグにwebの項目があるのにトリガーのとこにはないのは気持ち悪い。

webの監視も、webアプリだけ監視したい場合があってそういう時どうすんの?なんて悩むわけだけど、お決まりのやり方は本に書いてなかったので、tweetしたら色々教えてもらった(感謝)。

  1. webを提供しているホストに紐付ける
  2. Zabbixサーバーに集約する
  3. 集約用専用ダミーホストをつくる

死活監視をしているサーバーでwebアプリを運用している場合は1でよいとして、webアプリだけの場合は2か3かな。2の場合はネットワークの死活と紐付けられるので、複合型トリガーを作るには便利で、3の場合はトリガー作成の際、余計なアイテムが出てこないというメリット・デメリットがあるそうです。

自分の環境に応じて選択すればよいと思う。

Zabbixでメールを送信出来るようになるまで

一昨年くらい前の静岡インフラ勉強会で紹介されてたzabbixが良さそうと思って書籍を購入したんだけど、購入後放置していた。

最近やっと使い始めたら、便利なんだけどメールの送信設定でハマった。

がtwitterのzabbix界隈の人達のおかげで設定できた。zabbixユーザー層厚い。というか厚いのはいいことだ。それから、職場のネットからはtwitterが遮断されているのでiPhoneでやり取りすんだけど、zabbix界隈の人達の助言がなかったらどんだけ時間をムダにしたんだろとか。

まぁ、それ以上にうちのIT部署は死活監視なんて使ってないんだけどねーw

zabbixのほうの設定

メールを送るのに

  • サーバーの設定:管理 ->メディアタイプでメールサーバーの設定をする
  • ユーザーのメールアドレス登録:管理 -> ユーザーでユーザーのメールアドレス設定
  • アクションの設定:設定->アクションでメール送信の設定

と3つの段階を踏む必要がある。ちなみに二番目の設定を忘れていた(わかりにくい)。ちなみに、ここまで設定してもメールが送信できなかったのではまった。

トラブルシュート

まずはエラーログってことで/var/log/zabbix/zabbix-server.logを覗いてみるもののなんも出力されてないのでイラッときた。エラーが出るのは想定内だけど、エラーログが出ないのは想定外なんで、ああいうのでイライラするのは環境に慣れているせいかもと思った。

ここから、twitterのzabbix界隈の人達の助言にお世話になりっぱなしで。

  • Administration -> auditをみる
  • eventの時間をクリックしていってログをあたる

とエラーが見つかるということを知った(今回の場合後者だった)。ログによると permission denied (13)っていうエラーでメールの送信ができていなかった。

あらかじめ、telnetでメール送れることを確認してあったので、permission deniedがでるのは謎だったのだけど、若干悩んだ挙句SELinuxが有効になっていることに気づきdisabledにして無事送信できるようになった。

管理->メディアタイプorユーザーの設定のところにテスト送信をするという機能がついていればこれほど悩まず解決したのにと思った一方で、悩んだおかげで多少詳しくなったからまぁいいかなぁと。

スクラムとは何か(アジャイル開発)

僕の場合アジャイル開発という大雑把な括りで理解しているので、具体的な開発手法名はなかなか覚えにくい、というよりそれすらちょっと抽象的な表現なので分かりにくいと言ったほうが適切か。

スクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・行動パターンを共有する自己相似の知識創造活動であり、それを実践する人びとである

本書を読みきれば、上の定義があーなるほどと理解できるようになる。あとは、自分のフィールドに翻訳する必要があるのだが、カルチャーを変革する系の手法なので、ボトムアップな取り組みだけではうまくいかないだろうし、上の理解が必須かなぁと思った。なのでマネジメント層に読んでもらいたいなぁと。

  • アジャイルは顧客満足を実現する手段であり可能性のひとつ
  • アジャイル開発では知識の外部への伝播が語られていない(これは欠点)
  • PDCAのPの前にはSECIのSを置くべき

スクラムを実践するには組織を変えていく情熱が必要である

これがなー、厳しい。リーンスタートアップみたいなやり方は時間がかかるしなぁ。

第三部の「アジャイルと開発とスクラムを考える」の野中郁次郎先生の考察が非常に深かった。アジャイルでは知識の外部への伝達が弱いのは技術者の流動性が高すぎるからだと考察している。流動性がそれほど高くない僕のいる業界なんかでは暗黙知の共有とか形式知化なんかは非常に重要なことなので、本書のオリジナルの論文(日本の製造業)と対比しながらの考察は理解が非常に深まった。

以下、製薬業界用メモ。

ユーザーストーリーのフォーマット

  • <ユーザーの役割>として
  • <機能>が欲しい
  • なぜなら<機能の価値や目的>だからだ

動態担当として、logPを下げてほしい、なぜなら膜透過性が改善するからだ

みたいな、なぜ今そういう化合物を作っているのか?というストーリーを張っておかないと、振り返った時に個々の化合物が合成された背景を掴めないし、そのやり方がうまくいきそうかどうなのかが外部から判断できない。

ケミストの「うまくいったから、結果としてうまくいったんだ」というようなくだらないトートロジーに付き合わされるのはかんべんしてほしい、というのはみんなの願いであろう(ケミストそれ自身の願いでもある気がするw)。

プロダクトバックログ

プロダクトバックログとは、実現するかもしれない未来の詰め合わせである。創薬的には合成してもいいかなぁと考えている案のリストと考えることができる。リードオプティマイゼーションにおいてはそういうアイデアリストをプロジェクトごとにまとめて管理して確度の高そうな案から作っていくというやり方がプロジェクト的に理想的かなと思っているんだが5年くらい前からトライしているんだけどうまくいっていない。色々理由はあると思うんだけど知財的なことを考えると誰が作ったかが重要視されるのでまぁしょうがないのかなぁと。

とか考えるとUK-QSARでみかけたAZのスライドはまさにバックログを実装していてすごいなぁと。

空洞化のウソはウソなのかホントウなのか

空洞化のウソ / mark-wada blogで触れられていて気になったので読んでみた。

筆者は新興アジア推しの現地化推し。

著者は空洞化を3つに分解する

  • 雇用の現象
  • 国内技術水準の停滞
  • 海外で稼いだ金が国内に還流しない

雇用の減少

筆者は現地化すれば企画立案部門とか新規開発部門のような付加価値の高い分野に雇用拡大(国内)できると論じているが、これは案にブルーカラーは仕事がなくなると言っているようなもんですね。逆に国内の教育も付加価値の高い人材をつくることに焦点をあわせないといけないが、実際はそうなっていないから、ホワイトカラーの人材も国内外問わずに取ってこないといけないでしょう。

まぁこうなるわな。

国内技術の水準の停滞

こっちのほうが重要だと思うんだけど、現場と離れたところに企画立案部門をつくると官僚化しておかしくなることが多いと思うが、開発力だって落ちていくでしょう。

第一三共とランバクシーの話が出てたけど、創薬知らなすぎなヒトの考えるストーリーだよな。コレに関してはお話にならない、イノベーションが求められている部分がそもそもずれているので。

お金の還流の問題

「日本入っている」戦略で現地化をうまくやってという話は正しいのだろうなと思う。結局人口分布に基づいた戦略は必要になるしなぁ。

お金の流れ的には空洞化していないってのが正しくて、雇用と技術に関してはどうなのかな?っていう印象。

というより、空洞化しているかどうか議論するということが些細な事なのかなと。

あわせて読みたい感じの対談

ビッグデータの衝撃というよりデータ分析の仕事が重要になるよっていう話

ビッグデータとは

  • Volume(データ量)
  • Velocity(データの生成頻度)
  • Variety(多様性、構造化できないという意味も含む)

のいずれか、またはそれらの組み合わせ。

構造化できない大量のデータがリアルタイムにどんどん生成されていくような状況だと、RDBに収めにくいし、処理するのにも新しい技術や手法が求められるということ。

ProductName ビッグデータの衝撃――巨大なデータが戦略を決める
城田 真琴
東洋経済新報社 / 1890円 ( 2012-06-29 )


本書では上に書いてあるビッグデータは狭いと考えていて、データ処理技術、ヒトを含めた組織まで含めてビッグデータとして捉えているが、そっちの話は分析力を駆使する企業のがずっと詳しいし、分析という観点から書いてある。

分析が先なのか、データが先なのかという話に関していえば、優秀なデータサイエンティストを有していればデータを与えれば意味のある分析結果がドンドン精製されてくるが、分析するヒトがいなければデータ生成はムダなコストにしかならないので、分析(者)ファーストだろうなと。

「Data is the new oil」とは良い例えだと思う。結局精製技術次第だし。あとは原油にあたるようなデータの入り口付近にいる業者も有利なんだろうな。

CROSS 2013でデータサイエンティストのセッションがあったみたいですね。

イノベーションを生みだすために必要なこと

リーン・スタートアップを読んだ。

リーン・スタートアップとは、スタートアップの成功確率を高める方策を集めたものである。

アイデアよりも実行すべきかどうか

「この製品を作れるか」と自問したのでは駄目。いまは、人間が思いつける製品ならまず間違いなく作れる時代だ。問うべきなのは「この製品は作るべきか」

検証できない仮説は意味ないですね。ただモチベーションを上げる手段としての仮説はアレだよなぁと。

ユーザーストーリーは検証による学びが得られてはじめて完結だと考えること

創薬プロセスももうちょっとこういったことを意識しないと駄目だろうなぁと思うが。

リーンスタートアップにおける製品開発プロセスでは「行わなければならない実験をプル信号としてそれに反応する」と考えるべきだ

ピボットのタイプに種類があることを知った。

  • ズームイン型
  • ズームアウト型
  • 顧客セグメント型

高速文字列解析の世界が素晴らしかった

丸4日かけて8章(最終章)以外を読んだ。正月休みの後半の時間をこの本を読むのに費やしたのは正解だった。新年開始早々、知的な満足感が得られた。

本書を読めば、BWT、簡潔データ構造、ウェーブレット木、FM-Indexが理解できる。

LF-mappingのところ(p.28の補題3.4)を理解するのに時間がかかったが、これを理解できればFM-Indexのアルゴリズムが理解できる。ついでにWavelet Matrixも理解できた。ひとつひとつ丁寧に読み進めていけば理解できるようになっていたので良かった。

本や論文で書いてあるなら、まず読んで知っているのが必要条件(slide 24)と著者のスライドに書いてあるように、BWT、簡潔データ構造、ウェーブレット木、FM-Indexは知らないといけない知識になるんだろうなぁと。

pubmed調べたら、bioinformatics用途でしかみつからないのでchemoinformatics方面で応用できたらいいなぁと思った。

その他

  • LZEndはちゃんと理解していない
  • Boyer-Mooreは昔やった

簡潔データ構造

4章

簡潔データ構造は、操作が高速でありながら作業領域量が小さいという2つの性質を兼ね備えたデータ構造であり、データ圧縮と索引の技術が組み合わさったものである

完備辞書(FID)

  • access: B[i]を返す
  • rank:B[0,i)中のb∈{0,1}の数を返す
  • select:B中で伝統から見てi+1番目に出現したb∈{0,1}の位置を返す

p.48の式がo(n)ビットに抑えられていると書いてあるのだが手で計算して確かめていない(ので後で計算する)。 (13.01.05 libcdsのチュートリアル読んだら理解した)

簡潔木の説明がさらりとしすぎてあまり触れられていない気もするが、本書においてあまり重要でないってことでいいのかな(全体を読んでみないとわからない)。

それから読んでいて索引が貧弱だなと思った。RRRとかselectとか引けない。