blog/2014-10-05-reading_phoenix_project.md at 2e579de6a6195848d4d7df154984f41932c7a7f5

9.6 KiB

Raw Blame History

title

author

date

wordtwit_posted_tweets

wordtwit_post_info

tmac_last_id

categories

『the DevOps 逆転だ!究極の継続的デリバリー』を読む

kazu634

2014-10-05

a:1:{i:0;i:1787;}

O:8:"stdClass":14:{s:6:"manual";b:1;s:11:"tweet_times";i:1;s:5:"delay";s:1:"0";s:7:"enabled";s:1:"1";s:10:"separation";i:60;s:7:"version";s:3:"3.7";s:14:"tweet_template";s:126:"ブログに新しい記事を投稿したよ: 『the DevOps 逆転だ!究極の継続的デリバリー』を読む - [link] ";s:6:"status";i:2;s:6:"result";a:0:{}s:13:"tweet_counter";i:2;s:13:"tweet_log_ids";a:1:{i:0;i:1787;}s:9:"hash_tags";a:0:{}s:8:"accounts";a:1:{i:0;s:7:"kazu634";}s:4:"text";s:145:"ブログに新しい記事を投稿したよ: 『the DevOps 逆転だ!究極の継続的デリバリー』を読む - http://tinyurl.com/n72c9t8";}

528527127428096001

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Winを読みました。これまで Agile や Dev/Ops と呼ばれる潮流について正直理解できていなかったのですが、これを読んで理解できたように感じます。要はものづくりの現場の改善活動の手法をITの分野に拡大していく潮流だったのですね。

作中では『ゴール』で描かれている Theory of Constraint について度々言及されているのだけれど、製造業のものづくりの現場の改善活動の輪を IT に拡大していこうという活動として捉えられていました。この視点がこれまで自分にはありませんでした。Wikipedia によれば、Theory of Constraint とは

制約条件の理論は、収入の割合がひとつ以上の制約プロセス、すなわちボトルネックにより制限されているという前提を基礎にしている。ボトルネックプロセスにおけるスループット (生産率) の増大によってのみ、全体的なスループットの増大が可能になる。効果的なTOCアプローチの実施において鍵となるステップは次のとおりである。

制約を特定する (ボトルネックはそのプロセスの前の製品在庫により識別される)

その制約を徹底活用する (その有用性と効率性を増やす)

ほかの全プロセスをその制約プロセスに従わせる (ほかのプロセスはボトルネックに奉仕する)

制約を底上げする (もし必要なら、恒久的にボトルネックの許容量を増やす)

すすぎと繰り返し (行動をとると、ボトルネックは移りゆき、さらなる注意が求められる)

とあります。ボトルネックを特定し、それを最大限活用すること、そうすることでボトルネックが変わっていくので、また同様に対応を続けていくこと。これが Theory of Constraint のステップなのだそうです。この本を読んでいくと、IT系の人間がこれからの会社を支える重要なキーパーソンというかボトルネックとして描かれている。これが全てということではないだろうけれど、自分の進む道を考える一つの契機になります。

同じ系列の本として、トヨタのカンバン方式を IT の現場に持ち込むことを意図した書籍をこれから読もうと思います。