会社のビジネス側の皆さんが読まれている名著らしいので読んでみた。 物理本だとすごい厚さらしいが、実際に読んでみると2-3日あれば読み終えることができた。物語調なのでサクサク読める。
読むには読めるのだが、これをソフトウェア開発にどう適用するか、という点はなかなか難しいなと思った。
勿論ソフトウェア開発プロジェクトにおいて、ガッツリ線表が引かれているならクリティカルパスがあるし、クリティカルパスがある以上それ以外の工程がどれだけ頑張ってもプロジェクト自体の短縮にはならないよね、というのはわかる。
ただ、恥ずかしながらしばらくそういったプロジェクトをしていないのと、顧客に売るためのソフトウェア開発をしていない(作った物自体が直接利益に結びつく生産をしていない)ので、「企業の目的はお金を稼ぐこと」と置くと、この本の工場のような計測・改善が難しいと感じた。
どちらかというと「自分たちが実装した機能で、実際に利益に結びつく業務のボトルネックを削減できるか？」という観点が当てはまる気がした。何を作って何を作らないべきか。
一方で、会社の様々な部分に応用が効く理論ではあると勉強になった。
自分の会社は工場ではないものの、読んでいて「これ◯◯/□□の部署のお仕事に当てはまりそう」と思う部分は数多くあった。また本では推奨されていないが、意図的に自分自身の仕事のゴールを部分最適に寄せると「これをやっても自分・自組織の◯◯の改善には影響は薄いな」とかも考えることができそう。
一通り読んで、社内ソフトウェアを開発しているソフトウェアエンジニアとしても、「これをすることで会社としてどれぐらい美味しいのか？」を考えるのは大切だと改めて思えた良い本だった。
同作者から工場ではなくプロジェクトにフォーカスした本も出ているようなのでぜひ読んでみたい。
