人力 "make test"

オープンソース的世界観id:kanryoさんに取りあげていただいて、そこのコメント欄で短いけど重要な議論が行なわれています。

私がここ数日、断片的に書いているように、オープンソースにはソフトウエア開発に限定されない、素晴しい思想と方法論の萌芽があります。まずは、曖昧でもいいから、そのことを外部にアピールして興味を引くことが重要だと思います。

でもある段階まで来たら、厳密にそのプロセスを分析して、ソフトウエア開発のみで通用する所とそうでない所を明確に分けて論じる必要があると思います。そして、ソフトウエアのみで通用する部分について、政治等の他の社会的活動にオープンソースのプロセスを適用していく上で、どのようにその不足分を補っていくかを考えなくてはなりません。

そういう問題意識で、私がキーポイントだと思うのは、テストスクリプトの存在です。オープンソースソフトウエアは、多くの場合、セルフテストと呼ばれる補助的プログラムとともに配布されています。だから、これを改良する人は、"make test"というコマンドを打つだけで、自分の改良した内容に対して最低限の検証が行えるようになっています。

開発者がパッチ(改善提案)を山ほど送られてもオーバーフローしないのは、その改善提案が機械的に処理可能になっていて、"make test" というコマンド一発で、どうしようもないものを排除できるからです。この慣行が、外部で改良する人とそれをまとめる人、両方にとって非常に重要な位置を占めています。

もちろん、"make test"自体も徐々にブラッシュアップされていくもので、特に開発途上では100%の信頼性はありません。しかし、どうしようもないパッチが多いのも事実で、あるレベル以下のものは見ないですむという省力化の効果は大きい。これは、富豪的、つまり知的リソースが潤沢にある環境では特に重要なことです。

ソフトウエア開発以外のプロセスにオープンソースの方法を適用していく上では、この部分にどういう代替策を用意するかが重要だと思います。

社会保険料も税金も値上げしません。年金給付水準は維持します」みたいなパッチを機械的に排除できる手段があれば、話は楽です。しかし、マニフェストを"make test"するのは、マシンには不可能です。ここは人力に頼らざるを得ません。ただ、ネットをうまく利用すれば、チェックする為の人力は充分確保できると思います。というか、2ちゃんねるはそういう機能を不完全ではあるが果たしつつあるのではないでしょうか。2ちゃんねるでの議論はレベルが高いとは言えないですが、誰にでも開かれているので、スレをまとめれば多方面からの最低限のチェックがあったことにはなります。

匿名で、建設的で統合的な無矛盾の政策をまとめるのは無理かもしれません。でも、匿名掲示板は人力 "make test" の機能のみを果たせばいいのです。むしろ、2ちゃんねるはパッチの一次受けつけとフィルタリングに特化して、そこから出てきた基本的な案を「はてなダイアリーのドリームチーム」が「包括的妥協案」としてまとめていく、というような、システムの機能的な棲み分けが必要なのではないかと思います。