お盆休みに入る前に、何か良い本はないかと探していたところ上司からこの本を勧められた。
内容は、工場における生産をTOC(制約条件の理論)を用いて改善していくもの。物語形式でドキドキハラハラしながら学べるビジネス本です。
制約条件の理論 - Wikipedia
自分は知りませんでしたが、非常に有名な本とのこと。
ただ読んだだけでは勿体ないと思ったので、TOC(制約条件の理論)をwebサービスに当てはめるとどうなるか？をやってみました。
素人が考えているので、誤りもあるかもしれませんがご了承ください。
1. 本の内容を簡単に確認
内容を簡単に確認します。詳細はwikiや本書をご確認ください。すでに知っている方は読み飛ばしてください。
基本的に、工場でモノを作って販売するビジネスプランが前提です。
そして、継続的にお金を儲けるための指針を示しています。
その際の指標になるのが、下記の3つです。
「スループット」「在庫」「業務費用」
これらに対して、「スループットを増大させる」「在庫を減らす」「業務費用を減らす」といったことを目指し、なかでも「スループットを増大させる」に注目します。
「在庫」「業務費用」を下げれば、儲けるために使うお金（コスト）は減り、儲けは増えますが限界があります。
「スループット」を増加させることに理論上限界はありません。これが、「スループット」に注目する理由です。
では「スループット」を増大させるためには何を行えば良いのか？
本書では、スループットを決定する「ボトルネック」に注目し、これを発見・活用することを提言しています。
「ボトルネック」を活用していく話はさらに続くのですが、詳しくは本書をご覧ください。
ここからが本題です。TOC(制約条件の理論)をwebサービスに当てはめて考えていきましょう。
2.1 前提
先に前提だけ確認しておくと、
とします。
2.2 指標はそのまま使える？
工場でモノ作って販売しようと、webサービスで利用分だけ料金もらおうと、基本的な目的は「お金を稼ぐ」こと。
この点において、webサービスにおいてもTOC(制約条件の理論)が使えそうな気がします。
TOC(制約条件の理論)が掲げる3つの指標が、webサービスにおいて何に当たるか考えてみると、
スループット」：単位時間あたり全ユーザーの合計利用料金
在庫：なし
業務費用：人件費、クラウド利用料金
といったところでしょうか。どうやらこれらの指標はそのまま使えそうです。
ポイントとしては、当然ながら在庫がないことですね。
仕掛かり中の新機能や機能改善は在庫になるのか？とも思ったのですが、これらがwebサービスに反映されたとしてスループットが上昇に直接寄与するとは言えないので、在庫にはならなそうです。
ともかく、お金を儲けるために「スループットを増大させる」ことに注力しないといけません。TOC(制約条件の理論)が掲げることそのままですね。
次のステップとして「スループットを増大させる」ために、スループットを決定づける「ボトルネック」を見つけ出す必要があります。
ちなみに、本書において最初のボトルネックは工場内のある工作機械でした。物理的なボトルネックなのでイメージしやすいです。
では、webサービスの場合、スループットを増大させることのボトルネックは何になるのでしょうか？
基本的には市場がボトルネックになると思います。
スループットのボトルネックになりうるものには下記の3つがあります。
物理的制約：例）とある工作機械の処理速度、原材料が届く頻度
方針的制約：例）社内手続き(自社、顧客含め)、評価指標
市場制約：例）需要があるかどうか
このうち、物理的制約はwebサービスにおいてほとんど発生しないでしょう。AWSやGCPなどを使用してれば、サーバーの増強はいくらでもできます。
次に、方針的制約ですが、webサービス利用者が個人の場合はほぼないでしょう。しかし、webサービス利用者が法人の場合、利用側の社内手続き等で時間を要し、スループット増大を妨げるボトルネックとなりえます。
最後に市場制約。これは、常にボトルネックとなるでしょう。webサービスの場合、基本的にいつでも利用ができることが想定されますから、「需要 ＜ 供給」が常に成り立つと捉えることができます。需要の有無こそがボトルネックという訳です。
以上をみると、まず対処できるボトルネックは市場制約しかありません。
物理的制約は無いと考えていいと思います。
方針的制約は、これはどちらかといえば利用側の問題でもあると思われます。webサービス提供者が手を出しにくい領域にあります。
そのため、ボトルネックへの対処としては、需要を喚起させるためのマーケティング戦略であったり、市場制約を作っている原因であろうwebサービスの改善などになると思います。
3. 一旦、小まとめ
以上のように考えると、本書が紹介したような物理的制約はwebサービスではほぼなく、スループット増大を妨げるボトルネックは常に市場にあると思えます(割と当たり前な感じ)。
「物理的制約にどう対処していくか」は結構面白いのですが、それが活用できないのは悲しいですね。。。
しかし、部分的になら使えそうです。
それが次です。
4. 物理的制約への対処は開発に応用できそう。
あくまで、開発に限定した場合です。
webサービス開発において、開発にはある程度のステップを踏むと思います。
例を挙げるなら、以下のようなものでしょうか。
仕様を決める→実現方式を決める→実装する→テストする→本番環境へデプロイする。
これを工場での製造ラインと同じように見れば、物理的制約への対処方法がwebサービス開発にも応用できるはずです。
ただ、1点注意しておくと、ここでの増加させようとするスループットは「単位時間あたりにいかにお金を稼ぐか」ではなく、「単位時間あたりにいかに新機能・機能改善を本番環境へ反映させる」になります。
その点、TOC(制約条件の理論)からかけ離れたものになります。
しかし、やることは同じです。全体のスループットを決めるボトルネックを見つけ、それを活用したり、ボトルネックを非ボトルネックにすることです。
ボトルネックへの対処例を挙げるなら、次のようなものが考えられます。
・テストがボトルネックであるのなら、自動テストを導入して、テストを非ボトルネックにする。
・実装がボトルネックなら、常に実装を行えるように、実装タスクがある程度積まれた状態を維持するようにする。
今に始まった話ではありませんが、これらの取り組みがスループット増大に期待できそうです。
TOC(制約条件の理論)の物理的制約への対処が、webサービス開発にも通じる点です。
4. まとめ
名著「ザ・ゴール」を読んだので、本書の中で扱っている内容が、webサービスにも応用できるか検討してみました。
前提としているビジネスモデルが異なるため、完全に本書に沿った応用は難しそうですが、部分的にはwebサービスにも利用できそうです。
気になった方は、一読してみてください。(ちなみに本書は結構分厚いです。読み切るまで多分10時間くらいかかりました。)
photo credit: P. Marioné lost souls via photopin (license)
