先週、次の翻訳に少しコメントしました。

• http://recompile.net/2007/02/post_32.html

普段、他人の翻訳にわざわざ突っ込みはいれないのですが、微妙なミスを放置するのに忍びなくて思わずコメントしてしまいました。

事の発端は、次のMLへの投稿です。

• http://www.nabble.com/IMPORTANT%3A-Triage-on-P3-bugs-for-GlassFish-V2-9.1-p8980732.html

「(超意訳)リリース間際なのにP3バグ(*)がたくさんあります。リリースまでに修正すべきか否かのトリアージが必要なので、各自、バグにコメントしてください」

(*)たぶんバグ登録時のデフォルトプライオリティがP3なんだと思います。

これに対する返答が、上記の翻訳元の投稿です。

主張のポイントは、バグにコメントや余計な指標をつけずに、プライオリティという一元的な指標を使え、です。プライオリティは「あるターゲットリリースで修正するか否か」だけで決まる指標です。

つまり、

• P2: ベータリリースまでに要修正
• P3: 正式リリースまでに要修正

これが大方針で、残りのP1、P4、P5は、ここから相対的に決まります(例えばP1は「すぐ修正」. P4とP5は今回のリリースでの修正は必須ではない)。

この方針に従うと、P2バグの総数が、ベータリリースまでの期日を示します。P2とP3バグの総数が、正式リリースまでの期日を示します。指標を一元化することで、スケジュールを見える化している、と言えます(*)。

(*)プライオリティの変更は禁止していないので、リリース日直前に突然、P3をP4にすることは可能ですが...。これは単に信頼関係の問題です。

MLでは、次のようなもっともな疑問が上がっています。

• 「適切なプライオリティを付けるのはコストがかかるのではないか? 誰がそのコストを払うのか?」

バグの担当者がその責務を負う、がその答えです。バグ報告者はプライオリティをつけますが、最終的な判断はバグの担当者です(判断がつかない場合、適切な人に投げる責務を含めて)。

Lotus時代、ひとりで1000件近いバグを抱えている開発者がいました。1000を越えていたのは、ごく少数のトッププログラマだけで、多くの開発者は100以下だったと思います。ひとりが抱えるバグの数は100以下にしておくのが精神衛生上良いように思います。