はじめに
千株式会社でQAエンジニアをしているおすしです。
この記事は SEN Advent Calendar 2025の19日目の記事です。
本記事は、私たち社内QAチームがこの一年の活動を振り返る中で感じたことや、実際に試行錯誤してきた取り組みをもとにまとめたものです。
アドベントカレンダーという場を借りて、同じような課題意識を持つQAエンジニアの方が「自分の現場でも何か一つ試してみよう」と思えるヒントを持ち帰っていただければ、という思いで執筆しています。
なお、ここで紹介する内容は万能解ではありません。私たち自身もまだ試行錯誤の途中ですし、プロダクトや組織によって最適解は変わるはずです。 その前提で、あくまで一つの実践例として読んでいただければ幸いです。
「品質を上げるには、何をすればいい？」という問いから
「品質を上げていくため、改めて何をしていこうか？」
これは今年、QAチームの中での目標について会話した際の一部です。 改めて、というのは、中核を担うメンバー（@two_pack）が増えたことでQAチームで行っていくことを再構築していくために体制、方針などについて話しました。
千には複数のプロダクトがあり、QAチームは横断グループとして活動しています。 その中でこれまで未参画だったプロダクトへQAが参画するタイミングで、まずはQAが行っている足下の作業からアップデートを進めました。
以下は取り組んできたことの一例です。
＜取り組んできたこと（一例）＞
- プロダクトやプロジェクトに関わらず、テスト工程の管理をテスト計画からテスト終了判定まで同じ方式で行うように統一する
- QAの各工程での成果物のフォーマットをわかりやすく改善し統一のものを使用する
- 案件専用のSlackチャンネルを作り、他の案件の情報と混在しないように分ける
インプロセス活動への転換と横断的な視点確保への工夫
弊社ではこれまでQAエンジニアが多くない事情から、プロダクトに固定せずフレキシブルな動き方で活動することが多かったのですが、逆にプロダクトに常に密着したインプロセスの活動ができにくいことも課題として残っていました。
そのため、未参画だったプロダクトへの参画を機にインプロセスの方式へと転換しました。 但し、弊社のプロダクトは個々のプロダクト同士が大きなサプライチェーンでつながっているため、特定の範囲だけに注力した活動になってしまうと、全体としての目線が狭まったり、抜け落ちてしまう懸念があります。
このため、できる限りQAエンジニア同士が、プロダクトやプロジェクト横断で情報を取りやすくするために下記のような工夫をしました。 以下は横断で情報を把握しやすくするための工夫の一例です。
＜横断で情報を把握しやすくするための工夫（一例）＞
- 専用のSlackチャンネルには、主担当以外のQAエンジニアも参加することで、状況を追いやすくし必要に応じてフォローに入れるようにする
- 不具合を同じリポジトリ下で登録し、プロダクト毎で散らばっていた不具合情報を一か所で閲覧できるようにする
- QAでのレビューは主担当以外のQAエンジニアもレビューアとして参加し、狭い観点でのレビューに留まらないようにする
QAノウハウを開発チームへフィードバックしていく取り組み
加えて、QAチームやQAエンジニアのみが単独または独自で閉じてしまっては、改善まで向かうことが難しい活動もあります。 開発チームとの協力、信頼関係が醸成されて初めて価値ある活動になるため、今後もさらに感度高くアクションしていくことが求められます。
下記は改善のアクションとして継続取組中の内容の一例です。
＜改善のアクションとして継続取組中の内容（一例）＞
- 開発プロセスの最初から参加し、リスク分析を含む品質に関するフィードバックを行う
- 発生不具合に対して、実際の検出工程と本来検出すべき工程を整理し分析する
- 不具合の発生原因と未然防止策などについて、共有会を開催し開発チームと一緒に考える
開発チームへのテスト技術提供と全員で品質を作るために
また、下記はこれから挑戦をしていく事柄の１つです。
＜これから挑戦していく事柄（一例）＞
- QAチームは、開発チームが精度高くテストを行えるためのテスト手法など知見を提供する
こちらは、今までよりもさらに品質が高く、スピード感を持ってリリースをしていくうえでとても重要だと思っています。
と、このように書くだけであれば簡単なのですが、 これは、QAが最後の門番的な役割ではなく、QAチーム、開発チームを含む全体で品質を作る文化醸成の実現に必要なことです。
そして、この実現のためには、どこでどのような品質保証の手段があるのか、それが抜け漏れた場合には、どういう影響があるのかということを共有し認識する必要があります。
テストは品質保証における重要な手段の一つでもあり、果たす価値も大きいと考えている中で、それを全員で認識していくということと、テストを「決められた単なる作業」にしないということが重要だと思います。
「品質保証の設計」に目を向ける
また、品質保証の手段はテストだけではないということも大切なポイントです。 この視点で捉えると、考える対象が変わります。
- どんなリスクが存在するのか
- そのリスクは、どの手段で抑えるのが最も合理的か
- そもそもテストで見るべきリスクなのか
QAチームでは、プロジェクトの初期段階でこれらを整理する時間を意識的に取るようにしました。 例えば、
- プロジェクトの初期段階から参画し、PRDへの「リスク分析」やPBIにおける「受入基準」を策定する
- 仕様が曖昧な部分は、テスト設計に入る前に開発・デザイナーと一緒に言語化する
- 利用者価値に直結する振る舞いは、関係者を交えたレビューやモデリングで認識合わせを行う
といった具合です。その際に「どのような品質保証を行えば十分と言えるのか？」を検討、共有し関係者間で合意した上で進め、全員が納得した状態で自信をもってリリースを行うことを目指しています。
テストは手段の一つにすぎない
テスト以外にも、品質保証の手段は数多く存在します。
- レビュー、ペア設計、モデリング
- 仕様や意図の可視化・ドキュメント化
- 開発プロセスの改善
- ログ監視やメトリクス分析
- ナレッジ共有の仕組み化
これらをどう組み合わせ、どこに力を配分するかを考えること自体が、品質保証活動の中核だと私たちは捉えています。
具体例：私たちのチームで試していること
アドベントカレンダーということで、ここではいくつか具体的な取り組み例を紹介します。
1. リスクベースでの保証手段の割り当て
すべてをテストで確認するのではなく、リスクの性質ごとに手段を分けています。
- リリース時期とテストボリュームのアンマッチ： 計画段階でのテスト方針合意
- 仕様解釈のズレが起きやすい部分：QAと開発による早期レビュー
- 障害時の影響が大きい機能：テストにおける注力ポイントの策定
この整理を行うことで、「なぜここはテストしないのか」「なぜここは厚く見るのか」を関係者と合意しやすくなりました。
2. モデリングと対話による手戻り削減
テスト工程で不具合として顕在化する問題の中には、実は設計段階で防げたものも多くあります。 そのため、テスト分析の中で画面遷移図や状態遷移図を使ってモデリングを行い、QAが提案を行ってすり合わせを促すきっかけを設けています。
3. 「やらないこと」を決める合意形成
完璧を目指せば、テストはいくらでも増やせます。しかし私たちは、品質保証とはリスクをゼロにする活動ではないと考えています。
「今回はどこまで保証するのか」「どのリスクは受け入れるのか」を明示し、関係者全員が納得した状態でリリースする。この合意形成を支援することも、QAの重要な役割だと感じています。
おわりに：改善し続ける品質保証へ
私たちQAの仕事は、「テストだけをすること」ではありません。プロダクトが期待された価値を、継続的に提供できる状態をつくることだと思っています。
この記事が、読者の皆さんにとって
- 自分たちの品質保証のやり方を見直すきっかけ
- 明日から小さく試せるアイデアの種
のどちらか一つでも提供できていれば嬉しいです。 私たち自身も、まだ道半ばであり「より良くしていきたい」という思いを原動力に、これからも品質保証の仕組みづくりに向き合っていきます。
SEN Advent Calendar 2025 20日目となる明日はデザイナーのぽんさんです。どうぞお楽しみに！
そして！
私たちと一緒に、幼保業界や写真業界のDXを進めていく仲間を募集中です！ QAエンジニアの募集も行っていますので、ご興味がある方はご覧になってみてください！
📋 採用情報
