20260320_JaSST26_Tokyo_登壇資料.pdf

Transcript

1. © estie Inc. JaSST’26 Tokyo 村上 槙 / Murakami Shin AIを活用したリバースエンジニアリングで考える 自動テストの全体方針 1
2. © estie Inc. 自己紹介 2 x: @mura_shin0928 経歴： estie QAマネージャー ← Shippio QAエンジニア ← SHIFT QAキャリアスタート ← 愛知で自動車のソフトウェア開発 ← 福岡県生まれ 趣味： - マンガ、アニメ - お酒、ゴルフ（初心者） - 男性アイドル（妻の影響） - 最近けん玉 株式会社estie 2025/1：入社, 2025/8〜：QAマネージャー 村上 槙（murashi）
3. © estie Inc. アジャイル開発現場の「あるある」 こんな状況身に覚えありますか？ ドキュメント文化があっても、ポイントポイントでしか残らない ドキュメントは意思決定に使われるが、実装で詳細が詰まるのでコードが神様仕様 プロダクト初期からあるコードや仕組みは特にドキュメントがない → コードが唯一の「正」になっている
4. © estie Inc. AIで「振る舞いのテスト」は書きやすくなった 最近ではAIの力で、コードの振る舞いを理解するハードルが下がった DevinやClaude Codeに「この機能の振る舞いを教えて」と聞けばわかる世界 振る舞いを理解できれば、それに対するテストは書ける → 振る舞いのテスト は書きやすくなった
5. © estie Inc. AIで「振る舞いのテスト」は書きやすくなった playwright-cliやagent-browserを使えば 自然言語でE2Eテスト実装ができる時代 Skillsなどと組み合わせれば自律実装も実現できる
6. © estie Inc. AIで「振る舞いのテスト」は書きやすくなった playwright-cliやagent-browserを使えば 自然言語でE2Eテスト実装ができる時代 本当にそれだけで充分？ Skillsなどと組み合わせれば自律実装も実現できる
7. © estie Inc. それだけで充分？ 自動テストの目的は： システム全体が正しく動き続けていることを保証すること 適切なサイズのフィードバックを素早く得られること のはず AIによる超高速開発時代において、 E2Eテストが簡単に書ける！で満足している場合ではないし、 E2Eテスト以外を「開発者テスト」と言っている場合ではない。 → QAエンジニアもシステム構造を踏まえた自動テスト設計に今一度目を向けよう
8. © estie Inc. 本日のテーマ 振る舞いのテスト 構造に基づくテスト設計 ポイント この機能は正しく動くか？ どこに・何を・どの順でテストを配置するか？ AI活用 書きやすくなった ★本日の話 効果的な自動テストをどう設計していけばいいか？ → AIを活用した一つのやり方として、本日の内容を共有します。
9. © estie Inc. 自動テスト全体方針におけるポイント Where どこに・どんなテストを配置するか？ What first どこから着手するか？
10. © estie Inc. Where: どこに・どんなテストを配置するか？ 「Software Engineering at Google」を参考に2軸で整理 small medium large Test Size 単一プロセス 単一マシン 制約なし リソース DB・ネットワーク不要 Docker等でローカル完結 外部環境含む unit integration e2e Test Scope 単一モジュール 複数モジュール連携 システム全体 → どのSize × Scopeをどこに配置するか = システム構造を踏まえて決める 引用：https://abseil.io/resources/swe-book/html/ch11.html
11. © estie Inc. What first: どこから着手するか？ Emily Bache (Test Desiderata 2.0)： 「良いソフトウェアテストとはどのようなものか」を評価するためのモデル *Kent Beck氏考案のTest Desiderata 12の性質を4つのマクロ目標に再整理したもの ① Predict production success 本番環境で動くことの保証 ② Fast feedback 素早いフィードバック ③ Support design change コード変更を支える ④ Low cost of ownership 総保有コストを低く → 4つのマクロ目標をどれだけ広く満たせるかで優先度が決まる 引用：https://coding-is-like-cooking.info/2025/12/test-desiderata-2-0/
12. © estie Inc. 問いの再定義 Where（配置） システム構造の理解が必要 What first（優先度） 判断基準が必要 一方でドキュメントは不完全、コードが神様という状態... まず「コードからシステム構造を復元してみる」 → これをAIで加速するのが、本日の本題
13. © estie Inc. リバースエンジニアリングの流れ Step1: システム全体像を把握 Architecture Summary を取得 AI ↓ Step 2: Test Sizeで分類 テスト配置 を導出 AI ↓ Step 3: 優先度判断 4つのマクロ目標 で導出 AI+人間 ツール：Claude Code + drawio MCP
14. © estie Inc. Step 1: システム全体像を把握（INPUT） プロンプトイメージ： リポジトリはモノレポ＋外部サービス連携の構成です。 テスト戦略のために全体像を把握したいです。 以下を「サービス単位」の粒度で整理してください。 コンポーネントレベルの詳細は不要です。 1. サービス/アプリの一覧と一言説明 2. サービス間の依存関係（A→B = AがBを呼ぶ） 3. 外部サービス・インフラとの連携 4. 同期リクエスト以外の処理パターン： - 非同期処理（キュー、Webhook、 ジョブ非同期実行、ポーリング取得） - 定期実行処理（cron、バッチ等） 出力：(A) drawio構成図 (B) Architecture Summary ポイント： 粒度を明示 「サービス単位」を支持し、コンポーネントレベルは不要 非同期パターンを「処理の形」で例示 構造として重要だが指示しないとスキップされがち Architecture Summaryを出力させる → Step 2にそのまま渡せる情報
15. © estie Inc. Step 1: システム全体像を把握（OUTPUT） → コードから、サービス構成・依存関係・非同期パターン・定期実行が一覧化される システム構成図イメージ： Architecture Summaryイメージ：
16. © estie Inc. Step 2: Test Sizeで分類する（INPUT） プロンプトイメージ： 【前提情報】 （Step 1のArchitecture Summaryを使う） 【目的】 Test Size × Test Scopeで テスト配置の全体方針を決めたいです。 Test Sizeの定義： - small: 単一プロセス内。外部依存なし - medium: 単一マシン内。DBはローカル - large: 制約なし。外部環境をまたぐ 実行トリガー: Commit / Deployed / Scheduled 出力形式： 対象|Scope|Size|トリガー|外部依存|備考 重要：同一対象で複数行を作らない モックOK→medium、実環境必須→large ポイント： Step 1の出力をそのまま渡す コピペだけで済むようにする Test Sizeの定義を明示 Google準拠でAIの解釈ブレを防ぐ 実行トリガーを分類軸に追加 CIで回せるかが一目でわかる 重複排除を明示指示 後続の分類で重複が増える（integrationとe2eの区別が曖 昧になるなど）の問題を防止
17. © estie Inc. Step 2: Test Sizeで分類（OUTPUT） テスト対象 Scope Size トリガー 外部依存 FE 純粋ロジック unit small Commit なし FE コンポーネント統合 integration medium Commit GraphQL: MSW mock BE 純粋ロジック unit small Commit なし BE + DB integration medium Commit MySQL: Docker Cron 純粋ロジック unit small Commit なし Cron + MySQL integration medium Commit MySQL: Docker BE 外部サービス integration large Deployed Staging実API E2E e2e large Deployed 全実サービス Embulk ETL integration large Scheduled Staging実DB → システム構造からテスト配置が導出された
18. © estie Inc. Where どこに・どんなテストを配置するか？ What first どこから着手するか？ システム構造をもとにTest Size x Scopeでテスト配置を設計
19. © estie Inc. 【再掲】What first: どこから着手するか？ Emily Bache (Test Desiderata 2.0)： 「良いソフトウェアテストとはどのようなものか」を評価するためのモデル *Kent Beck考案のTest Desiderata 12の性質を4つのマクロ目標に再整理したもの ① Predict production success 本番環境で動く保証 ② Fast feedback 素早いフィードバック ③ Support design change コード変更を支える ④ Low cost of ownership 総保有コストを低く → 4つのマクロ目標をどれだけ広く満たせるかで優先度が決まる 引用：https://coding-is-like-cooking.info/2025/12/test-desiderata-2-0/
20. © estie Inc. Step3: 優先度判断 テスト対象 Size トリガー ①Predict ②Fast ③Change ④Low cost BE + DB medium Commit ◦ ◎ ◎ ◦ FE コンポーネント統合 medium Commit ◦ ◎ ◎ ◦ BE 純粋ロジック small Commit △ ◎ ◎ ◎ FE 純粋ロジック small Commit △ ◎ ◦ ◎ Cron + MySQL medium Commit ◦ ◎ △ ◦ Cron 純粋ロジック small Commit △ ◎ △ ◎ BE 外部サービス large Deployed ◎ ✗ △ ✗ E2E large Deployed ◎ ✗ ✗ ✗ Embulk ETL large Sched ◦ ✗ ✗ ✗ 凡例：◎強く満たす ◦満たす △部分的 ✗満たさない 各テスト対象を4つの評価軸で採点し、多くの目標を同時に満たすものから優先的に自動化する
21. © estie Inc. Step3: 優先度判断 テスト対象 Size トリガー 優先度 BE + DB medium Commit 高 FE コンポーネント統合 medium Commit 高 BE 純粋ロジック small Commit 高 BE 外部サービス large Commit 中 E2E large Deployed 中 FE 純粋ロジック small Commit 低 Cron + MySQL medium Commit 低 Cron 純粋ロジック small Commit 低 Embulk ETL large Sched 低 優先度「高」は CIで回せる medium/small に集中 AI -> 人間判断
22. © estie Inc. Where どこに・どんなテストを配置するか？ What first どこから着手するか？ システム構造をもとにTest Size x Scopeでテスト配置を設計 テスト配置に対してマクロ目標をもとに人間で最終判断
23. © estie Inc. 今回のアプローチで得られたもの E2Eテスト一辺倒から脱却 テスト配置表で「システム全体のどこを何で守るか」が設計され、各レイヤーで適切なテストが分かるようになった 適切なサイズのフィードバック small/medium/largeが適切に配置されることで、適切な自動テストを書くための方針が明確になった コンテキストゼロからの高速キャッチアップ システム構成図 + テスト配置表で”現在の状態”が簡単にキャッチアップできる SLO測定の議論の土台 SREなどチーム外メンバーと議論する際の土台にもなる
24. © estie Inc. 今回のアプローチで得られたもの E2Eテスト一辺倒から脱却 テスト配置表で「システム全体のどこを何で守るか」が設計され、各レイヤーで適切なテストが分かるようになった 適切なサイズのフィードバック small/medium/largeが適切に配置されることで、適切な自動テストを書くための方針が明確になった コンテキストゼロからの高速キャッチアップ Architecture Summary + テスト配置表が「現在地の地図」になる SLO測定の議論の土台 SREなどチーム外メンバーと議論する際の土台にもなる 高速に変化する事業・複数プロダクト・外部連携がある環境だからこそ、 キャッチアップの高速化と構造の整理が重要 全体像がわかる土台があることで氷山の一角だけでなく、 普段意識していなかった課題にも目が行くきっかけになる
25. © estie Inc. 課題 AIの出力は「叩き台」 非同期パターンの抜け漏れ、粒度の過不足など人間による調整は必要 ポリレポ構成では一プロダクト範囲に閉じる 他プロダクトとの連携部分の品質保証は別途検討が必要 コード上に表現されない重要情報がある 認証認可の設定、インフラ構成、環境変数など。これらを認識した上で構成図を活用する必要がある
26. © estie Inc. 今後の展望 今日（完了） ✓ 完了 全体方針 — Where・What first 次：個別テストの設計・実装 優先度に基づいて、さらに内部構造を深ぼった上で各テストを実装する → 方針に基づき具体的なモジュールや関数 (What) を決めた上でテスト実装する with AI その先：ハーネスエンジニアリング 今回作った構造化ドキュメントが、エージェントにテストを書かせる「文脈」になる AIエージェントにテストを書かせるための開発環境設計 ＝ ハーネスエンジニアリング 進行中 引用：https://openai.com/ja-JP/index/harness-engineering/
27. © estie Inc. まとめ 振る舞いのテストが書きやすい今だからこそ、システム構造に基づいて 「どこをどうやって守るべきか」に目を向けよう まずは、プロンプト打つだけ！ 誰でも簡単にできるのでぜひ明日からやってみてください！
28. ご清聴ありがとうございました！