2012/02/02 21:24:10
アジャイル開発を創薬系にどう取り込んでいくかっていう観点で。
第V部のアジャイルなプログラミングに関しては昔考えたことがあるので、II−IV部あたりを。III部の計画づくりはうまく取り込むのが難しそうな気がするけどIV部の運営は色々参考になる。
まず、ソフトウェア開発と初期創薬開発の似ている部分異なる部分を書いておくが、特に異なる部分が重要。
異なる点
- 工学的にコントロールできるわけではなく、発見に頼る部分がある。つまり作ってみて評価してみないとわからない部分が大きい
- 成功したかしないかの二択。9割完成したとかはない（こういうのは失敗とみなされる）
- ベロシティがうまく見積もれない。ブレークスルードリブンなので非連続の進捗になりやすい
- あっちを動かすとこっちがおかしくなるというなかでバランスをとリながらベストを探るという多次元最適化戦略になることが多い
似ている点
- 何人もの異なるエキスパートの協調作業を強いられる。役割はきちんよ分かれているが、優秀な人材は幾つかのフィールドをまたぐことができる（インフラもフロントエンドもできるプログラマみたいな感じ）
- 自分のジョブしかできないヒトはスコープが狭いし、メタな視点に立てない。学習意欲のない人の生産性が低いもの一緒
みんなをバスに乗せる
スタートを切る前からだめになってしまうプロジェクトの主な理由は次の二点
- 答えるべき問いに答えられない
- 手強い質問をする勇気を持てない
まぁ、創薬プロジェクトでもよくありますね、認識しておかなければいけない問題を敢えて目をつぶって進めてた結果、激ハマリっていうパターンが。
手強い質問を先にすませてしまうためにインセプションデッキというツールが使える。
インセプションデッキは10の手ごわい質問と問題から構成されており、いずれの課題もプロジェクトを開始する前に聞いておかないとまずい質問ばかりだ
エレベーターピッチ
効能
- 明快になる
- チームの意識を顧客に向けさせる
- 核心を捉える
テンプレート
- [潜在的なニーズを満たしたり抱えている課題を解決したい]したい
- [対象顧客]向けの、
- [プロダクト名]というプロダクトは、
- [プロダクトのカテゴリ]です。
- これは[重要な利点、対価に見合う説得力のある理由]ができ、
- [代替手段の最右翼]とは違って、
- [差別化の決定的な特徴]が備わっている。
やらないことリスト
「やる」、「やらない」、「あとで決める」をきちんと見える化しておくツール。
創薬プロジェクトで「やらない」にタスクを入れるのはなかなか難しいかも。なので、「やる」と「後で決める」を明確に分けられればいいかな。
アジャイルなプロジェクト運営
ジャストインタイム分析の利点
- 最新かつ最も充実した情報に基づいて分析できる
- プロジェクトが進むにつれて分析がうまくなっていく
- 手戻りが大量に発生することを避けられる
最後の手戻りを避けられるのは大きな利点だな。それからリリースボードとストーリーボードは便利そうだ。
アジャイルな計画づくり
これが一番納得出来なかった。ベロシティが見積もれないようなプロジェクトだと与えられた期間を頑張るしかないんじゃないかなぁと思う。
それから名前が付いてるのかどうかわからんけど、探索的なプロジェクトだと締め切り間際になると集中力を発揮して何とかやり切るパワーみたいなのってありますよね。そういうのも重要だと思うんだよね。
というわけで、この部に関してはモヤモヤ感が残っているのでまた後で書くかもしれない。
2012/01/28 09:10:47
2.3.1がリリースされたようです。
個人的に興味があるのは
- PNG files from Open Babel contain molecular information and can be read to give the MDL Molfile.
- Pybel now uses the built-in 2D depiction, and no longer needs OASA.
とABINITのフォーマットに対応したあたりかな。
あと、openbabel-python.iをいじってたので、ここをいじった場合のコンパイルのオプションをメモっておく。swigが有効になるようにしないといけないのに気付かなくてハマった。
cmake ../openbabel-2.3.1 -DPYTHON_BINDINGS=ON -DEIGEN2_INCLUDE_DIR=/usr/local/tmp/eigen-eigen-2.0.12 -DRUN_SWIG=ON
OBGenericからOBOrbitalDataへのキャストをできるようにして、vectorの設定もしたので、手元のpythonバインディングでは
orb = toOrbitalData(mol.GetData(openbabel.ElectronicData))
orb.GetAlphaOrbitals()[orb.GetAlphaHOMO()-1].GetEnergy()
とやるとHOMOのエネルギー(eV)を得られるようになっている。
追記12.01.28
homebrewでいれたpythonで使いたい場合optionで指示する
$ cmake ../openbabel-2.3.1 -DPYTHON_BINDINGS=ON \
-DPYTHON_LIBRARY=/usr/local/lib/libpython2.7.dylib -DPYTHON_EXECUTABLE=/usr/local/bin/python \
-DEIGEN2_INCLUDE_DIR=/Users/kzfm/openbabel/eigen-eigen-2.0.17 -DRUN_SWIG=ON
2011/12/30 18:05:23
去年2010年に読んだ本というエントリを書いたので、今年も読んだ本の中から良かったものを選んでみた。
アジャイルな手法とか、最近のソーシャルネットの手法を効果的に取り込んだ、創薬研究プロセスとかそのためのインフラ構築に興味があるので、ビジネス本はそういうあたりがインスパイアされそうなものを選んであります。
技術書は色々読んだが、Scalaはもう少し追いかけていきたいなぁと思っている。
ビジネス本
働き方やこどもの教育には関心があるので、今後どういう方向に向かうのかっていうのは興味がある。
まだ書評を書いてないけど、これは非常に面白いです。賛成できないところもあるけど、それすら「なぜ賛成できないのだろうか？」と考えさせられるので読んでて楽しかった。インセプションデッキと、エレベーターピッチは創薬プロジェクトでも有効だろうなと思うので取り入れてみたいなぁと。
デザインの骨格
山中俊治
日経BP社 / 1680円 ( 2011-01-29 )
僕はドラッグデザインにはアートの要素が沢山含まれていて楽しい仕事だと思っているし、工業デザインの範疇に入ると考えている。
技術書
技術書は
Javascript使いになろうとするなら必読かな。
集合指向言語として考えればSQLの言語仕様は非常に面白い
Perlでいうところの「モダンPerl入門」またはPythonで言うところの「エキスパートPythonプログラミング」に対応する感じの中級を目指す人向けの本。
Scalaはもっと盛り上がってもいいと思うんだけどなぁ。
Emacs使いは読まねばならん。もう少し自分好みに手を入れられるように積極的にelisp書いていきたいなぁ。
2011/12/01 21:29:27
mol形式(sdf形式)のデータだと化合物の区切りが$$$$なので、化合物を追加したい場合は何も考えずにファイルに追記するだけでいいのでよいですね。
PDB形式のデータにsdf形式の化合物情報をマージしたいんだけど、いい方法ないかなぁと調べてみたところmol2でOKだった。
両方mol2形式にして
cat compounds.mol2 >> protein_data.mol2
ってやればマージできる。
どういう用途を想定しているかっていうと
ある適当な部分構造(substructure)を持っている化合物の複合体結晶構造に、同じsubstructureをもつ別の化合物のコンフォマーを発生しつつ複合体のsubstructureの座標でalignする
つまり
- obconformerでコンフォマーを発生
- 複合体結晶構造のリガンドの部分構造を使ってobfitでコンフォマーをアライン
- 一つのファイルにまとめてドッキングモデル完成
みたいなことをやりたかったわけです。こういうのはファイルが2つに分かれてるとユーザーのヒトとか使いにくいしどういう計算したのかわからなくなっちゃうからね。
2011/11/24 19:32:42
biopythonのMLに「蛋白内部に埋没している残基をどうやってけいさんすんの？」っていう質問が流れてて、HSEっていう指標が実装されているのを知った。
HSEってのはCalphaとCbetaのベクトルと直交する平面で球を切ってUpとDownの半球のことで、その中に他の残基のCalphaとCbetaが幾つあるか数えるという単純なCNっていう指標で溶媒接触表面積の代わりに使えるらしい。
この指標って例えば（潜在的な）リガンド結合部位の予測に使えたりするんだろうか？
PPI阻害剤なんかのターゲット部位予測に使えたら面白いかもねと思った。
2011/11/17 09:05:10
ネットワーク分析は楽しいですね。普段は化合物のネットワークとかいじっているんだけど、もう少し見識を広めるために違ったタイプのネットワークの分析手法を勉強してみたくなって本書を読んでみた。
社会ネットワークとは、アクターと呼ばれる行為者としての社会単位が、その意図的・非意図的な相互行為のなかで取り結ぶ社会諸関係の集合である
これらをミクロな視点からみていくか、マクロな視点からみていくかだけど、マクロな視点だと個人の特性が失われてしまうので、これはダメらしい。自分の経験では、（ケミストリーを知らない）ケモインフォマティクスのヒトが、個々の化合物をパラメーターで潰してしまって実態とかけ離れたマクロな解釈しかできないのをよく見るので、まぁそうかなとも思う。
で、よりよい社会像を得るためにどうしたら良いのかということで、社会構造の二重性モデルを使うのが、現代の社会ネットワーク分析らしいです。
個人的に興味が湧いたのは9章の「弱い紐帯」が重要か、ブリッジが重要かという話題とネットワークは凝集的で閉鎖的がいいのか、離散的で開放的がいいのか？という話題。第三部の「ソーシャル・キャピタル研究：組織論への展開」は読み物として面白かった。
セイヤーによれば「関係」は形式的なものと実質的なものに分けられる
形式的の関係とは「ともに30歳」みたいなもので、実質的な関係の例は「夫婦」
ハイパーグラフは個人がグループに所属するような所属関係のネットワークを表すのに利用されたり、重複メンバー関係をモデル化するのに便利
これは以前教えてもらったときに調べた。
かなり教科書っぽいので、手を動かしたい場合は「ネットワーク分析 (Rで学ぶデータサイエンス 8) 」のほうが良いかも
2011/10/11 21:44:16
先週のインフラ勉強会でCIツールとしてJenkinsを教わったので、早速GitHubのpythonプロジェクトをjenkinsで動かしたりしていた。まぁ大体動いたのだけどエントリに起こす時間がないのでまた今度。
というわけで、継続的インテグレーション入門を見なおしているんだけど、実際に少し触ってからもう一度読むと、あーなるほどと思うことがあって勉強になるわけです。
製薬のようなライフサイエンス業界にも似たようなCIの取り組みをしている会社があるみたいで（残念ながら国内では知らない）、彼らはContinuous Improvementと呼んでいるんだけど、基本的にはアジャイル開発の流れを汲んでるっぽいので、目的とするところは一緒ですね。
ただ、テストにヒト（ベンチワークの研究社）を必要としたり、イテレーションが一週間位と長かったりするのでそのままソフトウェア業界のベストプラクティスを参考にするわけにはいかないんだろうけど、強いしなやかな組織をつくるためには正しい方向性の一つなんじゃなかろうかなぁと思うわけですね。
こういうのもそうなんだけど、創薬の現場にもっとアジャイルな手法を取り入れたら素敵なんだろうなぁと思っているのだけどねぇ。
2011/09/30 21:40:03
今日のPBPKのセミナーはおもしろかったけどつまらなかった。
おもしろかった部分はまぁどうでもいいとして、つまらなかった部分を書いとくが、例えるならば、セミエンピリカルな分子軌道法を肯定してる的な。
今日の発表の全てからab initio的な理論計算の至高が感じられなかった。
PBPKにフィッテイング許したらそれは論理コンパートメントモデルと同じレベルに堕ちちゃうじゃん、堕落じゃねーの？と。自分でPBPKモデリングをやったときに、実測のlogDとかcLogPとかけ離れたパラメータを投入しないと、実測のPKに合わなくて、非常に気持ち悪いと感じていたのだけど、どこもそんな感じでやっていた。
理論計算やっているひとから見ると非常に気持ち悪いですね、そもそもチョイスしたモデルがダメなんじゃねーの？みたいな。
結局そういうダメなモデルをフィッテイングで合わせるんだったらin vitroのデータ必要ないじゃんとか思うんだけど。QSPRと整合性の取れないモデルってことは結局in vitroとin vivoの関係性を捕まえてないってことだしなぁ。
そこを肯定しちゃうと前進なんてしないんじゃないかなぁ。in vivoを排除するからこそのPBPKだ！みたいな気概が感じられなかった、プラクティカルでイイじゃんみたいな。
Structure-PBPK relationshipは遠いなと思った。
2011/08/25 16:24:57
デザインの骨格は良書ですなーとおもっていたが、デザインの輪郭も負けず劣らず素晴らしい本であった。
「デザインの輪郭」という言葉は、この本のためだけに思いついたわけではない。これは、「デザインとはいったい何であるか」という問いに答えるときに思い浮かぶ像のようなものである。
デザインの輪郭
深澤 直人
TOTO出版 / 1890円 ( 2005-11-10 )
あまり言語化すると、ゆるふわっとしたものが失われるのでエッセイくらいで感覚として伝えるというこの方式のほうがよく伝わってくる感があった。
選択圧自体は人為的なものではなくて、いわゆる「状況」なんです。状況が、それが生き残るかどうかということを常に選択しているということです。
仕事のやり方に関してはここらへんの言葉が好きですね。
ピラミッドは頂点から組む。
下から組み上げても台形にしかならない場合があるから
これも理想でしょう。
オフィスは肥えた土壌のようなものです。
スタッフと毎日耕している
ブレーンストーミングもやらないし、
アイデアをたくさんだそうともしない
2011/08/17 05:46:35
創薬系ももっときちんとログをとって定期的に振り返る、それを細かいサイクルでおこなったほうがいいんじゃなかろうかという意味合いも込めてSAR Newsに寄稿したのが去年のことだけど、もっと知識管理全体をどうするのがいいだろうかと、ここ数ヶ月考えていたので、お盆休みを利用して少しまとめてみる。(なぜ数カ月考えていたかというと、4月にITサポートの部署に異動になったという大人な事情ですねw)
今回移った部署が管理しているインフラ自体は僕らが昔作ったものだが（ITっていう名前がついててもシステム開発できたり、まともなプログラミングができるわけではない。）異動後何回か面談してみても、現在の上司に最近の手法であるアジャイルを創薬システムに応用してみようとか、PDCA(創薬だとDesign-Make-Test-Analysisかな)とかそういう話をしても理解出来なかったし、だからといっていまさら勉強する気もないだろうからなぁ。
とはいえ誰かがそろそろ前進させないとまずいと思うので、異動した記念にでも夏の終わりにでも(2,3個役職飛ばして)振るだけ振ってみる予定なんだけど、他のヒトの役にも立つかもしれないのでエントリとしてまとめておきます。
Data, Information and Knowledge
Data, Information and Knowledgeに従って考えていくと都合がいい。というのは割とスパッと切り分けがしやすいから。図ではwisdomが頂上に君臨しているのだけど、よく見るのはData,Information,Knowledgeの三層構造なので、そっちで考えていく。
Data
まぁ、どこの会社もデータのインテグレーションはやるでしょう。とくに実験データのトレーサビリティをどうするかは問題になると思いますができるだけロボットデータにタイムスタンプを付与するくらいはやっといたほうがいいですね。あと実験者に電卓を叩かせないでIC50とかそういう値まで自動的に計算するようにしたほうがよいですね。（実験者は意外にタイポが多い）でもこういった話は今回はどうでもいいので略します。データのインテグレーションは適切に行われているという前提なので最下段のピラミッドはクリアーですな。
Information
データがインテグレーションされたら、次にやるのは分析ですね。分析は別にRでもなんでもいいけど、情報管理という意味では分析のスナップショットが取れる奴がよいですね。
Spotfireとか使うと分析の共有化（情報の共有化）ができます。
Information can be considered as an aggregation of data (processed data) which makes decision making easier.
Data, Information and Knowledge
なぜ情報が必要かというと、それは意思決定がしたいからです。確かにInformationの層をきちんとすれば意思決定は効率的に行えるでしょう。
ところで、意思決定とはなんであろうか？なぜ我々は意思決定をしたいのだろうか？
意思決定をするために必要なものは情報とあと何であろうか？を考えてみます。
合成した化合物が活性あったよバンザーイ（さくせん:ガンガンいこうぜ）とか、頑張って難しい合成こなしてみたけど活性なかったよショボーン（さくせん：いのちをだいじに）
これは意思決定をしているわけではないですね。
ある仮説を立ててそれが正しかった正しくなかったか、正しい場合より角度の高い仮説はどうなのか、仮説が正しくなかった場合どこに問題があって、それを証明するにはどうしたら良いか、つぎはどういう方向で攻めるべきか
そういう継続的な改善作業をコントロールする仕組みが必要なんだと思います。でも、これはInformationの層では管理できないので、Knowledgeの層になにか、(とても大切な何か)が必要なんでしょう。
Knowledge
Knowledge is usually based on learning, thinking, and proper understanding of the problem area.
It can be considered as the integration of human perceptive processes that helps them to draw meaningful conclusions.
Data, Information and Knowledge
知識も簡単に検索できてすぐに理解できるような必要があるが、慣習的に報告書の打ち出しやPPTの資料が必須のとこも多いと思うんだけど、探索コストのかかるフォーマットはどうなのかなぁと思うが。誰の得になるんだろうか？wikiでイイじゃんとも思うが。自分は実験報告書をwikiで管理してて、職場のwordのフォーマットでいつでもexportできるようにしてるので、便利だし昔やった仕事もパパッと探せて快適ですね。
知識管理システム
Rocheのやつは経験の共有化に重点をおいてるっぽいような気がする。であれば、構造のハンドリングできるようにしたwikiにタグつけたり、検索エンジンを強力にすればいいような気がする。文章自体構造化してあるんだから、みんな大好きPPTとかWORDでもPDFでも出力は気にならないでしょう。あとはバージョン管理システムのいいやつ入れておけば良いんじゃないかなぁ。でもやっぱ文化醸成の努力が素晴らしかったんだろう。
GSKのほうはHDD（仮説駆動型ドラッグデザイン）を推進するようなものだったと思う。合成案を相互レビューできるようにしてあったかな。合成のヒトは合成案を否定すると人格否定と捉えるヒトが結構いるから、こういう仕組みっていいよなぁと思った記憶がある。
こういったタイプの経験管理というのは、ノウハウを共有化して、プロジェクトを効率化するとともに、個人に張り付いた知識を引き剥がし、職場全体の財産にすることができるのでよいのだが、あまりインスパイアされないのでやっててあまり楽しくはない。
問題管理システム
ソフィーの世界の作者が別の著作で良い事書いてたので、よく引用してます。知識ベースっていうのはまさに前者ですね。
An answer is always the stretch of road that's behind you. Only a question can point the way forward.
Hello? / Jostein Gaarder
stackoverflowっていうプログラマのためのQAサイトが良くできていて、クローンが幾つか作られています(OSQA,shapado)
うちではshapado入れてみて半年くらいたつのだけど、ユーザーはまだまだ少ないが質問も70を超えてきて結構楽しい。良い質問にインスパイアされると、より楽しいアイデアが浮かんだりするし、複数のプロジェクトで同じような問題抱えてると、部署で何とかすべき課題なんじゃないの？なんてわかったりするし。
結局、知識管理をも内包したプロジェクトを前進するための全てをきちんと管理し、知識が属人的になりすぎないようにしつつ、柔軟にリソースをコントロールするための全体的な仕組みを考えていきたいが、そのためにはプロトタイプを幾つか作ってみて反応を見ながら進めないといけないなぁと。
論文管理
読書情報は属人的なものであるが、どういう論文を読んだか、それでどうインスパイアされたか、(自分の持っている情報と照らし合わせて)どこを否定したかといったblogっぽいブックマークサービスがあると便利です。ポイントは目録じゃなくて、それを読んでどう考えたかを記す部分です。ちょっと前に新しいのをつくろうとしつつ開発が止まっているが、なかなかモチベーションを保つのが辛い。
自分でつくってみて、音楽は曲のつなぎかた自体に意味がある(DJing楽しい)から曲名リストは意味があるけど、論文目録眺めても大して面白くない。リファレンスをたどっていきつつサマライズするようなサービスは面白いかもしれないが。
どういうツナガリに意味を持たすかだなーと思う。
技術
Express+ChemDoodleというjavascriptライブラリ同士の組み合わせなんかもコンセプト的にも技術的にも面白そうな気がするが。あとHTML5とタブレットで色々変わりそうな気もしている。
参考書籍
こういったアプローチはソフトウェア開発業界の方が断然進んでいるので、そういった本を幾つか。できるだけ概念を説明しているようなのを選んでみました。
Redmineによるタスクマネジメント実践技法
継続的インテグレーション入門 開発プロセスを自動化する47の作法
入門Git
入門Git
濱野 純(Junio C Hamano)
秀和システム / 2310円 ( 2009-09-19 )
アブダクション
アジャイルサムライ−達人開発者への道−
「新しい働き方」ができる人の時代
パーフェクトJavaScript (PERFECT SERIES 4)
達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)
Scala実践プログラミング―オープンソース徹底活用
Emacs Lispテクニックバイブル
Bioinformatics Programming Using Python
Python for Bioinformatics (Chapman & Hall/CRC Mathematical & Computational Biology)
社会ネットワーク分析の基礎―社会的関係資本論にむけて
ネットワーク分析 (Rで学ぶデータサイエンス 8)
継続的インテグレーション入門 開発プロセスを自動化する47の作法
Pharmacokinetic-Pharmacodynamic Modeling and Simulation
Redmineによるタスクマネジメント実践技法
アブダクション―仮説と発見の論理