情報システムは極めて不確定性の高い基盤のうえに成り立っている。刻々と変化する技術や、それらを取り入れた製品群が登場するため、選択肢は増える一方であるばかりでなく、実際に情報システムを構築するうえで検討すべき、それらの組み合わせは、ほぼ無限である。しかし、多くの製品は、ビジネスへの適用が実証され、安全であるとはいい難く、無審査に採用することは多くの危険を伴う。そのため、システムの開発では、しばしば、データベースや開発ツールの選択、システム・アーキテクチや処理方式、設計法などが問題としてクローズアップされて来る。
情報システムの構築はまた、技術的に非連続である。例えば、ソフトウェア製品はバージョンアップなどが著しいため、特定のバージョンに関する操作や利用法のノウハウは、次のシステム開発では、すでに陳腐化しているケースが多い。また、ハードウェア製品/ソフトウェア製品それぞれの特定の組みあわせに関するノウハウも、以降のシステム開発で生かせるとは限らない。したがって、リーダからメンバーへあるいは、ベテランからルーキーへと、ノウハウが継承されにくく、技術者は常に、初めての製品、初めての組み合わせに挑まざるを得ない。
このため、システム構築に際しては、採用した、あるいは採用予定のツールに関して、特性や制約を調べ上げておくことが必須となる。処理系は、非連続な技術に根ざした不確定性をもち、しかも、標準化は、まだこれからである。システム開発に際しては、常に、処理方式、システム構成などの妥当性や有効性を検証しておかねばならない。そのためには、
A)システム実現可能性チェック → 全体設計、実装工程で実施
システム構成
ソフトウェア・プロダクト選定
パフォーマンス・フィジビリティ
B)処理方式/API妥当性チェック → ミドル開発、共通化工程で実施
構造化/共通化/ライブラリ化
データI/F方法(モジュール間/プロセス間/マシン間)
トランザクション処理パタンといった、2種類のプロトタイプを想定した開発計画を立てるべきである。
なお、パイロット開発や、ユーザの参画によって、インタラクティブにアプリケーションをデザイン・チェックして行くプロトタイプは、上記の二つとは異なる。
初心者にも簡単にアプリケーションが作成出来るようになったと言われる…正確には、常に言われ続けている。しかし、開発・利用に必要なノウハウ・知識を持ち、アプリケーションを独自開発出来るユーザは、それほど多くはない。合理的で的確な構造や仕組みをとり、効率良いアプリケーションを開発するには、相当高いスキルが求められる。裏を返せば、仮に「プログラム不要」を謳うような仕組みであったとしても、作った後の実用を考えるならは、やはり専門家の為のツールなのである。
従って、場合によっては、「ツールの習得や、ツールを使った開発にどの程度の時間を要するか」、「想定する要員と体制で、予定通りの品質のアプリケーションが作れるかどうか」、などといったチェックも必要となる。これは、旧来からある、パイロット開発の目的を絞ったプロトタイプであると位置付けられる。
C)開発体制チェック(パイロット開発) → 品質指標作成、標準化工程
Learn on Demand(実践訓練)
ボリューム/生産性/所要期間等の計測
プロジェクト標準(作業手順、利用環境、用語、etc.)そして、ユーザ参画によるプロトタイプは、アプリケーションの正確性/機能/プロセス/使い勝手などをチェックするものであるため、さらに別途、次の様に位置付けるべきである。
D)アプリケーション・チェック → 作成工程(設計～テスト)
クライアント画面/機能仕様
ミドル/バック機能仕様
データベース内容システム構築のプロトタイプは、以上のような各パタンを区別したうえで実施すべきである。見た目確認と接続検証のように、目的や方法の異なったプロトタイプを、同じ「プロトタイプ」だからといって、一つに括ってはならない。もちろん、全てのプロトタイプが常に必要であるか否かは、一概には結論づけられない。単純に言えば、「合目的性を確認しつつ、プロトタイプを実施する」ということである。
於：ソフトウェア・シンポジウム’95 滋賀 SEA
コメント