anti-computer

　
　プロトタイプ（prototyping）とは、本稼働用（production run）システムを作る前に、実験的ではあるが、実際に稼働するプロトタイプ（原型）を作り評価するプロセスをいう。
　プロトタイプの目的は、ユーザ要件（requirements）を明確にする点にあるとされているが、小生は、screen-painting を重視して、「インフォーマル・データ」を捕捉することを目的にしている。^{（注 1）}

　1980年代、プロトタイプが提示された理由は、 SDLC （System Development Life Cycle）を前提にした waterfall モデルが現実にそぐわない、という点にあった [「ベーシックス」、2004年 2月 1日、284 ページ参照 ]。^{（注 2）}

　さらに、1980年代なかば、CASE ツール^{（注 3）}が提示されたとき、 SDLC において、上流工程用ツール（Upper CASE ）と下流工程用ツール（Lower CASE ）の接続が論点になって、Lower CASE のジェネレータが、プロトタイプを搭載していて、Upper CASE （分析・設計ツール）と Lower CASE （ジェネレータ）が、要件定義の手段を、それぞれ（べつべつに）、提示した。
　Upper CASE は、job-analysis の要件定義を提示し、Lower CASE は、プロトタイプの要件定義を提示した。

　システム・エンジニアが、システム化の対象になっている事業を的確に記述できないなら、前回、述べたように、エンドユーザが作業日報を記述して、仕事の網羅性を検証して、EDP 化の対象を指示したならば、プロトタイプを使うほうが、（システム・エンジニアが作成する曖昧な概念図に比べて、）的確である。
　しかも、プロトタイプは、（エンドユーザが隠蔽している）インフォーマル・データを、screen-painting を使って捕捉できる強みがある。

　プロトタイプには、以下の 3つのやりかたがある。

　（1）使い捨て型（throw-away）
　（2）スケルトン型（nucleus、skelton）
　（3）コンポーネント型（component）

　1980年代では、技術的に、コンポーネント型は実現されていなかったので、ジェネレータは、スケルトン型を搭載していた。1990年代終わり頃から、プロダクトとして、（プロトタイプを配慮した）フレームワークがマーケットに出てきて、プロトタイプを使いながら、コンポーネント型プログラム生成を実現できるようになった。

　Waterfall モデルが現実にそぐわないので、小生は、プロトタイプを前提にした RAD^{（注 3）}を、いままで（大型汎用機の環境およびクライアント・サーバ形態では）、実地に使ってきた。しかし、（情報が、インターネットを経由してやりとりされる）ウェッブ環境のなかで、プロトタイプを配慮したプロダクトがなかったので--実地のシステム作りと、システム作りを支援するはずのプロダクトのあいだで、大きな乖離があって--、苛々していたのだが、小生の或るクライアントが、或るフレームワークを使って、 RAD を実現できることを検証してくれた。そのクライアントが使ったフレームワークは、Webtribe （メディア情報開発株式会社）である。WebTribe には、Visual Frame というプロトタイプを配慮したプロダクトが製品群のなかに用意されている。

　プロトタイプは、エンドユーザとＩＴの接点である。プロトタイプは、エンドユーザが、みずからの要件を、具体的に、指示して検証できる function である。

　システムを作る際、エンドユーザの要件を的確に取り込む 1つのやりかたとして、以下の手順を考えてみてほしい。

　（1）システム化の対象（事業）の網羅性を検証する。（作業日報の作成）
　（2）システム化の対象のなかから、EDP 化対象を選ぶ。
　（3） EDP 化対象のなかから、プロトタイプ対象を選ぶ。
　（4）プロトタイプ画面（および他の画面・レポート）、帳票ならびにファイルを
　　　　対象にして、データベース構造を作成する。
　（5）アトリビュート・リストを作成する。
　（6）アルゴリズムの定義表を作成する。

　以上の作業は、どのような IT 技術を使おうが、事業を EDP 化する基本的な作業である。以上の作業が終わってから、ツール（フレームワーク）の使いかたがトピックとなる。ユーザ要件の取り込み（プロトタイプ）を配慮して、 RAD を実現するフレームワークとして、 Visual Frame と WebTribe をお薦めする。

　（2004年6月16日）