前回、ソフトウェアの開発には水平方向・垂直方向のスケーラビリティがあると軽く触れた。水平方向のスケーラビリティとは人を増やせばそれだけ開発能力が向上するということで、垂直方向のスケーラビリティとはソフトウェアの規模が大きくなっても開発速度が逓減していかないことだ。今回は垂直方向のスケーラビリティについてもっとよく考えてみようと思う。
ソフトウェアは大規模で複雑になれば難しくなる。1,000行のプログラムを１日で書けたとして、100,000行のプログラムを100日で書けるかというと絶対に無理だ。なぜならば、プログラムというのは全体に渡って整合性が取れていなければならないからだ。スタイルは統一されていなければならない；名前は衝突してはいけない；どこかで確保したリソースはどこかで開放せねばならない；同じ変数を共有しているときは意図しない書き換えがないことを保証しなければならない；マルチスレッド・プロセスなら同期を取らなければならない。大規模になればなるほど整合性を保つのが困難になる。何も考えずに規模を膨らましていくと整合性が保てなくなって破綻する。
以前、単位時間あたりの生産量の式を考えたけれど、これは単純化した話だ。バグの混入を減らせば生産性が上がるといって、エイやとバグと丸めてしまっている。規模が多いなることによる混乱だとかも以前の計算ではバグに含んでしまっている。
優れたプログラマが優れているのは規模が大きくなっても破綻させないこと、規模が大きくなってもそれによる混乱を引き起こさないことです。
では、規模が大きくなったらどれぐらい大変になるのかをざっくり計算してみようと思う。
規模Nのプログラムを開発するのにかかる労力をWを考える。すでにxの量のコードがあって、そこにちょっとの変更としてdxのコードを加えるとする。このとき、すでにあるコードのうちrの割合の分だけ調べたり・書き換えたりしなければならないとし、単位規模あたりのコードを作る労力をwをする。全体の労力Wはちょっとの変更の労力の積分となり、以下で表される。
プログラム開発の労力に、規模の自乗に比例する項が現れている。これが前述しているコードの整合性を保つための手間である。ある程度Nが大きなればこれが無視できなくなる。さらにNが大きくなれば大きくなるほど、この項は急増していき負担が増大していく。
コードに垂直方向のスケーラビリティをもたせるためには、なんとかしてかこのコードの整合性を保つための手間を減らさなければならない。
次回はどうしたら良いのかを考えてみたいと思う。
