自分の職場ももっと継続的なインプルーブメントが必要だろうなぁと思っているが、なかなか難しいですね。まぁ、ああいうのは地道にやるしかないのかねぇとインテグレーション入門を読みなおした。

CIは単に技術の導入にとどまらず、組織やその組織の文化にも変化を及ぼす

第一部はCIの背景や、原則、プラクティスについて書いてあるので、ソフトウェア業界じゃなくても色々参考になります（といってもソフトウェア業界のCIを知らないとよく分からないかもしれないが）

というわけで、自分の置かれている業界（製薬業ですね）におけるCIとはどんなもんかねというあたりをメモっておく。

ちなみに第一部の各章はこんなタイトルです。

• 第１章 始めよう
• 第２章 継続的インテグレーションの紹介
• 第３章 CI によるリスクの軽減
• 第４章 変更を起点としたビルドの実行

継続的インテグレーション入門 開発プロセスを自動化する47の作法
ポール・M・デュバル
日経BP社 / 3360円 ( 2009-08-06 )

以下、用語に関しては特に説明しないが、創薬系におけるバージョン管理というものはどういうもんだろうかとかは考えたことがあるので参考に。

バージョン管理リポジトリ

バージョン管理リポジトリの目的は、アクセスが制御されたリポジトリを用いることによって、ソースコードや、その他(ドキュメントなど)のソフトウェア資産に対する変更を管理することである。これによって、一ヶ所からすべてのソースコードが入手できる「唯一の入り口」が提供される

創薬プロジェクトにおける資産とは何だろうか（というよりどこまで管理すればいいのだろうか）？という問いに閑する答えはシンプルで、プロジェクトを進めるために必要な全てですね。特に実験データに関してはロボットデータまで管理する必要があって、IC50とか中途半端なデータから管理してると、ある日突然シボンヌしますね（データの正しさが担保できない）。

それから、実験プロトコールや、報告書もプロジェクトにおける重要な資産なのできちんと管理する必要があるだろう。プロトコールのような手順のほかにBDDっぽい何か、つまりプロジェクトにおけるビヘイビアのようなものも必要だろう。

インテグレーション

ソフトウェア開発のようにレッドからグリーンを繰り返すサイクルとは異なり、いつか成功するかもしれない失敗を繰り返すから、基本的には常にレッドである。創薬プロジェクトは探索的なタスクが多く、イシューを細かく切ったとしても、それぞれが相互に強く依存しているために、常に手戻りが起きる危険が発生する。

そのため、インテグレーションとかビルドの考え方は大きく異なってくるが、どうしたらいいかに関しては自分の考えが固まっていない（だから文章におこしてるわけだが）。

よくありがちな創薬プロジェクトっていうのは

1. in vitro薬理活性
2. in vitro動態パラメータ
3. in vivo 動態パラメータ
4. in vivo 薬理パラメータ

の順にそれぞれ閾値を決めて、多段フィルタリングのイメージでゴールに向かって進んでいく。上で書いたように基本的には成功（閾値を超える）するかもしれない失敗を繰り返しながら後半のアッセイ系に進む確率を挙げていくわけです。

基本的にアッセイを繰り返すことにより、そのアッセイ系での成功確率は上がっていくわけですが（あがらないのももちろんあるがそれはサイエンスとして理解できてないとか本質を捕まえてないと表現する）後ろのほうでイシューが出てきて合成方針が変わると、最初の方のアッセイ系の成功確率ががくんと下がることがよくある。

というわけで、フローとして流すのがいいのか、幾つかのアッセイを並行で流して多次元最適化を行うのがいいのかはコストの制約とか、プロジェクトの性質で決まってくるのだと思うが、プロジェクトスタート時にはどういう組み方をしたらいいのか不明だし、大体、デフォルトのプロジェクトフローをまわしやすいように組織が最適化されているので、なかなか難しいですね。

結局創薬におけるインテグレーションってのはプロジェクトのどの粒度でナニを達成するのかをもっと突き詰めて考える必要がある。バージョンの考え方と、前進しているってのはどういうことかっていう定義が必要なんだろうなぁ。

インスペクション

インスペクションは種々のアッセイ結果を解析していく上で得た理解、つまり薬剤候補としての化合物の性質の許容の範囲ということになる。こういう情報はコミット時（または合成に着手する前）にアラートとしてフィードバックされるべきものであろう。

推測するな計測せよっていうのは創薬プロジェクトにおいてもやはり至言で、ウェット（実験系）のヒトは実験結果を解析しないで雰囲気でいい加減な解釈をするヒトが多い。たんに散布図とるだけでも、いい加減な解釈してるとバレるんだけど、受け取る側のケミストも裏取りしないで素直に受け取るので、一緒に泥沼に突き進んでいく光景が散見されて微笑ましい（こういうのはうちだけの問題ではないだろう）。

ただし、これはヒトの問題で片付けないで、システムとしての問題として考えるべきことであろう。根拠としてのプロットを明示するような規約を用意するだけでもこういうアホなやりとりはだいぶ減るだろうし、自動的にプロッティングを用意するシステムにすればなお良い。そういう状況でも治らない場合は組織的な病気なので伝染る前に前に移ることを考えましょう。

テスト

テストは試験です、つまり人力です。ソフトウェア業界ではどんどん追加していくわけですが、創薬プロジェクトではプロジェクトが始まった段階で既にテストが存在しています（逆にテストがないとプロジェクトが始まらない）。テストは基本的にコストのかかるものであり、ある段階で新たなイシューが発生した場合に新たなテストを組み込むかどうかは大きな意思決定を伴うし、新たなコストが発生しますね。

CIの価値

1. リスクを軽減
2. 繰り返しが多い手作業を削減する
3. いつでも、どの環境にもデプロイできるソフトウェアを生成する
4. プロジェクトの可視性を改善する
5. ソフトウェア製品に対する開発チームの自信を深める

1,4,5は創薬プロジェクトでも同様なことが起こり、有用であろう。2の手作業はちょっとわからないが、手順をきちんと決めることでアウトソーシングできるとかであれば、コスト削減と、コモディティ化という意味で意味があると思う。

3は創薬プロジェクトにはデプロイに相当する仕事がないからあまり関係ないかも。

個人的には4,5に関心があるなぁ。