「Excelの画面設計書」で合意した気になる危険

Excelの設計書は便利です。でも、それだけで合意したと思うのは危ない。

・実際の画面サイズ感が見えない
・操作の流れが想像に頼る
・「ここ押せる？」のズレが最後に出る

結果、合意したはずの要件が、実装後に崩れてしまう。

要件定義から「動くモック」を作る

ここでAIの出番です。要件定義書から、HTML + バニラJSでモックアップを作らせます。

私は、こんな指示をよく使います。

・「要件定義書の内容を元に、発注入力画面のモックを作って。ベースのプラットフォームはSalesforce、LWC+Apexで実装できる範囲で」

できたHTMLは、そのままブラウザで開けます。“動く画面”を早く見せる。これだけで会話が変わります。

一番効くのは、会議中に直せることです。

・「この並び、現場は逆です」
・「ここの項目、月末だけ必要です」
・「ボタンは右下じゃなく上に欲しい」

こう言われたら、その場で修正して「これでいいですか？」と聞く。これができると、合意の質が一段上がる。

プロトタイプは、設計の正しさを証明するものではありません。会話を引き出す装置です。

・口頭では出ない本音が出る
・「やっぱりこっちが良い」が早く出る
・結果として、合意のリズムが整う

私はこの「リズム」を大事にしています。ユーザーはできるだけ具体的な形で合意しないと、後で必ず手戻りになります。

仕様書は必要です。でも、人は動くものを見た時に本音を言う。

AIでモックを早く作り、会議でその場修正する。これができると、合意形成が一段速くなる。

次回は第9回「Gitで保守と差分を管理する」話。
合意を履歴として残すことが、運用フェーズの安定につながります。