OSCON 2005でのSpikeSourceの講演
IT ConversationsでオープンソースベンチャーのSpikeSourceのKim Poleseの講演を聞いた。業界人向けの内容ではあるが、平易な言葉で明快にSpikeSourceの目指す方向を述べており業界人である私には参考になった。表題のリンク先でMP3ファイルがダウンロードできる。
SpikeSourceはオープンソース界では名の通った会社で、「オープンソーススタック」を商品としている。私の理解では、たとえば以下の組み合わせを検証した上で検証済みスタックとして出荷している。
当たり前と言えば当たり前だが、商品としてオープンソーススタックを出すに当たってSpikeSourceがおこなっているのはテストで、それこそが彼らが生み出している付加価値の源泉であることが納得できた。講演の内容は以下の通りである。聞いて頭に残ったものを書いているので超訳と思って読んでいただきたい。
Do It YourselfからDo It Togetherへ
オープンソースの利用はDIY(Do It Yourself)であったが、そこからDIT(Do It Together)へ移行しなければならない。現在では多数のオープンソースソフトウェア(以下OSS)があり、企業のIT部門はそれらを組み合わせて活用している。OSSの数が多くなるにつれて、また、OSSへの依存度が増すにつれて多くの企業がOSSの管理をするための組織を持つようになった。OSS間での互換性のチェックや、パッチ管理、ライセンス管理をおこなうためである。こういた組織は企業内のITベンダーと言える存在で、貴重な企業のIT開発資源を使ってしまっていることになる。このようなDo It Yourselfの段階からDo It Togetherの段階へ移行することで貴重な開発資源をより戦略的な開発に向けることができるようになる。
鍵はテスト
DITの段階へ移行する鍵になるのはいかにテストである。その部分に着目してSpikeSourceという会社は作られた。マイクロソフトには開発要員とテスト要員が同数居る。そして典型的な製品で50万のテストケースについてテストがおこなわれている。マイクロソフトの製品の品質についていろいろ言われるが、他の同様の製品よりもしばしばねばり強い。その理由はこのテスト体制にある。
OSSに対してマイクロソフトのようなテストの方法は取れないし、取るべきでもない。そこで、いかに組織的・自動的にテストをおこなうかということになる。オープンソースコミュニティとしてその方法を確立できれば新たな段階へ飛躍することができる。SpikeSourceだけでできることではなく、コミュニティ全体での取り組みが必要だ。
OSSのテストに関する状況は80年代の半導体産業と似ている。それまではテスト手法が未熟で、実現可能なチップの規模が制約されるようになっていた。そこにチップのテスト技術を提供する会社が現われ制約が取り払われた。
