画面仕様書を「作りまへん」リスク

IT Pro の開発ドキュメントの最適化で笑わせてもろたちうわけや。これ書いた人は画面仕様で酷い目に遭ったことがないんやろうわ。笑った箇所は次の通り。
帳票
画面仕様書をプロトタイプ・アプリケーションで代用する方法があるちうわけや。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになるちうわけや。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減るちうわけや。これは帳票にも同じことが言えるちうわけや。

　あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」やねぇ！ボタン配置や文字色を目の前で変えられるものやから、いつまでたっても顧客は「ちーとばかしコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴せんと直せへんものがあることをギッチリと顧客に理解してもらうでために、画面仕様書はどうしても必要。

　コレ書いた人は、画面仕様書を前に顧客と丁々発止したことがないから、そないなコト言えるちうわけや。せやなかったら light weight なやつしか作ったことがないからやろうわ。以下3つの観点から、画面仕様書を「作りまへん」リスクを書く。

　　　1. 画面とチェック仕様
　　　2. 画面と業務プロセス
　　　3. 画面とデータベーステーブル