ザ･ゴール 企業の究極の目標とは何か

ザ・ゴール ― 企業の究極の目的とは何か

往復3時間の電車の中で一気に読破。

制約理論

内容は、「TOC（制約理論）による生産管理の改革の方法」が小説仕立てで書かれています。

機械工場の複雑な生産プロセスには、必ずボトルネック（同時に、非ボトルネック）が存在します。このボトルネックこそが、工場の生産能力を決めている、という話。

ボトルネックで失われた一時間は、工場全体で失われた一時間に等しい

プログラムを組んでいる身としては至極当然の事実ですが、その事実に会計の知識が加わると以下のように発展します。

• 非ボトルネックを無駄（＝ボトルネックの生産能力以上）に稼動させることは、在庫を増やし工場全体のキャッシュフローを悪化させる
• 従来の測定基準では、とにかく機械を稼動させることがコストを下げる方法であるとされ、これは間違っている
• ボトルネックを常時稼動させ、非ボトルネックは必要な最低限度の部品在庫を維持するように計算して稼動させる

キャッシュフローとかの会計知識については、先日この本を読んで入門してみたわけですが…

餃子屋と高級フレンチでは、どちらが儲かるか?

(PMとしての)自分の立場にボトルネック理論を応用してみる

当然、自分は工場を管理する立場などにはないわけですが、ボトルネックの考え方はあらゆる場面に適用できそうです。例えばソフトウェア開発のプロジェクトの場合、プロジェクトの進行には多様なファクターが絡んできます。生産能力という点だけで考えれば、次のようなものです。

• メンバーの技術力
• チームの人数
• 使用する言語・技術
• 開発環境・ツール

自分は言語へのこだわりが強くて、（極端には）CommonLispとか、（現実的には）Python・Perlとかを採用したいと思うわけです。まぁ正直Javaなんか使ってられるかと。そういうPaul Grahamかぶれみたいなことを思うわけです。

しかし、言語の選択がボトルネックになるようなケースというのは現実には稀です。言語の処理系の選択・言語の力は非ボトルネックですから、非ボトルネックをいくら増強したところで利が薄いばかりか、下手をすれば全体の効率に害をなす場合すらあるかもしれないわけです。
開発プロジェクトのボトルネックは、

• テスト体制とか顧客との交渉
• 仕様策定
• チームの連絡体制
• スケジューリング

などであって、これらがチーム全体の生産性を決めます。そして言語・技術の選択も、言語そのものの力ではなく、他に存在するボトルネックをいかに改善できるかという点で最適化されるべきなのかなあと。

なので、少しそういう視点でJavaとかを見たら好きになるかな…と思ったのでした。

と、まさにソフトウェア開発についての続編があるようなので、そちらも読んでみます。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?