ソフトウェア開発のスケーラビリティ - 超ウィザード級ハッカーのたのしみ

人月あたりの生産量、１kステップあたりのバグ数みたいな指標は便利なのでよく用いられる。私も、

で単位時間あたりの動くコードの生産量といった数をおいた。単に数値を数値で割っているだけだから、これらを定義することはできる。

しかし、開発されるコードの行数が人月に比例するか・バグ数がコードの行数に比例するかというと当然そんなことはない。人が２倍になっても開発能力は２倍にはならないし、時間が２倍になったからといって２倍のコードがかけるわけではない。他の人と同期を取るため、他のコードとの整合性を取るために効率は落ちる。開発規模が２倍になったからといって、バグの数が２倍になるわけではない。コードが巨大になって複雑になればバグは増える。

別にXXXあたりという指標を使うのが良くないとは思っていない。私も使っているし、簡単のためにエイヤと近似するのは普通のことだ。感覚的という以外の根拠はないが、２倍とか３倍とか同じ程度のオーダーだったら線形性の仮定もそんなに悪い近似ではない。

しかし、１０倍とか２０倍になったときに同じ尺度を使うのは無理だ。１人で１０日かかるものを、１０人でやっても１日でできるわけがない。1日で100行のプログラムを書けた人が、10000行のプログラムを100日で書けるかというと難しい。

人間が増えることによる複雑化とコードが大きくなることによる複雑化は異なるものだ。私は視覚的に前者を水平方向、後者を垂直方向と呼んでいる。*1

ソフトウェアは一般には水平方向・垂直方向の拡大に対して線形にスケールアウトしていかない。これをどうやって線形に近づけようか、スケーラビリティをもたせようかと多くの人が悩んできた。

その結果得られたのが、プログラミングパラダイムやプログラミング言語や開発ツールや開発プロセスといった人智である。

構造化プログラミング・オブジェクト指向プログラミング・関数型プログラミングといったプログラミングパラダイムによってソフトウェアは部品化され、部品ごとの独立性（直交性）が高まり、分業しやすくなったり、機能追加しやすくなった。設計というのはコードにスケーラビリティを持たせるためにするものだ。優秀な人の書いたコードはスケーラビリティがある。プログラミングパラダイムをサポートする言語は、パラダイムの導入を簡単にしたり強制したりするので、凡庸な人でもある程度はきれいな設計になる。

ガベージコレクタによって、人類はメモリ管理から開放された。メモリ管理はスケーラビリティを損ねるものであった。自分が確保したメモリであってもすべて開放するのは骨が折れる作業だが、他人が確保したメモリはなおさらだ。メモリリークしていたとしたら、規模が大きくなるほど場所を特定するのは手間がかかる作業となる。

開発ツール・開発プロセスによって人間というボトルネックが少し解消されたり、人間同士の同期を取るのが速くなる。

昔と比べると、大規模なプログラムが速く開発できるようになっているはずだ。開発を効率化したかったら、賢くない人の経験ではなくて、天才達の成果に頼るのが正しい。

天才達の知恵を借りたとしても、ボトルネックになっているのはやはり人間だ。プログラミングは知性の限界への挑戦みたいなものだから。

したがって、身も蓋もない事実だが、開発を効率化したければ人間をスケールアップするのがもっとも合理的だ。つまり、賢い人に札束を積んでやってもらうということ。高々１０倍の給料で、１００倍の生産性を持った人が雇えるのだ。給料１００倍なら生産性は１００００倍だ。

そんなことされたら、私の仕事がなくなるかもしれないが、私が経営者ならそうする。おそらく上手く言っているところはそうしている。日本のすべての経営者がこれに気づいて、給与水準のインフレが起これば私の報酬も上がるのだけれどなあー。