26102011 work
経営に近い人達は当たり前だけど忙しいしだらだらとアポの時間を取れるわけではない。だから、自分たちは顧客とか出資者にプレゼンするつもりで臨まないといけない。同じ船に乗った同士とか昔の上司だからとか、よーく話せばわかるとか、そういうぬるい考えを持ってはいけない。
つまり、常にエレベーターピッチのようなものを用意して、現状の問題点と改善点を完結にプレゼンできるようにしておかないといけないし、30分程度の時間をもらえたらwin-winの提案をして資源を勝ち取らなければならないと思っているし、まぁ実践している（できているかどうかわからないけど）。
というわけで、最近は寝る前にこの本を読んでいるんだけど、言い回しが堅苦しいのでよく寝られる。
内容はいいと思うんだが、咀嚼できてないので3回くらいは読まないと分からない感じ。
25102011 work
著者はノーリツ鋼機の経営戦略室にいたらしい。ノーリツ鋼機といえばお家騒動的なアレとか産業が急速に減衰した業界ですね。
こういう背景を踏まえた上で読んでいくと、特に三章以降は恨みっぽい感情も行間に見え隠れしつつも、株主資本主義に疑問を呈している感もあるかなぁと。ネクスト・ソサエティで似たようなことをドラッカーも書いてたな。
一章、二章のどう働くかは参考になった。
16102011 work
自分の職場ももっと継続的なインプルーブメントが必要だろうなぁと思っているが、なかなか難しいですね。まぁ、ああいうのは地道にやるしかないのかねぇとインテグレーション入門を読みなおした。
CIは単に技術の導入にとどまらず、組織やその組織の文化にも変化を及ぼす
第一部はCIの背景や、原則、プラクティスについて書いてあるので、ソフトウェア業界じゃなくても色々参考になります（といってもソフトウェア業界のCIを知らないとよく分からないかもしれないが）
というわけで、自分の置かれている業界（製薬業ですね）におけるCIとはどんなもんかねというあたりをメモっておく。
ちなみに第一部の各章はこんなタイトルです。
以下、用語に関しては特に説明しないが、創薬系におけるバージョン管理というものはどういうもんだろうかとかは考えたことがあるので参考に。
バージョン管理リポジトリの目的は、アクセスが制御されたリポジトリを用いることによって、ソースコードや、その他(ドキュメントなど)のソフトウェア資産に対する変更を管理することである。これによって、一ヶ所からすべてのソースコードが入手できる「唯一の入り口」が提供される
創薬プロジェクトにおける資産とは何だろうか（というよりどこまで管理すればいいのだろうか）？という問いに閑する答えはシンプルで、プロジェクトを進めるために必要な全てですね。特に実験データに関してはロボットデータまで管理する必要があって、IC50とか中途半端なデータから管理してると、ある日突然シボンヌしますね（データの正しさが担保できない）。
それから、実験プロトコールや、報告書もプロジェクトにおける重要な資産なのできちんと管理する必要があるだろう。プロトコールのような手順のほかにBDDっぽい何か、つまりプロジェクトにおけるビヘイビアのようなものも必要だろう。
ソフトウェア開発のようにレッドからグリーンを繰り返すサイクルとは異なり、いつか成功するかもしれない失敗を繰り返すから、基本的には常にレッドである。創薬プロジェクトは探索的なタスクが多く、イシューを細かく切ったとしても、それぞれが相互に強く依存しているために、常に手戻りが起きる危険が発生する。
そのため、インテグレーションとかビルドの考え方は大きく異なってくるが、どうしたらいいかに関しては自分の考えが固まっていない（だから文章におこしてるわけだが）。
よくありがちな創薬プロジェクトっていうのは
の順にそれぞれ閾値を決めて、多段フィルタリングのイメージでゴールに向かって進んでいく。上で書いたように基本的には成功（閾値を超える）するかもしれない失敗を繰り返しながら後半のアッセイ系に進む確率を挙げていくわけです。
基本的にアッセイを繰り返すことにより、そのアッセイ系での成功確率は上がっていくわけですが（あがらないのももちろんあるがそれはサイエンスとして理解できてないとか本質を捕まえてないと表現する）後ろのほうでイシューが出てきて合成方針が変わると、最初の方のアッセイ系の成功確率ががくんと下がることがよくある。
というわけで、フローとして流すのがいいのか、幾つかのアッセイを並行で流して多次元最適化を行うのがいいのかはコストの制約とか、プロジェクトの性質で決まってくるのだと思うが、プロジェクトスタート時にはどういう組み方をしたらいいのか不明だし、大体、デフォルトのプロジェクトフローをまわしやすいように組織が最適化されているので、なかなか難しいですね。
結局創薬におけるインテグレーションってのはプロジェクトのどの粒度でナニを達成するのかをもっと突き詰めて考える必要がある。バージョンの考え方と、前進しているってのはどういうことかっていう定義が必要なんだろうなぁ。
インスペクションは種々のアッセイ結果を解析していく上で得た理解、つまり薬剤候補としての化合物の性質の許容の範囲ということになる。こういう情報はコミット時（または合成に着手する前）にアラートとしてフィードバックされるべきものであろう。
推測するな計測せよっていうのは創薬プロジェクトにおいてもやはり至言で、ウェット（実験系）のヒトは実験結果を解析しないで雰囲気でいい加減な解釈をするヒトが多い。たんに散布図とるだけでも、いい加減な解釈してるとバレるんだけど、受け取る側のケミストも裏取りしないで素直に受け取るので、一緒に泥沼に突き進んでいく光景が散見されて微笑ましい（こういうのはうちだけの問題ではないだろう）。
ただし、これはヒトの問題で片付けないで、システムとしての問題として考えるべきことであろう。根拠としてのプロットを明示するような規約を用意するだけでもこういうアホなやりとりはだいぶ減るだろうし、自動的にプロッティングを用意するシステムにすればなお良い。そういう状況でも治らない場合は組織的な病気なので伝染る前に前に移ることを考えましょう。
テストは試験です、つまり人力です。ソフトウェア業界ではどんどん追加していくわけですが、創薬プロジェクトではプロジェクトが始まった段階で既にテストが存在しています（逆にテストがないとプロジェクトが始まらない）。テストは基本的にコストのかかるものであり、ある段階で新たなイシューが発生した場合に新たなテストを組み込むかどうかは大きな意思決定を伴うし、新たなコストが発生しますね。
1,4,5は創薬プロジェクトでも同様なことが起こり、有用であろう。2の手作業はちょっとわからないが、手順をきちんと決めることでアウトソーシングできるとかであれば、コスト削減と、コモディティ化という意味で意味があると思う。
3は創薬プロジェクトにはデプロイに相当する仕事がないからあまり関係ないかも。
個人的には4,5に関心があるなぁ。
11102011 chemoinformatics work
先週のインフラ勉強会でCIツールとしてJenkinsを教わったので、早速GitHubのpythonプロジェクトをjenkinsで動かしたりしていた。まぁ大体動いたのだけどエントリに起こす時間がないのでまた今度。
というわけで、継続的インテグレーション入門を見なおしているんだけど、実際に少し触ってからもう一度読むと、あーなるほどと思うことがあって勉強になるわけです。
製薬のようなライフサイエンス業界にも似たようなCIの取り組みをしている会社があるみたいで（残念ながら国内では知らない）、彼らはContinuous Improvementと呼んでいるんだけど、基本的にはアジャイル開発の流れを汲んでるっぽいので、目的とするところは一緒ですね。
ただ、テストにヒト（ベンチワークの研究社）を必要としたり、イテレーションが一週間位と長かったりするのでそのままソフトウェア業界のベストプラクティスを参考にするわけにはいかないんだろうけど、強いしなやかな組織をつくるためには正しい方向性の一つなんじゃなかろうかなぁと思うわけですね。
こういうのもそうなんだけど、創薬の現場にもっとアジャイルな手法を取り入れたら素敵なんだろうなぁと思っているのだけどねぇ。
25082011 chemoinformatics work life
デザインの骨格は良書ですなーとおもっていたが、デザインの輪郭も負けず劣らず素晴らしい本であった。
「デザインの輪郭」という言葉は、この本のためだけに思いついたわけではない。これは、「デザインとはいったい何であるか」という問いに答えるときに思い浮かぶ像のようなものである。
あまり言語化すると、ゆるふわっとしたものが失われるのでエッセイくらいで感覚として伝えるというこの方式のほうがよく伝わってくる感があった。
選択圧自体は人為的なものではなくて、いわゆる「状況」なんです。状況が、それが生き残るかどうかということを常に選択しているということです。
仕事のやり方に関してはここらへんの言葉が好きですね。
ピラミッドは頂点から組む。
下から組み上げても台形にしかならない場合があるから
これも理想でしょう。
オフィスは肥えた土壌のようなものです。 スタッフと毎日耕している
ブレーンストーミングもやらないし、 アイデアをたくさんだそうともしない
この本は相当面白いです。
マーケティングにあるような、差別化戦略とかポジショニングは結局価格競争とか、過剰サービス競争に巻き込まれないように、ニッチな市場を複数開拓する。
「月三万円ビジネス」ではインターネット向きの商品はなるべく避けます。インターネット向きというのは、極端に言うと「売り飛ばし」ができる商品です。得る人と買う人の人間関係は離れていればいるほどいい
つまり、人間関係が近くなるようなビジネスを目指す。ワークショップ形式とかの体験を売るようなビジネスとかね。
いくつかのビジネスが載っていますが、かなり参考になった部分が多い。筆者の住んでいる所が実家の近くなのでビジネスと顧客のイメージがなんとなくわくというのもあるかもしれないが。
17082011 chemoinformatics work
創薬系ももっときちんとログをとって定期的に振り返る、それを細かいサイクルでおこなったほうがいいんじゃなかろうかという意味合いも込めてSAR Newsに寄稿したのが去年のことだけど、もっと知識管理全体をどうするのがいいだろうかと、ここ数ヶ月考えていたので、お盆休みを利用して少しまとめてみる。(なぜ数カ月考えていたかというと、4月にITサポートの部署に異動になったという大人な事情ですねw)
今回移った部署が管理しているインフラ自体は僕らが昔作ったものだが（ITっていう名前がついててもシステム開発できたり、まともなプログラミングができるわけではない。）異動後何回か面談してみても、現在の上司に最近の手法であるアジャイルを創薬システムに応用してみようとか、PDCA(創薬だとDesign-Make-Test-Analysisかな)とかそういう話をしても理解出来なかったし、だからといっていまさら勉強する気もないだろうからなぁ。
とはいえ誰かがそろそろ前進させないとまずいと思うので、異動した記念にでも夏の終わりにでも(2,3個役職飛ばして)振るだけ振ってみる予定なんだけど、他のヒトの役にも立つかもしれないのでエントリとしてまとめておきます。
Data, Information and Knowledgeに従って考えていくと都合がいい。というのは割とスパッと切り分けがしやすいから。図ではwisdomが頂上に君臨しているのだけど、よく見るのはData,Information,Knowledgeの三層構造なので、そっちで考えていく。
まぁ、どこの会社もデータのインテグレーションはやるでしょう。とくに実験データのトレーサビリティをどうするかは問題になると思いますができるだけロボットデータにタイムスタンプを付与するくらいはやっといたほうがいいですね。あと実験者に電卓を叩かせないでIC50とかそういう値まで自動的に計算するようにしたほうがよいですね。（実験者は意外にタイポが多い）でもこういった話は今回はどうでもいいので略します。データのインテグレーションは適切に行われているという前提なので最下段のピラミッドはクリアーですな。
データがインテグレーションされたら、次にやるのは分析ですね。分析は別にRでもなんでもいいけど、情報管理という意味では分析のスナップショットが取れる奴がよいですね。 Spotfireとか使うと分析の共有化（情報の共有化）ができます。
Information can be considered as an aggregation of data (processed data) which makes decision making easier.
なぜ情報が必要かというと、それは意思決定がしたいからです。確かにInformationの層をきちんとすれば意思決定は効率的に行えるでしょう。
ところで、意思決定とはなんであろうか？なぜ我々は意思決定をしたいのだろうか？
意思決定をするために必要なものは情報とあと何であろうか？を考えてみます。
合成した化合物が活性あったよバンザーイ（さくせん:ガンガンいこうぜ）とか、頑張って難しい合成こなしてみたけど活性なかったよショボーン（さくせん：いのちをだいじに）
これは意思決定をしているわけではないですね。
ある仮説を立ててそれが正しかった正しくなかったか、正しい場合より角度の高い仮説はどうなのか、仮説が正しくなかった場合どこに問題があって、それを証明するにはどうしたら良いか、つぎはどういう方向で攻めるべきか
そういう継続的な改善作業をコントロールする仕組みが必要なんだと思います。でも、これはInformationの層では管理できないので、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.
知識も簡単に検索できてすぐに理解できるような必要があるが、慣習的に報告書の打ち出しや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.
stackoverflowっていうプログラマのためのQAサイトが良くできていて、クローンが幾つか作られています(OSQA,shapado)
うちではshapado入れてみて半年くらいたつのだけど、ユーザーはまだまだ少ないが質問も70を超えてきて結構楽しい。良い質問にインスパイアされると、より楽しいアイデアが浮かんだりするし、複数のプロジェクトで同じような問題抱えてると、部署で何とかすべき課題なんじゃないの？なんてわかったりするし。
結局、知識管理をも内包したプロジェクトを前進するための全てをきちんと管理し、知識が属人的になりすぎないようにしつつ、柔軟にリソースをコントロールするための全体的な仕組みを考えていきたいが、そのためにはプロトタイプを幾つか作ってみて反応を見ながら進めないといけないなぁと。
読書情報は属人的なものであるが、どういう論文を読んだか、それでどうインスパイアされたか、(自分の持っている情報と照らし合わせて)どこを否定したかといったblogっぽいブックマークサービスがあると便利です。ポイントは目録じゃなくて、それを読んでどう考えたかを記す部分です。ちょっと前に新しいのをつくろうとしつつ開発が止まっているが、なかなかモチベーションを保つのが辛い。
自分でつくってみて、音楽は曲のつなぎかた自体に意味がある(DJing楽しい)から曲名リストは意味があるけど、論文目録眺めても大して面白くない。リファレンスをたどっていきつつサマライズするようなサービスは面白いかもしれないが。
どういうツナガリに意味を持たすかだなーと思う。
Express+ChemDoodleというjavascriptライブラリ同士の組み合わせなんかもコンセプト的にも技術的にも面白そうな気がするが。あとHTML5とタブレットで色々変わりそうな気もしている。
こういったアプローチはソフトウェア開発業界の方が断然進んでいるので、そういった本を幾つか。できるだけ概念を説明しているようなのを選んでみました。
継続的インテグレーション入門 開発プロセスを自動化する47の作法
入門Git
意思決定は技術ですね。この本は結構面白かったので創薬の場合で考えてみた。
意思決定には、おかしなパラドックスがある。誰でも意思決定の重要性については理解しているが、それでも意思決定のトレーニングをする人は極めて少ない。
本書は特に意思決定の際にはまりがちな落とし穴を8つ紹介している
モデラーの間にはよく知られた格言がありますね、正しいモデルなんて存在しない、十分に表現できるモデルが得られただけだみたいな（正確なのは忘れた）。
思考モデルとは、外の世界の現実を自分の内側に描写したものである。細部よりもその情報が素早く自分に到達することを重視した、不完全な描写と言ってもいいだろう。
例えば芳香環を共鳴による電荷移動だけしか知らなくて電子雲のイメージを持てないとかそんな感じ。モデルの限界わかってないと、ハマることは多い。
帰納法的に考えてしまう問題は、要は限られた情報をもとに未来を予測してしまうことだ。
これはQSAR,QSPRの抱える本質的な問題ですね。構造XX相関は、知っていることの範囲でしか答えることができないし、どこまでいっても相関であって因果関係とは異なる。
ストレス反応があると短期的に特になることを追求できるが、長期的に何がいいのかを考えられないのだ。これが、トンネルビジョンになる原因の一つだ
プロジェクトでミクロな視点しかできないのは本人の資質かなと思っていたけど、環境要因も後押ししてるのかもしれない。短期成果は見えやすいのでプロジェクトリーダーにあがりやすいんだけど、こういう人がなるとプロジェクトが迷走しやすい（経験的に）
物事を予測する際に、人間がアルゴリズムを上回る結果を出すような分野を見つけるのは不可能
直感がうまく機能するのは安定した環境下なので、複雑な状態では重要性としては低い
理論構築をする過程では、仮説が実データと合っているかを研究社が検証し、その中で出てくる例外（アノマリー）を見つけ、さらに理論を研ぎ澄ましていくのだ
深く考えて本質を捉えるということですね。特にその際に相関関係と因果関係は違うということをきちんと理解することが重要。
lead optimizationするときには大抵logPとかPSAの相関からそういったパラメータの上げ下げで問題を解決するストーリーにしたがるけど、それってメカニズム的に説明がつくの？っていうことを常に問いかける癖をつけておくとよいですね。
所謂ブラック・スワンですね。
平均回帰性から、運により大きな成果をあげた人は次も同じくらい大きな成果をあげるとは限らない。結果よりもプロセスを重視するということは、そういった運の要素を見極めながら実力を評価するということなのでしょう。
まぁ、でも企業は結果を評価してプロセスなんて後付ですよね。頑張ったから結果がついてきたという言葉に現れているような気がする。
一ヶ月くらい前に業界の集まりがあったので、割と仲良くして頂いている他社のメディシナルケミストの人にこんな論調の話を振ってみた。
帰ってきた答えは「ケミストはまぁ他の業種でもつぶしが利くから製薬業界にこだわらないでも日本に就職先はあると思うよ」ということだった。でも、これがしめしていることは、合成っていう作業は、誰でもやれる系のコモディティ化するタイプの仕事のひとつってことじゃないかなぁと思った。まぁ、実際替えがきくしね。
さらに昨日、外資系のソフトウェアベンダーさんが量子化学計算ソフトウェアの売り込みに来てたんだけど、「海外のメガ・ファーマのニーズを汲みとって製品設計してますけど、日本のユーザーさんはまだあまりいないので、今入れて頂ければ日本でトップのほうになれると思います」っていう営業トークだもんなぁ。多分国内企業の性格を汲んだトークなんだろうけど、、、
流行を追いかける人には流行をつくりだすことはできないって言葉を思い出した。
自分のいる業界の未来を考えるに、メガ・ファーマのアジアの拠点が日本にないってことは、やはりこの国のこの業界はクォリティ/コストに競争力がないってことだと思うんだよなぁ。日本にこだわる必要あんのかなぁ、伸びそうな国に移って頑張るっていう選択肢を取る人はいないのかなぁ。まぁ、10年20年すれば答えが出るので気長にまとう。
日本人は自分は出ていかずに、お金を先に出稼ぎに行かせる人が多いようです。しかし、お金より先に人が働きに出ていく時代が来たのです。
本書はそんな日本の状況をわりと外側から客観的に見たコラムですな。英語が出来たらアメリカとかヨーロッパを目指す記事が割と目に付く機会が多い気がするけどアジアのどこかを目指すっていう方向性もあるんだよなぁと思った。
ツイッターあまり関係ないし原著の題名THE WHUFFIE FACTORだし、日本語タイトルに騙されてた。新しい経済はどう回るか、どう回すかを考えさせられる本ですな。
貨幣資本から知識資本、そしてその先にはウッフィー資本が待っているのかなぁと漠然と感じる。
いま私たちは2つの並行する経済を生きている。そして俗に言う「資本」つまり「マーケットキャピタル」は、ソーシャルキャピタルがたくさんあるところで生まれるようになってきているのだ
わかったブログで見かけて以来、読まなきゃ思って積んでいたのだけどやっと読み終えた。
ウッフィー資本自体はそれほど目新しいものではないと思うけど、それが重要視されるファクターになってきたというか、セルフブランディングの重要性が増しているということかなぁと思う。
というわけで、LinkedInの日本語版は結構楽しみだったりする。
アントレプレナーの教科書
「誰が」会社を変えるのか 近未来企業へのシナリオ
継続的インテグレーション入門 開発プロセスを自動化する47の作法
デザインの輪郭
月３万円ビジネス
Redmineによるタスクマネジメント実践技法
入門Git
アブダクション―仮説と発見の論理
まさか!?―自信がある人ほど陥る意思決定8つの罠
ブラック・スワン[上]―不確実性とリスクの本質
ブラック・スワン[下]―不確実性とリスクの本質
アジアの時代を予言して２０年
ツイッターノミクス TwitterNomics
モチベーション3．0 持続する「やる気！」をいかに引き出すか
ネクスト・ソサエティ ― 歴史が見たことのない未来がはじまる