プロトタイピングあれこれ

プロトタイピングの罠

業務多忙で押しまくられているため、研究所長が某MLに先日ポストした内容を、少し手直ししてお送りします。

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

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

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

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

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

プロトタイピングで変わる制作料金体系？

ソフトウェア開発の領域でプロトタイピングが主流になってくるにつれて、マニュアル制作の現場で困った事態が持ち上がっています。制作者が頻繁なアップデートに付き合わされるため、特定案件から手が離せないという問題です。

マニュアル業界ではページ単価とか文字（苦笑）単価といった制作料金体系を採用しているところが多いのですが、これは大きなチェックを2〜3回＋最終修正のやり取り、という作業フローを想定しているからこそ成立する体系であるといえます。要するに、制作者を特定案件に張り付かせることなく複数の案件を受け持ってもらうことで、制作会社として負荷の均一性の確保と全体の売り上げ増を狙うという方法論です。

ですが、マニュアルなりヘルプなりの制作者が、毎週リリースされるビルドという形でプロトタイピングに付き合わされるのであるならば、このような方法論自体が通用しないことになります。作業工数と売り上げの想定の根底が崩れることになりますので、これは由々しき問題です。プロトタイピングで設計が行われる案件に関しては、イラストや基本デザインといった個別単価見積もりが可能な部分と、制作者を専属させるための人月計算で算出する部分に分けて考えるべきなのかもしれません。しかしこれでは大幅なコストアップになるでしょうから、発注側はなかなかこの条件を飲まないでしょう。

この問題については、実際に制作料金が上がるかどうかよりも、設計プロセスの変化による制作プロセスへの影響に発注側の担当者（特にメーカーのマニュアル担当者）がまったく気付いていないというのが一番の問題でしょう。制作システムが写植からDTPに移行したときにも、前時代的なワークフローや意識を引きずったままの担当者が多く見られました（もちろん今も見かけます）。設計プロセスという部分は制作システムと違ってさらに目に見えにくい部分ですから、担当者レベルでの意識改革には、まだまだ時間がかかるのでしょうね。あ〜、頭痛い。（2001.06.19）