このページは何？
2026年4月24日に行われたQAセミナーについて書いたメモです。
トピックや内容のサマリ、それを受けての所感などを徒然なるままに書いていきます。
【登壇者】
中野 氏（株式会社LayerX バクラク事業部 QAエンジニア）
湯本 氏（フリー株式会社）
1. なぜ「テストマネジメント」を学ぶのか
「テストマネージャー」という役割に限定せず、「テストマネジメント」という活動を分解すると、現場のQAエンジニア（インプロセスQA）に役立つ知見が非常に多く含まれている
現場のよくある悩み:
- テスト計画に何を書けばいいかわからない
- 「リスク」の定義が曖昧で、優先順位がなんとなく決まっている
- ステークホルダーに対して、テストコストや妥当性を数字で説明できない
新シラバス（V3.0）の価値:
- 共通言語の構築:
- 用語と概念を揃えることで、現場の会話がスムーズになる
- アジャイル・ハイブリッド開発への対応:
- テストマネージャーだけでなく、QAエンジニアが活用できる技術として再定義されている
2. テストマネジメントの3本柱（シラバス構成）
新シラバスは以下の3つの領域で構成されている
① テスト活動のマネジメント
- プロジェクトテスト戦略:
- 組織全体の「組織的テスト戦略」をベースに、各プロジェクトのコンテキストに合わせて具体的なテストアプローチ（技法やレベルの組み合わせ）を決定する
- リスクベースドテスト:
- リスク（発生可能性 × インパクト）を識別・分析し、それに対する軽減活動（レビューやテスト）を定義して実行・モニターする
② プロダクトのマネジメント
- 欠陥マネジメント:
- バグのワークフロー管理。改善のためのデータ分析を行いやすくするため、終了ステータスを統一するなどの標準的な考え方を学ぶ
- テストメトリクス:
- プロジェクトの状況を数字で可視化し、意思決定の基準とする
③ チームのマネジメント
- スキル開発:
- チームに必要なスキルを4つの領域で可視化し、育成につなげる
- ステークホルダー管理:
- 関係者が「協力的」か「無関心」かなどを把握し、適切なコミュニケーション（期待値調整）を行う
3. 現場で活かすための実践アドバイス（Q&Aより）
テスト計画と戦略の立て方
-
「10分/ワンページ」テストプラン
- 膨大なドキュメントではなく、本当に決めなければならないこと（バグ管理、ステータス定義など）を簡潔にまとめる。テンプレートをに沿った穴埋め作業ではなく「思考の整理」として活用する
-
組織的戦略への落とし込み:
- 小さな成功体験（APIテストの共通ルール化など）をドキュメント化し、徐々に組織全体の標準へと育てていく
リスクベースドテストの運用
- 「リスク洗い出し会」の開催:
- プロダクトマネージャーやエンジニアを巻き込み、30分程度で懸念点を出し合う
- 出たリスク（ToDo）がリリースまでに「軽減活動済み（Done）」になっているかを徹底して追跡する
開発チームとのコミュニケーション
-
QAはエンジニアよりも下だと思わない:
- ユーザーは必要な箇所しか触らないが、QAは必要ない箇所も触る
- コードが書けなくても、ユーザー以上に製品を触り尽くすことで「仕様の番人」としての自信と信頼を獲得する
-
品質は「期待値」:
- 期待値が満たされないと不満（バグ）になる。サポートチームやPMと連携し、どこまでが許容範囲かの「落とし所」を合意するコミュニケーションが重要
感想など
- ゆもつよさんに質問したこと
- Q:全社方針を優先すべきか、それとも各事業部レベルまで具体化すべきかで、テスト戦略の適切な粒度に悩んでいる。事業部ごとに分断された組織で、全社的なテスト戦略を立てると、抽象的すぎて実行に落ちにくくな理想と感じている
- A:全社でやりたいかどうか、による。事業部ごとに独立した戦略を立てるのもよし。それでも全社QA的なスローガンはあったほうがいいかもしれないね
- 例）freeeでは「もっと早く、もっと手前で」がスローガンとのこと
- 中野さんがおっしゃっていた、「10分テスト計画」が刺さった
- 難しく考えずに取り入れられそう
- 1page Test Planというのもあるらしい
- これからの時代、「AIの活用」と「QAとして必要とされ続けるためのスキル向上」の両立には「人間がテスト計画を書く」がいいのではないか、という気づきを得られた（参照：mixi2）