anti-computer

　
　Waterfall モデルが現実にそぐわないので、小生は、プロトタイプを前提にした RAD ^{（注 1）}を実行している。
　小生が実行している RAD は、おおまかに言えば、以下の体系である。

　（1）現行の画面・帳票をインプットとして、Ｔ字形 ER 図を作成する。
　（2）Ｔ字形 ER図を読んで、「mission critical な event」^{（注 2）}を探し出す。
　（3）「mission critical な event」を入力・更新・照会する画面のプロトタイプを
　　　　作成する。
　（4） [ プロトタイプを作成中に、]
　　　　インフォーマル・データが出てきたら、Ｔ字形 ER図のなかに追記する。
　（5）データ項目ごとに、アトリビュート・リストを作成する。
　（6）画面・帳票ごとに、アルゴリズムの定義表を作成する。

　
　Ｔ字形 ER図が作成された時点で、以下の 3点を確認・検証する。

　（1）再構築の目的（再構築が実現しなければならない目的）
　（2）現行事業の顕在的・潜在的な問題点
　（3）現行事業の顕在的・潜在的な問題点に対する改善案

　
　以上の諸点を加味して、Ｔ字形 ER図を推敲する。
　以上の作業は、 DA ^{（注 3）}とエンドユーザがおこなう。
　以上のドキュメントが正式に承認されたら、 DBA ^{（注 4）}は、Ｔ字形 ER図のなかに記述されたデータセットを用意して、データを移行する。

　
　SWAT チーム^{（注 5）}は、以下のドキュメントをインプットとして、プログラムを作成する。

　（1）Ｔ字形 ER 図
　（2）アトリビュート・リスト
　（3）アルゴリズムの定義表
　（4）画面・帳票

　
　 RAD の際だった特徴は、以下の点にある。

　（1） SWAT チームの人数は、10人とする。

　（2） [ 1,000,000 ステップくらいのアプリケーション・システムなら、]
　　　　6ヶ月以内に、システムを導入する。

　
　小生が RAD を実行している最大の理由は、事業過程の周期（計画・実行・批判）とシステム作りの期間が、大幅に乖離しているので、事業過程が見直しされる周期内に、システムを作る点にあった。^{（注 6）}

　それを実現するためには、まず、プログラムの作成量を、大幅に削減しなければならなかった。幸い、適切なデータ構造が用意されていれば、（手続き型言語を使って作成してきた）プログラムのソース・コードの 70％を削減することができる [ この数値は、実態調査をした報告値である ]。^{（注 7）}
　さらに、適切なデータ構造が用意されていれば--そして、RDB を使うとすれば--、プログラムのなかでは、「nested-IF」が、ほぼ、皆無に近いコントロール・フローが実現できる。（「nested-IF」がなければ、）当然ながら、プログラムのテスト工程は、短縮されるし、プログラムの品質も高くなる。

　大型汎用機の環境やクライアント・サーバ形態では、小生は、プログラムの再利用を考えてはいなかった。（プログラムのソース・コードを大幅に削減して、しかも、ソース・コードは、「nested-IF」のない構成なので、）「プログラムは使い捨て」という考えかたをしていた。そういうやりかたをしてきて、システム作りの生産性は、従来比、平均 3倍を実現してきた--或るクライアントでは、従来比 8倍という報告もあった。

　2000年頃から、（コンポーネントを使った Java プログラム生成の）フレームワークが出てきて、「プログラムの再利用」が論点になってきた。小生のクライアントが、「フレームワークを使って、RAD ができるどうか」を検証しているが、コンポーネントを使って、生産性を、どのくらい向上できるか、という点は、今回、測量していない。^{（注 8）}

　プログラミング・パラダイムとして、以下の 2つを考えることができる。

　（1）構造的プログラミング
　（2）抽象データ型

　複数のファイルを読み込んで、レポートなどのアウトプットを手続き型言語を使って作成する際、構造的プログラミングが多く用いられてきた。

　構造的プログラミングは、ソリューションを第一義に考えて、ソリューションを手続き的に変換して、変数のなかに値を代入し、1つずつのステップを実行するやりかたである。1つずつのステップを実行する際、「場合分け」を網羅して、コントロール・フローは、「判断（IF）と繰返し（ループ制御）」の操作を基本とする。「データの型（構造化）」は、問題に即応した型が定義される。

　いっぽう、「抽象データ型」は、データに固有な操作も同時に扱い、データとプロセスをカプセル化するやりかたである。

　
　「アトリビュート・リスト」は、「抽象データ型」として扱うことができる。
　「アトリビュート・リスト」は、コンポーネントとして、再利用できることは確かだ、と思う。

　「アルゴリズムの定義表」のなかに記述される（テーブルの「関係」のなかで成立する--すなわち、複数のテーブルを対象にした--）プロセスは、できうるかぎり、（JOIN および PROJECTION を使って、）データに対する I/O のみで終わるように配慮しているが、系列（関係）のなかでしか検証できないバリデーション・ルールもあれば、系列（関係）のなかでしか成立しないアルゴリズムも、多々、ある。
　たとえば、「データ解析に関する FAQ」の 293ページに示した事象（「resource 対 event ＝複数-対-複数」）では、resource と event は同じであるが、ビジネス・ルールが変化したら、データ構造もアルゴリズムも変化してしまっている。すなわち、resource と event は、ほとんど、再利用できるが--アトリビュート・リストは、ほとんど、再利用できるが--、「関係」のなかで成立する構造は、ほとんど、再利用できない--アルゴリズムの定義表は、ほとんど、再利用できない。

　モジュール化は、「再利用」を目的にしているのではなくて、（環境が変化したら、）修正しやすい構造を作ることが目的ではないか。

　おそらく、（フレームワークを使うユーザにしてみれば、）論点になるのは、「アルゴリズムの定義表」が、コンポーネントを使って速く作ることができるかどうか、という点にあるのではないか--あるいは、「アルゴリズムの定義表」を、コンポーネントを使って作ることができないとしても、それ以外のプロセス（プロトタイプ作成や画面作成とか、アトリビュート・リストの入力とか）が、コンポーネントを使って生産性を高めることができれば、フレームワークは有用である。
　そして、事業が変化した際に、コンポーネントを使って、プログラムを作成するほうが、（構造的プログラミングを用いて作成された）プログラムのソース・コードを修正することに比べて、生産性が高いのであれば、フレームワークは、多大に有用になる。

　
　（2004年6月23日）