FOSSプロジェクトに時間ベースのリリースを勧めるMichlmayr氏

 前Debianプロジェクトリーダー(DPL)のMartin Michlmayr氏による、ケンブリッジ大学テクノロジ・マネージメント・センターでの博士論文が完成間近だ。論文の表題は「Quality Improvement in Volunteer, Free, and Open Source Project: Exploring the Impact of Release Management(ボランティア/フリー/オープンソースプロジェクトにおける品質向上:リリース管理が与える影響についての調査)」で、Debian、GNOME、Linuxカーネル、OpenOffice.org、Plone、X.orgといった 大規模なFOSS(フリー/オープンソース)プロジェクトの事例研究が基となっている。

 Michlmayr氏は学術研究の成果を可能な限り広くアクセス可能にすることを目的とする「オープンアクセス運動」の支持者でもあることから、自身の研究成果についてもできるだけ頻繁にブログで取り上げ議論を行なっており、また博士論文の最終版をインターネット上に公開することも計画しているという。そしてそのような研究成果を広く一般に知らしめるための取り組みの一つとして、Linux.comの取材にも応じ、大規模なFOSSプロジェクトには時間ベースのリリースが望ましいと考える理由について語ってくれた。

 Michlmayr氏によると、FOSSプロジェクトにはソフトウェア開発プロジェクトの中でも特に独特である二つの特徴があるという。一つめはFOSSプロジェクトのメンバーの所在が地理的に分散しているため、コミュニケーションに遅延が発生するということ、そして二つめはメンバーの多くがボランティアであるため、非常にやる気があっても、ここぞという時に必ず手が空いているわけではないということだ。この二つの特徴には利点もいくらかあり、例えばメンバーが地理的に分散しているということは、コミュニケーションがすべて記録されることにつながるということだ。また、この二つの特徴があったとしても、やる気のない雇われたメンバーが一ヶ所に集まっていた場合の作業よりも好ましいことは確かだ。とは言えMichlmayr氏によると「総合して考えると、そのような二つの特徴によって作業の連携やリリース管理がかなり難しくなることもある」とのことだ。

 特に問題となるのは、このような二つの特徴によって計画性のなさという結果につながることが多いことだという。Michlmayr氏によると「大規模で多数の部門から構成されているようなプロジェクトのかなり多くが “リリースの準備ができたらリリースする”という方針を良いものと考え、固執しているけれども、大規模プロジェクトではリリース前にやっておきたいと思う作業が常に存在するものなので、この方針では悲惨なことになる。延び延びになったり、時代遅れのソフトウェアになったり、メンバーのイライラの原因にもなりかねない。また、ソフトウェアの実際のリリースがいつになるのか誰にも分からないのだから、ユーザやベンダが計画を立てることができないという問題もある」とのことだ。現在オンラインで公開されているMichlmayr氏の博士論文のドラフト版では、このような問題を抱える代表的な例としてDebianプロジェクトが挙げられている。

 このような問題を解決せずにおくと「信用が失われ、開発協力者が減る」ことになる可能性があるとMichlmayr氏は指摘する。「ボランティアの人たちは、せっかく自分が開発協力した内容が実際のユーザの手に届くまでに何年もかかるようなプロジェクトに開発協力しようと思うだろうか。このように信用を失うということが特に問題なのは、それが悪循環に陥ることになるからだ。つまりリリースが遅れることが度重なると、プロジェクトが期限通りに実際にリリースするということに関して誰も信用しなくなり、(期限通りにリリースするために必要な開発協力を得ることが難しくなるので)必然的に、さらに遅れる結果になってしまう」。

 Michlmayr氏によると、このような状況を解決するためのソリューションが、時間ベースのリリースなのだという。Michlmayr氏はそのような時間ベースのリリースへの移行には「かなりの作業」が必要となることを認めつつも、時間ベースのリリースへの移行が不可能ではない証拠としてGNOMEプロジェクトを挙げた。そして実際のところMichlmayr氏は、リリースということに関してプロジェクトが問題を抱えているように思え始めた場合には、時間ベースのリリースへの移行が不可欠であると考えている。

 Michlmayr氏は、「リリースということに関する問題の多くは、プロジェクトが小規模であったときにはうまく行っていたプロセスが大規模なプロジェクトには実は向いていないということに起因する。小規模なプロジェクトでは“リリースの準備ができたらリリースする”のままであることも可能だけれども、大規模なプロジェクトでもそのように組織化されていない方法を行なっていると、深刻な問題が起こってしまうことになる」と説明する。

時間ベースのリリースのメリット

 Michlmayr氏によると、プロジェクトが時間ベースのリリースへ移行することには、プロジェクトに関わるすべての人にとって利点があるという。例えばプロジェクトによって開発されたソフトウェアを利用する大規模な組織にとっては、時間ベースのリリースとなることによって、そのプロジェクトのソフトウェアの新版がいつ出てくるのかが分かるようになるので、本業の計画やインフラストラクチャの計画が立てやすくなる。同様に、(そのプロジェクトのソフトウェアを配布する)商用ディストリビュータもマーケティングの計画を立てやすくなり、また個人ユーザもプロジェクトをより信頼することができるようになる。

 とは言え時間ベースのリリースの恩恵をもっとも受けるのは、他でもないプロジェクトの開発コミュニティ自身だという。Michlmayr氏は、時間ベースのリリースを行なうことにより次第にコミュニティ内での規律が保たれるようになり、コミュニティのメンバー同士が自分たちの取り組みをより効率的に協調させ合うことが可能になると考えている。また時間ベースのリリースにより、短期的にも長期的にもよりうまく計画を立てることができるようにもなるという。さらにユーザのフィードバックについても、そのようなリリースサイクルの一部としてよりタイムリーなものになるため、より少ない労力で計画の中に取り込むことが可能になるという。

 Michlmayr氏によると、そのようなメリットがある一方で、時間ベースのリリースには「明らかなデメリットはこれまでのところ見つかっていない」とのことだ。ただし「大掛かりな変更をしたい場合にも、時間ベースのリリースのままで実現可能なのかどうか」ということについては何とも言えないという。そしてこの問題についてはGNOME 3.0の開発方法についての話し合いの際、GNOMEプロジェクトで議論されていたと補足した。Michlmayr氏は「この問題については十分な答えを用意することはまだできないが」とした上で、大きな変更と時間ベースのリリースとを両立させるために「時間ベースのリリースをしながら、大きな変更もしたい場合には、開発コードを分岐させ、分岐させたコードを複数のリリース期間に渡って(メインのコードと並行して)開発するというのも一つの手」だと提案した。

時間ベースのリリースに移行するタイミング

 Michlmayr氏によると、時間ベースのリリースに移行するためにまず最初にすべきことというのは、依存症の治療と同様、現在の戦略がうまく行っていないことを認識することだという。そしてプロジェクトが時間ベースのリリースに移行すべきかどうかを判定するための4つの基準を挙げている。

  • リリースするときはいつも重大な修正や新機能が追加されている――逆にプロジェクトが小規模で一つ一つのリリースが小規模(わずかな付け足し)である場合には、時間ベースのリリースはおそらく不必要なルールとなるだろう。
  • ソフトウェアの配布が安価である――言い換えると、商用の箱入りパッケージソフトウェアについて時間ベースのリリースを行なうことは現実的ではないが、インターネット上でダウンロードされるフリーソフトウェアについては現実的だということだ。
  • 次期リリースにおいて特定の新機能や大掛かりな変更をする必要が必ずあるというわけではない――つまり、特定の顧客のための開発である場合や、ユーザに対しアップグレードの価値を納得させるための新機能が必要となる商用製品の場合には、時間ベースのリリースというのは適切ではないということになる。
  • コードがモジュール型で、各コンポーネントの開発やリリースを各々独立して行なうことができる――この条件を満たしていると、柔軟性があり締切に間に合わせやすい。

 プロジェクトは、時間ベースのリリースへの移行を決断したら、次に適切なリリース間隔を決め、詳細なスケジュール/方針/インフラストラクチャを検討する必要がある。

 Michlmayr氏は、このような移行において特に重要なことは、有能なリリースマネージャを任命することだと考えている。Michlmayr氏による「有能なマネージャ」の定義は、マネージメント能力に加え、コミュニティを構築し、プロジェクトの目指す方向についてしっかりとしたビジョンを作成し、目標を見失わずに必要なときには要求を断ることができる能力も兼ね備えた人物とのことだ。

 またMichlmayr氏は、リリースマネージャについて「プロジェクト全体に直接的に関与し実際に口を出すようでないといけない。リリース期日やスケジュールを発表するだけで十分で、そうすれば後はプロジェクトの参加者が勝手に作業を進めてくれるだろうと考えているプロジェクトもあるけれども、現実には、スケジュールや締切が迫っていることについて、繰り返しメンバーに周知徹底させるという作業が大切だ」という点を強調した。

知見の応用

 最後に、博士論文のための調査研究で得られた知見を実際的な現実問題の役に立つように応用するという点に関して聞いてみた。この点に関してMichlmayr氏は、FOSSプロジェクトにおけるリリース管理について、もっとも良い方法がどのようなものであるかを具体的に提案することは避けた。Michlmayr氏によると「それを提案するには、それだけでまるまる別の博士論文(3本ほどね)が必要になってしまう」とのことだ。

 しかし一方でMichlmayr氏は、この研究の応用という点に関しては、この研究が潜在的にFOSSプロジェクトだけでなく、どのようなボランティアによる取り組みにも役立つ可能性があるということを指摘した。

 「インターネットのおかげで、将来的により多くの協働的なボランティアプロジェクトが生まれるだろう。フリーソフトウェアに関して今僕らが得た知見は、そのようなプロジェクトに役立てることもできるはずだ。フリーソフトウェアプロジェクトにおけるリリース管理についての僕のこの研究は、ボランティアのように参加協力者に対する強制力のようなものがない場合に、成果をリリースしていくためにプロジェクトはどのようにしたら良いのかという問題に対する一つのアプローチと考えることができるのではないだろうか」。

Bruce Byfieldは、NewsForge、Linux.com、IT Manager’s Journalへ定期的に寄稿するコンピュータジャーナリスト。

NewsForge.com 原文