今回は大規模システムの開発のお話です。
ただし、技術的な難しさを論じるのではなく、大規模システムを経済的に作るには？という視点でいきたいと思います。

システム開発のコスト

システム開発のコストに一番大きく影響するのはステップ数です。 と、言うと反射的に違う！といいたくなるのですが、落ち着いて考えてください。 1,000stepのプログラムと1,000,000stepのプログラム、開発にコストが掛かるのはどちらでしょう？ そう、ステップ数というのは確かにシステム規模と強い正の相関性を持ちます。 次にコストに影響するのは開発に関わる人員の質だ、とジェラルド・ワインバーグ氏が論文で述べています。 このあたり、詳しくは ソフトウェアエンジニアリング論文集80'sで読むことが出来ます。

大規模システムのソースのうち、その多くは単純で退屈な、しかし分量だけはめいっぱいある、そんなソースです。
システム開発コストを抑えるためには、この人海戦術的な部分をいかに効率よく作り上げるかが重要です。 つまり、まずは一番人手の掛かっている部分でざっくりとコスト削減しようという考えです。
システムの難しい部分はその全量からすればごく一部です。そこの部分の作業量を削ったところでコストへのインパクトは少ない。 それよりは、頭数で大量生産的に製造しているような箇所の生産効率を考えるほうが実りが大きいわけです。

プログラミングの効率と経済の稿ではバベッジの原理について解説しました。 「労働を分解し、単純労働を分離して安い労働力をこれにあてる」という手法です。

システムアーキテクトは、もちろん顧客の提示する要件を満たすようにシステムを設計することが 第一に求められるでしょうが、当然ながらコストについても考えなければなりません。
そうなると、バベッジの原理なりを用いてコスト削減を図る必要があります。 これを念頭においてソフトウェアのフレームワーク的な部分を選定あるいは設計しなくてはならないのです。

単純労働の分離

システム開発の単純労働の分離は難しい課題です。 しかしながら、システム開発の経済性という強い要求により、 ここに答えを見出そうと各社がさまざまなフレームワークを提唱しているわけですね。

ビジネスイベントにいって各社のブースを回ると、この単純労働の分離について 盛んにアピールしていることが見て取れます。
これらのプレゼンを見ると、まるでアーキテクト不在でもシステムが魔法のように仕上がるような風ですが、 そんなことはありません。実態は設計に精通した人が少なくても済むような 開発ツール、フレームワークなだけなのです。 0では駄目なことはIT業界の人であればうなずけるところでしょう。

単純労働の分離ということは、逆にアーキテクトが難しいところを一身に背負うことに他なりません。 単純労働側はあまりものを考えなくても作業が出来るように、そのための苦労をアーキテクトが 肩代わりしているわけです。

分離のための道具

オブジェクト指向はこれらの要件を満たすための道具として優秀です。 1996年のJavaの発表以来、C#も含め、単純労働の分離のためにオブジェクト指向は 積極的に活用されてきました。いまや、プログラマの必修事項となりつつあります。

このオブジェクト指向の効能は、近年の大規模開発のインフラとしての 普及を見て分かるとおり、相当に高いものです。
GoFに代表されるデザインパターンはオブジェクト指向の活用法の道しるべとなり、 単純労働の分離をさらに後押ししてくれます。

クラスの使用は簡単で、単純労働の効率の向上に寄与してくれます。
しかし、アーキテクト側の立場でのオブジェクト指向は難解で、相当の修行を必要とします。 簡単に使えるようなクラスを設計することの難しさは筆舌に尽くしがたいものがあります。
この非対象性は単純労働の分離を象徴しているかのようですね。

IDE(等号開発環境)の普及、および高機能化も単純労働の分離に大きく作用しています。 コンパイラレベルでの警告も随分と高度化し、コーディングの段階で事前にバグとなりそうなものを 排除してくれるようになりました。これは、作業に従事する人員の学習を助け、ハードルを下げるものとなっています。 ヒューマンエラーの排除としても大きく寄与していますね。

2007年現在、スクリプト言語が熱を帯びてきていますが、これもまた、 単純労働の分離のための効果的な施策とみられているためでしょう。
Javaも6になってスクリプト言語との連携機能が盛り込まれました。 こういったインフラ整備がどのように萌芽するのか、今後注視しておきたいところです。