情報考学　Passion For The Future

最速で開発し最短で納めるプロジェクト・マネジメント

・最速で開発し最短で納めるプロジェクト・マネジメント―TOCの管理手法“クリティカル・チェーン”

私はベストセラービジネス小説「ザ・ゴール」シリーズのファンである。

著者の物理学博士エリヤフゴールドラットが考案したTOC（制約条件理論）が主題の名作。工場長である主人公は、閉鎖寸前の工場の業績を、TOC理論を使って生産プロセスを最適化することで、業界に革命を起こす。その過程で、TOCの考え方が、工場の経営だけでなく、あらゆるプロジェクトや日常生活までをも最適化できる汎用的な理論であることが分かっていく。

この本では、博士の小説では詳しく語られなかった理論的側面が解説されている。ザ・ゴールとあわせて読むと、特にITの開発プロジェクトにも目が向けられており、IT業界の開発マネージャに参考になる。

TOCは幾つもの理論から構成されているが、概要は次のようなもの。

■ボトルネック、中間在庫、手あまり

例えばこんな作業ラインがあるとして、括弧内にそれぞれの1日当たりの生産能力（処理できるユニット数）を示すとする。

第一工程（100）→第2工程（25）→第3工程（80）→スループット（成果）

ボトルネック：
この工程にいくら作業を投入しても、1日当たりの成果は25ユニットを超えることはできない。第2工程の作業者が病気で休んでしまったり、使う機械が壊れてしまうことがあるから、大抵は25以下である。第2工程が、TOCの重要な要素「制約条件（ボトルネック）」となっている。

溜まる中間在庫：
企業の生産性は、成果として1日何ユニット生産できるかだけでは測らない。上記のラインで1日100ユニットを投入すると、終業時には第1工程と第2工程の間に、75個の中間在庫が溜まることになる。日を追うごとにこの数字が増えていく。中間在庫は、企業にとってコストとして評価されてしまう。

手あまり：
さらに第3工程では、1日80の生産力があるのに、直前の工程からは最大25しか流れてこないものだから、55分の生産力が無駄になってしまう。第3工程の人たちはやることがなくて、ぶらぶらする結果、この作業ライン全体の人件費の効率を下げてしまう。

「工場の生産性はボトルネック工程の能力以上には絶対に向上しない」という博士の結論がある。TOCでは、ボトルネックを強化することをまず考える。

■ボトルネックの最適化

TOCの改善方法は、上の作業ラインを使って説明すると、次のような流れになる。

１　制約条件の発見
　　　第2工程がボトルネックだということを発見する
２　制約条件の最大限の活用
　　　第2工程が1日当たり25ユニットを必ず生産できるようにする
３　制約条件以外を制約条件にあわせる
　　　第1工程の生産力を25を少し上回る程度に調整する
４　制約条件の強化
　　　第2工程にスタッフや機材を増やす
５　変化のチェックと繰り返し
　　　別の工程がボトルネックに変化していないか等チェックし1へ戻る

いくつか細かなルールがある。ボトルネックの前の工程は生産力を多めに配分し、少量の中間在庫をわざと残す。第1工程が事故で止まった場合でも第2工程以下が動き続けられるからである（保護能力）。また、手あまりの存在を容認し、全体にゆとりをもたせる（バッファー）。

■ドラムバッファーロープによるスケジュール作成

TOCではドラムバッファーロープというスケジュール管理手法がある。比ゆ的な表現として、ボトルネック工程が自分のペースに合わせて工場内に聞こえるように太鼓を叩く。太鼓のペースで他の工程は作業をする。各工程をロープで結びつけ、歩調を合わせるわけだが、わざとロープにたるみを持たせる。ボトルネック工程以外が遅れが起きても、たるみのおかげで、連鎖的に作業が中断することを防ぐ。

TOCは作業は確率的に見て必ず遅れるものという前提で組み立てられている。各工程はサイコロを振っているようなものとみなす。出た目が処理して次の工程へ渡すユニット数であるとする。サイコロは平均3.5が出るようになっているが、途中プロセスの誰かが3.5を下回る数を出せば、最終工程の出す成果は3.5を下回ってしまう計算になる（遅れの伝播）。

例えば第1工程と第2工程が2を出した場合、第3工程が6を出しても、処理すべきユニットは2しかないので、2以上の成果は出ない。逆に第1工程と第2工程が6を出したとしても、第3工程の確率平均は3.5でしかないので、最終成果も3.5程度になる可能性が高い。業務フローの遅れは伝播するが、早く仕上げた結果は伝播しないのだ。人間が行う作業である以上は、常に完璧を期待できない。遅れは必然となる。

■導入に際しての気持ちが分かる第4章

この本の面白さは第4章「夢をかたちに変えるスケジュール　開発部門のプロジェクト管理に挑む　物語編」にあると感じた。この章では、理論解説ではなく、各業界に散らばった同期が集まって、TOCの考え方をそれぞれの視点で議論する対話になっている。

TOCはマネジメントの考え方だから、管理する方と管理される方の意識の違いが導入時の最大の課題になる気がする。人は誰しも、自分の仕事を最適化したいけれど、上から最適化されたくはないと思う。この章では、クリエイターやデザイナーなどの非マネジメントサイドの意見がある。

3人以上のチームでフロー作業を行う場合にTOCは価値がある考え方と思った。他にも問題解決法の「思考プロセス」や、プロジェクトの安全余裕バッファーの量と配置の理論、全作業の中で最も重要なラインを強化する「クリティカルパス」などの理論も解説されている。

私も来年こそは遅れゼロを目指したいのだけれど、それって去年もそう言ってたっけ...。

Posted by daiya at 2003年12月23日 23:59 | TrackBack