なぜザ・ゴールを読んだのか
テスト駆動開発を書いたKent Beckの著作を追っていくと、おそらく次に読む本がエクストリームプログラミングになる。アジャイルと言えばスクラムが有名ではあるが、エクストリームプログラミングもアジャイルの流派の1つである。これを勉強するのもアジャイルの理解を深めるのによいだろう。と思って読んでいた。
その中で、制約理論という章が出てくる。この制約理論というのは、どういう理屈かというと、とどのつまり「ボトルネックを無くそう」である。少なくともエクストリームプログラミングを読んだ上では私はそう感じた。何を当たり前のことを言っているのだろう。と。
プログラムを書いた。その動作速度が遅い。といったときには、プロファイルをとり、その中で時間のかかっている処理(=ボトルネック)を改善する。というのは、当たり前の行為である。それをなぜそれほど1つの理論として粒だてて話しているのか、理解に苦しんだ。しかし、それは私が何かしら文脈を読めていないのかもしれない。と思い、では、制約理論の元となった書籍を読んでみよう。その制約理論の元となった本が「ザ・ゴール」である。
帯には、ジャパネットたかたの社長の文言や、iPS細胞で有名な山中教授、Amazonの創業者、ジェフ・ベゾスも読んだ。という文字列が並ぶ。しかも、Amazonの書評には、
◆かつて17年間も日本での出版だけが禁じられた「幻のビジネス書」!!
本書の原著「The Goal」の初版が発売されたのは1984年。全世界で1000万人以上が読んだベストセラーにもかかわらず、長い間日本で翻訳出版が許されなかった。著者のエリヤフ・ゴールドラット博士は、出版を拒否し続けた理由について、次のように語っている。「日本人は、部分最適の改善にかけては世界で超一級だ。その日本人に『ザ・ゴール』に書いたような全体最適化の手法を教えてしまったら、貿易摩擦が再燃して世界経済が大混乱に陥る」
というとても信じられないことが書いてある。そこまで言うなら読んでみよう。そして、制約理論とは何か。ちゃんと理解しよう。と思ったのが、この話のいきさつである。ただ、個人的におすすめは漫画版である。
個人的な感想にはなるが、基本的に、小説版は読みにくい。というのは、基本的には物語仕立てである。そのため、物語のストーリーを見せるために、理論としての要点が散逸しているため、後で読み直したときに参照しにくい。一方で、漫画版は、要点が簡潔にまとまっており、分量も少ないため、見返したときにはるかに見やすい。一部の内容に省略は改変があるが、理論を大筋として学ぶためには問題はない。そのため、個人的には漫画版のほうを読むことをお勧めする。
今回、たまたまコミック版を手に入れることができて、理論における解像度が上がった(本当に良かった)。しかし、理解の解像度が上がったために、アジャイル開発手法とビジネスの気持ちの悪さということに気づいてしまった。というのが本編である。
制約理論とは
制約理論は、5つの集中ステップから構成される。
5つの集中ステップ
- 制約を見つける
- 制約をどう徹底活用するかを決める
- ほかのすべてをステップ2の決定に従わせる
- 制約の能力を高める
- ステップ1.に戻る
以上である。ここで言う、制約とはボトルネックと言い換えてもよい。本当に当たり前のことしか書いていない。これだけである。もう少し正確な表現をすると、
「時間当たりの売り上げ」を最大化するボトルネックを最適化する理論である
ということである。
ケーススタディ
以下のような製品の製造ラインを考える。
A,B1,B2,C,Dという工作機械がある。それぞれの製造能力は、画像の下にある数字通りである。それらの機械を用いて製品p1,p2を製造している。p1は、A→B1→B2→Dと工程を踏む必要があり、p2は、A→C→Dと工程を踏む必要がある。ここでは、問題は簡単のために、すべての工作機械は1つの仕掛かり部品を取り込むと1つの部品を製造するとする。
ここで、「p2という製品を300個欲しい。」という発注が来た。この製品を製造するとき、工場の稼働方法により、製造時間にどれほど時間に差があるのか？ということを見ていきたい。
フルパワー製造
仮に、これらの機械をフルパワーで稼働させた場合、p1とp2はどれほどの生産能力があるだろうか？p1は3.5個/時、p2は2.5個/時となる。Aに供給される原材料を無限とすると、生産能力がB2<B1<Aかつ、C<Aかつ、B1+C<Aのため、B2やCが生産するとき、供給される部品の在庫はなくなることがない。したがって、Dに入る部品は、B2由来の7個とC由来の5個である。Dは前工程の在庫からランダムに部品を取り出し、製品を製造すると、先ほどのp1は3.5個/時、p2は2.5個/時という製造能力になる。これらを図にあらわすとこのようになる。
フルパワー製造の場合、
- p2の製造能力は2.5個/時
- p2の発注を捌くには120時間かかる
- Aは17個/時で在庫を作る
- B1は1個/時で在庫を作る
- B2は3.5個/時で在庫を作る
- Cは2.5個/字で在庫を作る
- 3.5個/時でp1の在庫が増える
制約を意識した製造
p2の製造工程を見てみよう。Aの製造能力は20個/時、Cの製造能力は5個/時、Dの製造能力は6個/時である。そして、p2は必ずA→C→Dの工程を必ず踏まなければならない。と考えると、どう頑張ってもp2は5個/時しか製造できない。この制約(ボトルネック)に合わせてすべての製造工程を調整する。
- Aは5個/時でしか製造しない
- Cは5個/時のフルパワーで製造する
- Dはp2しか製造しない
これらを行うことで、
- p2の製造能力は5.0個/時
- p2の発注を捌くには60時間かかる
- Aは在庫を作らない
- B1は在庫を作らない
- B2は在庫を作らない
- Cは在庫を作らない
- p1の在庫は作らない
フルパワー製造と制約を意識した製造に対する考察
上記の話を表にまとめると以下のようになる。
| 項目 | フルパワー製造 | 制約を意識した製造 |
|---|---|---|
| p2の製造能力 | 2.5個/時 | 5.0個/時 |
| リードタイム | 120時間 | 60時間 |
| Aの在庫量 | 2,040個 | 0個 |
| B1の在庫量 | 120個 | 0個 |
| B2の在庫量 | 420個 | 0個 |
| Cの在庫量 | 300個 | 0個 |
| p1の在庫量 | 420個 | 0個 |
この話の重要なポイントは、
会社全体の機械をフルパワーで製造したほうがp2の製造能力は下がり、リードタイムも悪化してしまう
ということである。そして、
フルパワーで製造してしまうほうが余計な在庫を持ってしまい、在庫コストも発生する
ということである。したがって、ボトルネックを最初に特定し、そこから逆算ですべてを考えろ。というのが、制約理論の本懐である。
非ボトルネックの非経済性
ここには、もう1つの学びがある。
ボトルネックの処理能力を超えて、非ボトルネックを働かせるな。休ませろ。
ということである。
p2の製造ラインのみを取り出して考える。この時、Aを20個/時のフルパワーで製造する。しかし、Cが5個/時でしか製造できないため、Aは15個/時で在庫を作り続け、在庫の管理コストが発生し、非経済的になる。
また、フルパワーで製造した場合の、Dにかかわる部分だけを取り出してみる。Dは、B2から入ってきた部品とCから入ってきた部品から、p1,p2を製造している。今、p2が300個欲しいというオーダーである。しかし、B2を稼働させたことにより、 Dの稼働が3.5個/時食われ、p2の製造が減速している。
この根の深いところは、 もともとp2を製造する分においては、Cだけがボトルネックであった。しかし、非ボトルネックであるB2を稼働させてしまうことにより、非ボトルネックであったDまでボトルネック化してしまった。 もちろん、もっと精密に制御し、Cを優先するなどの処置を行えばこれらは起こらないだろう。しかし、結局B2が在庫を抱えることは変わりなく、在庫コストが高くなる。
したがって非ボトルネックを無暗に動かすことが、さらなるボトルネックを生み、問題を発生させることがある。 ということは留意しなければならない。
ボトルネックの解消法
p2を製造するうえで、Cの5個/時という製造能力がボトルネックになることが分かった。これらはどのように解消すべきか？ということもザ・ゴールには書かれている。
- ボトルネックの時間の無駄をなくすこと
- ボトルネックの負荷を減らして生産能力をあげること
例えば、本文ではボトルネックの機械は、人を手厚くあてがい稼働が止まらないように調整していた。また、ボトルネックの機械に入る前段階で検品を行う。ということも書かれていた。これは、すべてがボトルネックに支配されているため、ボトルネックの製造部品を1つも無駄にしないため、先に材料の不良を取り除くことで安定した製造を進める例が書かれていた。ほかには、ボトルネックの仕事を外注に出す。古い工作機械で同様の作業を並列して行う。処理工程や製造方法を変えることで、そもそもボトルネックで処理しなくて済むようにする。といった工夫が書かれている。
リードタイムに関する対処法
ザ・ゴールを読んで、自分が面白かったし、納得した話が
優先度の変更はリードタイムの悪化により起こり、現場が混乱し、さらにリードタイムが悪化する
ということ。例えば、1つの製造に10日間かかるとする。作業を始め、3日目に要求が変わり、別の作業を行って完了する。そこで、もともとの作業に戻るわけだが、作業手順を思い出したり、機械のセットアップを変更する必要があり、さらに9日間作業する。そのような切り替えにより、コストが発生して、もともと10日間の作業予定が12日間に変わってしまう。これは、逆に考えると、もともとの作業期間が3日間であれば、別の作業を差し込まれることなく、作業が遅延することはなかったわけである。そう考えると、1つの作業に長期間ロックされる。つまりリードタイムの長い作業ほど、優先順位の変更が走り、外からの力により作業を中断させられ、さらに遅延が起きやすい。というとても納得できる内容であった。したがって、リードタイムを短くすべきである。というのは1つ価値のある指針であると感じた。
本文には、リードタイムの削減にも言及しており、
「バッチサイズを小さくする」
ということが書かれている。バッチサイズとは一度に処理する量のことであり、これを小さくすることを考える。工場に資材が入ってから完成品として出ていくまでの時間は4種類に分類できる。
1.「セットアップタイム」・・・機械や装置などのリソースの準備に必要な時間
2.「プロセスタイム」・・・実際に処理に必要な時間
3.「キュータイム」・・・処理をするリソースの前で列を作って待っている時間
4.「ウェイトタイム」・・・完成品を組み立てるときにほかの部品が来るのを待っている時間
ザ・ゴールの漫画版では、リードタイムの短縮のためにバッチサイズを半分にすることを実施しようとする。
どの部品でもセットアップや処理に必要な時間は短くキュータイムとウェイトタイムが長いそうだ
(中略)
バッチサイズを半分にすれば各バッチのプロセスタイムも半分になる
同じようにキュータイムとウェイトタイムも半分になる
つまりリードタイムが圧縮され仕掛かりの待機時間が半分になることでオーダーの生産ペースがあがるんだ
この想定にはおそらく誤りがある。そんな工作機械はバッチ処理にメリットがないからだ。例えば、10個を1つのバッチとして、10時間(プロセスタイム)で処理できる機器があるとしよう。では、それを1つのバッチ5個として使用した場合、処理時間が5時間になる。ということは考えにくい。仮に、そういうことができるのだとしたら、常に1個ずつ処理すれば、1時間で処理できる。そっちのほうが確実に性能がいい。だから、それはバッチにしている意味がそもそもない工作機械であり、現実的ではない。仮に存在するとすれば、10個のときは10時間であるが、5個にしたとき8時間で処理できる工作機械である。バッチとして最大の処理速度を出せるように設計されているはずである。
ただ言わんとしていることはわかる。仮に納品物が5個の場合、10時間で10個という処理性能を捨て、8時間で5個という処理を選ぶほうが、2時間作業時間が増え、その分、別の仕事を請け負えるので、そっちを選べ。ということである。
会計との摩擦
ここまでくると、なぜ制約理論を用いて製造しないのか？ということに疑問をもつかもしれない。しかし、会計的には、制約理論を用いて製造したほうが純資産へ悪影響を及ぼす。
まず、ある程度、会計の知識が必要となる(私も若干あってるかは自信ない)。会計上、原材料や、仕掛品、完成品の在庫は資産として計上される(厳密には異なるが簡単のため)。フルパワー製造の場合、やたらと仕掛かり品を作るし、先ほどの例では必要のないp1という製品の完成品在庫も作っていた。そして、それに伴って、原材料も多数在庫しているだろう。しかし、一方で制約を意識した場合、非ボトルネックはあまり稼働させてはいけない。そして、仕掛品や完成品在庫も最小限になる。しかも、制約を意識した製造のほうが、原価が高くなる傾向にある。先ほどのリードタイムの例のように、10個同時に処理をしていたものを、5個同時に処理をするようにすると、機械へ部品を搬入する手間が2倍になり、人件費も多くなることが考えられる。このようにリードタイムは短くなるかもしれないが、1つ1つの金銭的コストで考えると高くなっている場合がある。したがって、売り上げを多く作っているかもしれないが、売上げに対する利益率は悪い場合がある。
そして、純資産は、利益・完成品在庫・仕掛品・原材料の総和で計算される。これらを踏まえると、フルパワー製造のほうが、制約を意識した製造より利益は少ないかもしれない。しかし、多数の原材料・仕掛品・完成品在庫を持つため、フルパワー製造のほうが、制約を意識した製造より純資産が多くなる。というカラクリがある。したがって、会計的に正しい(純資産が多くなる)方向へ製造しようとすると、フルパワー製造してしまう。ということになる。しかも、製造した1個当たりのコスト感でみれば、フルパワー製造のほうが安い。 この辺りは、小説版ではひと悶着あるが、漫画版ではカットされている。
制約理論の誤謬
ザ・ゴールは副題として、「企業の究極の目的は何か」と題されている。この答えは、「儲けること」である。したがって、あくまで売り上げを最大化することである。生産能力を最大化することではない。そのために「時間当たりの売り上げ」の最適化を行う。 これを間違ってはいけない。
例えば、フルパワー製造の場合、p1は3.5個/時、p2は2.5個/時である。制約理論を意識した製造の場合は、p1は0個/時、p2は5個/時である。これで本当に良いのか？答えは良い。である。それは、この問題設定の場合、極論的にはp1を製造しても売り上げにつながらないから。である。でも、現実問題としては、p1の発注も入っているだろう。それは、そのような問題設定として、解けばよい。というだけである。あくまで、売上のある製造に対し、それを最短で納品するための手段として、ボトルネックをベースに最適化する手段が制約理論の肝である。
エクストリームプログラミングにおける制約理論
エクストリームプログラミングにおける制約理論は、原著における正確な制約理論ではない。と私は認識している。それは、制約理論の根底にある「時間当たりの売り上げ」を最大化していないからである。どちらかというと、「最大流問題」に近い。
最大フロー問題（さいだいフローもんだい、英: Maximum flow problem）または最大流問題とは、単一の始点から単一の終点へのフローネットワークで最大となるフローを求める問題である[1]。単にフローの最大値を求める問題と定義されることもある。最大フロー問題は、より複雑なネットワークフロー問題である最小費用流問題の特殊ケースと見ることもできる。
確かにボトルネックを見つけ、それに対して、改善を行い、出力のスループットを上げる。という行い自体は、制約理論、もしくはザ・ゴールのアプローチに近い。しかし、売上に焦点を置いていないことを考えると、それは異なる印象がある。
アジャイルの暗黙のビジネス上の価値
このあたりで、私は何かしらの気持ち悪さを感じ始めた。
アジャイルはソフトウェア開発の手段であり、売り上げを作る手段ではない。
という当たり前のことである。例えば、スクラムガイドには、以下のような記述がある。
開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。 これは多くの場合、プロダクトバックログアイテムを1日以内の小さな作業アイテムに分解することによって行われる。 これをどのように行うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない。
そう。スクラムは、プロダクトバックログアイテムを価値(売り上げ)のインクリメントにする方法は教えない。
エクストリームプログラミング(XP)はソーシャルチェンジである。
XPとは、ソフトウェアを一緒に開発する人たちが高みに至るまでの改善の道である。
XPは、ソフトウェア開発の制約に対応するための方法論である。
XPはリードタイムを短くリリースするためのソフトウェア開発の方法論である。
やはり、よくよく考えると気持ちが悪いと思い始めた。では、なぜ売り上げにつながるわけではない。という開発手法を選んで私たちは開発するのだろうか。
XPは、あいまいで急速に変化する要件に対応する。XPは今でもこうした状況に適している。これは好都合といえるだろう。現代のビジネス世界における急速な転換に適応するには、要件を変化させる必要があるからだ。
VUCAの時代とはよく言われるが、不確実性の高く、流れの速い世の中である。その中で、リードタイムの短い開発手法により、世の中についていくことが大切である。ということらしい。このあたりで、ある程度、自分の中で言語化出来て、「牧歌的すぎる考えではないか？」ということだった。
おそらく、「機能開発のリードタイムが短い」は「ビジネスの成功」において十分条件に過ぎず、必要条件ではないのではないか。という推察である。例えば、「ビジネスが成功した理由として、ビジネスニーズへリードタイムが短く機能開発できたからである」は成り立つと思われる。しかし、逆に「ビジネスニーズへリードタイムが短く機能開発できたから、ビジネスに成功しました」は必ずしも正しくない。これはなぜそう思ったかというと、「そもそもビジネスニーズを正確にとらえることが簡単であれば、全員がビジネスとして成功しているはずである」ということである。そう。そもそも、ビジネスニーズを正確にとらえる力がないのに、そのビジネスニーズに適応する力があったとしても、ビジネスの成功はないだろう。ということである。その意味で、実はアジャイル開発手法というのはソフトウェアビジネスのための開発手法として、牧歌的すぎるのではないか？ と、今回調べて思った。これもある意味で当たり前のことを書くが、アジャイル開発はソフトウェア開発手法に過ぎない。ビジネスの成功を目指して開発された手法ではない。しかも、それはビジネスの成功の必要条件ですらない。というあたりに自分の認識は落ち着いたが、何かしら自分の中で感じるものがあった。