[開発プロセス] バグのトリアージ

Compact Oxford English Dictionary より。

triage
/triij/
noun
1 the action of sorting according to quality.
2 Medicine the assignment of degrees of urgency to wounds or illnesses to decide the order of treatment of a large number of patients.

― ORIGIN French, from trier ‘separate out’.

「トリアージ」 というと、 日本では、 救急医療での治療優先度付け作業を表す言葉として知られています。
本来の意味は、 上に引用した 1 のように、 なんらかの基準 ( = 品質 ) に基づいて順序付けをする作業のことです。
# 語源は  「分離する」 という意味のフランス語 trier だということですが、 それを知らずに、 トリアージとは救急医療の用語が本来であると信じ込んで、 「バグのトリアージ」 という言い方はヘンだ、 と噛み付く人も世の中にはいますw

ソフトウェア開発の、 テスト～デバッグのフェーズでは、 検出された不具合を選別し優先順位付けをする作業を言います。
「優先度設定」 とか呼べばいいじゃん、 って言われそうですが、 それだと、 上がってきたバグ票は全部デバッグするのだ、 というイメージになっちゃいます。 優先順位を付ける前に、 選別することが必要なんです。 ( 英語でも同様な事情で適切な単語が無くて、 フランス語を使ったんだと想像してます。 )

もしトリアージを行わずに、 テスターから上がってきたバグ票を、 開発者に直接渡してデバッグ作業に入ってもらうと、 どうなるか…?

• とりあえず簡単そうなバグからデバッグに取り掛かってしまう。
  → 納期が来たときに、 重要なバグが残ってしまうかもしれない。
• 仕様書の誤りや、 テスターの勘違いで、 実はバグじゃなかったかもしれない。
  → デバッグしたはずが、 逆にバグを増やすことになってしまう。
• バグ票の指示が曖昧で、 かつ、 仕様書も曖昧なことがあるかもしれない。
  → 同種の複数のバグ修正を複数の開発者に配分したとき、 異なる修正をしてしまうかもしれない。

…ということが起きる可能性があります。 というか、 火事場プロジェクトでは確実に起きているでしょう。
そしていずれもが、 納期遅れや追加作業の発生に結びついてしまうでしょう。

そこで、 上がってきたバグ票に対して、 バグのトリアージを行います。

1. その不具合は、 バグなのか? ( 仕様書のバグかもしれないし、 じつは仕様通りなのかもしれない。 )
2. そのバグは直すべきか? 直さないと、 どうなるか?
3. 直すべきだとしたら、 その影響範囲 ( スコープ ) はどのくらいか? 1機能の一部か? 複数機能の大部分か?

バグ票のひとつひとつについて、 このように検討した上で、 直すべきバグを選択し、 修正作業を行う優先順位を決めます。 また、 その過程で、 バグ票に書かれた再現手順や修正指示が適切かどうかも判断します。
これがバグのトリアージ作業です。
# 優先順位の決め方は、 ぶっちゃけ納品時に 「ごめんなさい」 して許してもらえそうなものから優先順位を落としていく、 って感じです f(^^;

限られた時間とメンバーで修正作業をやらねばならないのですから、 バグのトリアージは必須の作業です。
また、 仕様をきっちり把握しているメンバーでなければ、 トリアージはできません。

※ ちなみに、 MSF ver.4.x では、 プロジェクトマネージャ ( PL ) の仕事だとされています。 実際には、 PL の責任の下で、 仕様設計者が主に作業することになるでしょう。

※ 書いてから気付いたけど、 バグ票に書かれた再現手順が適切かどうかチェックするのは、 本来はテストチームの中でやるべき作業ですね。

# 結合テスト～デバッグ を上手く回すためのカナメの作業だと思うんですが…
# プログラミングの専門教育を受けてきた若い人たちにも、 P2M の教育を受けたはずの中堅どころにも、 トリアージの話をすると 「初めて聞いた!」 みたいな反応をされてしまうのは、 なぜ? (;;