28052009 work
不確定要素満載でかつ、一回のイテレーションが割と長め（数週間）でイテレーションが被っていて、途中に割り込みが入ることが多く、且つそれらによって戦術が変化することが頻繁におこることの多い、研究プロジェクトにアジャイルはどの程度有効なのだろうか？と気になった。
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引きそのうち試してみたいなぁ。色々やりたいことはあるが、最近体調悪すぎだ。
「manage it」を読んだ
読み終えるのに結構時間がかかったというか半年くらいかけて読んだ。 ちょっと読みにくい本だったな。
Manage It! 現場開発者のための達人式プロジェクトマネジメント創薬研究系でも参考になる部分はもちろんあったが、IT系どっぷりじゃないと理解しにくい面が多かったかも。
26052009 work
創薬の探索プロジェクトにmsprojectはいけてないですな
いけてないどころかむしろアレ。
人月計算はそういうレベル（合成する、アッセイする）みたいな、ルーチーンのとこだけ必要で、それ以外のとこでは必要ないですし。ガントチャートもアホっぽくて気に入らん。
なんつーか、ガントチャートに落とせない部分を如何にコントロールするかが重要なんだよなぁという本質的な矛盾を感じる今日この頃。
創薬研究に特化したプロジェクトマネジメントシステムをつくれば需要はあるんじゃないかなぁと思った。
アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング24052009 chemoinformatics work
leadhoppingのこと
リードホッピングとはつまるところ、選択されなかったより良い未来を、過去にさかのぼり選択しなおすことだと思うのだ。または、現在の結果が(成功にせよ失敗にせよ)選択されたことで、過去の時点の確率が変化したというベイズっぽい解釈でもよいかと。
上の図でいうと外側のサークルを類似性とかで辿ったとしてもホッピングなんて成し遂げられなくて、もっと、最初の化合物に近いところにさかのぼりつつうまい分岐点で辿りなおさないといけない。
そのためには化合物のデータベースがここの化合物がどう継承されるかを記録されプロジェクト毎にツリーとして表せるようにしておかないといけないんだろうなぁ、なんて思うわけだ。
ちょっと農業してきます
田舎とのギャップが、あーーーー！なんて思ってしまうところがあり、かなり面白かった。
ちょっと農業してきます (sasaeru文庫 お 2-1)さて、私もとちぎのど田舎に帰省していた時に、このエントリをみながらフムーなどと思ったのだけど、ただただ東京にいるだけでは、漫然と変化に流されてしまい、淡々と変化を食わされている状態に陥るのではなかろうか？なんて思った。
まぁ芯は必要で、東京のメリットはネットワークの構築速度が速いことかなぁとか。いったんネットワークが構築されてしまえばメンテナンス自体は、グローバルなのでまぁどうでもいいかなと。田舎はネットワーク構築のチャンスが格段に低いな。一方、やる気さえみせれば(いわゆる)ハブにはすぐに到達するんではなかろうか？
あとは、成長を前提としない(または緩やかな後退を前提とした)ビジネスモデルは地方のほうがよく考えている気はする。サステイナブル？東京との温度差をうまく緩やかな成長エネルギーに向けるみたいな。特に酒なんかは地産地消の精神に東京の購買意欲を少し混ぜると良さげですよなと。
そういう意味では京都のサイズは素敵だなぁと思う。
という京都で暮らしたいなぁというネタでした。
27042009 work
重要でないけど緊急な仕事を如何にやらないか
重要だけど緊急でない仕事を如何にこなすかは長期的な視点での自分の成長において重要なファクターだ。一方、重要でないけど緊急な仕事を如何にやらないかにこだわるのもそれ以上に重要なことではないだろうかと最近よく思うようになってきた。
- この種の仕事を受けてしまうと、周りの自分に対する重要度のファクターが低く見積もられてしまう（環境要因）。いっぽう、自分の重要度に対する認識が知らず知らずのうちに下がってしまう
特に裁量労働とかだと、自分の裁量でそういう仕事を重要だと捉えてこなしているみたいな感じになってしまい、超痛いので、そういう仕事を受ける時にはそれがどの程度重要で緊急性のあるタスクなのだが納得いくまで説明してもらうようにしている。
途中で根負けして「じゃぁいいよ、他の人に頼むから」とか言わせられるようなタスクは自分でやる必要がない。どんどんおろしていけば、重要かつ緊急にマッチングするような人に行き当たるし、もし最終的にタスクの受け入れ先がだれもいなくても、それは「本人にとって重要且つ緊急なタスク」に違いないので自分でやるでしょ？
まぁ、あとはそういうタスクはいくらこなしたところで、相手が恩を感じるようなことにはならず、持ちつ持たれつ的な貸し借りも発生しないので、やるだけ無駄。
WEB+DB PRESS Vol.50
予約した
WEB+DB PRESS Vol.5019042009 work
自分で失敗を自覚するまで納得できない人
自分で失敗を自覚するまで納得できない人は失敗が確定するまで、失敗が近づけば近づくほど指数関数的に頑張り（そして周りにもがんばりを強要し）、精神論をまき散らしつつ周りを巻き込み疲弊させ最終的に集団心中するようなタイプが多いような気がする。
しかし、本人は頑張ったという達成感で一杯なので、次もめげずに同じことを繰り返すのだ。
屍を超えていくのではなく、屍を再生産しようとするそのスタイルは僕は好きではなかったりする。
PDCAと陰陽
会社で資料をつくる時にはplan-do-check-actなPDCAサイクルを引き合いに出すことが多いのだけど、本当は陰陽マークのほうが好みだ。
do-checkは陽でact-planは陰
陽の部分は効率化の対象になりやすく陳腐化しやすいけど、陰の部分は内に向かい経験により高いところを目指せる。
そしてヒトはdarkcoreに向かう
Warlords Rising30032009 work
open accessやばい
製薬会社だと、会社に縛られる要因ってのは
- 会社にいないと実験できない（設備の関係）
- 会社でないとディスカスできない事柄（社内的なノウハウ）
- 論文の量(知識の吸収)
最初の設備に関してはコンピューター系にとってはもう関係ない。むしろ自宅のマシンで小さいサンプルのコードを動かして、会社のクラスタではrunするだけみたいな。職場というのは、スケールとデータの違いのみ。
二番目も、ディスカスなんて週一でいいし、社内でするより社外でのつながりを重視したほうが得るものが多い。社外で得た情報やアイデアの中から会社にとって良さげなものを選別してコミットしとけば良いような。結局、会社は共有レポジトリみたいなもんで、pushとpullしに出かけていくところ。そしてpullの頻度が出社の頻度なのが理想。得るものがなければpushだけして帰ればいいんじゃないの？それが裁量労働+成果主義のあるべき姿だと思うけど。
(研究者として)会社に縛られる最大の要因が、論文アクセスだ。他人の知識を書物として吸収できるのは重要だが、会社の資産故に外部との議論に使えない。しかし、オープンアクセスになったら気兼ねなく意見をブログに載せられるし、横のつながりも増えるだろう。現実に、open accessの論文をもとにディスカッションするのが一番盛り上がるし。
とか考えると、会社のこじんまりとしたキャリアパスとかアレだよね。SOHOとかベスト