こんにちは。freee人事労務でQAエンジニアをしているnunです。freee QA Advent Calendar2025 18日目です。
今回はQA主導で各プロジェクトのリリース後に行なっているレトロスペクティブ、いわゆる振り返りについて書いていきます。この記事の中ではそうして開催している振り返りのことを「QA振り返り」と記していくこととします。
プロジェクトのより良い振り返りについて考えている方はぜひ最後まで読んでみてください。
QAがプロジェクトの振り返りを行う価値
どんなにQAが上流から関わっていようと、実装後〜リリース前にはQAによるテストプロセスが発生します。プロジェクトの最後の行程にあたる部分にいるQAは、プロジェクト理解の鮮度や振り返り開催時期の調整などの点で効率的です。
またQAによる品質指標を元にした定量評価を行うことで、常に一定の視点からプロジェクトを振り返ることができる点も有用です。ブレない指標を元にプロジェクトを振り返ることで、過去プロジェクトとの比較が行いやすいと言えます。
そして、こちらはあくまで自組織の都合なのですが、自分はfreeeに入社してから約3年給与チームのQAを担当しています。freeeの組織の都合上PM/デザイナー/エンジニアは入れ替わりが激しく、所属から2年が経過した辺りで自分が給与チーム歴の一番長いメンバーになってしまいました。そういった事情もあり過去プロジェクトとの比較した評価はもちろん、共通認識の維持や知識の継承といった点からもプロジェクト評価の重要性が増したように感じます。
他機能のテスト実行のヘルプに入ることもありました。その際にも該当するプロジェクトの品質評価を定量で客観的に提示する資料となり、品質について考える場を提供することができました。
そういった点からQAが振り返りを主導し定期的に開催することの効率性を感じています。
QA振り返りの中身
QA振り返りはQAが事前に資料を作成し、会に臨んでいます。会の中では資料の説明はもちろん、プロジェクトについてのフィードバックを広く集め、議論する形で開催しています。
・事前準備：目的と心得
私ははじめにQA振り返りの目的と心得を紹介するようにしています。
目的は、プロジェクトの中で起票された不具合分析の共有を行うことに加え、テストプロセスに留まらないプロジェクト全体へ目を向けることで次のプロジェクトに向けたチームとしてのネクストアクションの洗い出しを行うこと、と定めています。有難いことにこれまで課題もネクストアクションも出てこないというQA振り返りはありません。常に向上心を持ってプロジェクトに向き合うチームでい続けられていて素敵なことだなと感じます。
続いて心得では、QA振り返りを行う上で個人への攻撃を避けチーム全体の問題として捉えること、問題を防ぐためにどう仕組み化できるかを前向きに議論することの2点を中心に触れるようにしています。チームで動いている以上すべての問題は個人でなくチームに帰属し、チームの課題として捉えチームで建設的に予防策を考えたいためです。
・事前準備：不具合の詳細と品質指標
次にQAからの定量の品質指標として、数字から見るプロジェクトの品質について紹介していきます（ちなみに会ではスケジュールのおさらいをして、テストプロセスがどのくらいの期間あったのかという切り口からもプロジェクトを分析しますが詳細は割愛します）。
指標となるのは大きく、不具合数、プロジェクトで変更の入ったコードの行数、それらから分かる不具合の密度の3つです。
不具合数は、プロジェクト内で見つかった不具合*1の一覧を共有し、件数だけでなく重篤度の内訳がどうなっていたかを改めて紹介します。どの段階で不具合の作り込みを防げたか/どの段階で考慮できていると良かったかといった辺りもピックアップし、次のプロジェクトの不具合の入り込み予防につなげます。プロジェクトごとの機能の複雑さだけでなくメンバーの該当箇所の理解度といった要素も関わってくるため、かなり差が生じます。
フロントエンドに変更を加えるUI刷新メインのプロジェクトとバックエンドに変更を加えるプロジェクトとでも不具合の出方が異なってくるため、過去プロジェクトと比較する場合にはどちらか属する方と比較するようにしています。
変更の入ったコードの行数は、PR作成時にプロジェクトごとのMilestoneを紐付けてもらうことで計測できるようにしています。これはプロジェクトの複雑さや影響範囲によって差が生まれます。
不具合密度は、不具合数をコードの行数で割ることで算出するもので、1行あたり何個の不具合が入り込んだと言えるかを表す指標です。2つの要素を組み合わせて出す数字であり、3つの指標の中で最も比較しやすい指標と言えます。過去プロジェクトと比較することで、今回のプロジェクトの傾向が見えてくることもあります。
ちなみにQAからはこれらの指標とともに所感の共有も行います。指標がこうなっているからこういうプロジェクトと言えそう、実際自分もこういう印象だった、という流れです。
・当日の議論：課題
前述の品質指標について記載する枠と、それ以外の所感なんでも記載する枠を設け、そこへの記載から議論を行なっていきます。
色々な議論が展開されますが、やはりチームとしては開発エンジニアの割合が大きくなるため開発面での議論は多くなります。直近あったのは特定の機能の複雑度合いが高く見積りを誤った、後から更新の加わった仕様変更がドキュメントに反映できていなかったなどでした。
・当日の議論：ネクストアクションの提案
最後に、課題に対するネクストアクションの確定です。議論の中でアクションが見えてくることも多くありますが、それを改めて箇条書きにして漏れのないよう合意をするとともにラップアップにつなげる時間となります。先ほどの議論の例で言うと、想定以上に複雑だと分かった機能への変更を加える場合には多めに工数を見積もる、仕様変更が生じた際には変更の起きた場でドキュメント更新担当者を決め、最新化するとともにその変更が入った日付も併記する、などがアクションとなりました。
議論が発散し過ぎてアクションに迷う場合には抽象度を変えることで本質を見つめ直して落とし所を探ったり、議論が重くなりそうな部分は残った時間をすべて使う形で触れる順番を変えたりします。そうした議論の工夫やタイムマネジメントもファシリの腕の見せ所となります。議論が盛り上がるのは良いことではありますが、発散しすぎないよう注意しながらアクションの確定まで進めていきましょう。
QAがプロジェクトの振り返りを主導することで得られるもの
以上のような品質指標を用いたプロジェクトのQA振り返りを開催することで、常に一定の基準からプロジェクトを評価、比較することができるようになります。プロジェクトから学びを呼び起こし次につなげるという意味では感想戦としての振り返りでも問題ないのですが、品質指標を用いることでその感想を呼び起こすための切り口が提供できるようになります。QAというリリース直前のプロセスの立場から見た振り返りには、プロジェクト全体を包括して語れる広い視野があるとも言えます。
当たり前ですが完璧なプロジェクトなどなく、プロジェクトの進め方には常に伸び代があるものです。特に現在所属している給与という緻密さを求められるドメインにおいてはより良い品質への改善は欠かすことのできないものであり、こうしたチーム全体の取り組みと高い意識が、品質を保ち続ける一因だと考えています。
まだまだ自分のQA振り返りにも改善点はありますが、今後もプロジェクトの区切りとして開催し続けていきたいと思います。
品質指標を用いた定量的なプロジェクトの評価とその比較から見える改善点、少しでもより良い品質を突き詰めていく一助になれていれば幸いです。
明日は、品質企画の kuritaro-san が「99 回の成功と 1 回の失敗は同じ仕組みから生まれる ―障害に対する視座の転換」について記事を書いてくれます。 お楽しみに〜！
ではでは、よい品質を〜
*1:freee社内ではハッピーとも呼ばれます
