【プロジェクトの炎上ケース】
プロジェクトが炎上化するケースとしては、典型的には下記のような状況が考えられます。
- 顧客要件が曖昧で要件定義がいつ終わるかわからない
- 大規模プロジェクトで経験のない開発技法を採用したため、メンバーのスキル不足で上流工程に多大な時間がかかり、納期遅延やコストオーバーランのリスク発生
- 納期絶対のため上流工程の品質確保が不十分で、下流工程で設計バグや多くの手戻りが発生し、メンバーの長時間残業が恒常化している
- スコープが予想以上に膨らみ、計画時のリソース（要員）を大幅に増員して対応しようとしている…etc.
筆者も大規模なシステムを新しい開発アプローチである「オブジェクト指向技術」で開発するプロジェクトをプロマネとして担当した経験がありますが、メンバーのスキル不足のため、顧客が満足するような成果物（オブジェクト部品）を提供することができず、プロジェクトを炎上化させたことがあります。
今回は、このような炎上化したプロジェクトをなんとか鎮火させて、プロジェクトをソフトランディング（軟着陸）させる一つの方法として「トリアージ」について説明します。
【炎上プロジェクトのリカバリーマネジメント】
リカバリーの本質はターン・アラウンド（方向転換）です。失敗プロジェクトの被害を最小限に食い止めるための活動になります。一種の「火消」ですが、延焼を防ぐことも重要課題になります。
リカバリー作業として、まず着手することは、プロジェクトの現状把握です。何が作業として終わったのか、残作業として何が残っているのかを明確にします。その残作業に対して、今後の計画（スケジュールや必要な要員）を立案します。ここで重要なことは、無理をしないで、やり切れる実現の可能性の高い計画を作成することが肝要です。これができないと更なる炎上になります。
【トリアージ】とは
炎上化したプロジェクトのリカバリーに長い時間はかけられないのが現実です。短期間で、正常な状況に戻すことが、リカバリーのプロマネに求められます。ここで使われる有用な考え方が「トリアージ」です。
「トリアージ」とは、患者の重症度に基づいて、治療の優先度を決定して選別を行うことです（語源は「選別」を意味するフランス語の「triage」）。救急事故現場において、患者の治療順位、救急搬送の順位、搬送先施設の決定などにおいて用いられます。また、数量の乏しい必需品（治療薬など）を最大の効果がえられる人にだけ優先的に割り当てるシステムでもあります。具体的には、生命の危険のある患者には赤色のタグを、多少処置がおくれても生命の危険がない患者には黄色のタグを、軽度の患者には緑色のタグを、また生命の兆候がない患者（死亡）には黒色のタグをつけ、治療の優先度の高い順に、限りあるリソース（この場合は、医療スタッフや治療薬）を有効活用します。炎上化したプロジェクトで言えば、乏しいプロジェクトリソース（時間と要員）を残作業に優先順位をつけて割り振ることにより、プロジェクトをソフトランディング（軟着陸）させるためのプロセスが「トリアージ」です。
【トリアージにおける残作業の優先順位】
ここで問題になるのが、優先順位をどのように決定するかということです。エドワード・ヨードン氏は著書『デスマーチ』の中で、炎上化したプロジェクトを「デスマーチプロジェクト（Death March Project）」と命名しています。その著書のなかで、システムの残作業項目を「やらねばならぬ（must-do）」、「やったほうがいい（should-do）」、「やれればやる（could-do）」の３つに分類しています。この３つのトリアージ戦略は、残作業を
- 「やらねばならぬ（must-do）」作業に最初に集中し
- 時間があれば、「やったほうがいい（should-do）」作業に力を注ぎ
- 《奇蹟》が起これば、「やれればやる（could-do）」作業に手をつける
に分類することです。
極端に言えば、最後の「やれればやる」作業を事実上やらないと諦めることです。
このことにより、ユーザーの要求が一部満たされない状況が発生することになりますが、果たしてそれが大きな問題でしょうか？
有名なパレートの法則（80/20ルール）が当てはまると仮定すれば、要求事項の20％をインプリメントすれば、システムの価値の80%を提供できると言えます。炎上化したプロジェクトをソフトランディングさせるためには、この決断がリカバリーを遂行するプロマネには求められます。
★ Tip of the day
- 炎上化プロジェクトでは、ユーザーの要求をすべて実現する時間がない
- 「トリアージ」による残作業優先順位付けが有効なプロセス
- 最後の「やれればやる（could-do）」は事実上諦める作業である
