前回はこちら
今回は、合意の質を上げるためのプロトタイピングの話です。画面設計書で合意したのに、完成後に「イメージと違う」と言われる。そんな経験ないでしょうか？
「Excelの画面設計書」で合意した気になる危険
Excelの設計書は便利です。でも、それだけで合意したと思うのは危ない。
・実際の画面サイズ感が見えない
・操作の流れが想像に頼る
・「ここ押せる？」のズレが最後に出る
結果、合意したはずの要件が、実装後に崩れてしまう。
要件定義から「動くモック」を作る
ここでAIの出番です。要件定義書から、HTML + バニラJSでモックアップを作らせます。
私は、こんな指示をよく使います。
・「要件定義書の内容を元に、発注入力画面のモックを作って。ベースのプラットフォームはSalesforce、LWC+Apexで実装できる範囲で」
できたHTMLは、そのままブラウザで開けます。“動く画面”を早く見せる。これだけで会話が変わります。
会議中に直して、その場で合意する
一番効くのは、会議中に直せることです。
・「この並び、現場は逆です」
・「ここの項目、月末だけ必要です」
・「ボタンは右下じゃなく上に欲しい」
こう言われたら、その場で修正して「これでいいですか？」と聞く。これができると、合意の質が一段上がる。
私が現場で効いたと思うポイント
プロトタイプは、設計の正しさを証明するものではありません。会話を引き出す装置です。
・口頭では出ない本音が出る
・「やっぱりこっちが良い」が早く出る
・結果として、合意のリズムが整う
私はこの「リズム」を大事にしています。ユーザーはできるだけ具体的な形で合意しないと、後で必ず手戻りになります。
まとめ: 合意は「動くもの」で前倒しできる
仕様書は必要です。でも、人は動くものを見た時に本音を言う。
AIでモックを早く作り、会議でその場修正する。これができると、合意形成が一段速くなる。
次回は第9回「Gitで保守と差分を管理する」話。
合意を履歴として残すことが、運用フェーズの安定につながります。