システム開発の分野で有名なトリアージと言えば，エドワード・ヨードンの『デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか』ですが，そのいわば前段として，以下の本を取り上げたいと思います．
- 作者: 渡辺幸三
- 出版社/メーカー: 日本実業出版社
- 発売日: 2003/10/17
- メディア: 単行本
- 購入: 15人 クリック: 186回
- この商品を含むブログ (49件) を見る
さて本題．トリアージが，どこで使われているかを見ていきます．引用の前に書かれていることをかいつまんで記しておきますと，要件を，多数の親子関係からなる「要件ツリー」*1で記述しています．その親の位置に書かれる要件はルート要件，子の位置にはエンドユーザー要件という名称がついています．
それぞれのエンドユーザー要件には以下のような3段階の優先順位を，偏り過ぎない比率で設定することをおすすめします．
A = 最優先で実現されなければならない(赤)
B = Aが実現されたうえで実現されなければならない(黄)
C = Bが実現されたうえで実現されなければならない(緑)
ここだけ読むと，先日書いたカジュアル条件をすべて満たしています．
このように課題を優先づけながらこなしてゆく方法は「トリアージ(triage)」と呼ばれています．もともと，戦争で多くの負傷者が出た状況で(略)ただし，どのような治療を施しても助かる見込みがないと判断された負傷者には「黒色のタグ」が与えられて何も処置されません．冷酷なようですが，処置すれば助かるような負傷者がより多く手当てされることになるので，非常時においては合理的な基準です．
(p.37)
黒タッグが登場しまして…．
システム要件にもこのような順位を与えてください．そうすると，基本設計以降でスケジュールや費用が十分でないことがわかったときに，どの要件をあきらめたらよいかを判断しやすくなるからです．ときには，実現可能性があまりに低いような要件に対して「黒色のタグ」を与えることも必要でしょう．このような配慮をせずに，いざというときに「技術的にやりやすいことを優先させる」とか「どんなに困難であってもこれについては意地でもやる」という方針をとったばかりに，コストがかかったわりに中途半端なシステムになるケースが少なくないからです．
(pp.37-38)
ここで「黒タッグに相当する分類」が出てきました．好意的に解釈するなら，ABCの3分類に黒を追加しなかったのは，黒判定をすること，また記録に残すことのインパクトに配慮したからなのでしょう．
なお，要件ツリーは「憲法」のようなもので，すべての局面で何度も参照されますが，この憲法は基本設計の過程で改正されることが少なくありません．たとえば(略)具体的，または包括的な要件に置き換わったり，(略)要件が追加されたりします．その際には全体の優先順位も見直されます．
(p.38)
「トリアージは頻繁に実施されるべき」に対応するアドバイスになっています．ただ，災害医療のトリアージでは，現場トリアージ，搬送トリアージ，病院トリアージに分かれますが，要件定義のトリアージにはそういう段階分けがなく，そのため，トリアージオフィサーの裁量がうんと大きくなることが予想されます．
トリアージに関係する説明はここまでとなっており，残りのカジュアル条件については，依然として該当していると言わざるを得ません．実際の分類事例が書かれていれば，そこから，要件定義にトリアージを適用することの妥当性や有用性を知る手がかりになりそうなのですが．
それから，要件ツリーの親子関係において，子の要件（エンドユーザー要件）に対してのみ赤黄緑（と黒）の分類を行い，親の要件（ルート要件）に対する言及がないのも，気になります．しかしここに引っかかるのは，ルート要件が傷病者に，エンドユーザー要件が症状に，それぞれ対応付けられるように見えるからかもしれません．
*1:「ツリー」と称するものの，1個のtreeではなく，treeが複数個からなるforestで構成されます．
