中途半端なプロトタイピングは事故のもと

「プロトタイプを作っても実際の現場では上手くいかない。あれは机上の空論だ」という声を聞くことがあります。完全型プロトタイプ開発を推進する立場としても、この意見は真剣に受け止めています。しかし、そう言った経験の多くを紐解いてみると共通するパターンが見えてきます。それは、プロトタイピングそのものの問題ではなく、中途半端なプロトタイピングの結果だということです。

「省略」が引き起こす連鎖的な不備

コストやスケジュールを抑えるために、プロトタイプの作成を途中で止めてしまうケースがあります。

「ここは言わなくてもわかるだろう」「この機能はシンプルだからプロトタイプは不要」という判断で、一部の画面や機能をプロトタイプから外してしまう。個々の判断は合理的に見えますが、機能間の連携やデータの受け渡しといった部分で、後になって想定外の不備が発生します。一つの画面単独では問題なく見えても、実際の業務フローで動かしてみると、前後の処理との間に齟齬があることが判明する。これは、全体を通してプロトタイプを作り切っていないと気づけない種類の問題です。

また、ベンダー側が画面モックアップをプロトタイプとして提出するケースもあります。見た目は完成しているように見えますが、実際の業務データで動かせない、操作フローが確認できない。これでは、プロトタイプが本来持つ「業務課題を発見する」という機能を果たせません。

検証作業を「軽いタスク」にしてしまう問題

プロトタイプが完成した後の検証プロセスでも、同様の問題が起きます。

現場のメンバーに「手が空いたときに確認しておいてください」と依頼し、正式な業務として位置づけない。そうすると、現場では「見た目が綺麗」「数箇所クリックしてみたが問題なさそう」「なんとなくできている気がする」という、パッと見の印象だけで判断が終わってしまいます。あるいは「忙しくて時間が取れない」と言われ、そもそも十分な検証が行われないまま進んでしまうことも珍しくありません。

プロトタイプの検証は、「時間があればやる作業」ではなく、「開発の成否を左右する最重要プロセス」です。それを形式的に済ませてしまうと、現場の課題は何も発見できないまま本番開発に入ることになります。

三者の本気度が揃わなければ機能しない

プロトタイピングが期待通りの成果を出すためには、発注担当者、現場のメンバー、ベンダーの三者全員が、前向きにシステム開発に取り組む必要があります。この中の一つでもいい加減になると、コストやスケジュールが余計にかさむだけです。

発注担当者が要件の絞り込みを怠れば、要件爆発や方向性のぶれが生じます。
現場のメンバーが検証作業に本気で関わらなければ、潜在的な課題は見つかりません。
ベンダーが質の低いプロトタイプを納品すれば、正しい検証そのものが不可能になります。

逆に言えば、三者がそれぞれの役割を真剣に果たしたとき、プロトタイピングは驚くほどの成果を生みます。実際にプロトタイピングがしっかり機能した現場では、リリース後の混乱がほとんどなく、スムーズに本番稼働へ移行できています。これは机上の空論ではなく、現場での実際の経験です。

「やりきる」ための三つの実践

中途半端を防ぐために、特に意識してほしいことが三つあります。

プロトタイプは最後まで作り切る。 「大体できた」で止めず、業務フローの全体を通じて動作確認できる状態まで仕上げること。省略した箇所が、後々のトラブルの起点になります。

検証する業務のチェックリストを事前に作成する。 何を確認すればプロトタイプの検証が完了したと言えるか、具体的な項目を整理しておくこと。「なんとなく触った」ではなく、業務シナリオを一通り実施できたかを確認の基準にしてください。

スケジュールと作業内容をあらかじめ決め、業務として集中的に取り組む。 検証作業を「空き時間でやるもの」にしない。日程と参加者を事前に確定させ、その時間を検証のためだけに確保してください。

プロトタイピングへの評価は、プロセスの質に依存します。中途半端なプロトタイピングで失敗した経験があるなら、ぜひ一度「やりきるプロトタイピング」を試してみてください。