DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

戦後最悪の火山災害となった御嶽山の噴火により被災された方々には、心からお見舞いを申し上げます。まだ行方のわからない方々の少しでも早いご帰還をお祈りしております。

前回は「80対20の法則」を意識し、最少努力で最大成果をあげるためには「優先順位づけ」が大事であるということを考察しました。「優先順位づけ」といえば、「トリアージ」という概念をシステム開発のプロジェクトに転用することがあります。今回はデスマーチ・プロジェクトにおける「トリアージ」について考えます。

【　トリアージとは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「トリアージ」の概念については、エドワード・ヨードン氏の『デスマーチ』をはじめ、既にシステム開発のプロジェクトのさまざまな局面で、さまざまなニュアンスの違いを含みながら転用されているように思われます。

まずは、『デスマーチ』における定義を確認してみます。（※１）

「トリアージ」という概念
“triage”という言葉の語源は、「グループ分けすること」を意味する古いフランス語の”trier”からきている。American Heritage Dictionary（第3版）では、次のように定義している。

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

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

この説明を読むと、時間やコスト制約のあるプロジェクトにおいては、前回ご紹介した「80対20の法則」を意識した優先順位づけが必要だということを示しているだけのように受け取れます。

しかし、私が「トリアージ」という言葉を聞いて直感的にイメージするのは、むしろ1番目の定義の方です。つまり、「戦場、災害地、病院の緊急処置室」にたとえられるほどの危機的な状況（デスマーチ）に陥ったプロジェクトにおいて、ごく限られたリソースを効果的に活用することで、プロジェクトをソフトランディング（なんとかカットオーバー）させるためのプロセスというイメージです。

【　プロジェクトの危機的状況とはどんな状況か？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
では、「トリアージ」が必要となるような、システム開発における危機的状況がどんなものか、私自身の経験も踏まえて少し紹介してみます。このような危機的状況を既にご経験済みの読者の方がいらっしゃるとすれば、いやな記憶をよみがえらせてしまうかもしれませんが。。。

＜システム開発プロジェクトの危機的な状況の例＞
・システムテスト実施中で、カットオーバーまで残り2ヶ月
・外部設計が長期化し、未だに顧客レビュー指摘が解消できていない
・納期をずらすことができないため、内部設計以降を五月雨で実施
・外部設計レビュー指摘などによる手戻りが多発して品質もボロボロ
・結合テストの途中から進捗遅延、品質不良に対して、顧客のクレームが常態化
・開発・管理体制を当初の3倍に増員し、事態の収拾を図ろうとしている
・業務仕様を知る当初からのメンバーは、顧客対応、社内調整に忙殺され事実上戦力外
・業務仕様を知らない応援メンバーが開発、品質向上を行うことでますます品質劣化
・・・

とまあ、デスマーチ・プロジェクト特有の悪循環が起きている状況を想像してください。私もこのリストを書きながら吐きそうになってしまいましたが。。。

さあ、こんな状況のプロジェクトを立て直すために、もしあなたがプロジェクトマネージャーとしてアサインされたとしたらどうしますか？あと2ヶ月で、この状況を何とかしなければならないとしたら。。。

【　危機的状況への対処法　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まあ、これだけ危機的な状況であれば、顧客との関係もあり、いろいろなアプローチが考えられますね。とにかく現場を仕切るためにアサインされたとしたら、だいたい次のような動きをとる必要があるでしょう。既にモチベーションを失っているプロジェクトメンバーに対して、さらに叱咤激励するだけでは、かえって逆効果になってしまいます。

＜危機的状況への対処法（一般論）＞
１．残タスクの洗い出し
・　当初計画に対して何ができていて、何ができていないか
・　現状の問題・課題、リスクを把握して、対応策を列挙（できる範囲で）
・　レビュー指摘対応残、障害対応残、仕様変更対応残
・　顧客や社内への状況説明など想定される重たいマネジメントタスク　　・・・

２．優先順位づけ（トリアージ）

３．リソース割り当て

残タスクの中には、当初予定されていたタスクのうち未実施のタスクだけでなく、顧客レビュー指摘対応、テスト工程で摘出された障害対応、カットオーバーまでに取り込む必要がある優先度が高い仕様変更対応、顧客への状況説明など想定されるマネジメントタスクなども全部ひっくるめて考える必要があります。

そして、洗い出された残タスクに優先順位づけ（トリアージ）を行い、トリアージされたタスクに対して、ごく限られたリソース（人、時間、コストなど）を割り当てるのです。

もちろん、危機的状況のプロジェクトにアサインされてすぐに、的確に状況を把握して上記のような対処が整然と行えるはずはありません。もう時間は限られているため、短期間に素早く上記の手順を実施し、かつ、何度も何度も繰り返し実施する必要があります。

何度も繰り返す理由は、混乱の中で見落としていた残タスクが後で見えてくることがあるし、悪循環をもたらす隠れた課題やリスクに気付くこともあるし、それによって、残タスクの優先順位は刻々と変わっていくためです。

これを繰り返し実施している間に、ソフトランディング（なんとかカットオーバー）の落としどころをどこにするのか、顧客とのハードな折衝を行うことになります。

ここにあげた危機的状況への対処方法が、私のイメージするデスマーチ・プロジェクトにおける「トリアージ」のプロセスということになります。

【　デスマーチ・プロジェクトにおけるトリアージの優先順位　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここで問題になるのが、優先順位をどのように決定するかということです。エドワード・ヨードン氏は『デスマーチ』の中で、システムの要求項目を「やらねばならぬ（must-do）」、「やったほうがいい（should-do）」、「やれればやる（could-do）」の３つに分けたうえで、

「やらねばならぬ」要求項目に最初に力を集中し、
時間が残っていれば「やったほうがいい」要求項目に力をそそぎ、
奇蹟が起これば、「やれればやる」要求項目に手をつけるのである。

としています。（※１）

危機的状況のプロジェクトにおいては、時間をかけて優先順位を吟味している時間は残されていません。洗い出された残タスクのうち、３分の１を優先順位Ａ（やらねばならぬ）、残された３分の２のうち半分を優先順位Ｃ（やれればやる）に振り分け、最後に残った３分の１を優先順位Ｂ（やったほうがいい）という具合に、残タスクが概ね３等分されるように、時間をかけずに、ざっくりと振り分けるのです。そして、この段階で優先順位Ｃ（やれればやる）となったタスクは、事実上、やることをあきらめるタスクということになります。

「デスマーチ・プロジェクトにおけるトリアージとは、残タスクの１／３をあきらめることだ！」

となると、優先順位を振り分けるルールが気になりますね。危機的状況においては、どうしても政治的な背景（たとえば、ステークフォルダー間の責任の押し付け合いなど）も視野に入れながら優先順位を決めるでしょうから、どんなルールが良いかは一概には言えません。

そのような背景を考慮せずにピュアに考えるならば、以下のような要素を加味して、優先順位づけのルール決めをすることになるでしょう。

＜優先順位決めのルールを決定する際に考慮すべき要素（例）＞
１．リリース後すぐに稼働する処理かどうか
２．トランザクション量が多いか少ないか
３．システム化の目的に直結するかしないか
４．代替えの運用手段が無いかあるか
５．エンドユーザークレームにつながるか
６．データベース等のシステム不整合につながるか
７．目につきやすいか
８．会社損失につながるか
９．次期開発や将来的に見て重大リスクとならないか
１０．残された期間で十分な実現可能性は見込めるか・・・

こんな風に残タスクの３分の１をあきらめなければならない状況なんて、まっぴらごめんですよね。このような「トリアージ」は、本当に危機的状況の場合だけにしたいものです。これで急場をしのげたとしても、おそらくいろいろな意味で、のちのち禍根を残すことになるのではないでしょうか？

ところが、この「トリアージ」的な考え方をプロジェクトの初期段階から適用すべきだというのが、『デスマーチ』におけるエドワード・ヨードン氏の主張ではないかと私は理解しています。。。

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　エドワード・ヨードン（2006）『デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか』日経ＢＰ社