少し前ですが、以下を読みました。

• http://www.hyuki.com/yukiwiki/wiki.cgi?QualityImprovementInFreeSoftware (翻訳)
• http://www.cyrius.com/publications/michlmayr-phd.html (論文)

Linux(*)のBTSは次のbugzillaです。

• http://bugzilla.kernel.org/

今、オープンバグを探すと、たった1546件しかありません。ソフトウェア開発を知らない人は1546件を多いと思うかもしれません。実際には、驚異的に少ない数だと思います。

(*)言うまでも無いですが、GNUをつけないLinuxはカーネルのことです。

論文は、リリースの周期を決めて、そのリリース周期を守れ、と主張します。無計画にリリースがだらだらと延びることを批判しています。長すぎるリリース間隔には悪い点が多いので、短い方が望ましいようです。ただし、リリース間隔を過度に短くすることは主張していません。実際、「7.1.4. Cost Factors Related to Releasing」で、リリースに関わるコストを考察しています。OpenOfficeでは2ヵ月ごとのリリースをやめて、3ヵ月ごとにリリースに延ばしたようです。

リリース間隔を短くするには、ソフトウェアを常にある程度安定した状態に保つ必要があります。「8.2.1 Stability of the Development Tree」に次の4つのプロセスが挙がっています。

• Branches
• Peer review
• Testing
• Reverting and postponing

注目したいのがBranchesとReverting and postponingです(Peer reviewとTestingは自明なので省略します)。

branchingは、安定化に時間のかかる開発作業はメイン開発ツリーと別のところで作業を行い、安定してからメインツリーに入れるプロセスです。Reverting and postponingのrevertingは、メインツリーに一度入った機能でも、リリース品質に達しない機能はメインツリーから外すプロセスです。postponingはリリース品質に達しない機能は、(例えリリース予定機能であったとしても)リリースに含めないプロセスです。

branchingとrevertingは、言うほど易しくありません。ソフトウェアが適切にモジュール化できていなければ達成できません。このふたつが可能になれば、大規模ソフトウェア開発としてスケールできます。

個人的な開発体制の理想は、ゴールだけ共有して、後は各人が自分のペースでゴールに向けて走りだすことです。ペース配分はひとりで勝手に決めてもいいですし、数人でまとまっても良いです。リリース間隔の整数倍の周期で作業する人がいても良いと思っています。つまり、リリース周期が1ヵ月の場合、2ヵ月や3ヵ月の周期で作業する人がいても構いません。

現実は理想どおりに行きません。なぜかリリース前になると、全員を動員しなければいけない作業が残って、全員の足並みを揃える羽目になります。締切を決めて作業見積りをさせると、なぜか全員にタスクが割り振られる、という結果になります。人数が変化しても、全員必要、という結果に変化はありません。感覚的には、目に見えないgiant lockがあって、全員の作業が同期してしまうイメージです。スケールするために、この目に見えないgiant lockを取り除きたいのです。

以前からこの現象に気づいて、どうにかしたいと思っていました。先行して作業を進めておけば防げるだろうと考えましたが、考えが甘かったことに気づきました。結局、心理的な問題です。どれだけ前倒ししても、使えるリソース(人と時間)は使い切ってしまうのです。

今考えている手は、強制的に別の周期で動く部隊を作ることです。はじめから使えないリソースとして周知させておけば、巻き込まれないで済みます。