Drkcore

リーンソフトウェア開発を読んだ

アジャイルとは結局のところ何なんだろう？という疑問が再浮上してしまった。

アジャイル・ソフトウエア開発を、トヨタの生産方式とし知られる「リーン思考」の視点から解説したユニークなアジャイル解説本です。「ムダをなくす」という意味のリーン思考と「俊敏さ」を主眼とするアジャイル開発とは、根本的なところで実は同じ考え方であり、方法論としても共通するところが多くあります。

ソフトウェア開発は製造と大きく異なるが、創薬もソフトウェア開発と大きく異なると思う。

開発はレシピの作成であり、製造はレシピにしたがって料理をつくることであると考えていい。

という文脈にならうのであれば、創薬とはレシピの発見である。つまり見つかるかもしれないし、見つからないかもしれないという不確定さが常につきまとう。

リーンソフトウエア開発～アジャイル開発を実践する22の方法～
メアリー・ポッペンディーク
日経BP社 / ?円 ( 2004-07-23 )

7つのリーン原則

ムダの排除
学習効果を高める
決定の遅延
できるだけ早く提供
チームに権限を与える
統一性
全体をみる

ムダの排除に関して

だれも読まないペーパーワークは価値を付加しない

バリューストリームマップも重要

学習効果を高める

ある程度の新しい情報を得るためには、ある程度の失敗率がなくてはならない

決定の遅延

イテレーションをくり返すなかで、自然と設計が浮き彫りになってくるようなシステムの作り方をすると、開発中に発生する変更に対応しやすいロバストな設計ができあがる

問題解決に関しては

深さ優先の手法は、照準を合わせる領域を正しく選択した場合にのみ、うまくいく

できるだけ早く提供

プルシステムの特徴は「見える化」つまり目で見るマネジメント

全体をみる

「ヒトは生産性の測定対象となる計測結果を最適化しようとする」ので測定対象は慎重に選ばないといけない。

標準化
仕様化
分解

オースチンの指摘

個人の成果計測値を個人に帰するのではなく集合化することが重要だ

28092012 work

「残業なし」で「好成績」のチームは理想論（個人だったらあるけど）

理想は追いかけるものだけどね。

なぜ、あの部門は「残業なし」で「好成績」なのか? 6時に帰るチーム術
小室淑恵
日本能率協会マネジメントセンター / 1575円 ( 2008-12-24 )

ワーク・ライフ・バランスの重要性を説くのだけど。

ワークライフバランスは、「ワークとライフを両方充実させることで、結果として、どちらもうまく回るようになる」という考え方です

個人的にワーク・ライフ・バランスってのはワークとライフの融合を説くものなので、サラリーマンのような時間を売る職業にそれを強いるのはなんだかなぁーと思うところではある。広義の賃金圧縮だろうと。サラリーマンも自営化してきて、成果で賃金が大きく変動するんだったら分かるんだけど。

とはいえ、働き方としてはそうだよなぁと思うのも事実。僕も「より面白いところ、やりがいのあるところ」があれば速攻移るべきだ（流動性に貢献するべき）と思うしね。

18092012 work

チケット駆動開発を読んだ

付箋の数と良書度は比例する（脳内調べ）。

アジャイルとウォーターフォールという二元論的な考え方は、その概念が普及する段階では役に立ちましたが、もうその次代は終わりつつあると思います。様々な開発法があるなかで、どのようなプロセスで開発するか、具体的な実践技術が求められているでしょう。

1347269572

僕のチケット駆動に対する期待は、創薬研究への応用なので、チケット駆動開発の背景にある考え方がぎっしり詰まった本書は、色々な発見や再発見があったり、今の仕事のアナロジーを見つけたりとかなり満足度の高い本だった。ただ、redmineをある程度使っているとか、アジャイルサムライ読んだとかそういいう基礎知識は必須なので、いきなり本書を読むよりは前作を読んだりしておいたほうがいいかなと思う。

Redmineによるタスクマネジメント実践技法
小川明彦
翔泳社 / 3444円 ( 2010-10-13 )

アジャイルサムライ−達人開発者への道−
Jonathan Rasmusson
オーム社 / 2730円 ( 2011-07-16 )

本書は、ソフトウェアの使い方が載っているわけではない(mantisくらいかな)ので、そこは注意。

チケット駆動開発
小川明彦
翔泳社 / 3444円 ( 2012-08-24 )

処理手順

障害管理ツールの処理手順(p.24)を創薬探索系に重ねると、

障害発見者: アッセイ担当
BTS: BTS
担当者: 合成担当

という感じになるかな。そうすると障害とは何か？という話になるが、創薬系だと予想外の結果ということになるだろう。

予想外というのは仮説駆動開発の文脈だったら、なんのために合成するのか？という最初の目的が達成されたかどうかで判断するところだろうが、明確な目的を持って合成されることは少ないので、MMPに照らし合わせてcliffかどうかで判断してもいいかもしれない。結局cliffは予測外の事象だからね。

リポジトリマイニング

創薬系だとリポジトリにあたるものは既に存在するので、そこから今後の予測を行う技術は非常に興味がある。本書では詳しく解説されてないので、他の文献をあたろうと思った。

バージョン

本書を読んでredmineのバージョンの使い方を理解した。だが、創薬系だと多次元で並行的に進めていくので、ソフトウェア開発だと2系と3系を同時に開発するみたいな感じかなあ。ちょっと難しい。

バージョンの概念は、単なるタグだけでなく、合意というマネジメント要素も含んでいるのです。

p.295のバージョンの概念が欠落する理由も参考になった。

2012.09.18追記

著者の方からレスポンスを頂いた。ありがとうございます。

Q.創薬系のプロジェクトのバージョンとは何か？ A.プロジェクトのマイルストーンに相当します。　学会で報告する、創薬研究の開発が完了する、などのチェックポイントが大きなマイルストーンになりますが、たぶん1ヶ月単位で意味ある成果物を出せるように、マイルストーンの目的を明確にすればいいでしょう。

大きいマイルストーンはあるのだけど、一ヶ月単位で測れるようなマイルストーンというのはあまり見ない気がする。というわけで、今必要なのはそういうブレークダウンした形のマイルストーンをどう定義するかだな。そういう意味ではメトリクスも足りてないだろう。

もう一つは、創薬開発手法は生産ではなく開発だという点において、トヨタ生産方式みたいな工場の生産系よりはソフト開発手法にすごく似ているのだけど、大きく異る点が1つある。それは探索の割合が非常に大きいということだ(ライフサイエンス全般に言えることだけど)。これは工学と明らかに違って、コントロール出来ない要因を多分に含んでいて、それを考慮したような仮説ドリブンなマイルストンが必要なんだろうなぁと。

もう少し丁寧に考える必要があるが、理解が前進したので嬉しい。

13092012 work

国際学会English―挨拶・口演・発表・質問・座長進行

読み流しておこうと思ったのだけど、結局時間がとれなかったというか、黒龍のひやおろしを呑み始めてしまったので、集中力が霧散して緩みまくっている。

国際学会English―挨拶・口演・発表・質問・座長進行
C.S.ラングハム
医歯薬出版 / 2625円 ( 2007-04 )

明日の新幹線のなかで流し読みしておこう。

というより、LBDDとかいいつつ120%量子化学に傾倒しているので、明日の内容はアウェーすぎるんじゃないかと不安がないわけではないが。まぁ、自分の中ではLBDDの行き着く先は量子化学計算だと思っているので空気を読まずに発表する。

そして、明日のセミナーが終わったら、次の日から二日間PyConJPなので楽しみだ。

11092012 work twitter-bootstrap

自分用twitter bootstrapを管理する

ウェブ業界なんかだとデザイナーさんがいるので、「デザインがーーーーー」みたいなのはクリティカルな問題にはならないのかもしれないが、製薬系の研究所とかだと、研究所内のシステム構築のためにデザイナーを雇うとかまずあり得ないので、しょっちょう悩みます。

特に、イントラでウェブサービスやろうとか思ったらjQuery使って見ためを良くしたりとかユーザビリティとか考えて使いやすくしたりといったフロントエンドのスキルは必須。

つまり、モックを使ってできるだけ早く70点のユーザーインターフェイスを作るスキルが超重要なわけだ。

しかも、twitter bootstrapを使おうと思ったら、頻繁なバージョンアップに対応しないといけないわけで。

GitHub対応

GitHubハンズオンやったので、その時の@ishisakaの資料を参考にすればいいと思います。

とりあえず、本家からforkしたらcloneして、upstreamを設定します。

git clone git@github.com:kzfm/bootstrap.git
cd bootstrap/
git remote add upstream https://github.com/twitter/bootstrap.git
git fetch upstream
git merge upstream/master

これで最後のニ行を叩けば常に本家の更新に追随できるようになります。

設定を変更

Twitter Bootstrap Customization Best Practicesの後半を参考に、bootstrap.lessとvariavles.cssをコピーして自分用の設定ファイルを用意する。my_bootstrap.lessとmy_variavles.lessにした。Makefileのbootstrap.lessもmy_bootstrap.lessに変えておく。

こうしておけば本家のファイル群を変更する必要がないので、いつでも

git fetch upstream
git merge upstream/master

すれば、本家の更新に対応できる。

コンパイルしたい場合には

$ make bootstrap
mkdir -p bootstrap/img
mkdir -p bootstrap/css
mkdir -p bootstrap/js
cp img/* bootstrap/img/
recess --compile ./less/my_bootstrap.less > bootstrap/css/bootstrap.css
recess --compress ./less/my_bootstrap.less > bootstrap/css/bootstrap.min.css
recess --compile ./less/responsive.less > bootstrap/css/bootstrap-responsive.css
recess --compress ./less/responsive.less > bootstrap/css/bootstrap-responsive.min.css
...
cat bootstrap/js/copyright.js bootstrap/js/bootstrap.min.tmp.js > bootstrap/js/bootstrap.min.js
rm bootstrap/js/copyright.js bootstrap/js/bootstrap.min.tmp.js

bootstrapディレクトリ以下にコンパイルされる。

その先

あとは、Twitter Bootstrap＋その他で「本当に」イケてるモックを作る手順なんかを参考にしながらいい感じの自分用モックを量産すればいいと思うのだが、そういうのをもくもくとやるといい気がしませんか？

というか、やることにしたので興味があれば参加するといいと思います。プレゼンしたいひとも歓迎。

静岡デベロッパーズつくる会#6 (Mock! Mock!)

ATND 静岡デベロッパーズつくる会#6

だらだらと作ってもよし、黙々と作ってもよしのつくる会です。前回同様、好きな時間に来て好きな時間に帰ってかまいません。

今回はMock! Mock!とモックをモクモクいじる回にしてみました。みんなで一緒にtwitter bootstrapをいじりましょう。

レスポンシブ・ウェブデザイン標準ガイドあらゆるデバイスに対応するウェブデザインの手法
こもりまさあき
エムディエヌコーポレーション / 2625円 ( 2012-05-25 )

10092012 work

通勤どこでも仕事術

だいたい知っていることだった。出張報告書の予想版を予め書いておくというのは参考になった。

通勤どこでも仕事術
美崎栄一郎
ぱる出版 / 1470円 ( 2011-07-30 )

電源タップは持ち歩くのに便利なのが欲しいなぁと思ったので、モバイルタップを買ってみた。

SANWA SUPPLY モバイルタップ 2P・3個口ホワイト TAP-M1W

サンワサプライ / 682円 ( 2012-01-31 )

29082012 work

チケット駆動開発の本を読み返した。

2月くらいからredmineを使い始めて、中規模なサイトを2,3個作って、チケットの粒度とか運用サイクルとかリズム（トヨタ生産方式でいうタクトに近いかな）なんかについて色々とわかってきたので改めて読んでみた。

Redmineによるタスクマネジメント実践技法
小川明彦
翔泳社 / 3444円 ( 2010-10-13 )

最初は複数人で使うつもりで啓蒙してみたりしたんだけど、予想通り難しかったので、他人にふった仕事もIssueとして全て自分で管理したら、うまくまわった。4.２節の権限ポリシーをワークフロー型に振って、他人に仕事をアサインするっていうタスクをチケットとして切ったことになるのかな。

他人への仕事のアサインを不確実性のあるタスクとして登録して、タイムアウトしたら自分に再アサインするというやり方にしたわけだけど、これで淡々とこなせるようになったし、さらにイライラしなくなって精神的にも都合が良かった。

ついでにチケットも会議と紐付けるようにしたので、会議を定期的にやれば、プロダクトの開発サイクルもそれにつられてタイミングが揃うようになったし、会議の議題とかチケットの粒度も次の会議までの期間でできそうな(3週間くらい)に揃えやすくなった。

変化を受け入れる技術、プロジェクト管理、開発環境がなければ、アジャイル開発は絵に描いた餅です

これはそうだよなとしみじみと思った。というわけで、これも読む予定

チケット駆動開発
小川明彦
翔泳社 / 3444円 ( 2012-08-24 )

その他

化合物の合成を１つのチケットにしてbacklogsプラグイン使えば、かなり便利に使えると思うんだけどどうかな？と思った。そのうち試してみたい。

25082012 work life

ライフサイエンスQAにケミストリーな質問をしても良いらしい

先日のtwitterのやりとりが、FAQっぽかったので@32nmのススメもあってLSQAに投稿しておいた。LSQAは主にバイオインフォマティクス系の話題をとりあつかうもんだと勘違いしていたので、これからはもう少し質問しよう(回答も)と思った。

うちの職場でもOSQAを入れているのだが、なかなかアクティブにならないので、検索した時にヒットしなかったら別のサイトに検索書けるようにならんだろうか？P2PみたいにQAがつながらないかなぁと。GitHubみたいにQAがフォーク出来る感じだといいんだけど。

まぁ、ユーザー100人規模だとなかなかアクティブにしにくいのかなぁ？もっとずっと規模の大きい研究所で試してみたいなぁと思うこともあるが、それは甘えなのかな（多分そうなんだろう）。

ただ、個人的にはこういうことをやる場合のユーザー数は時間を超えた述べで考えないといけないのかなと思っていて(つまり一年後の自分は他人)、持続的で効率的な研究スタイルのためには絶対必要な仕組みだと思うんだけど、プロジェクトに張り付いていると、目先の問題を解くことで一杯一杯でなかなか理解してもらえないとこがもどかしい。

そういう意味では、ChEMBLはちょっとしたブレークスルーかもねーなんて思ったりする。従来メディシナルケミストリー的な情報は閉じていて出てこなかったのが、気軽にデータをあつかえるようになったから、個人の趣味レベルで色々やれるようになったし、パブリックデータベースに閑する質問はパブリックでやればいいだろうから、これからもっと面白い情報も出てくるんじゃないかなーと。