プロトタイピングは，利用者とともにシステムのプロトタイプ（試作品）を作って，仕様を固める開発手法である。その効果を出すには，プロジェクトのどの範囲をプロトタイピングでカバーするのか，仕様の最終的な取りまとめをだれがいつまでにやるのか，といった原則をあらかじめ決めておく必要がある。そうでないと，利用者の意見が収束せず，仕様がいつまでも確定しないといった事態を招く危険がある。
プロトタイピングと呼ぶ開発手法が使われ始めてもう10年近くになる。プロトタイピングは，システムの実際の利用者に設計過程からプロジェクトへ参加してもらい，意見を交換してシステムのプロトタイプ（試作品）を作り，仕様を固めていく手法である。
だが，実際に「役立つプロトタイピング」がどれだけ行われているかとなるとはなはだ疑問である。プロトタイピングの効果を，利用者に自由に意見を言わせて，それをできる限り取り入れようとすることだけに求めると，逆に利用者の意見がいつまでも収束せず，仕様が確定しないといった事態を招くからだ。
プロトタイピングの功罪（1）
修正が続出，本稼働が遅れ
製造業のA社は98年秋から購買システムの再構築に乗り出した。99年3月から新しい購買システムを稼働させる計画であった。現行の購買システムは稼働してから8年が経過し，処理内容が陳腐化してきていた。バッチ中心の処理方式がA社の購買業務の実情にそぐわなくなってきているという問題もあった。
新購買システムの担当を命ぜられた情報システム部の係長はプロジェクトの先行きに不安を抱いていた。直前に担当した債権管理システムの開発で苦い思いを味わっていたからである。
債権管理システムの開発プロジェクトは非常に混乱した。稼働時期を予定より3カ月も遅らせたばかりか，稼働後のシステムが利用者に不評で，手直しを何度も強いられた。混乱した理由は，利用部門から仕様変更が相次いだことだ。
係長は，債権管理システムの開発にあたって，通常のシステム開発手順にのっとり，要求仕様・基本設計・詳細設計と各工程ごとに利用部門である営業管理部の了承を取り付けながら作業を進めていった。利用部門は詳細設計の段階まで，反対はもちろんコメントすらしなかった。ところが，プログラムが完成し，実地テストに入ったとたん，「我々の要望と違う」，「こんな画面では，実務上使用に耐えない」などとシステムへの批判が相次いだ。
「なぜ設計段階で問題を指摘をしてくれなかったのか」と情報システム部の係長は反問した。しかし，利用部門は，「資料を見ても専門用語の羅列で内容が分からなかった」，「紙に書かれた情報だけではどのようなシステムになるのか想像がつかなかった」というばかりであった。
結局，係長は情報システム部の上司から，「我々，情報システム部の担当者は利用部門の意を汲んで仕事をしなければならない」とさとされ，無理矢理自分を納得させて，システムを手直しした。
購買システムの開発プロジェクトにあたって，係長は「債権管理システムのような失敗を二度と繰り返すまい」と心に決めた。そして，さまざまな書籍を読んだり，システム構築の研修会にも積極的に出席した結果，プロトタイピング手法を導入することにした。
プロトタイピングは当初，順調な滑り出しであった。要求仕様が固まり，基本設計がすみ，詳細設計の段階で，画面サンプルを用意し，「このようにデータを入力すればコンピュータはこのように反応する」といった具体的なイメージを利用者に見せ，相談しながら開発を進めた。利用部門からは「分かりやすい」，「今後は常にこの方式でシステム構築を進めるべきだ」と好評であった。
しかし，問題はここから始まった。システムの試作品を作って見せると，利用部門から修正意見が出る。次回の会議までに，その意見を取り入れて修正して見せると，また別の利用者から修正要請が発生する。こうして，詳細設計の段階で作業が大幅に遅れ出した。
本稼働の遅れを招いてはならないと，情報システム部は詳細設計を終了したいと利用部門に伝えたが，なかなか応じてもらえない。結局，本稼働は予定より2カ月遅れ，5月からになってしまった。本稼働を直前に控え，情報システム部の係長は，新システムが果たして利用部門にとって本当に満足してもらえるものになったかどうか，いまだに確信を持てないままである。
