もう少し「システム」と「ツール」の話を続けます。
丁度CNETに梅田さんのゲストブロガー石黒邦宏さんが、100万行のソフトの作り方(1)(2)を書いています。
100万行、業界用語？で1000K。（20年以上前のことでかなり記憶が不確かですが、銀行のオンラインシステムが3000K程度だったと思います。これを大体300人位の体制で開発していたと思いますので、石黒さん達の体制を45人と仮定すると丁度生産性が2倍程度向上していることになります。）
今まともなアプリケーションシステムを作ろうと思えば、この100万行程度のコードが必要です。
これを昔の銀行システムのように、一から設計して、2年後に完成してみなければ最終形が見えないのではなく、石黒さんが書いているように、
「エンジニアはひたすら開発を行ないます。そして、開発したコードはエンジニア相互のレビューに廻されます。相互チェックシステムというわけです。ソースコード管理は今ならフリーソフトのCVSを使うか、お金に余裕がある場合は商用のソースコード管理ソフトであるクリアケースを使うのが一般的でしょう。毎日タグと呼ばれる印をつけて（これはいつでも過去の状態に戻せるようにするため）、デイリービルドを作成し、テストに廻します。このサイクルはほぼ毎日行なわれます。」
日次単位で完成品を更新していく方法で、日々実現されるべき機能を目で実際に確認しながら開発していく手法こそ、アプリケーションオリエンティッドの設計に直接つながるきわめて重要な方法です。ツールや部品をいかに組み合わせたり応用していくかを考えて設計するのではなく、直接実現されるべき機能を目の前に用意して、これをそのままリファインさせていけばいい。
そこで実現されるものは、量が質を生むがごとく、100万ステップを越える毎に質的な変化が起こり、その使いやすさは格段に向上します。
過去のシステムに比べて、今のシステムのほうが格段に使いやすいのは、コンピュータの能力の進歩に裏付けられた圧倒的なコード量の違いから来ているのは明らかです。 KAI