The Goal のコミックス版を読んだ。1時間ちょっとで読めるわりに学びが多かったので自分の整理をしておく。
本書での Goal は、お金を儲けることとしている。具体的には、工場がどうやって今よりお金を儲けられるようになるかということを考えていく。本書で出てくる知識は抽象度が高く、ソフトウェア開発会社にも当てはめられると思っている。本記事では、本書で出てきた概念をソフトウェア開発会社に当てはめたらどういうマッピングになるのかを考察してみた。
まずは重要な用語などを整理する。
Goal は先程述べたように会社がお金を儲けること。お金を儲けられているか評価するための指標として以下の 3 つがある。
- スループット
- 在庫
- 業務費用
スループットは販売を通じてお金を作り出す割合のこと。販売 を通すのがポイント。生産しても売ればければスループットではない。
在庫は販売しようとするものを購入するために投資したすべてのお金のこと。
業務費用は在庫をスループットに換えるために費やすお金のこと。スループットは上げられればよい。在庫と業務費用は下げられるとよい。なぜなら、得られるお金はスループットの結果であり、利益はスループットの結果得たお金から在庫や業務費用を引いたものになるから。在庫と業務費用の区別方法としては、お金を使った結果売れるようなものが残る場合は在庫、そうでない場合は業務費用としていた。
これらをソフトウェア開発会社に当てはめてみる。スループットの 1 例としては、製品の追加開発をしてより多く売れたかどうか。SaaS のようなものを開発している前提で書いている。在庫の 1 例としては仕掛中の機能開発や未リリースの機能やコードがそれにあたる。業務費用の 1 例としては、Github など製品を作るために必要な管理ツールやインフラコストなどが考えられる。スループットを上げるには、機能開発をユーザに届けることを増やす必要がある。そうなると、在庫はなるべく持ちたくない。早くリリースしたい(ユーザに使ってもらいたい)。そうなると、4 keys のようなソフトウェア開発の指標が腹落ちする。リードタイムやデプロイ頻度の指標はユーザへ機能が届けられているかに役立つはずだ。これらが低いと開発の長期化による業務費用の増加や在庫が多くなることで損失を受けていることが明らかである。個人的な一番の発見は。こういったソフトウェア開発の指標が本書を読んで確かに効果がありそうだなと思えたことだった。効果がありそうなのはわかる、けどなんでそうなのかが自分の言葉として説明できなかったことが本書の内容とマッピングさせることで根拠の強いものになった。
また、本書では工場をベースに 3 つの指標を改善していくのだが、工場では需要に対してどれだけ生産能力を合わせてスループットを最大化できるかが重要かと思う。需要に対して、生産する能力が大きすぎてもいけないし(在庫が増える)、小さすぎてもいけないため(想定どおりの売上が得られない)。それに対し、SaaS のようなソフトウェア開発での需要はわからないこともある。プロダクトアウトを実施する場合には需要に関係なく、ひとまず売れるものを作って需要を探しに行くからだ。そのため、大きなスループットを得るためには小さいスループットによる探索を繰り返す。このようなパターンでも結局はスループットの速さを重視すればいいので、本書の指標による考え方は有効だと思っている。速さをだすためには、開発による成果のスコープを可能な限り小さくすればいい。スループットに関わる部分なのでここには時間をかけるべきだ。しかし、これが決まらないと開発ができないので、作るものやそのスコープ検討を複数ラインで展開できているといいと思った。何を作るかの部分はわかりやすいボトルネックだから解消しておいたほうがいいから。この部分を解消できたらあとは各開発チームのプロセスで時間がかかっている部分の解消だ。プロセスを可視化し、チームでボトルネックを解消したらより早く探索が実行できるようになるはず。
開発プロセスのベストプラクティスはこういった理論による背景があるのかなとつながりを考えさせられる良書だった。最近はこういった戦略に関わる部分の話が好きなので良書があればおすすめしてほしい。