読者です 読者をやめる 読者になる 読者になる

ソフトウェア開発のスケーラビリティ

計算機 考察

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

プログラマの生産性の公式 - 超ウィザード級ハッカーのたのしみ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

人月の神話

人月の神話

*1:もしかしたらもっといい呼び方がされているかもしれない。