完全型プロトタイプ開発なら、現場が混乱しない

「要件定義では確認したはずなのに、完成したシステムが想像と違った」——この問題の原因は、確認に使ったものと完成物の間にあるギャップです。

「確認した」と「使える」は別の話

システムの要件定義では、画面のワイヤーフレームやフロー図、仕様書を使って確認を行うことが多いです。関係者が集まり、「この画面でよいですか」「この操作の流れで問題ありませんか」と確認し、承認をもらいます。

ところが、完成したシステムを実際の業務で使い始めると、現場から「思っていたのと違う」という声が出てきます。

「確認したはずなのに」と発注側は感じます。でも現場担当者からすると「こんなはずじゃなかった」という感覚も本物です。どちらも間違っていません。

原因は、「要件定義で確認したもの」と「完成物」の間にある形の違いです。紙やスライドで見た画面と、実際に動くシステムは、同じ仕様から作られていても体験として別物です。

操作の手間が想定より多かった。仕様書では「入力して保存する」とシンプルに書いてあっても、実際に使うと「毎回この入力をしなければいけないのか」という負担感が出てきます。画面を実際に操作して初めてわかる手間です。

業務フローに合っていなかった。確認時に想定していた業務の流れと、実際の現場での流れが微妙にずれていることがあります。例外的なケースや、普段と違う状況での操作を、静的な資料での確認では想定しきれなかった場合です。

現場担当者が習得できなかった。「機能として存在する」ことと「現場で使いこなせる」ことは別です。要件定義の担当者と、実際に使う現場の人が異なる場合、現場の実態に合わない仕様が通ってしまうことがあります。

現場が混乱する根本的な原因は、「確認に使ったもの」と「完成物」の差です。この差が大きいほど、リリース後のギャップも大きくなります。

完全型プロトタイプ開発では、本番同等の機能と画面を持つプロトタイプで確認を行います。実際に業務を担当する人が、本番と同じ操作感で確認できます。

紙の上では見えなかった「使いにくさ」「手順の多さ」「例外への対応方法」が、この段階で表面化します。発見するタイミングがプロトタイプ段階であれば、修正のコストは本開発後と比べて大幅に抑えられます。

リリース後に現場から修正依頼が相次ぐ状況は、発注側にとってもベンダーにとっても理想的ではありません。

現場が実際に使えるシステムを最初から届けるためには、実物に近いものを現場担当者に確認してもらう機会が必要です。完全型プロトタイプは、その機会を本開発の前に設けるための手段です。

確認するものと完成物のギャップをなくすことが、リリース後の混乱を防ぐ一番の近道です。