情報大工のひとりごと

プロトタイピングの罠

ユーザーの反応を見ながらどんどん作り込んでいくという、プロトタイピング手法がWebサイト構築でもソフトウェア設計でも主流のようですが、ちょっと安易なプロトタイピングが多すぎると思ったことはありませんか？

確かに中途段階での評価を素早く反映して、製品に作り込んでいくことができるというプロトタイピングは、ユーザーにとってより良いものができる可能性が高い設計手法といえます。ですが、それもプロトタイピングのスパイラル（実装→評価→修正〜）に入る前に、やるべきことを適切に行っていればこそという前提が忘れられているように思えます。

そもそもプロトタイピング手法というのはスパイラルをまわすことで品質を作り込んでいく手法ですから、途中の変更をもともと織り込み済みの設計手法です。そうはいっても、中途段階での根本的なロジックの変更には弱いことが見過ごされているように思えるのです。まあ根本的なロジック変更に対応できる手法なんてものは、この世に存在しないでしょうけれども。

それでは、根本的なロジックの変更を引き起こす要因とは何でしょう？ それはWebサイトにおける情報構造デザイン、UI設計における基本操作ポリシーなどのように、目には見えないけれどもユーザーが向き合うシステムの根底を支えている部分の仕様変更なのです（業務システムのデータ構造もこの種の例に入りますが、データ構造の設計には時間をかけていることが多いので、おそらく大丈夫でしょう）。こうした部分を作り直す必要に迫られたときは、たいていは目に見える部分全体が作り直しの対象となります。

ですから、情報構造デザインやらUIポリシー設計といったシステムの根幹部分をもっとよく検証してから、スパイラルに入るべきなのです。ご時世柄か短期決戦プロジェクトが増えているいることもあり、ちゃんと考えずにスパイラルに入ることが多くありませんか？ いや、疑問型ではなく、見聞きした範囲ではこうしたプロジェクトの方が多いのですが（汗）。「今更そんなとこ直せねえよ」ということでWebサイトなりソフトウェアの使い勝手の質があがらず、結局損をするのはユーザーです。もっとも、最終的にはビジネスの失敗ということで、プロジェクト実施部隊が責任を取ることになるのでしょうけれども。