テストは書くより消すのが難しい/Deleting tests are harder than writing

PHPConference Japan 2026の発表資料です

Transcript

1. テストは書くより消すのが難しい 〜3ヶ月で60,000行のテストを削除した判断軸〜 PHPConference 2026
2. 自己紹介 名前：荻島 貴（おぎ） 所属：カオナビ 職業：開発者（PHPer） 特技：スノーボード トークン燃やすこと ←🆕 PHPCon Japan初登壇！
3. 個人開発のWebサービス
4. 過去の登壇
6. エンジニアリングカルチャー（？） https://speakerdeck.com/sanogemaru/lets-make-software-easy-to-discard https://www.docswell.com/s/naopusyu/KYD7W3-unused-code-cleanup https://speakerdeck.com/gennei/build-feature-toggles-to-be-thrown-away
7. なんか捨てたり、消したりすることに こだわりのある人（？）が多い
8. 本題
9. テスト、書いてますか？
10. テスト、消してますか？
12. ちょっと情報量多いですね...
13. 整理すると • なぜテストが消しづらいのか？ • テストコードはどうあるべきなのか？ • どうやってあるべき形に近づけていくのか？ • 必要なテスト、不要なテストをどうやって判断するのか？ • AIに任せるべきところ vs 人間が判断すべきところ
14. テストを消しづらい理由
15. テストは消しづらい • テストコードは顧客価値に直接影響しない • 「なくすのはなんか不安」「CIグリーンだし...」 • ひとつひとつのテストはそこまで重くない
16. そう考えていた時期が 私にもありました...
17. テストは消しづらい • テストコードは顧客価値に直接影響しない → 開発速度の低下は顧客価値を棄損しない？ • 「なくすのはなんか不安」「CIグリーンだし...」 → そのテストは「何を担保している」のか？ • ひとつひとつのテストはそこまで重いということはない → １ケース0.5秒もちりつもで確実に重くなる
18. 発表の前提となるスタンス 私たちがテストを消すことを躊躇する時、そこには「サンクコストバイアス」が 存在していないでしょうか？ テストコードとプロダクトコードを読み、そのテストが守っているものを正しく 認識できた時に「これは不要」と言い切れるようになるのでは...？
19. おさらい ✅ なぜテストが消しづらいのか？ ☑ テストコードはどうあるべきなのか？ ☑ どうやってあるべき形に近づけていくのか？ ☑ 必要なテスト、不要なテストをどうやって判断するのか？ ☑ AIに任せるべきところ vs 人間が判断すべきところ
20. テストコードはどうあるべきか？
21. どんな粒度で、 どのくらい書いたらいいのか？
22. A. 会社やチームによる
23. テスト戦略 • テスト戦略はその会社・チームの成熟度合いやステージによる • 共通しているのはテストにも粒度があり、適切に設計 する必要がある • 技術力が高ければ、速度を維持したまま（あるいはより高速に）開発しなが らテストを書ける
24. https://speakerdeck.com/k1low/phperkaigi-2023
25. 単体テストの考え方／使い方 • テストに関する発表で大体引用さ れてる • テストに関して体系的に学べる • 一人で読むの大変なので輪読がお すすめ（割と鈍器）
26. そうはいったって書けないものは書けない もちろん、実際に修練を積んだベテランであれば「テストを書いた方が早い」 も正になります。 ただ、経験の浅いエンジニアが多い現場や、スケジュールに対するプレッ シャーが強い現場、エンハンスよりも新機能が評価されやすい状況など、テ ストを書くためのモチベーションを維持しにくい環境があるのもまた事実。 そんな状況と私たちはどう向き合っていくべきなのでしょうか？
27. 「スタートアップだからテストを書かない」は正しいか？ “スタートアップのCTOクラスの人がたまにそういうことを 言っているのを聞くことがあります。もしくは「スピード優 先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを 書「け」ない、のではないでしょうか 。ただ、スタートアッ プという言葉に未熟であるという意味が含まれているの であれば「スタートアップだからテストを書かない」という 問は真になるかも知れません。スタートアップは得てして 未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いませ ん。でもそれは、スタートアップだからでもスピード優先 だからでもない。自分達が未熟だからで、そこには向き 合うべきだと考えます 。” https://blog.song.mu/entry/startups-and-test-code
28. 現状を正しく認識した上で 自身で判断することが大事
29. おさらい ✅ なぜテストが消しづらいのか？ ✅ テストコードはどうあるべきなのか？ ☑ どうやってあるべき形に近づけていくのか？ ☑ 必要なテスト、不要なテストをどうやって判断するのか？ ☑ AIに任せるべきところ vs 人間が判断すべきところ
30. どうやってあるべき形に近づけていくのか？
31. 前提となる自社の状況 • 「書く」ということは当たり前になっていた • 「どういうテストを書くべきか？」は書き手に委ねられていた • カバレッジ取得を目的としたテストや観点が重複したテストが存在 テストの絶対数が多く、CIの実行時間が長い ⬇ リリース回数に影響
32. 具体的にやったこと 1. 小さく実験 → 自チームのコードベースで実験し、効果を確認 2. 増やさない仕組みを作る → ガイドラインの整備、ADRの作成 3. 移行対象を減らす → まずは不要なテストコードを消す 4. 改善を実施
33. 具体的にやったこと 1. 小さく実験 → 自チームのコードベースで実験し、効果を確認 2. 増やさない仕組みを作る → ガイドラインの整備、ADRの作成 3. 移行対象を減らす 👈今回の話は主にここまで → まずは不要なテストコードを消す 4. 改善を実施
34. ADRについてはこちらをチェック https://speakerdeck.com/hanhan1978/adr-after-a-year
35. でも動くの難しくないですか？ • 予算は？ • 時間は？ • 人は？ • 承認は？
36. A. そんなものはない
37. https://speakerdeck.com/hanhan1978/avoid-php-legacy
38. https://speakerdeck.com/hanhan1978/avoid-php-legacy
39. つまりは「気合い」
40. おさらい ✅ なぜテストが消しづらいのか？ ✅ テストコードはどうあるべきなのか？ ✅ どうやってあるべき形に近づけていくのか？ ☑ 必要なテスト、不要なテストをどうやって判断するのか？ ☑ AIに任せるべきところ vs 人間が判断すべきところ
41. 「不要なテスト」を どうやって判断するのか？
42. こんなAPIテスト見たことありませんか？
46. APIのテストは重い ①顧客価値に直結するようなハッピーパスやバリエーション → 残すべき ②エッジケースや異常系 → より軽量なテストで担保できないか？ 例：バリデーションエラー時に422を返す
47. 基準を元に以下のトリアージ用カテゴリを作成 A. すでに重複する観点がより軽量なテストで担保されている（削除可） B. より軽量なテストで担保可能（削除可） C. テストコードの書き方を変えるだけで改善が期待できる D. プロダクトコードの改修を行えばより軽量なテストで担保可能 E. 削除ができないもの（必要なテスト） これらを元にトリアージと削除をAIを使って実施
48. トリアージ〜削除の手順 調査 1. 2. 3. 4. 実装 コードを読ませる 判定 判定結果をレポート インデックス追加 🤖20〜80並列 1. 2. 3. 4. レビュー 削除前に再調査 コードを削除 AIレビュー MR作成 🤖10〜20並列 1. 2. 3. セルフレビュー レビュアーレビュー マージ（削除完了） 👨基本直列
49. おさらい ✅ なぜテストが消しづらいのか？ ✅ テストコードはどうあるべきなのか？ ✅ どうやってあるべき形に近づけていくのか？ ✅ 必要なテスト、不要なテストをどうやって判断するのか？ ☑ AIに任せるべきところ vs 人間が判断すべきところ
50. AIに任せるべき VS 人間が握るべき
51. やった中で起きた大小のトラブル 1. トリアージを誤判定 → 実際には依存が複雑で削除できないものが多数あった 2. 削除可能なテストを誤判定 → 実際にはカバレッジがないテストを削除しようとした 3. 作成された MRがフォーマットに則っていない → サブエージェントへの指示不足
52. 🤖「プロダクトコードに変更なし、 レビューは不要です！」
53. 任せてよかった 🤖 自分で握ってよかった 👨 1. アタリをつける 1. 判断基準の作成 2. 機械的にできる作業 2. 「ループ」の設計 3. 検証可能な作業 3. 成果物の確認
54. おさらい ✅ なぜテストが消しづらいのか？ ✅ テストコードはどうあるべきなのか？ ✅ どうやってあるべき形に近づけていくのか？ ✅ 必要なテスト、不要なテストをどうやって判断するのか？ ✅ AIに任せるべきところ vs 人間が判断すべきところ
55. まとめ • テストが消しづらいのは理解しきれていないのでは？ • テスト戦略は現実と向き合いながら考える • 行動を起こす時はまずは小規模に 「増やさないこと」と「減らすこと」を分けて考える • AIはテコとして使い、人間が最終責任を持つ
56. ご清聴ありがとうございました