要求のトリアージは大事（5/14追記）

ソフトウェア開発を始めるにあたって、一応「成功する要求仕様 失敗する要求仕様」に目を通しております(^^;。
本書で説明されている「要求のトリアージ」は大切ですよね。
現在、[pepoz]のシステムをインドの開発会社にお願いして進めているわけですが、だんだんと修羅場度が募るにつれて、何を捨てて何を残すか、何を次期送りにして何を間に合わせるかの判断がかなり重要な意味を持つようになります。
ソフトウェアというものは、開発が開発を呼ぶようなところがあり、細部に着目すると工数が無限に膨れ上がります。重箱の隅をつつく的な姿勢はかなり抑制しないといけません。

要求のトリアージとは、捨てるための判断基準、というところでしょうか。人によって定義が異なってくるのでしょうけれども。

C社のコンサルティング部門で私の前に座っている方がリスクマネジメントの専門家でいらっしゃいます。某政府の某リスクマネジメント系某Pなども担当されたことがあるそうで、発想がプロです。
彼から医療の現場におけるトリアージの話を聞いたことがありますが、その様がまったく上掲の本に書かれている通りでした。要治療患者をすばやく選別し、意思決定をして歩くわけですね。なかなかシリアスな背景を持っている言葉です。

書き始めたはいいけれども、落としどころがなくなってきました…。

ビールでも飲んで帰ろう。

---------

5月14日追記

要求を出す→それが人日になって返ってくる→実行可能かどうかを判断する→要求を出す→それが人日になって返ってくる→実行可能かを判断する。その繰り返し。

要求は必要資源に翻訳され、現実的な制約があるなかで決断が下され、実行に回る。そうしてモノができあがる。こういう図式に、なにか、普遍的なものがひそんでいるような気がしてなりません。