Report on Japan's infrastructure topic on weekend.
| « 2008年5月12日 | 2008年5月13日の投稿 |
2008年5月21日 » |
ソフトウェア開発を始めるにあたって、一応「成功する要求仕様 失敗する要求仕様」に目を通しております(^^;。
本書で説明されている「要求のトリアージ」は大切ですよね。
現在、[pepoz]のシステムをインドの開発会社にお願いして進めているわけですが、だんだんと修羅場度が募るにつれて、何を捨てて何を残すか、何を次期送りにして何を間に合わせるかの判断がかなり重要な意味を持つようになります。
ソフトウェアというものは、開発が開発を呼ぶようなところがあり、細部に着目すると工数が無限に膨れ上がります。重箱の隅をつつく的な姿勢はかなり抑制しないといけません。
要求のトリアージとは、捨てるための判断基準、というところでしょうか。人によって定義が異なってくるのでしょうけれども。
C社のコンサルティング部門で私の前に座っている方がリスクマネジメントの専門家でいらっしゃいます。某政府の某リスクマネジメント系某Pなども担当されたことがあるそうで、発想がプロです。
彼から医療の現場におけるトリアージの話を聞いたことがありますが、その様がまったく上掲の本に書かれている通りでした。要治療患者をすばやく選別し、意思決定をして歩くわけですね。なかなかシリアスな背景を持っている言葉です。
書き始めたはいいけれども、落としどころがなくなってきました…。
ビールでも飲んで帰ろう。
---------
5月14日追記
要求を出す→それが人日になって返ってくる→実行可能かどうかを判断する→要求を出す→それが人日になって返ってくる→実行可能かを判断する。その繰り返し。
要求は必要資源に翻訳され、現実的な制約があるなかで決断が下され、実行に回る。そうしてモノができあがる。こういう図式に、なにか、普遍的なものがひそんでいるような気がしてなりません。
| « 2008年5月12日 | 2008年5月13日の投稿 |
2008年5月21日 » |

顧客に“ワォ!”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命