🧪

PRレビューを通じたUnit Test品質向上の14ヶ月

に公開
Test
自動テスト
QA
品質管理
idea

こんにちは。株式会社ココナラ QAグループの鈴木(まるちゃん)です。

こちらは株式会社ココナラ Advent Calendar 2025 13日目の記事です。

はじめに

いろいろな場面でUnit Testの重要さを説く場面が多くなってきたと感じます。実際にUnit Testを書き始めた、もしくはUnit Testを見直したチームも多いと思います。

弊社も例に漏れず、2024年1月からUnit Testの整備を続けてきました。そして2025年9月、最も積極的に取り組んだAチームで障害密度52.8%削減、本番障害数66.7%削減という成果を観測することができました。今回は375件のテストコードを含むPRレビューを通じて得た知見と、明確な成果に至るまでの全記録を公開します。

用語定義

障害密度 = QA時に検出した障害数 / コード変更量(KLOC)

本番障害数 = 本番に流出してしまった障害数

先に結論：どんな成果があったのか

最も積極的に取り組んだAチームで、障害密度52.8%削減、本番障害数66.7%削減を達成しました。

指標 FY2023 FY2024 FY2025 改善率(FY2023→FY2025)
障害密度(Aチーム) 0.72 0.70 0.34 -52.8%
本番障害数(Aチーム) 6件 3件 2件 -66.7%

Aチームは14ヶ月で255件のテストPRを提出し、継続的にテストを書き続けました。

一方、他のチームでも障害密度は改善したものの、本番障害数には差が出ました。 この違いがどう生まれたのか、以下で全て公開します。

背景 - なぜ自動テストポリシーが必要だったのか

クリティカルな本番障害の発生

FY2023、私たちのプロダクトでクリティカルな本番障害が立て続けに発生しました。ユーザー体験に大きな影響を与える重大な問題でした。問題の根本原因を調査したところ、QAチームがテスト活動したプロジェクトでは問題なく、流出元はQAチームが関わっていないプロジェクトに集中していました。しかし開発リソースに対してQAチームの人数は少なく、すべてのプロジェクトにQAチームが入ることは不可能でした。

品質意識の低下

FY2022からQAチームが発足し、プロジェクトにおいて品質活動を行い始めました。その過程でクリティカルな本番障害数は減る一方で、QA時の不具合数は減らない状態でした。QAチームが品質活動を担うことで、開発者の間に『最悪QAでテストすれば検知できる』という依存意識が徐々に広がっていきました。

進まないUnit Test実装

プロジェクトにおいて「最大の価値を最速で届ける」が最優先目標でした。その影響でプロジェクト遅延が発生すると、自動テストの実装が後回しにされることがありました。その影響でリグレッションが発生しやすい状態になっていました。さらにはテスト追加しようにも、テスタビリティを考慮した設計になっておらず、テスト追加を阻害していました。

自動テストポリシー策定

これら3つの問題を解決するために、 「エンジニア自身で品質意識を持ち、自分が自信を持ってリリースできるために自動テストを整備していく」 ことを目的にテストポリシーを策定することにしました。

テストサイズによる自動テストの定義

まず取り組んだのは、自動テストの明確な定義です。テストは以下の4つに分類されることが多いです。

  1. Unit Test
  2. Integration Test
  3. E2E Test
  4. Manual Test

これらの定義が曖昧だと、本来Unit Testで書くべきテストがUnit Testで書かれなかったり、逆にE2E Testで書くべきテストがUnit Testで書かれてしまい、テストの偽陽性を高めてしまいます。これを解決するために参考にしたのが、Googleが提唱する Test Sizes という考え方でした。
https://testing.googleblog.com/2010/12/test-sizes.html

GoogleのTest Sizesを選んだ理由は3つです。

これを踏まえて定義すると分類は以下のようになります。

分類 定義(Test Sizes)
Unit Test Test Sizesに定義されているFeatureすべてをテストダブルで置き換えたテスト群
Integration Test Unit TestのうちMediumでは利用許可されたFeatureのテスト群
E2E Test Unit/Integration TestのうちLargeでは利用許可されたFeatureのテスト群
Manual Test 自動化できない、もしくは自動化するコスパが悪いテスト群

"品質の高い"Unit Testの定義

次に取り組んだのは、「品質の高い」Unit Testとは何かの定義です。本来であればIntegration TestやE2E Testも整備するべきですが、一度にすべてを推進できません。そのため当時はUnit Testに絞って推進することにしました。

これらから、4つの指標を定義しました：

指標 説明
リファクタリングへの耐性が高い 偽陽性が限りなく低い状態を目指す
リグレッションに対する保護力が高い 偽陰性が限りなく低い状態を目指す
フィードバックが速い 修正してからFBまでの時間が限りなく速い状態を目指す
テストケースが明確である 何をテストしているテストなのか明確である状態を目指す

"品質の高い"Unit Testを書くためには？

定義だけでは不十分です。具体的にどう書くかのガイドラインも必要でした。後述の参考文献・資料を参考にして作り上げたプラクティス集の構成は以下になります。量が多いので詳細は割愛します。

構成
  • 事前準備
    • テストする目的ってなに？
    • とりあえずテストを書けばいいの？
    • "質"の良い自動テストとは？
  • 機能設計
    • Dependency Injection
    • Humble Object Pattern
  • テスト設計
    • 「リグレッションに対する保護力が高い」へのアプローチ
      • ホワイトボックステスト技法
        • 命令網羅(C0)
        • 分岐網羅(C1)
        • 条件網羅(C2)
      • ブラックボックステスト技法
        • 同値分割法と境界値分析
        • デシジョンテーブルテスト
        • 状態遷移テスト
  • テスト実装
    • テストダブル
      • トレードオフを理解する
    • 「リファクタリングへの耐性が高い」へのアプローチ
      • 実装詳細ではなく最終的なアウトプットを確認する
      • privateメソッドはpublicメソッド経由でテストする
    • 「テストケースが明確である」へのアプローチ
      • テストは完全かつ簡潔にする
      • メソッドではなく、振る舞いをテストする
        • 振る舞いを強調するようにテストを構成する
        • テストされる振る舞いに因んでテストを命名する
      • テストにロジックを入れない
      • 明確な失敗メッセージを書く
      • テストとコード共有：DRYではなくDAMP
        • 共有値
        • 初期設定の共有
        • ヘルパーメソッドと検証メソッドの共有
        • テストインフラストラクチャー
  • その他参考リンク

実践！自動テストポリシー推進 - 14ヶ月間、何をしたか

推進活動の全体像

自動テストポリシーを策定しても、それだけでは意味がありません。チーム全体に浸透させ、実践してもらうことが重要です。エンジニアを巻き込んだ推進活動は、2024年10月から開始し、2025年12月現在も継続中です。

PRレビューの実績データ

特に重点を置いたのが、PRレビューを通じた継続的な啓蒙です。14ヶ月間で、合計375件のPRをレビューしました。

チーム別レビュー数

チーム レビュー数
A 255件
B 61件
C 59件
合計 375件

チーム別PRレビュー数

月別推移

成果の発表 - 数値で見る改善効果

テストカバレッジ

テストカバレッジ

障害密度

障害密度

本番障害数

本番障害数

各指標の変化からわかったことと今後の展望

わかったこと

14ヶ月間の取り組みから得られた、データに基づく知見を共有します。

1. PR数が多いチームは本番障害数が少なかった

各チームのデータを比較すると、以下の傾向が観測されました：

チーム PR数 本番障害数(YoY)
A 255件 減少
B 61件 横ばい
C 59件 増加

唯一Aチームだけが本番障害数を減少させています。一方で、障害密度はどのチームも低下しています。この違いから、単にテストを書くだけでなく、継続的に大量のテストを書くことが、偽陰性の低下に繋がった可能性があります。ここから憶測ですがテストを書く中で、テスト設計のスキルが身につき、テスト漏れが低下した可能性があります。

2. カバレッジは品質の十分条件ではない

興味深いことに、BチームはAチームよりもカバレッジ向上率が高いにもかかわらず、本番障害数は減少しませんでした。このデータは 「カバレッジが高い = 品質が高い」とは限らない ことを示しています。

ただし、Cチームのように低カバレッジの場合は障害密度が改善しても本番障害は減らないことから、最低限のカバレッジは必要です

今後の展望

テストポリシー推進は、Unit Testの基盤構築フェーズから、次のステージへと進みます。

1. Integration Test(Medium)の拡充

Unit Testで個々のメソッドの品質は担保できつつあります。しかしTest SizesでUnit Testでテストダブル利用を推奨した部分のテストは書けていません。Unit Testだけではプロダクトの品質は担保できないので、次は Integration Testの整備を進めています。

2. レビュー自動化による効率化

現在、PRレビューの一部を生成AIに代替する施策を進めています。作成した自動テストポリシーをインプットすることで、レビュワー工数を削減し、より高品質な高度なテストコードのレビューが行えるようにします。

3. Unit Testの継続的改善

Integration Testを始めるからといって、Unit Testをおろそかにはしません。依然Cチームはカバレッジが低いため、施策を推進予定です。

この1年の取り組みで、「テストの文化」は確実に根付きました。 次は、その文化を土台に、より高度な品質保証体制を構築していきます。

参考文献

本記事は、以下の書籍・資料を参考に実践した内容です：

明日はまつもとさんによる「要件定義はSVOC + 5W1(2)Hで！」です。

ココナラでは積極的にエンジニアを採用しています。

採用情報はこちら。
https://coconala.co.jp/recruit/engineer/

カジュアル面談希望の方はこちら。
https://open.talentio.com/r/1/c/coconala/pages/70417

Discussion