プロジェクトの要件を可視化するためにプロトタイピングを利用する

　プロトタイプは、実際に作られるアプリケーションの見た目を示すものだ。プロトタイプは開発ライフサイクルの初期に作られるもので、外見、印象、アプリケーションの一般的なワークフローなどに関する価値ある洞察を与えてくれる。

　製品の最初の実装をプロトタイプと呼ぶ人もいるが、これは正しくない。もし複数の実装があるのであれば、最初の実装はパイロットテストと呼ぶ方が正しいだろう。同様に、プロトタイプは提案されたソリューションがうまくいくかどうかを検証するために使われるものでもない。これは正しくは概念実証と呼ばれる。

　プロトタイプの主たる目的は、要件を収集し、文書化することだ。もし十分に優れた要件のセットが事前に分かっているという自信があれば、特に最初のプロトタイプを作る理由はない。最初のプロトタイプが作られたら、まずそれをクライアントに示し、その段階までの仕事について確認してもらうべきだ。その後、そのプロトタイプを使い、追加要件を集める。要件を収集したら、それを他の手段で収集した追加要件と同じ形で文書化する。

　プロトタイプは、オンラインの画面を含む外見からスタートする。この際、核となるビジネスプロセスのプログラミングはできる限り行わず、このプロトタイプで画面から画面へと遷移するのに必要なプログラムだけを作成する。プロトタイプの要点は、アプリケーションの視覚的な表現を示すことであり、その背後にある複雑なビジネスロジックを示すことではない。

プロトタイプをその後どう扱うか

　作成したプロトタイプの扱い方には、2つの選択肢がある。

• 完全に、あるいは部分的に廃棄する。通常、プロトタイプを作った場合、要件を収集した後は廃棄する。プロトタイプは、最終的なソリューションへの出発点である必要はないことを覚えておくこと。主たる目的は要件を収集することだ。私は、ウェブ上で実行されるはずのオンラインアプリケーションに対し、PowerPointやExcelでプロトタイプが作成されるのを見たことがある。このPowerPointのプロトタイプを、その後プロジェクトが進行するに従って再利用するという考えはまったくなかった。一方で、最終的なソリューションと同じ技術を使ってプロトタイプを作る場合も多いだろう。この場合、プロトタイプのコンポーネントの一部を、プロジェクトの設計と構築のフェイズの出発点として活用することもできる。
• 対話的に開発を進め、最終的なアプリケーションを作成する。対話的な開発アプローチを取っている場合には、最初のプロトタイプは素早く作れるはずだ。しかしこの場合、その成果を廃棄する代わりに、プロトタイプに新しい要件を適用して更新する。2度目の手順では、アプリケーションにより多くのビジネスロジックが組み込まれる。この時点で、もはやプロトタイプと呼ぶべきものではなくなる。プロトタイプの外見は、最終的なソリューションを開発するための基礎として使われる。

　まとめると、プロトタイプは要件を収集するために使われるものであり、アプリケーションのルックアンドフィールとプロセスのワークフローを可視化するのに特に役立つ。プロトタイプの寿命はプロジェクトのライフサイクルモデルによって異なる。プロトタイプを廃棄してしまう場合もあれば、一部のコンポーネントをプロジェクトで後に再利用する場合もある。また、プロトタイプを最終的なソリューションを開発するための基礎として使うことも可能だ。

この記事は海外CNET Networks発のニュースをシーネットネットワークスジャパン編集部が日本向けに編集したものです。海外CNET Networksの記事へ