パワーツールは、開発は、極めて短期間に、高品質かつ低コストのシステムを実現するツールとして注目されている(呼称は様々であるが)。しかし、パワーツールだけで大規模システムが開発出来る訳ではない。RADなどの開発手法における品質向上のひとつの考え方は、「コーディング作業の廃止 == プログラムミスの排除」である。波及効果として、ドキュメント作成/テストなどの工程省略が考えられる。各手法ではCASEツールなどのコード生成機能を意図しているが、パワーツールも、ノンプログラミングで開発可能な範囲が広いと云う意味で、同様の効果が期待出来る。但し、全体のシステム・アーキテクチャ設計、ネットワーク設計、個々の業務機能設計など、設計上の正当性/妥当性は、現状の技術や装備では自動化不能である。従って、プロジェクトで設計レビューを省略することは望ましくない。
パワーツールを用いると、極めて短いサイクルで設計→開発→テストを回し、利用者のレビューを短期間に受ける開発工程(ラウンドトリップ型とよばれる)を採用する事によって、システムの合目的性を高め、仕様変更や、修正に耐えるようにする事ができる。さらに、ユーザ・エキスパートが参画し、業務仕様を明確にすることで、
- 事前設計書としてのドキュメントが不要(FIX後の要否は別途)
- コミュニケーションによるオーバヘッドが少ない
- レビューや検証のための「儀式」が不要
- 本質的な仕様変更や、仕様誤りが起こりにくい
などのメリットを生む。
この具体的な実施方法の一つが、RADなどの、ユーザ参画によるプロトタイプであるが、タスクのブロック化(範囲とレビュー対象の括り)を明確にしないと、収束しない恐れがあり、タイムアウト(時間切れで終える)方式を取らざるを得なくなる危険がある。
この場合、ドキュメンテーションに代表される仕様の定義を、どこまで行うかが、大きな問題である。一般には、クライアント/サーバ・システムであれば、ドキュメントが不要になるという考え方が多い。一方では、大規模開発であれば、厳密なドキュメンテーションこそが重要であるとする考え方もある。すべからくドキュメント化すると、手間がかかるうえ、その後の修正や変更の反映がおろそかになりがちなため、次第に現状から乖離してし、遂には省みられなくなる。片や、ドキュメンテーションを軽視した開発では、どこまで行っても仕様が安定しないと云う罠に陥りやすく、低品質でメンテナンスのしにくいシステムとなりがちである。
パワーツールを用いたクライアント・アプリケーションの開発において、想定しうるドキュメント対象は、入出力、プロセス、レイアウト、使い勝手、etc.がある。このうち、作成する必要のあるドキュメントは、実は、入出力だけである。なぜなら、正確に伝え、理解し、他に代替出来ない情報は、入出力だけだからである。
プロセスは、変わりやすい。また、殆どの場合、ドキュメントを見るよりも、ソースやスクリプトを直接見た方が、技術者に取っては分かりやすく、ドキュメントとソースが異なっているという不安はまったくない。従って、極めて厳重な定義が必要で、かつ、開発に先だって、それが記述可能な場合を除いては、ドキュメントは不要である。
レイアウトは、安定しない。利用者の人数だけ仕様のバリエーションがあるといって良い。従って、ドキュメント化は無意味である。また、ドキュメントとしてDTPソフトで絵を書くくらいなら、GUIエディタを使って開発を始めた方が早い。メンテナンスも然りである。従って、レイアウトのドキュメンテーションは不要である。
使い勝手は、レイアウト以上に、千差万別であり、事実上、ドキュメント化、定量化ができない。また、多くの場合、スタイルガイドや共通モジュール、オブジェクトなどによって規定されているため、変更が難しい。わざわざドキュメントに記録し、他人に伝える必然性は殆ど無いといえる。従って、使い勝手のドキュメンテーションも不要である。
残る入出力は、画面や帳票の存在意義であり、正確性と妥当性を評価する指針である。正確に定義されていることはもちろん、正確にアプリケーションが作成されている事が求められる唯一の属性である。従って、パワーツールを用いたクライアント・アプリケーション開発では、だた、入出力だけをドキュメント化すればよいという事になる。
ソフトウェア・シンポジウム’95 滋賀 SEA
コメント