システム開発のトリアージは上流工程で！

トリアージ（triage）とは（たぶん）医学用語なのですが、
システム開発でも使ったりします。

システム開発の場合には機能だったり不具合に対して優先度をつけますが、判断するタイミングは、上流工程の終盤あたりだと思います。

開発がスタートされて顧客と要件を詰めていくと機能がどんどん増えていきます。
これはあたりまえの事で顧客はこの時点になって自分の中で要件が固まっていくからです。

最初にヒアリングを受けたときには”もやっと”したイメージの中で話していますし
紙と会話だけではなかなか自分の業務とリンクしないからです。
それが上流工程の終盤になってようやく画面と業務がリンクし始めて
あれができない、これができないと言って必須機能が増えます。

通常、追加分の機能に対してプロマネは、金と期間を調整します。
金も期間もほぼ固定なので結局は機能に対して優先順位をつけましょうって流れに
なります。これがトリアージ（triage）です。

この時点でうまくトリアージができるとデスマーチに陥りにくいです。

しかし私の経験したデスマーチプロジェクトではこのタイミングでトリアージができていませんでした。

私が経験したデスマーチプロジェクトではトリアージが行われるのはが納期間際です。

その時点になってやっと開発チームの上司を含めて機能の取捨選択を行います。
そのときには「この機能はできません。」とは言えないので「２次開発」
若しくは「リリース後」と表現された一覧を作成して、顧客に泣きつきます。

この時点ではなかなか金、期間の交渉は難しいです。
顧客と敵対関係になっている可能性は高いですし、リリース間際なので今更「できません」は
顧客側としても納得できません。

なのでどうせトリアージが必要になるので、交渉し易い上流工程でしましょう。って話なのですが、
上流工程でも顧客は予算が決まっているのでなかなか難しいのが現実ですね。^^;