QAエンジニア入門　〜チームで品質を高める連携のしかた

●はじめに

■■■第1章　QAエンジニアの基本をおさえる
■■1.1　これまでのQAエンジニアと現在のQAエンジニアの姿
■1.1.1　よくあるQAエンジニアのイメージ
■1.1.2　変化してきたQA（品質保証）の役割
■1.1.3　多様化したQAエンジニアの姿
■■1.2　各職種から見たQAエンジニアの姿
■1.2.1　開発者から見たQAエンジニアの姿―品質の観点で開発を一緒に設計するパートナー―
■1.2.2　PdMから見たQAエンジニアの姿―意思決定を支える伴走者―
■1.2.3　デザイナーから見たQAエンジニアの姿―ユーザー体験を一緒に整える相手―
■■1.3　テストの役割と限界をおさえる
■1.3.1　なぜテストは欠かせないのか
■1.3.2　テストで証明できないこと
■1.3.3　テストとQAの関係

■■■第2章　QAエンジニアの業務を覗く
■■2.1　QAエンジニアのプロジェクトでの流れ
■2.1.1　仕様確認で「考慮漏れ」と「手戻り」を防ぐ
■2.1.2　テスト活動がどう進むのか
■2.1.3　リリース後の品質保証活動
■■2.2　テスト活動の具体例
■2.2.1　テスト計画：目的と作成方法
■Column　用語の混同を防ぐ：テスト戦略／テスト計画／「○○テスト」
■2.2.2　テスト設計：品質を担保する「観点」の引き出し
■Column　テスト設計技法入門：効率的なテストケースの作り方
■2.2.3　テスト実施：不具合を発見し、品質を可視化する
■Column　探索的テスト、アドホックテスト、モンキーテスト
■Column　良い不具合報告、悪い不具合報告：開発者との円滑なコミュニケーション術
■2.2.4　テスト終了作業：未来の品質を作るための振り返り
■■2.3　テスト以外の業務
■2.3.1　プロダクト開発への早期関与と「シフトレフト」
■2.3.2　プロセス改善の推進：データ活用と振り返り
■2.3.3　品質の文化を育む：日々の発信と、特別なイベント

■■■第3章　QAエンジニアの価値
■■3.1　QAエンジニアの貢献
■3.1.1　プロダクトとユーザーへの深い理解
■Column　QAエンジニアの「引き出し」は、どう作られるのか
■3.1.2　広い知識のネットワーク
■Column　フロントエンドとバックエンドを切り分ける「関心の分離」
■3.1.3　「いい感じ力」
■■3.2　QAエンジニアが提供する独自の価値
■3.2.1　「多角的」に評価する
■Column　職種別に見た「QAエンジニアの活かし方」の一例
■3.2.2　「本質」を見抜く
■3.2.3　「死角」を発見する
■■3.3　信頼がQAエンジニアの価値を生む
■3.3.1　なぜ信頼がQAエンジニアの生命線なのか
■3.3.2　信頼がもたらす価値の進化
■3.3.3　どうすれば信頼は生まれるのか
■Column　なぜQAエンジニアは「なぜ？」と問い続けるのか：根本原因を探る「なぜなぜ分析」

■■■第4章　QAエンジニアとの連携マニュアル
■■4.1　QAエンジニアを「仕様のレビュアー」として活用する
■4.1.1　「顧客価値と仕様のギャップ」を発見するセンサー
■Column　QAエンジニアはどんな目線でギャップに向き合っているのか
■4.1.2　「暗黙の要件」を掘り起こす質問者
■4.1.3　「受け入れ基準」を明確にする協力者
■■4.2　QAエンジニアを「リスクの可視化装置」として活用する
■4.2.1　リスクを「見える形」にする
■Column　なぜ「感覚」を「見える形」にするのか
■4.2.2　リリース判断に必要な「ユーザー影響」を伝える
■Column　なぜ「ピザ食べたい」だけでは伝わらないのか
■■4.3　QAエンジニアを「チームの学習装置」として活用する
■4.3.1　チームの学習を促進する「仕組みづくり」を推進する
■4.3.2　チームの品質意識とスキルを底上げする
■4.3.3　データにもとづいた継続的なプロセス改善
■Column　データは「人」を責めるためではなく、プロセスを見直すために使う
■4.3.4　「信頼」が、チームの学習装置を機能させる土台である
■4.3.5　QAエンジニアとして本章を読むあなたへ

■■■第5章　QAエンジニアの成長を阻む「壁」とAI時代の役割
■■5.1　QAエンジニアとチームの間に「壁」が生まれるとき
■5.1.1　役割の壁：QAエンジニアを「テスト実行部隊」と見てしまうとき
■Column　なぜ「QA＝テスト」というイメージが根強いのか
■5.1.2　プロセスの壁：「完璧な品質」を前提にした進め方
■5.1.3　評価と文化の壁：QAエンジニアの貢献が見えなくなるとき
■■5.2　QAエンジニアの「成長環境」を、チームの「利益」に変えるには
■5.2.1　「成長できない環境」が、チームに課すペナルティ
■5.2.2　チームの「コスト」を「利益」に変える、「いい感じ力」を実装する
■5.2.3　「いい感じ力」をチームの力に変える、3つの習慣
■■5.3　AI時代に、QAエンジニアは何を問い、何を守るのか
■5.3.1　AIを「使う側」の革命―QAこそが最大の受益者になる―
■5.3.2　AIを「作る側」の挑戦―賢いAIと安全に付き合うための新しい視点―
■5.3.3　未来へ：品質の「番人」から、価値の「共同創造者」へ

■■■第6章　品質と速度を両立するテスト自動化
■■6.1　なぜ、何を自動化するのか―価値と戦略を理解する
■6.1.1　自動化がもたらす真の価値
■6.1.2　何を自動化し、何を手動でやるべきか
■Column　戦略の指針となる「テストピラミッド」
■6.1.3　既存のテストツールか自作かをどう選ぶか
■Column　ロール別に見たテスト自動化への関わり方
■■6.2　どう自動化を設計し、運用するのか―実践のためのテクニック
■6.2.1　メンテナンス性の高いテスト設計
■6.2.2　テストデータと前提条件を設計する
■6.2.3　「何をテストしたいのか」から逆算して設計する
■6.2.4　CI/CDパイプラインへの統合
■■6.3　自動化を続けるための「技術」と「組織」の課題
■6.3.1　技術的な課題：不安定なテスト（フレーキーテスト）との向き合い方
■6.3.2　組織的な課題：スキル不足と属人化を乗り越える
■6.3.3　成功への道筋：小さくはじめてチームを育てる
■Column　テスト自動化でよくあるアンチパターン

■■■第7章　QAエンジニアとして現場でどう振る舞うか
■■7.1　はじめてQAエンジニアを担うときに知っておきたいこと
■7.1.1　QAエンジニアとして大事にしたい3つの考え方
■7.1.2　新しい現場／チームに入ったときに意識したい3つのこと
■7.1.3　自分の「現在地」をざっくり振り返る
■Column　本やブログで学んだテストを「自分の現場」にどう当てはめるか
■■7.2　QA組織をゼロから立ち上げるときの「品質活動プレイブック」
■7.2.1　まず決める：品質目標・スコープ・役割分担
■7.2.2　仕組みを作って回す：情報・会議・テスト・リリース判断
■7.2.3 段階的に広げる：シフトレフト・自動化・外部パートナー・持続可能性
■■7.3　キャリアと学び方をデザインする
■7.3.1　成長のステージと「次の一歩」
■7.3.2　キャリア／担う役割のバリエーション
■7.3.3　学び方とインプットの戦略
■7.3.4　QAエンジニアの成長を支える4つの力

●おわりに
●用語集