デスマーチにおけるトリアージ

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

トリアージの勉強を，とこの本を取り寄せたのは，1か月以上前のことでした．ざっと読み，今朝も読み直したのですが，医療におけるトリアージのことを十分に検討しているものの，「カジュアルトリアージ」の度合いがけっこう高い，という結論になりました．
基本的な要件とカジュアル条件*1について，どのくらい適合するかを先に書いておきますと:

• 災害医療におけるトリアージの手法を他の分野に適用する: YES
• 緊急性（分類を極めて短時間に行う必要性）がなく，人的・物的資源に限定を置く必然性がない: NO
• 分類基準に客観性が見られない: YES（ある意味NO）
• 黒タッグに相当する分類がない: YES
• 実際の分類事例が見られない: YES

この章から，または，本全体からたったひと言だけ覚えるとすれば，それは「トリアージ(triage)」である．(略)最も重要なことは，デスマーチ・プロジェクトではユーザーが求めているものをすべて実現するだけの時間がない，ことである．(略)
プロセスに関連するアイデアや戦略のすべてを無視せよ，と言っているのではない．詳細については本章の後のほうで述べるが，私が言いたいのは，やらなければ失敗は避けられないという絶望的な状況での戦術としてプロセスをデスマーチ・プロジェクト・チームに押し付けるのではなく，企業の戦略的な決定の一部として導入すべきだ，ということである．トリアージの概念は，ここでも当てはまる．(略)
(pp.127-128)

この章（第5章 デスマーチ・プロセス）の最初の説明です．緊急性については，了解です．

"triage" という言葉の語源は「グループ分けすること」を意味する古いフランス語の "trier" からきている．American Heritage Dictionary（第3版）では，次のように定義している．

triage 【(発音記号は省略)】 名詞

1. 負傷した人々を，緊急の医療処置の必要性や効果に基づいて，グループ分けするプロセスを言う．トリアージは，戦場，災害地，病院の緊急処置室で，割り当てねばならない医療資源に限りがあるときに用いられる．
2. 数量の乏しい必需品（食料など）を最大の効果がえられる人だけに割り当てるためのシステムを言う．

多くの人は，トリアージの医療上の意味はよく知っているだろうが，デスマーチ・プロジェクトに関係するのは，辞書の2番目の定義，つまり，最も乏しい必需品（最も乏しいのは，時間）を，最大の効果を引き出すやり方で割り当てることである．
(pp.128-129)

定義の確認，ですね．「多くの人は，トリアージの医療上の意味はよく知っている」には不同意ですが，トリアージに2種類の意味があって，医療における用法ではないことを指摘し読者に（それ以降を読むにあたって）同意を得ておくという点では，問題はないかと思います．

(略)私が関係したほとんどのデスマーチ・プロジェクトでは，システムの要求項目を，トリアージ・スタイルで，「やらねばならぬ(must-do)」「やったほうがいい(should-do)」「やれればやる(could-do)」の三つに分けるのが常識となっていた．(略)トリアージによるプロジェクト戦略は明確で，「やらねばならぬ」要求項目に最初に力を集中し，「やったほうがいい」要求項目に力をそそぎ，奇蹟が起これば，「やれればやる」要求項目に手をつけるのである．
(p.130)

「やらねばならぬ(must-do)」が赤に相当し，「やったほうがいい(should-do)」が黄，「やれればやる(could-do)」が緑っぽい．
ただ，医療におけるトリアージでは，緑もいつかは治療を受ける必要があるのですけどね．
黒は見当たりません．自分なりに何を黒と判定するか，考えてみたものの，いい表現（というか例）がなかったので，これはシステム開発におけるトリアージ利用の注意点としておきましょう．

プロジェクトの開始時点で，トリアージ戦略を採用できなければ，プロジェクトの完了に向かって醜い危機が発生し，そこに不快な政治問題が加わり，私の同僚，ディーン・レッフィングウェルが「無駄な在庫」と呼ぶ現象が起こる．これを理解するために，典型的なデスマーチの初期で何が起こるかを考えてみよう．(略)
(p.130)

略のところには，「初期」だけでなくデスマーチ全体のプロセスが書かれています．
さて，ここで重要なのは「デスマーチ・プロジェクトの開始時点で」ではなく「プロジェクトの開始時点で」となっていることです．言い換えると，「デスマーチに至らないようにするためには，どんなプロジェクトでも，開始時点でトリアージ戦略を採用せよ」と読み取れることです．

うまくいくようにするためには，出資者と利害関係者のすべてが，どの要求項目が「やらねばならぬ」区分に入り，どの要求が「やったほうがいい」区分に入り，どの要求が「やれればやる」区分に入るかについて，同意しなければならない．プロジェクトに金を出している人が，要求項目のすべてが「やらねばならぬ」区分に入り，他の二つの区分に入るものはなにもない，と言い張るなら，すべての議論は時間の無駄になることは明らかだ．そして，もし，いろいろな立場の出資者と利害関係者の間でトリアージ区分についてコンセンサスが得られない場合は，資源がないのにすべての関係者のためにすべての機能に手をつけることになり，プロジェクト・チームを無力にする．
(p.134)

赤黄緑の区分は，十分な経験に基づいて決められており，訓練を受けたものなら誰でも短時間で同じ判定をする，というのが災害におけるトリアージですが，上の引用はまったく違う方針で，一言でいうと「当事者間で同意を得る」です．
明快ですが，待て待てそんなんでいいのかという感もあります．
出資者・利害関係者が，プロジェクト・リーダーやプロジェクト・マネージャよりも，ヨードンの主張するトリアージ法をよく理解しているという可能性は低いわけですから，結局のところ「開発側の主張次第」となってしまうように思えます．プロジェクト・チーム（あるいはプロジェクト全体）を守るためとはいえ，この運用は要注意です．

この章の最初に述べた「トリアージ」の観点から見ると，一つの大きな問題がある．トリアージするのに，要求項目を管理する体系だった方法がないことである．どうやったらある要求項目が「やらねばならぬ」区分に入り，別の要求項目が「やったほうがいい」に入り，さらに別の要求項目が「やれればやる」区分に入るかを，あらゆる場面で知ることができるのだろうか? (略) SA/SDやOOA/OODは，要求項目をダイナミックなやり方で管理するのではなく，要求項目を理解し説明することを意図したものである．
要求管理が難しいのは，さまざまな要因がダイナミックに変わるからだ．プロジェクトの開始時点で，トリアージの優先度について出資者と利害関係者が同意し，また優先順位がプロジェクトの期間中まったく変わらないと信じるなら，おそらく像が空を飛べると信じているに違いない．(略)
(p.136)

ここは，医療トリアージにおいて，一度タッグをつけたらそれで固定ではない，状況やシーンに応じて変わり得る，ということと対応しているように読めます．
しかし，現場，搬送，病院といったさまざまな場面で多くの人がトリアージ判定に携わることとは，対応していません．
開発側のリーダーがmust-do / should-do / could-doの3分類を決め，出資者・利害関係者と調整して，確定するというのが，想定される流れなのでしょう．

最後に…自分がプロジェクト管理者の立場にあるとき*2，プロジェクトの管理を，must-do / should-do / could-doの3分類で行い，状況に応じて変更していくというのは，賛成・反対どちらでもなく，個人的にもどこかで使ってみたいなという思いはありますが，その管理方針や，何を手がけて何を手がけないということを，開発者（学生）あるいは関係者（共同研究者，研究プロジェクトのリーダー）に伝える際には，言葉を選ばないといけないな，「トリアージ」の一言で了承を得ようとするのはあまりにも乱暴だぞと，感じています．

*1:http://d.hatena.ne.jp/takehikom/20081111/1226347491

*2:実際，研究室の研究開発について，その一つ一つを管理している立場にあります．