#book #r2022  # なぜこの本を読んだか ずっと積んでいて、最近チームの仕事の仕方を整理する必要があってそのロジック強化のために読んだ また会社で特にマネージャー陣で読んでいる人も多かったので言語を獲得することが目的 # 何が書かれている本か 制約理論 (TOC) についてストーリー仕立てで具体例も交えながら書いている 特に以下のメッセージが強く印象に残ってる - ボトルネック (この本の中では悪いことではなく現実として最も処理能力の低いプロセスのことを指している) が全体の処理能力を決めてしまうのでそれ以上の仕事をしても在庫が溜まってしまうだけでありスループットの観点から見るとまずこのボトルネックの稼働率を100にすることが重要である - その次にボトルネックの処理能力を改善することで非ボトルネックの余剰処理能力の活用率を高めていく - 上記のような考え方で複雑なプロセスを単純化し (アウトカムで評価し) 改善していくことが重要である # メモ ## 従属事象 と 統計的変動 プロセスを複雑にするのは、 「従属事象」: A の後にしか Bは処理できないなどの直列的な従属関係 「統計的変動」: A の単位時間あたりの処理能力は平均こそあれど変動する (一定の幅の中を動く) 例えば、A -> B -> C という従属性がありそれぞれが単位時間あたり平均 20 の仕事ができるとしたときには、平均で 20 のアウトカムが出てくると想像してしまうが実際にはそうならずアウトカムがもっともっと低くなる 単純化のために A (15), B (25), C (10) という処理能力だったときには、以下のように結局 B がいくら調子がよくても A と C (特に C が全体のスループットを決めてしまう) example | 時間 / 処理数 | A | B | C | | -- | -- | -- | -- | | T1 | 15 | | | | T2 | | 15 | | | T3 | | 5 | 10 | ハイキングの例なんかも出てくるが、ハイキングでは一番遅い人にみんながひきづられてしまい、全体が遅くなるか、間の距離がどんどん開いてしまうかになる ## ボトルネック 本の中で主人公である所長にアドバイスをしているジョナという科学者はボトルネックを以下のように説明している > ... ボトルネックのフローを需要に合わせるということで正しい。... > ... ボトルネックは単に現実なんだ。ボトルネックが存在するところでは、生産システムから市場までのフローをボトルネックを使ってコントロールすべきだと提案しているだけだ。... つまり工場などでは、スループットの先に「販売」が待っていてそれが捌ける量以上に生産してしまうと在庫を抱えてしまう (負債のような考え) ので生産量を需要に合わせる必要がある。 またその場合には生産量というのはボトルネックの生産量になるのでボトルネックの生産量を需要と合わせるというコントロールをするというのが正しい考え方ということを言っている。 またボトルネックの稼働率がとても重要であり1秒も無駄にはできないため、例えばボトルネックのあとで品質検査を行って10% 弾かれた場合には、ボトルネックに10%無駄な仕事をさせているという考え方になる。( = つまりスループットが減ってしまう)  ## ボトルネックと非ボトルネックのプロセスパターン  ## スループットを生み出すステップ - セットアップ (準備のオーバーヘッド) - プロセスタイム (処理時間) - キュータイム (その処理が詰まっていてそれ待ちの時間) - ウェイトタイム (他の処理が終わるのを待ってる時間) # 感想 - 工場生産というコンテキストを踏まえて読む必要はあるものの、考え方はアジャイルの話やリーンの話だったりをより抽象度を上げたもので現代における様々なプロセスのフレームワークを解釈する上での知識になりそう - 「スループット」、「在庫」、「業務費用」の3つの概念と「ボトルネック」、「非ボトルネック」の話は本当に様々な領域を整理することができるなと感じた - 世の中で語られているものはかなり抽象度が高くて (しかも読み方によっては誤って解釈してしまう) ちゃんと読むのは大事だなと思うことができた - 一般的なソフトウェアにおける TOC はもっと単純だと考えていて、例えばユーザーは「購入する」という選択をしなかったりする (もちろん販売型のソフトウェアは違うけど) ので需要が無限と考えることができる場面もあったり、ボトルネックの処理能力を向上させるのに物理的制約が向上などと比較するよやや弱かったりするので自分の境遇における整理を改めてしたいと思った ### 社の times に書いた余談 The Goal 在庫はコストという話なんじゃなくて在庫を作っているということはキャッシュフローが悪い(業務費用をかけて在庫を作っているので出荷できないのであれば効果を生んでいない)という結論に至ることができて1つ在庫の考え方がすっきりして良かった。 ずっとソフトウェアのように在庫の物理的な大きさがないものと製品における在庫を比較することに違和感があったので。 あれは単にスループットが悪いということはROIにおけるIが何もしていないのに高い状態になってしまっていて(工場の稼働コストとかを考えると)本当は実現できたROIがマクロな視点では実現できていない(案件単位ではできているかもしれないが)ということなんだなあ でこれはアジャイル開発の話も同じことを言ってるっていう話に繋がるわけだなあ。 そうなるとフロー効率を重視しているわけではなくてボトルネックについてはリソース効率を最大化させよと言っていて勘違いしているとかなり主張が異なる気がするな 参考 - [ToC（制約理論）入門 / ToC Introduction](https://speakerdeck.com/recruitengineers/toc-introduction) - [ブルシットプロダクトからチームを守れ! ｢顧客が本当に必要だったもの｣をいかに追求しつづけるか /bullshit product rsgt2022](https://speakerdeck.com/moriyuya/bullshit-product-rsgt2022?slide=230) - 後半からボトルネックの話に入る