scalability

市場でシェアを拡大していっても、サービスを提供する組織のほうが限界を迎える

理想

「あとはセールス/マーケにお金を投下すればいくらでも伸びる」状態にする(=売る活動がボトルネック)

「1億円投資したら、1000万円は利益が出るだろう」と期待されていれば、資金調達もどんどんできる。結果伸びる

あるある

「この機能さえ作れれば需要あるし売れるはずなんだけど、、予算足りない」状態(=作る活動がボトルネック)

資本投下しても実現できるかわからないから、資金調達も簡単ではない

「1億円かけて10%の利益は見込めるんだけど、、30人追加採用しなくちゃいけなくて人件費まで考えたらROI低い」状態(=scalabilityがボトルネック)

あるあるのオーダー

※ 多分数学的には意味のある正しい表現ではないので、比喩としてのオーダー感

機能が増える → O(n!/n)でシステムコミュニケーションパスが増加、O(n)で売上が増加 → 利益率が下がる

人が増える → O(n!/n)でコミュニケーションパスが増加、O(n)で売上や実装速度が増加 → 利益率が下がる

課題

「人数や機能数あたりの」売上を伸ばせば伸ばすほど余裕が生まれて遊べる

そこで、課題を「人数や機能数あたりの売上を伸ばす」に設定してみる

色々ある解決策のうち、有効な一つとなりうる切り口は、dataとarchitecture

dataがあれば、O(n!/n)のコミュニケーションパスをO(n!/n^2)くらいにできる

ある程度は人じゃなくてdataと会話すればいいので

software architectureがしっかりしていれば、10倍の規模でも同じ人数で耐えられたりする

Cloud費用がO(n)で増えるだけなので

(広い意味での)組織 architectureがしっかりしていれば、アウトソースやSaaSを増やして規模に耐えられたりする

コミュニケーションパスがネットワーク状のO(n!/n)ではなく階層化された一方向のO(n^2)くらいに抑えられるので

この話が意味を持つタイミング

小規模な事業活動だと、オーダーなんて話を持ち出さずに議論したほうがよほど精緻

1000万円、1億円の世界まで大規模になってくると、、このオーダー感の議論が意味を持ち始める