バリューストリーム

http://www.infoq.com/jp/news/2008/05/impediment-scope

見た．注文を受けてから納品するまでのバリューストリームマップ．

製造業の場合の(狭義の)バリューストリームは、「ものの流れ」が価値の流れで、「在庫」や「ボトルネックの生産力」はものの流れを阻害するものと、バリューストリームの概念と実際のマッピングはしやすい．
("狭義の"と書いたのは、もの流れを阻害するのが、ボトルネック工程の生産力ではなく、人事評価制度など、会社の制度–文化などもあり得るから)

転じて、ソフトウェアのバリューストリームは、なかなかイメージがつかないなぁというのがぼくの第一印象．

例えば、細かな要求定義の(後半の)活動が付加価値を生んでいるのかそうでないのかの判断．
バリューストリームのスムーズなユーザ価値を生む流れをつくるのに、一イテレーションのタイムボックスの中で、要求定義の活動に時間を割り当てるのが妥当なのか、ディベロッパーテストの活動に時間を割り当てるのかの曖昧な意思決定が難しい．

だた、
http://www.atmarkit.co.jp/aig/04biz/vsm.html
に書いてあるように、バリューストリーム・マップの時間線はの「付加価値時間＋待ち時間」で書くらしい．「待ち時間」は観測がしやすい．

部品をつくる -- 待ち --> 結合テスト
（継続）リリース --待ち --> お客さんの受け入れ実施
バグ報告 -- 待ち --> 修正
などなど、いくつかは、すぐにだれでも見つけることが出来る。
私の脳内では、待ち＝「キューのアイコン」が、浮かんでくる．