第3章 · Lesson 12 / 17

読む現場の言葉を身につける

品質の見分け方

『動いた』で終わらせない

  • 目安 12 分
  • 進捗 12/17

このレッスンのゴール

  • 受け入れ条件を自分で書ける
  • 見た目・文言・例外ケースの確認視点を持つ
  • プレビューと本番の違いを説明できる

受け入れ条件を先に書く

品質はセンスではなく、条件です。依頼前に『これが見られたら成功』を3行で書いておくと、レビューが速くなります。

  • 正常系: いつも通りの使い方でこうなる
  • 文言・見た目: モバイルでも欠けない、誤字がない
  • やってはいけないこと: 別機能が壊れていない

プレビューは下見

多くのサイト案件では、PR ごとにプレビュー URL ができます。本番に出す前の下見です。Cloud Agent や CI がコメントしてくれることもあります。

プレビューでよく見えたら本番でも同じ、とは限りません。データ、権限、秘密情報が違うことがあります。それでも『出してから初めて見る』より安全です。

あやしいときの聞き方

『この変更で壊れうる場所は?』『テストした手順は?』『ロールバック方法は?』は、経験年数に関係なく有効な質問です。Agent にも人にも使えます。

理解チェック

  • 受け入れ条件を3行で書ける
  • プレビュー確認の手順を自分の言葉で言える

実践

進行中または仮想のタスクに対し、受け入れ条件を3行と、確認手順を5分で書き切る。

いま身についている開発者スキル

QA 視点 / 受け入れテスト

マイルストーン

レビュー力の土台ができた

リポジトリ・ブランチ・PR・品質の見方が揃いました。第4章では、その裏側の仕組みを深めます。