濱井です。
2002/10/16 12:30:31 +0900にmika@....comさんが送られた
メールに関する返信です。
TOCの制約の考え方は、基本的には、処理するモノと顧客に提供するモノとが
物理的に１対１に対応すると見なせる製造プロセスなどについてのものであって、
そのまま単純にソフトウェア開発などに適用できるものではありません。
コピーすることによりいくらでも増やせるように、処理する数量と顧客に
提供する数量とがほぼ無関係なソフトウェア開発などでは、数量を基にして
制約を考えることは意味がありません。
１日100台売るとしたら、１日100台作らなければなりません。99台しか
作れなければ99台しか売れません。１日100台作る能力があっても、99台
分の部品しかなければ99台しか作れません。100台分の部品を作る能力が
あっても、99台分の原材料しかなければ99台分の部品しか作れません。
このように全体において、１日100台分のモノが流れていないと１日100台
売ることはできません。どこかが１日99台分しか流れないと全体としても
99台分しか流せません。一番流れにくい箇所、そこが制約です。
ソフトウェアの場合、CD-ROMの複製などにおいて、このような数量的な
制約はまず考慮する必要はありません。市場の制約はありますが。
ソフトウェアの開発においては、このような物理的なモノ自体、通常必要
ありませんから、数量的な制約は一般にあり得ません。
クリティカル・パスがプロジェクトの開発期間を決めるというような面は
ありますが、開発期間が短ければそれでいいというわけではありません（何も
開発しないのが一番期間が短い）。
それと、大月さんが生産性と呼んでいるものは、処理能力と呼ぶべきだと
思います。TOCでは、全体の生産性は考えても個々の個人や設備などの
部分的な生産性は考えないはずです。