クリティカルチェーン

エリヤフ・ゴールドラット / 三本木亮 / 津曲公二

なぜ、プロジェクトは予定どおり進まないのか――そんな誰もが抱えるジレンマを解消する。これまで考慮されてこなかった人間行動の特性を踏まえ、プロジェクト・マネジメントにＴＯＣ（制約理論）を応用したクリティカルチェーン、我々の常識を覆し、パフォーマンスを飛躍的に改善するソリューションを提示。

• カテゴリ: ビジネス・実用
• ジャンル: ビジネス・経済 / 経営・企業
• 出版社: ダイヤモンド社
• ページ数: 400ページ
• 電子版発売日: 2013年04月19日
• コンテンツ形式: EPUB
• サイズ(目安): 3MB

[ブクログ · ★★★★★]

プロジェクトマネジメントするなら、理解した方が良い概念です。
クリティカルパスと、バッファタイムの考え方は付き纏いますし、誤って設定すると自分が死にます。

[ブクログ · ★★★★★]

この本、スゴく実践的で、タメになる。（もっと早く知りたかった）
さすが、評価されてるだけある。
プロジェクトマネージャー必読。

[ブクログ · ★★★★★]

11年ぶりに本書を読んでみた。全く色褪せていないことに驚きを隠せない。自分自身からみてもプロジェクトをリードしていく中での問題点や解決策は本書の中から今でも拾うことが可能であり、改めて普遍の思考プロセスだと再認識した。
本書ではザ・ゲーム以来著者が語ってきたTOC理論が、プロジェクト管理にも有効なことが示されている。生産工程におけるクリティカルパスの前に積まれたバッファー在庫は、プロジェクトエンドとクリティカルパスに合流する非クリティカルパスの合流前に置かれるフロート（バッファータイム）に置き換えられ、更にリソースのバッティングには、競合するリソースを繋ぐクリティカルチェーンへの拡張で解決している。

中でも素晴らしいのは、コストワールドからスループットワールドへの転換が経営的に如何に大事かを説いている点である。品切れなんてとんでもないことが改めて思い知らされた。

[ブクログ · ★★★★★]

・工場の生産工程を思い浮かべる。
Aさんはボトルネックである。1時間に生産できるのは最大10個が限界。
Bさんは非ボトルネックである。1時間に20個生産できる。
生産工程がBさんの工程（20個/時間）→Aさんの工程（10個）→最終製品
の順になっている場合、Bさんは1時間に何個加工したらいいでしょうか？

これは、感覚的には10個なのだがBさんが10個しか生産しない場合、Bさんは能率が50%ということになってしまう・・

①優れたコストパフォーマンスを実現するには、優れたローカルパフォーマンスを図るしかない
②ローカルパフォーマンスが優れていても、優れたスループットは実現できない
どちらの仮定が間違っているのか？
②の仮定が間違っている。Bさんが２０個生産した場合は、１０個が在庫となる。そして
在庫にはコストがかかるのだ。

・ある鉄鋼会社では「時間当たりの生産トン数が生産性の指標だとする。どうなるか。顧客の注文がないものも生産して、「時間当たりの生産トン数」を向上させようとし始めるのだ。

・建物の高さを測るとする。ある方法を用いれば10ヤードであり、ある方法だと20ヤード。
じゃあ、お互いに妥協して15ヤードにしましょうとなるか。ならないだろう。どちらかが間違って
いるのだ。（刑事事件と民事事件の関係に同じ）
サイエンスの世界ではコンフリクトした場合は、妥協を全く許さない。
・クリティカルパスとは「従属関係にあるステップを繋いだパス、つまり経路で、一番長いと定義される。もちろん時間で」」
・全てのパスをぎりぎりまで待ってスタートすれば、全てがクリティカルパスになってしまう・・
・コストワールドとスループットワールド。
①コストワールドとは個別最適。例えば、個々の部署が鎖で繋がっているとする。営業部、経理部、総務部、生産部。一つの鎖（例えば営業部にしよう）の重さ（経費にしようか）を節約すれば全体の重さ（経費）も少なくなる。
②スループットワールドは全体最適。鎖は繋ぎ目を全部外したらバラバラになった輪が残るだけ。でも重さは変わらない。鎖をつなぎ合わせることで、鎖の強度が決まる。では何によって鎖の強度が決まるか。一番繋がりが弱い輪（すなわちボトルネット）だ。鎖の強度を改善する場合は、この一番繋がりが弱い輪を強くすればいい。仮に他の輪の強度を強くしても全くの無意味である。
・コストワールドとスループットワールドは合い入れない。でもやり方ある。
①制約条件を見つける
②制約条件を徹底活用する（キャパ追加、又は既存のキャパからアウトプットを最大限引き出す）
③他の全てを制約条件に従属させる
この繰り返し。

・余裕時間は積み増しされる
（ぎりぎりの時間は見積もらない。
　-50%の確率で完了するタスクの工数が１MM
　-80%の確率で完了するタスクの工数が2MM
の場合、ほとんどの人間が後者を選択する。つまりリスクバッファは200%だ。　
・浮いた時間は無駄に消費される。
（早く終わっても報告しない。時間もその時間でできると思われたら
　最悪だ）
・学生症候群（期限までに時間的な余裕があればぎりぎりまで着手しない）
・マルチタスクの弊害
＜例＞
優先順位がない場合は、
直列：A工程（2日）→B工程（2日）→C工程（2日）
並列：A工程（1日）→B工程（1日）→C工程（1日）→A工程（1日）→B工程（1日）→C工程（1日）
となり、A工程が完了する期間は2日→4日と2倍になる。
・解決策としては
①作業毎に期限設定をしない。期間のみを提示する。作業が回ってきたらすぐに着手して進捗をこまめに報告し、完了すればすぐに報告する。
②余裕時間は必要なところに集中する。個々の作業にバッファーを組み込むのではなく、プロジェクト全体のバッファーとして集中管理する。
③資源の競合は計画段階で解消する。クリティカルチェーンを見つけること
④不確実性（ばらつき）を織り込む
個々の見積精度を高めるよりも、確率分布のばらつきとしてとらえる。

・３つのバッファー
①プロジェクトバッファー
②合流バッファー
③ボトルネックバッファー（ボトルネックの前におく。行進する先頭の兵隊とボトルネックを繋ぐ。他も繋ぐと在庫が積みあがる）

・ガントチャートには意思がある。どの作業をどのタイミングから開始するかはマネージャの意思だ。
・Win-Winの関係にならないのは、まだ一部だけしか見えていないから。全体を見えれば必ずWin-Winの関係が見つかる。

[ブクログ · ★★★★★]

TOCシリーズの第４作。
納期管理、プロジェクトマネジメント等のヒントが盛りだくさん。


＜備忘録メモ＞
・下級マネージャほど社内要因を理由にあげる
・「コストワールド」（伝統的原価計算）と「スループット・ワールド」
・「人に命じて仕事をさせる時代は終わった」
・下請へのコスト増←→トータルコスト（納期短縮）
・お金と時間の二次元　ダラーデイズ（投資）

[ブクログ · ★★★★☆]

ー　「そうだ。でも定義は大事だ。一度、定義を整理してみよう。 とりあえずクリティカルパスの定義は、そのままということにしておこう。いちばん長いパスだ。さて、ここからだ。もう、みんなわかっていると思うが、ここで重要になるのが制約条件だ。制約条件は、従属ステップがいちばん長くつながっているところだ。従属関係がリソースに起因することも考慮しないといけないわけだから、これには別の名前を用意したほうがいいだろう」

「『クリティカルチェーン』というのは、どうですか。 従属ステップがいちばん長くつながっているところ、つまり鎖ですから」 ー

「制約条件の理論」と「思考のプロセス」の応用編。
『チェンジ・ザ・ルール！』はIT投資（システム開発）、本作はプロマネ。

本作も面白かったが、対象が現場から離れてきている分、臨場感には欠けてしまう。奥様とのエピソードはもはや惰性のおまけ。『ザ・ゴール』の時には重要な役割があったけど、今回は何かを得るやり取りは何もない。

[ブクログ · ★★★★☆]

ザ・ゴールシリーズの第四段。
このシリーズならではの小説の作りになっているビジネス書であり、非常に読みやすい。
議論は根気よくしないと良い回答が得られないことがよくわかる一冊でした。

[ブクログ · ★★★★☆]

プロジェクトマネジメントを考える際、最も実践的かつ参考になる図書。
制約の理論がベースであるものの、近年話題であるアジャイル手法に通じる。
カンバン方式やスクラムの考え方に通じるため、こうした理論を自分のプロジェクトに適用したい人は是非一度は目を通して欲しい。

[ブクログ · ★★★★☆]

プロジェクトはいつも遅れるもの。多くの人が直面する悩みだが、制約条件の理論（Theory Of Constraints）を使って、この悩みを解決することを小説仕立てで展開する。
制約条件の理論は、「システムのアウトプットは、その最も弱い部分の能力で制約される」というもの。これをプロジェクトマネジメントに当てはめると、プロジェクトの開始から完了までの一連の作業、工程をつないだ経路のなかで最も長い作業を要する経路をクリティカルパスとする。このパスがプロジェクト全体の時間を左右する。
個々のステップ毎に見積もり時間を設定して合算した数字をプロジェクト全体時間とするのではなく、個々のステップは余裕を持たないギリギリの時間に削り（見積もり時間の半分くらい）そして削った余裕を全体のプロジェクトバッファと設ける。プロジェクトマネジメントはそのクリティカル・パスのモニタリングのみに注意するというもの。
実際にはそんなに上手くいくかは確信が持てないが、遅れる前提でガントチャートを書くのを繰り返すことを脱却できるかもしれない。何よりプロジェクトマネジメントを可視化するには面白い考え方である。

[ブクログ · ★★★★☆]

以前買ったものを再読。昔とは立場も違うので、この中に書いてあることで実践できそうなことが多い気がする。

ただ、クリティカルチェーンの算出や合流バッファ、リソースバッファの埋め込みにはソフトウェアが必須だと思うし、そうすると予算がないとできないな。。。ある程度予算動かせる立場ではあると思うけど、組織としてプロジェクトが遅れて問題と思っている立場の人間とつかわないと意味がないけど、そこまでたどり着いていないような気もする。