リリースは政治パフォーマンス
これは、面白いエントリで重要な指摘だと思うけど、プログラマ以外にはわかりにくい部分もあると思うので、リポジトリという概念を含めて解説してみたい。
集団作業におけるバージョン管理システムの意味
キーワードは「リポジトリ」と「CVS」。どちらも、プログラムのソースコードを管理する為の専用データベースに関わる専門用語である。そのようなツールを指す一般名詞が「バージョン管理システム」で代表的な実装として「CVS」と「subversion(SVN)」がある。リポジトリとは、そのデータベースのことで、これは、Wikipediaの履歴ページを見ていただくのが一番いい。
このページはWikipediaのメインページの履歴ページで、Wikipediaの全てのページには、このような履歴ページが付属している。というか、Wikipediaはこのような状態で保存されていると理解してもいいと思う。つまり、最新版だけでなく、誰がいつどのような理由でどの部分を修正したかが記録されている。古い版を参照することもできるし、古い版と最新版のどこが違うのかを見ることもできる。
ほとんどのオープンソースソフトウエアは、「バージョン管理システム」で管理され、このような状態で保存されている。
つまり、修正を加えても、任意の時点に巻き戻すことができるのだ。Wikipediaの場合は、特定のURLから古い版を参照することになるが、プログラムの場合は、コマンド一発で任意の時点のプログラム(ソースコード)の状態を手元のマシンに復元することができるのだ。
集団作業をする上で、「巻き戻せる」ということは、非常に重要だ。
誰もが、他人の作業を全て把握しているわけではないので、自分の行なった修正に問題がないか、特に他の人との作業との関連で問題が起きてないかに確信を持つことはできない。もし「巻き戻し」が不可能だと、修正を行なうことの責任が非常に重くなる。全ての作業者が、「自分のやったことには100%間違いがない」と確信できないと、作業を進めることができないことになる。それは、顔を突き合わせて緊密に連絡しているチームでないと不可能なことだ。
しかし、この「巻き戻し」があることで、その制限はかなりゆるくなる。100%でなく95%とか80%とか、ある程度の自信があれば、とりあえず修正してしまっていいのだ。差分を見ることで、他人は容易にその作業内容をチェックできるし、何か問題があれば、本人でもその他の人でも簡単にそれを元の状態に戻すことができる。「まずやってみて、問題が起きたらその時に調整すればよい」という発想で作業できるから、多くの人が気楽に参加できて、事前の調整をしないで共同作業を行なうことができるのだ。
だから、ソフトウエア開発としてのオープンソースプロジェクトにとっても、Wikipediaのような「オープンソース的精神」で運営されるプロジェクトにとっても、「リポジトリ」というデータベースの形式はかなり重要な要素であると思う。
ソフトウエア開発プロセスは「整合性」に対する必要性が高い
そして、Wikipediaのような文書を作成するプロジェクトであれば、その成果を取り出すには、とりあえず最新版があればいい。多少の不整合や間違いやチェック漏れがあっても、最新版には最も多くの情報が盛り込まれているので、それを提供しておけば大半のニーズは満たせる。
しかし、コンピュータプログラムの場合はそうはいかない。Wikipediaのページに相当する構成要素がたくさんあって、個別にメンテナンスされていることは同じだが、要素同士の連携について、はるかに厳密さが求められる。
たとえば、モーニング娘。からダブルユーが結成されたとすると、モーニング娘。のページの現役メンバーの名前から辻希美と加護亜依が削られるのと同時に、ダブルユーのページが作成されないと困る。両方に同時に二人の名前があるといった不整合は、人間は気にしないが、コンピュータはそういう所に厳格だ。
もちろん個々のページに間違いがあってもいけないが、このような不整合がないか、全てのページについて厳密にチェックしないと、完結した百科事典にはならない。「モーニング娘。に二人の名前が残っていてダブルユーのページがない百科事典」か「モーニング娘。から二人の名前が削られていてダブルユーのページが作成されている百科事典」でないと、全く使えないわけだ。ソフトウエア開発とは、こういう所で偏執狂的に厳格なユーザを対象にした百科事典を作ることと思えばいいと思う。
このような問題点を全部調整し終えた版を作成することを「リリース」と言い、そこまでの作業をシステマティックに行なうことを「リリースエンジニアリング」と言う。ソフトウエアの場合は、リポジトリと最新版を提供するだけでなく、定期的に「リリース」が作成され、大半の利用者は最新版でなく整合性が確認された「リリース」を使用することになる。
この例だと、モーニング娘。の担当者は、ダブルユーの担当者に対して、「次のリリースにダブルユーのページが間に合うかどうか」の確認をする必要がある。二人の名前が削るだけの作業は簡単だから(あるいはその二人は早く削りたいとか個人的な理由があったから（笑）)と言って先にやってしまうと、ダブルユーのページが間に合わなくて、不整合が発生してしまう。
一般的には、リリースの直前には、新しい機能の追加を止める時期があって、このようなケースでは、ダブルユーの新規ページの追加は差し止められる。なぜなら、ダブルユーのページ中に間違いが発見されてそのページを削ることになると、問題がモーニング娘。本体のページに波及し、そこに辻と加護の名前を復活させないといけなくなる。このように間違いが残っている可能性が高い新規ページの追加は保留して、古いページで修正された部分の確認に集中する期間が起かれ、その時に集中的にチェックを行ないリリースを行なう。
ダブルユーのページの追加をいつ行なうかという判断を行なうのが「リリースエンジニアリング」だ。
このような要素間の関連は複雑で、それぞれ個別の要素も常に進化しているので、膨大なソフトウエアのリリースは気の遠くなるような大変な作業になる。ソフトウエアの場合は、整合性のチェックをコンピュータにまかせられる部分もあるので、むしろWikipediaより簡単な所もあるが、それでも、大規模なソフトウエアでは、多くの調整作業が発生する。
Rubyのリリースエンジニアリング
冒頭に紹介したエントリーで、mputさんは、Rubyのリリースエンジニアリングの問題点を指摘されている。
はっきりいって、Rubyというソフトウエアでは、これまでずっとリリースエンジニアリングがうまくいってない。Rubyが広まるにつれてその不満の声が高まっているのだが、一向に改善されていない。そして、今回のリリースでも致命的な問題が発生してしまったようだ。
その件についての、まつもとさんのコメントに激怒しているのが、問題のエントリーである。
言わせてもらえばリリースが遅れて何が困るって、社会的信用が目減りするのが困るんですよ。前も書きましたけど、リリースなんて進歩とか退行とか、そういう理由で行うものじゃないんですよ。「このプロジェクトはきちんとした運営が行われています」ということを内外に示す政治的パフォーマンスなんですよ。だからこそ様式美と有職故実に則ってつつがなく進行して予定どおりにリリースすることが何より大切なんですよ。なんでそれが理解できないかな。
これは、基本的にはmputさんの言うとおりだと思う。
ただ、この議論は、同時に二つのレベルで進行しているように思える。ベースとしては、Rubyという具体的なプロダクトの、ここ何回かのリリースの手際に関する具体的な問題提起なのだけど、同時に、「オープンソース開発のターゲットは、リリースなのかリポジトリ」なのかという、抽象的な議論が含まれている。
リポジトリ本質論VSリリース本質論
お金をもらっているわけでもない、誰が喜んでくれるわけでもないのにやってらんない。むしろ、アレだ。開発側は淡々と開発を行い、ディストリビュータが適当なタイミングでパッケージにするというので、どうだろうか。
ここで、まつもとさんは、次のようなことを言っているのではないかと私は思う。
これに対して、mputさんは、次のように反論している。
にもかかわらずなんでソフトウェアはリリースされ続けるのかというと、それは結局、技術革新だけではどうにも解決できない儀式的・政治的要件から行われているのである。たとえばリリースを行うことで仕様変更を周知する役目がある。たとえばリリースを行うことで、プロジェクトが継続していることを周知する役目がある。たとえばリリースを行うことで、上にMacの例を挙げたようにディストリビューションに対する一定の選択肢を与える役目がある。いずれも技術的には必ずしもリリースを必要としないだろう。けれど、リリースという儀式を経ているからこそ、はじめて俎上に乗る部分というものが少なからずある。そういう、おもに人対人のインターフェースとしての行為という意味合いが、現代のリリースにおいては非常に大きなウェイトを占めていると思う。だからこそ、儀式的な傾向はより先鋭化していると感じるし、儀式としてのリリースがつつがなく執り行われるという事自体の重要性が増していると思うのだ。
まつもとさんのリポジトリ本質論に対して、mputさんは「人対人のインターフェースとしての行為」として、リリースに新しい意味を与えた上で、新しいリリース本質論を展開している。
実は、単なる愚痴に見えるまつもとさんの発言は、Kevin Kelly氏の「Scan This Book!」で展開されている、書物の未来像に重なる所もある。
Kelly氏は、書物がスキャンされ「あちら側」に集積されていった時、個々の本が無数のハイパーリンクで接続され、音楽プレイヤーのプレイリストのように、ユーザの側がそれを自由に再編成し、仮想の自分専用本棚を通して本を読むようになるだろうと言っている。その章のタイトルは、"3. Books: The Liquid Version" つまり、「本の流動的なバージョン」である。
Indeed, some authors will begin to write books to be read as snippets or to be remixed as pages. The ability to purchase, read and manipulate individual pages or sections is surely what will drive reference books (cookbooks, how-to manuals, travel guides) in the future.
それどころ、書き手の方も、(一冊の完成したバージョンでなく)リミックスされる断片のつもりで(本ではなく個々のページを)書くようになるかもしれない。個々のページを購読し、読み、操作することができれば、マニュアル本やレシピ集のような本を自分で構成することも将来は可能になるかもしれない(かなり意訳)
ソフトウエアのリリースは、Kelly氏が展開する未来像の中での書物の再構成に似ている。それは受動的にソース(断片)を受け取るだけの行為ではなく、能動的な関与でもあり、ひとつの創造性を持つ行為である。だからこそ、それに対する責任を伴なうわけだが、それはリポジトリ上で展開される開発プロセスとは別個のものではないか。
このような含みを持って改めてmputさんのエントリを読むと、その重要性がよくわかるかもしれない。
メディアが共有可能で流動的になった時に、情報は断片化して再構成可能な素材になっていくのが自然な方向である。リポジトリは時間軸方向にも、同じような自由度を提供する。しかし、「人対人のインターフェース」としてのリリースという行為はそれに関らず必要なものであると、mputさんは主張しているのである。だから、この主張は、(たぶん)ご本人も意図しないうちにKelly氏の論文へのツッコミにもなっていて、かなり射程の長いものであると、私は感じた。
