同じもの？いいえ（たぶん）違います。
私はときどき
優先度つきのスケジューリングは間違っている
とホラを吹きます。それにはそれなりの根拠というか、裏があるのです。
たとえば手元にある2001年に発行された「デスマーチ」という本の「プロセス」の章ではトリアージについて詳しく説明されています。
で、私が読んだ際の★印がPDF化されたいまでもドッグイヤーとともに残っていましたので引用します。
・・・
第5.1節の”triage”の観点から,1つの大きな問題がある｡それは,我々が要求項目を管理する組織化された方法を持っていない,ということである｡ある瞬間に,我々はどうやうて,どの要求項目が｢やらねばならぬ｣･区分に入り,どの要求項目が｢やったほうがいい｣区分に入り,そして,どの要求項目が｢やれればやる｣区分に入っているかを知ることができるのだろうか｡
・・・
多くの開発現場では、はるか雲上の”ビジネス側”から発せられたトリアージの区分～それは時に「優先順位」と翻訳されるでしょう～が現場に下りてくるまでに曲解され、さらにしばしば
タスクの優先順位
にすりかえられるのです。これは悲劇であり喜劇です。もしかしたらあなたは、
上流工程でトリアージに基づいた優先順位付けをおこなったのだから、
それに紐付いた作業単位＝タスクの
優先順位としてトリアージ結果の順位付けを利用して何が悪いのか？
と反論するかもしれません。そうしたらごみためまんは以下のように反論し返すのです。これはもはや水掛け論です。
なるほど。
ではあなた方がせっせと保守しているその
ガントチャートやPERT図は何ですか？
不毛な詭弁合戦はほうっておいて、「デスマーチ」から引用その２です。
・・・
これは,要求項目間の関連を明らかにし,大量の関連を管理するための手法,､プロセス,およびツールが必要なことを意味する｡そして,この領域には,助けになるはずの構造化分析やオブジェクド指向分析のようなよく知られた技法があるが,不幸にして,これらの技法が伝統的に要求項目の,優先順位,コスト,リスク,日程,要求著,およびそれが割り当てられた開発者,といった属性が無視されてきた｡その結果,要求項目を管理する必要性を感じていたプロジェクトチームは,ある程度の自動化を支援するために,スプレツドシート,ワープロ,または間に合わせの4GLデータベースに基づいた自家製のツールを使ってきた｡幸いなことに,より包括的で洗練された支援を行う新種のソフトウエア･ツールが現れつつある｡現在市販されているいくつかのツールには:Requisite(Requisite社),DOORS(Zycad社),およびRTM (MarconiSystems社)がある｡この章はツールでなくプロセスについて述べるつもりなので,これら3つの製品の詳細に踏み込む)つもりはないが,ツールはプロセスに影響を与えるので,こうしたものの存在を知ることは重要である[6]。
・・・
この中でたとえばDOORSは、現在IBM Rational製品になっているようです。
IBM – Rational DOORS – Software
IBM – Rational DOORS Requirements management for complex systems and software development
Rational DOORS – Features and benefits
IBM® Rational® DOORS® contains proven capabilities that can help increase quality and efficiency by optimizing requirements communication and collaboration. Rational DOORS, a scalable solution for managing project scope and cost, helps your projects meet business goals, satisfy customer needs, and address applicable regulations and standards.
トリアージの精度がすこぶるわるければどんなマネジメントも糞の役にも立ちません。
そこそこ精度が高いとして、そこで決定されたタスク遂行においてトリアージの優先順位が関係あるでしょうか。ごみためまんならこうします。
やらねばならぬタスクは、スキルと経験値の高いチームにアサインする
やったほうがいいタスクは、中堅のチームにアサインする
やれればやるタスクは、新規参加のチームにアサインする
これだけです。
これで期待通りの結果が出なければ、おそらくプロジェクトに参加しているチームの能力の総合計が不足しているか怠慢がはびこっているかのどちらかです。
トリアージで分類された小さな単位のタスクについてさえ高確度で達成できるチームをもし持っていないとしたら、そのプロジェクトは不幸なデスマーチではなくて、
できもしない仕事を請け負った
ただの詐欺
ということにほかならないと思うからです。チームを機能ごとの縦割りでアサインしたりするのは愚の骨頂すぎて間抜けのやることだというのは、ごみためまんが書くまでもありませんね。
# 画像処理アプリならこの害虫、とか笑止
特定のソースツリーを特定のメンバーのみに触らせるようなことが続けば、そこは談合の温床になるのは明白です。
ときどきチームを入れ替えるのが必要なことは、銀行員の長期休暇中の監査の例を挙げるまでもないことでしょう。
リンク：
優先度によるスケジューリングは間違い ごみため(ー日ー膳！)
ごみためまんのは第１版のようです。
