第3章 · レッスン 12 / 17

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

品質の見分け方

『動いた』だけで終わらせないコツ

  • 目安 12 分
  • 進捗 12/17
第3章のレッスン一覧12 / 17
  1. 09リポジトリ:プロジェクトの入れ物10分
  2. 10ブランチとコミット:安全に試す技術12分
  3. 11Pull Request を読み解く14分
  4. 12品質の見分け方12分

このレッスンのゴール

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

受け入れ条件を先に書く

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

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

プレビューは下見

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

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

あやしいときの聞き方

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

理解チェック

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

開いただけでは「済」になりません。チェックできたら押してください。

実践

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

このレッスンで出てくる用語

全部覚える必要はありません。気になる言葉だけ開いてみてください。

用語集を全部見る →

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

QA 視点 / 受け入れテスト

マイルストーン

レビューの土台ができました

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