「またこのバグ…」を未然に防ぐ！手戻りの質を変えた3つの視点

概要

• 開発チケットに「3つの視点」によるチェックリストを追加し、実装時のセルフチェックを強化しました。
• その結果、ロジック漏れのような「重い手戻り」が激減し、文言修正などの「軽い手戻り」へと質が変化しました。
• 1人目QAとして取り組んだ、バグを見つけるのではなく「バグを作らせないプロセス改善」の記録です。

1. はじめに

こんにちは、株式会社ゼストでQAエンジニアをしている宮垣です。 今年の7月に1人目のQAとして入社し、あっという間に半年が経ちました。

最初は複雑な製品仕様をキャッチアップするだけで精一杯でしたが、業務に慣れてくると、ある「もどかしい傾向」が見えてきました。それは、開発からQAにパスされたチケット（PBI）が、「同じような理由で差し戻しにされる」ケースが非常に多いということです。

今回は、この手戻りを減らすために私が取り組んだプロセス改善と、その結果見えてきた「バグの質の変化」についてお話しします。

2. 課題：コンテキストスイッチという見えないコスト

私が直面していた課題はシンプルです。「QA期間に入ってから、基本的なバグが頻発する」ことでした。

• バリデーションが効いていない
• 必須項目なのに空で保存できてしまう
• エラーメッセージが表示されない

これらはQAで見つければ修正できますが、「見つけて直すコスト」は想像以上に高いものでした。 開発者はすでに別のタスクに着手しているため、修正のために頭を切り替える（コンテキストスイッチ）コストが発生します。QAもテストフローが寸断され、お互いに「またこのパターンか…」と疲弊していました。

3. アプローチ：QAの知見を「実装前の武器」にする

そこで私は、QA工程でバグを指摘するのではなく、「実装時に開発者自身が気づける仕組み（シフトレフト）」を作ろうと考えました。

過去にReopen（差し戻し）になったチケットを分析し、「なぜ漏れるのか？」を突き詰めると、単なる不注意ではなく「他機能との整合性」や「UIの状態変化」への意識が希薄になりがちであることがわかりました。

そこで、以下のドキュメントを作成し、開発チケットの必須確認項目として運用することにしました。

作成した「思考補助」チェックリスト

単に「確認しましたか？」と聞くのではなく、「どのような観点で見るべきか」という視点を提供することを意識しました。具体的には、以下のような観点を確認項目として挙げています。

① UI/UX：表示の一貫性と情報の粒度 単に「画面が表示されているか」だけでなく、既存機能との整合性や、画面遷移による情報のブレがないかを確認します。

• デザインシステムとの整合性： 新しい機能のアラートや強調表示は、すでに存在する類似機能のデザインルールと矛盾していないか？（ユーザーが直感的に意味を理解できるか）
• 情報の等価性： 一覧画面と詳細画面で、使われている用語や定義に食い違いはないか？

② インタラクションと相互作用（最重要） ある機能を操作した結果が、他の機能にどう影響するかを確認します。特にデータの競合が発生しやすい箇所は重点的に見ます。

• 双方向の競合判定： 「Aを操作してBと競合した場合」だけでなく、「Bを操作してAと競合した場合」も同様に正しくハンドリング（警告やエラー表示）されるか？
• 同期の即時性： 別の画面や機能でデータが更新された際、現在見ている画面にもその状態変化が正しく反映されるか？

③ エッジケースと堅牢性 開発時には見落としがちな「極端なケース」や「意地悪な操作」を明文化しました。

• 境界値の描画： 日付やページをまたぐようなデータを作成した際、UIは仕様通りに（途切れずに、あるいは分割して）描画されているか？
• UIの堅牢性（連打対策）： 通信環境が悪い状況などを想定し、保存ボタンを連打しても二重登録や予期せぬエラーが発生しない制御が入っているか？

4. 運用：チェックリストは「義務」ではなく「補助線」

このリストを導入する際、開発チームにはこう伝えました。 「全項目を埋める義務としてのタスクではありません。実装中に『あ、これ考慮したっけ？』と気づくための補助線として使ってください」

具体的には以下のフローで運用しています。

1. Step 1： 過去のバグ傾向から作成したテンプレートをチケットに貼る
2. Step 2： 開発者はPR作成前にセルフチェックを行う
3. Step 3： QAはそのチェック結果を前提に、より探索的なテストに集中する

5. 結果：差し戻しの「質」が変わった

このシンプルな改善を導入して数ヶ月、明確な変化がありました。 「差し戻しの総数」が減ったのはもちろんですが、より重要なのは「差し戻しの理由（質）」が変わったことです。

• 以前（導入前）：
  • 「重複判定が動いていない」「ボタン連打でデータが壊れる」
  • → ロジックの実装漏れ（修正にはコードを書き直し、影響範囲を再調査する必要がある＝重い）
• 現在（導入後）：
  • 「メッセージは出るが、てにをはが仕様書と違う」「アイコンの色が少し違う」
  • → 文言や定義のズレ（テキストや定数を修正するだけ＝軽い）

致命的なロジック漏れがQA前に除去されたことで、私たちQAチームは「当たり前の動作確認」ではなく、「より複雑なユースケースの検証」や「品質向上のための活動」に時間を使えるようになりました。

6. まとめ

QAの仕事は「バグを見つけること」だと思われがちですが、今回の取り組みを通じて「バグを作らせないプロセスを作ること」こそが、QAの真価だと実感しました。

特に1人目QAとしては、すべてを自分一人でテストすることは不可能です。だからこそ、開発者を巻き込み、チーム全体で品質意識を高める仕組みづくりが重要だと感じています。

今後も「小さな改善」を積み重ねて、開発チーム全体の開発生産性を上げていきたいと思います。