ザ・ゴールを読み終わったので、読書メモです。

制約条件の理論、 TOC (theory of constraints) についての本です。組織の中で生きていくのに役立ちそうというのと、受託開発で基幹システムとかも作っているので、業務効率化とかその辺で役に立ちそうなので読んでみました。

目標

生産性とは目標に向かって会社を近づける、その行為そのものだ。会社の目標に少しでも近づけることのできる行為は、全て生産的なんだよ。その反対に目標から遠ざける行為は非生産的だ。わかるかね。

プログラマにとっての技術力も同じで、自分の技術力向上が会社にとってどう生産的なのか。つまり、技術力の向上が会社の目標に近づくことができる行為なのか、を意識する必要があります（長期的な目標→ミッションであったり、中期的な目標→ビジョンであったり、短期的な目標→今期の売上であったり？）。
あるいは、技術力で食べて生きたいのであれば、技術力が生産性、つまり会社の目標とつながっている会社にいくべきである、ということですね（例：技術が F1 レーサー並みでも、バス会社で働いていたら貰える給料は･･････？）

本文中で、ジョナは目標は一つしかない、と言っています。
自分が思いついたのは、以下の二つでした。
・ミッションの実現
・利益
どっちか？

読んだら、お金を儲けること、でした。ここでいうお金を儲ける、が売上と利益のどちらを指しているのかが気になります（その後の文脈から察するに、利益のことっぽい）。
ちなみに自分も利益が重要だと考えています。売上でなくて利益なのは、どれだけ売上が上がっても利益が出なければいつか潰れるからです（Amazonは例外）。例えば月収100万だが自腹で接待で70万使う仕事と、月収40万だが自腹がない仕事だったら後者の方が手取りは多い、っていうことですね。

在庫、業務費用、スループット
また、在庫、業務費用、スループットの3要素が重要だと書いてあります。

在庫：Input
業務費用：加工費
スループット：Output
の認識ですが、であってますかね？

自分の仕事に当てはめると、
在庫→成果物（仕様書、ソースコード、サーバ･･･）
業務費用→人件費、サーバ等のランニングコスト･･･
スループット→売上？
もっとよく考える必要があります。

クリティカルパス

若干ずれますが、大学で習った見積もり手法のクリティカルパス法のことを思い出しました。見積もりだけでなく、効率化やリスク管理という意味でもクリティカルパスを書き出す必要があるのでは。
クリティカルパスに時間当たりの生産能力などを加えると、この本で言っている話につながりそうな気がします。
→前工程で後れたときに、後ろにどれくらい影響が出るかーのシミュレーションができる。
→デッドラインに出てきたように、オフショア開発のモデルを作ってそこに数値を入れていくーでもよさそう。

ボトルネックの話
前の案件で、自分含む各業務の有識者がボトルネックになっていました（人数が少なく、その人達にしかできない仕事が多い）。
→本当に自分じゃないとできない仕事なのか、他の人に回せるのであればまわすということをやっていました。工場の機械だけでなく、人間の場合も同じ考え方ができる、ということですね。

オフショアについて
ベトナム（VN）との作業で、日本（JP）がボトルネックになっています。
→JP側の仕様書の生産能力が限られているため。他に、QAやテストなども。
→チームの生産性はボトルネックに依存するので、そこを解消する必要があるのでは。
→つまり、VNの手が空かないようにする、というのは余剰在庫を生み出すことなので、VN（非ボトルネック）にあわせるのではなくJP（ボトルネック）にあわせるべきでは。
→そのためにVN側の手が空くのは仕方ないというか、必然のこと。ボトルネックを解消しなければどうにもならない。

日本側がボトルネックなのは明らか。
VNの手が空かないように、仕事を投げるので手一杯。
→VNの手が空くことが本当に悪いことなのか（本の中で余剰人員の話が出ていた、暇な人ができるのは悪いことではない）。

ザ・ゴールを参考にして、オフショアのプロセスを改善できるのでは。
→色々試してみる。JP側のタスクを細かく書き出して、ボトルネック以外をVN側に振るなり、ボトルネックを効率化するなり。

払う給与は決まっているのだから、何もさせないからってコストが増えるわけじゃないわ。作業していようが何もしないで待っていようが、経費は増えないのよ。でも･･････、在庫は違うわ。増えれば増えるほど、お金が眠ってしまうことになるのだから。

直感的には理解しがたい。
けど重要っぽい。
但し、システム開発の場合は在庫の保管にかかる費用などがほぼ掛からない、同じものを量産するわけではない、など製造業とはかなり異なる部分があります（要は労働集約型と知識集約型の違い）。何が適用できて、何が適用できないのかはよく考える必要があります。
…と思ったら、既に本が出てるんですね。後で読もう。
後、この作者の外の本も結構役立ちそうなので、後で読む。

TOC戦略マネジメント―「制約条件の理論」実践ガイド
TOC/CCPM標準ハンドブック クリティカルチェーン・プロジェクトマネジメント入門

そういえば、バッチサイズってシステム開発の場合は何になるんですかね？機能？

マネージャー

「私たちが探し求めているものは、いったい何なんだ。三つの簡単な質問に答えることの出来る能力じゃないのか。『何を変える』、『何に変える』、それから『どうやって変える』かだ。マネージャーとして求められる、最も基本的な能力を探し求めているんだ。考えてみてもくれ。この三つの質問に答えられないような人間に、マネージャーと呼ばれる資格があると思うかね」

えぐい。
世の中に、この質問に堪えられるマネージャーがどれだけいるのだろうか…。

システム開発時も、目標は大事です。
コンサルタントの領域かもですが、目標が売上を20%上げることであれば、それをどうやってシステムで実現するつもりなのかを考える必要があります。
例えば、
・作業効率を上げてより多くの量をこなせる様にする
・作業の質を上げて、ロスを減らす
・他部門との連携を円滑化する（コミュニケーションコストを減らす）
などなど。
それによって、システムの要件や非機能要件が決まってくるのではないかと思っています。

全体として、小説仕立てでとても読みやすい本となっていました。
また、自分の仕事に当てはめて考えながら読むことで、色々気づきが多かったです。個人単位の生産性の向上にも適用できますし、チーム、部署、会社全体と広げていくこともできます。まずは個人、チーム単位でやってみようかと。