Lotus Notes を開発した Iris Associates (その７)

Iris Associates は、Notes / Domino という単独製品の開発を行っていたので、各バージョンのリリース前は会社中大騒ぎの状態になっているのではないかと想像する人もいるかもしれないが、全くそんなことはない。リリースの日程には、マイルストーンと呼ばれるチェックポイントが明確に示される。

主なマイルストーンには、Feature Freeze とよばれる「機能追加はここで終了」という日付、Code Freeze とよばれる「ソースコードの変更はここで終了」という日付、Release Candidate と呼ばれる「何事もなかったら、その日に作られた物が出荷される」という日付などがある。ただ、これは一般的なガイドラインで、「機能追加はここで終了」と言われても、その機能が重要な機能であったり、その機能がないと別の機能が動かない機能の追加は、その後も行われる。その際は、間に合わなかった機能ごとに評価が行われ、承認されれば、期限を超えての開発が承認されることになる。

ソフトウェア製品にとってバグはつきものであるが、そのバグをいかに効率よく修正していくかが、プロジェクトリーダーの腕の見せ所となる。プロジェクトリーダーはすべてのバグについて、修正するか修正しないかを判断していく。これが Triage (トリアージ)プロセスである。ソフトウェアに付属して提供されるリリースノートと呼ばれるドキュメントには「既知のバグ」という項目があるが、これは直前に見つかって間に合わなかったのでそのまま出したバグを記述しているのではなく、Triage プロセスでプロジェクトリーダーが明示的にバグを修正しない判断をしたものである。これはバグの影響度やその機能の使用頻度などを総合して判断される。Triage プロセスにおいては、プロジェクトリーダーが、担当チームのリーダーと個々にミーティングをもって、ひとつひとつのバグについてそのバグの修正を継続するか、バグ付きでリリースするかを決めていく。修正すると判断したバグは期限付きでエンジニアが修正作業を行うが、期限までに修正されないと、その時点の状況によってさらに修正を続けるか、あきらめるかを決めていく。当然のことながら、リリース日が近づいてくると、どんどん判断が厳しくなっていく。もし、重大なバグの修正が間に合わないときは、その機能ごとリリースからはずすか、リリース日を延ばすかの判断をすることになる。

Triage Meeting は、以前はリーダーと担当エンジニアを呼んで行っていたが、担当エンジニアからの情報が必要になるかどうかはわからない。そこで、途中から Triage Meeting にはプロジェクトリーダーのみが参加して、担当エンジニアは必要になったときだけ、Lotus SameTime のチャットで情報をもらうという方法に変わった。これによってエンジニアは製品の品質の向上の作業により多くの時間を使うことができるようになった。

リリース直前に慌てているのは、絶対に修正しなければいけないバグのある機能の担当のグループと、全体の品質の責任を持つ Quality Assurance のグループ、そして最後のリリース版のキットを作成するグループだけで、それ以外のグループはリリースされたというアナウンスを待っているだけとなる。リリースがアナウンスされると、パーティーモードに突入することとなる。