顧客はできたものを見たら「違う」としか言えない

パワポでいくら画面設計をしても、画面遷移を見せても、画面を実際に作るのはエンジニアであり続ける限り画面の最終形態をイメージできるのはエンジニアだけしかできないのです。だから、いくら画面設計をしてもダメ出しや微調整が繰り返されるのです。

工程はエンジニアサイドの不具合でなければ原則戻ることはしない固定化された管理が強く要求される手法を採用しており、要件、機能仕様、実現仕様と詳細化、具体化されるともに画面設計も具体化されるのです。

ですから、詳細化された画面をみてイメージと違う場合は工程を遡ってやり直しが発生することになります。

ベンダーはこれをやられると手戻りが大きいので不具合以外は対応したくないテーマです。

顧客にとっては、受入試験や業務総合試験などで初めて動く画面を見ることになるので、その場面でこれまで決めてきたことと実際に使ってみて「違う」というのです。特に、色合いについては印刷や投影される色味と差異が出るのです。

ベンダは試験工程まで進んでからの画面設計の変更に懲りて、画面設計工程を上流に持ち込むことで、画面設計の変更に伴う手戻りリスクを低減することを図るように知恵を出しました。

残念ながら、顧客が実際に動くものに触れるのはシステムができてからであり、顧客が現物を見てから初めて顧客の要件を確認するプロセスは、実は変わっていないのでした。

ベンダがいくら仕様凍結と言っても、使われなければただのゴミプログラムで価値がありません。

発想が柔軟なベンダは現物を見ないとそれでいいのか違うのかを顧客が言えないのなら、現物をさっさと作って動くプログラムを作り、顧客からフィードバックをもらうことで手戻りを減らす手法を採用するようになりました。

その古典的な手法はプロトタイプであり、今ならアジャイル開発です。どちらも短期間で動くプログラムを顧客が確認することができますが、前者は捨てることを前提としており、後者はそのままリリースすることを前提としています。

旧世代の画面設計は、顧客からの「違う」というフィードバックを柔軟に取り込めないところまで進んでからしか現物を見せることができないのです。

どっちにしても人は現物を見てから「考える」生き物なので、フィードバックを手戻りが少ないうちにもらう工程デザインをするのがプロジェクトのリスクをコントロールしやすいのです。