こんにちは。支出管理プロダクトQAのsunnyです。 この記事はfreee QA Advent Calendar 2025の5日目の記事です。 本記事では支出管理プロダクトの開発に初期段階から携わり、QAとしてどう関わってきたかについて紹介します。
1. 上流工程から関わるとは
どういうプロダクトにしたいか、プロダクトが提供する価値をどのようにして届けるか？の段階から関わることと考えています。 業務プロセスでいうと、要件がPRDから共有される段階から関わり、エンジニアの設計方針のミーティング参加やQAが用意する受入基準の読み合わせにまで一気通貫して関わること&巻き込むことです。
どのような取り組みをしてきたか
プロジェクトが開始する初期段階では、メンバーでどのようなユーザー価値を届けるべきかを話し合います。PdM（プロダクトマネージャー）、 デザイナー、エンジニア、QAで協力し、ユーザーストーリーマッピングを用いた資料読み合わせを実施しました。*1
ユーザーストーリーは大まかにプロダクトが提供する機能単位で（プロジェクトにとって程よい粒度で）分割し、「ユーザーの種類がプロダクトが提供する機能を利用する。ユーザーのビジネス価値を実現するため」といった型を用います。 要求段階ではまだ解像度が低い状態であるからこそ具体的にどのように機能提供するのか、その提供方法はユーザー価値（マジ価値）があるのか話し合います。 話し合いを経て、以下の成果を得ることができました。
- ユーザーのジャーニー
- ユーザーが目的を達成するまでの具体的なステップの明確化
- MVPリリース範囲
- 価値のある最小限の機能群についてチームで合意することができた
- 共通理解
- メンバー間で目線合わせできた。共通の課題を認識できた
できることから、できるとこまで
開発初期段階では実際に動かせるものが何もない状態であるため、QAはユーザーストーリーから受入基準を作成したりテスト実行環境の整備を進めます。 また、本開発において外部ベンターの機能を利用することが決まっていたため、まずはマニュアルをもとに実際の振る舞いの確認を進めました。 提供されているベンダーのAPIと、我々が実現したいユーザーストーリーがどのように組み合わされるのかイメージしながら動作確認します。
runnを用いて様々なシチュエーションを想定したAPIの振る舞いを確認し、ドキュメントの整備を行いました。*2
ユーザーストーリーや機能ごとの読み合わせ会
PdM、エンジニア、QAそれぞれの視点で開発対象のユーザーストーリー及び機能の読み合わせ会を実施します。QA視点でわかったことの共有や、見落としていた点をお互いで補い合う形で埋めていきます。
| 名称 | 実施者 | 目的 |
|---|---|---|
| Product Requirements Document | PdM | 要件の認識を合わせる |
| Design Doc | エンジニア | 実装方針の認識を合わせる |
| 受入基準 | QA | ユーザーストーリーを満たすべき基準の認識を合わせる |
このやりとりを通じ、ユーザーの動き方や、DBのテーブルの関係が定まり、プロダクトでどのような操作をすると、どのテーブルに作用するか？を大まかに理解できる状態になりました。
2. 培った知識の集積と相互レビュー
以上の過程で得られた受入基準や、そこから作成するテストチャーターをQA専用のリポジトリにまとめました。大別すると以下の2種類です。
- ドメイン知識：チーム間で常時使用する用語の定義、プロダクトのAPI整理（ユーザーストーリーを満たす画面操作でどのAPIが利用されるか）、ER図の関係理解
- QA成果物管理：受入基準、テストチャーター、LLM用プロンプト、テスト実行時のツールなど
特に用語の整理はQAのみならずエンジニアも普段のコミュニケーションでも役立っています。 各々一つの用語に対して違うイメージを抱くことがあるため、プロジェクトのユビキタス言語を定義することで、エンジニアのDesign DocやQAの成果物で共通の用語で記載することができています。
この用語を通じてQAとエンジニアの成果物をお互いにレビューします。実装と受入基準の差をこの段階で縮めていきます。
QAは、エンジニアが作成したPull Request（PR）に対しコメントで受入基準を満たしているかを確認し、早い段階から仕様通りの実装となっているかを検証しました。実装の解釈に自信が持てない場合は、コードオーナーに確認したり、社内のLLM基盤やAsk Devin*3を利用します。 LLM基盤の整備により、ある程度のコミュニケーションコストを抑えつつ疑問点の質問や不足部分の指摘を行うことができたと感じています。
このような相互レビューを通じ、認識漏れを極力潰す手段を試していきました。
3. 上流工程から関わることによるメリット
これらの活動を通じて、以下の3つのプロセスが導出されました。
- 資料読み合わせ：ユーザーのジャーニーや実装を理解し、ユーザーストーリーに基づいたシナリオテスト観点を導出。
- 知識の集積：外部連携における異常系テスト観点の発見、集積した知識をもとにした受入基準やテストチャーターの作成。
- 相互レビュー：仕様の細かい齟齬や考慮漏れを発見し、境界値や例外処理に関する詳細なテスト観点を導出。
これらのプロセスを経て、メンバー間の解像度が上がり、認識の相違ズレを極力減らすことができていると感じています。早い段階から欠陥を検知できるようになり、手戻り少なく対応できることがおいしいポイントであると思います。
現状抱えている課題は、同期的なコミュニケーション機会が増えるため、個々人の作業を進めるスピードに影響がでることです。 この課題については、日々進化する社内LLM基盤を用いたツール群を組み合わせ、定型の作業を自動化することで効率化を図っていければと考えています。
4. まとめ
ソフトウェア開発は学習のプロセスであるという*4言葉の通り、ここまでの道のりで全く想定していない「え、こんなケースだとこんな振る舞いするの！？」という新たな未知の発見もありました。その度に学習・記録を繰り返し、プロセスを見直してきました。 この作業の積み重ねにより、この先発生するかもしれない未知の振る舞い*5を抑えられることを期待しています。 今後、引き続きLLMの力を借りながらより精緻に抜け漏れを発見できるよう、上流工程から関わることを前提にあれやこれやと試していきたいと思います。
*1:QAチームでのストーリーの作り方については決済プロダクトのマジ価値を最速で届けるためのバックエンドQAの事例を参照
*2:昨年のAdvent Calendarでrunnの試行錯誤について記事を書きました。ご笑覧下さい
*3:Ask Devinについては公式のAsk Devinを参照
*4:元文とは違う意味で引用しましたが、個人的にお気に入りのフレーズです。原文:We want to defer making decisions until the last responsible moment because software development is a process of learning. User stories and BDD (part #2) - Discovery
*5:このような不具合は社内では「ハッピー」と呼称しています
