この文章で言いたいこと
この文章ではソフトウェア開発組織のスケーラビリティを「ソフトウェア開発組織メンバを増やせる」と定義する。またソフトウェア開発組織とは企業体のことではなく、「あるプロジェクト、プロダクトに関係する組織」と定義づける。
結論から言うとソフトウェア開発組織はスケールしない。ソフトウェア開発組織をスケールさせるという発想は幻想である。あなたはソフトウェア開発組織はスケールしないことを前提に計画を立てる必要がある。
なぜスケールさせる必要があるのか
例えば経営者の構想、例えば他社が追従できない高機能などで大規模なソフトウェアを開発をする動機があるから。大規模なソフトウェアを開発するには大規模なソフトウェア開発組織が必要となり、それにはソフトウェア開発組織をスケールさせる必要がある。
まーこの時点で何でそんな大規模なソフトウェアを開発しないといけないの？という根源的な疑問はあるものの、会社の偉い人がやりたくてやることなので仕方ない。
ここで問題なのはソフトウェア開発組織のスケーラビリティは指数関数であること。2倍の規模のソフトウェア開発をする場合、かかるリソースの量は2倍以上になる。これがソフトウェア開発の本質であり、ソフトウェア開発組織のスケーラビリティと大きな関係がある。（察しのいい人はこの時点で何が言いたいかわかるよね？）
リソースという限界
ソフトウェア開発組織をスケールさせる際に限界となるのはリソースの問題である。スケーラビリティは指数関数で効いてくるため、簡単にリソースの限界に到達する。
一般的な企業でよくあるのはプロジェクトの予算の枯渇だろう。開発組織をスケールさせる形で大規模なソフトウェア開発をしようとすれば、システムの規模に対して指数関数で予算が増えていく。このような状況では簡単に予算が枯渇するのはわかりきっているだろう。ただ実は問題なのは次に上げる事例の限界の到達の仕方である。
2019年7月、みずほ銀行の新しい勘定系システムの「MINORI」が稼働された。開発期間20年、総工数35万人月、総工費4000億円の世界最大のプロジェクトである。このプロジェクトの歴史的快挙は、人類のソフトウェア開発のスケーラビリティの物理的限界に到達したことである。断言してもよいがこれ以上大きな開発組織のソフトウェア開発は不可能であり、今後も現れない。現れたとしても指数関数で規模が大きなものはないだろう。
みずほ銀行の「MINORI」が示したのは、これ以上大きくしようとしても人類のエンジニア人口の限界があるため、これ以上規模が大きくできないデッドラインがあるということである。総工費4000億円を10兆円にしたところでスケールしない。
「MINORI」の場合は最終的に集める開発人員の質は目をつぶったと考えられるが、人類で流通しているエンジニアのリソースには意外と低い限界があり、特にモダンな開発がしたい場合については、その何十分の一程度しかエンジニアはいない。たとえ大企業でも先進的な技術が扱えるエンジニアは思ったほどとれないだろう。これはソフトウェアエンジニアの能力が適正に強力に依存するため、人類の何％がソフトウェア開発できるかは最初から決まっているためである。
誰にとっても優秀な開発チームはたくさん作れない、これが現実である。
札束で殴れば解決するという甘い考えは捨て、保有するリソースで指数関数と戦わなければならないのがソフトウェア開発である。指数関数との戦いには資本の大小は関係がない。これらのスケーラビリティの限界は小資本には関係ないと思われがちだが、指数関数の世界なので小資本もこれらのスケーラビリティの限界とは隣り合わせである（指数関数では予算が4000億円なのと100億円なのはそれほど大きな差ではない）。
スケールが不要な世界
ソフトウェア開発組織がスケールしないという現実があるなら、ソフトウェア開発の大企業は存在しない、またはスケールできずに崩壊状態であると考えられるが、それも事実ではない。ソフトウェア開発の大企業の中でもひとつのプロダクト、サブプロダクトのサイズには限界があり、それは「分割統治」されている。
いわゆるGAFAであっても「MINORI」の事案で示されたソフトウェア開発のスケールの限界の壁をこえたプロダクトはないはずである。企業の開発するソフトウェアは単独では適正なサイズに収め、分割する。大規模なソフトウェア開発は諦める。これが認めないといけない現実である。
都市銀行の勘定系システムと双璧をなす大規模ソフトウェア開発と言えば「車載ソフトウェア」である。トヨタのレクサスだと車載ソフトウェアの規模は「MINORI」と同規模の1億SLOC（ソースコードの行数）である。ミッションクリティカル性についても差はない。それでも恐らくトヨタはレクサスのソフトウェア開発に4000億円もかけていないだろう（そんなことしたら倒産する）。これだけ巨大なソフトウェアにもかわわらずうまくいっているのは車載システムが100～150個と言われるECUに分割され、分割統治されているからである。
とはいえ車載ソフトウェアが「MINORI」と同規模の1億SLOCというのはマジックナンバーになっており、ここが車載ソフトウェアも限界だと思われる。これ以上の大規模化は不可能と判断し、新しいアーキテクチャに移行、規模を縮小する必要があると思われる。
余計な心配はするな
人海戦術が発達してるソフトウェア開発の現場では「このやり方ではソフトウェア開発組織がスケールしない」という発想の人が多いように見受けられるが、余計な心配なのでしなくてよい。一番ベストなやり方をすれば良い。
それより重要なのはソフトウェア開発組織がスケールしないことを前提に、そんな大規模なソフトウェア開発を最初から考えないことだ。
もともとソフトウェア開発組織はスケールしないのだ。