創薬研究というのは細かな作業が沢山あり、変化の激しいテスト工程なのに、そのインフラにはBTSとかITSとかないのが不自然だと思っていて、この前寄稿したときにちと触れといた。僕はソフトウェア業界にいるわけじゃないけど、問題解決の方法論としては似たような部分があるから参考になるんじゃないかと常々思っていたら、ズバリな本が出ることを知ってすぐに予約しといた。
で、一昨日届いたので今日の移動時に一気に読んだ。
Redmineによるタスクマネジメント実践技法チケット駆動開発的なアプローチは自分の仕事管理では既に取り入れていたのであった。自分では文書駆動開発だと思っていたけど本書を読んだら、これは明らかにチケット駆動開発のコンテクストだよなと。
個人的には第一部の技法は非常に勉強になった。第二部は実際にRedmineをどう使うかという話はソフトウェア開発としては色々面白かったが、自分ではRedmine使ったことがないので、ピンと来ない話も幾つかあった。実際に使って見ながら本書を読み直せば新たな発見があるのだろうと思うので、今度、創薬のプロジェクトで、Redmine使えないか検討してみようっと。そうすれば創薬向けのITSとかBTSみたいなものがみえてくるような気がするんだよな。アジャイル創薬とかそういう方法論は一部試され始めているのでその先はこういうツールの重要性が認識されるだろうと思うんだよね。
それにしても、「ツールでサポートすれば行動が変わる。行動が変われば考え方が変わる」というのはいい言葉ですな。うちのインフラやってるチームにも本書を薦めてみようっと。
以下、メモ。
- 紙の障害票は障害の歴史を残してもれなく対応するのが目的なのに対し、オープンソースのBTSは情報の共有を重視
- チケット駆動開発のメリット
- 開発メンバーの仕事が把握しやすくなる
- ソースコードのコミット単位が明確になる
- ソフトウェア開発プロジェクトには情報共有と見える化が必要
- 測定できなければ制御できない
- チケットの粒度
- ニコニコカレンダー
- MS Projectは顧客向けの進捗報告の視点、TracやRedmineは開発チーム内部の進捗管理の観点
- ウォーターフォールは前工程の品質の悪さをそのまま引き継いでしまいがち
- これは創薬でも一緒やな
- アジャイルテストの四象限