生成物の良し悪しの見分け方
この章でわかること: コードが読めなくても、AIが作った物の「良し悪し」を見極める チェックの観点。動いて見えること=正しいこと、ではありません。
まずは「使って試す」
Section titled “まずは「使って試す」”一番確実なのは、自分が利用者になって触ってみることです。
- 意図した通りに動くか(ボタン、送信、画面遷移)
- スマホでも崩れず使えるか
- わざと変な入力(空欄、長文、絵文字)をしても壊れないか
- エラーが出たとき、利用者に分かるメッセージが出るか
コードが読めなくてもできるチェック
Section titled “コードが読めなくてもできるチェック”- AIに説明させる: 「今の変更を、専門用語なしで説明して」
- リスクを聞く: 「この作りで危ない点や、後で困る点はある?」
- 代替案を聞く: 「もっとシンプルな方法はある?」
AIに自分の仕事を説明・点検させることで、見えないリスクが言葉になって出てきます。
「動く」と「良い」は別物
Section titled “「動く」と「良い」は別物”その場で動いても、(1) 別の人が使うと壊れる、(2) 後から直しにくい、(3) 安全でない、 といった問題は残り得ます。プロトタイプ段階では完璧を求めすぎなくてよいですが、 顧客に見せる/データを扱うなら、上のチェックは通しておきましょう。
顧客に見せる前のチェック(デモが滑らないために)
Section titled “顧客に見せる前のチェック(デモが滑らないために)”商談で見せる直前に、最低限これだけは確認しましょう。デモ中の「あれ、動かない…」を 防ぐためのリストです。
- 主要な操作を最後まで通したか(入力→送信→完了表示まで)
- スマホで開いて崩れないか(顧客はスマホで見ることが多い)
- 仮データに「※サンプル」と分かる印があるか(本物と誤解されない)
- 公開URLが実際に開くか(直前にもう一度アクセスして確認)
- 見せたくない作りかけ画面に、うっかり遷移しないか
- 限定共有なら、パスワードが本番URLでも効いているか
作る前に「合格の条件」を決める(受け入れ基準)
Section titled “作る前に「合格の条件」を決める(受け入れ基準)”行き当たりばったりで確認すると、見落としが出ます。作る前に「これができれば合格」を 短い箇条書きにしておくと、確認が漏れません。これを受け入れ基準と呼びます。
例(問い合わせフォーム):
- 名前とメールを入れて送信すると、完了メッセージが出る
- 空欄のまま送信すると、やさしいエラーが出る
- スマホ幅でも崩れず、ボタンが押しやすい
そして、この一覧をそのままAIに渡して自己チェックさせるのが効きます。 境界(空欄・超長文・0件・絵文字)を試す観点も忘れずに。
スマホでの見え方を必ず確認する
Section titled “スマホでの見え方を必ず確認する”顧客の多くはスマホで見ます。PCの広い画面だけで確認すると、スマホで文字が はみ出したり、ボタンが小さすぎたりする崩れに気づけません。作るときも見るときも、 スマホ幅を前提にします(スマホで開く方法も参照)。
- 頼むとき: 「スマホ幅で崩れないように」「指で押しやすいボタンサイズで」
- 確認するとき: ブラウザの幅を狭める / できれば実機で開く
- 見る観点: 横にはみ出さないか、文字が小さすぎないか、折り返しが不自然でないか
レビューはあなたの役割。コードではなく『体験と振る舞い』を見る——これは ユーザー目線でものを見る人ほど、得意な評価です。