自組織にあったテストピラミッドを 設計しよう！ Teppei YAMAGUCHI @ Scrum Fest Niigata 2025 

自己紹介： Teppei YAMAGUCHI 自己紹介 株式会社 LayerX 所属 兼 個人事業主 プログラマー、コンサルタント、コーチ、テスター LayerX では、プロダクトのテスターをおこないつつ、事業部全体 の自動テスト環境や品質可視化の構築・整備も担当 出版 『ソフトウェアテストをカイゼンする 50 のアイデア』 『Fearless Change』 コミュニティワーク Regional Scrum Gathering Tokyo 実行委員 SQiP 研究会 分科会 4「アジャイルと品質」アドバイザー テスト自動化研究会 お世話係 © LayerX Inc. 2 / 16 

今日お話しすること © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ なぜテストピラミッドを自組織で「設計」するのか？ 現時点での私たちのテストピラミッド 私たちの設計プロセス まとめ 3 / 16 

テストピラミッドとは © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ 自動テストをテストの種類ごとに分類し、理想的なテストの量やテストの速度など、テ ストの種類間の違いを抽象的かつ簡便に伝えるモノ しかし、多くの組織で「知っている」だけで「使えていない」現状がある 4 / 16 

なぜ、テストピラミッドを自組織で「設計」するのか？ © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ 自動テストは書いていたものの、テストの粒度、責任範囲が曖昧 テスト実装時に迷いやチーム内の認識ズレが発生していた 例：「このテスト、ユニット？ それとも結合？」 自動テストを書く際に、どのツールを使うのか、またその使い方が不明確 上記の同様の課題 組織横断でのツール整備が進まない 5 / 16 

現時点での私たちのテストピラミッド 自組織にあったテストピラミッドを設計しよう！ 詳しくは「バクラク事業部のテストピラミッド設計」というブログ 記事を公開済みですので、ブログを参照ください © LayerX Inc. 6 / 16 

現時点での私たちのテストピラミッド（保証すること・確認すること） テスト名称 保証したいこと 何を確認するのか 使うツール E2E シナリオテスト お客様がやりたいことが実現できるか ユースケースが正しく実現できている Autify & Playwright(UI テストとは 別物) ページ UI テスト 操作画面が想定通りに表示され、操作で きるか 1. 操作するページが想定と異なっていない 2. ページを想定通り操作できる Playwright コンポーネント UI テ スト 画面コンポーネントが想定通りに表示さ れ、操作できるか 1. 操作するコンポーネントが想定と異なっていない 2. コンポーネントを想定通り操作できる Storybook API テスト 1. コードが想定通り動くか 2. 接続箇所が想定通りの設計になってい るか 1. 各コンポーネントが正しく動作している 2. 複数の API を利用した API が正しい値を返している 3. API のユースケースが正しく実現できている runn コンポーネントユニッ トテスト 画面側のコードが想定通り動くか UI コンポーネントが、出力する HTML, CSS のレベルで正しく動作して いる（= ブラウザはモック） Jest+testing-library or Vitest+testing-library ユニットテスト コードが想定通り動くか 1. 各コンポーネントが正しく動作している 2. 単体で実行できる API が正しい値を返している 言語のテストフレームワーク © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ 7 / 16 

自組織でのテストピラミッド設計の流れ 

「知っている」から「使える」へ © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ 自分たちの「文脈」に合った定義が必要 プロダクトの特性（toB SaaS、複数プロダクト横断がある） アーキテクチャ（モノレポ指向、マイクロサービス、フロントにロジックがそれなりにあるなど） 開発体制（複数チーム） テストピラミッドを設計し、使うことで目指す姿 共通認識に基づき、迷いなくテストを書ける 全自動テストがワークフローに自然に組み込まれる 9 / 16 

設計プロセス：誰が、どのように？ © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ ワーキンググループ化して実施 QA エンジニア (← 私) 複数の開発エンジニア なぜ「一緒に」設計するのか？ 目的は「現場で使える」定義 → 現場の意見・実態が必要 「共通認識」を醸成するため → 一緒に考えるプロセスが重要 「定義した人」だけでなく「使う人」が主体に 10 / 16 

設計プロセス：まず始めに © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ 現状のテストの棚卸し どのようなテストをどんな粒度で、どのツールを使って書いているか？ 暗黙のルール、困りごと、実現できていること 定義する目的・ゴールの言語化 なぜ今、定義が必要なのか？ 何を解決したいのか？ 11 / 16 

設計プロセス：レイヤー定義の具体化 テスト名称 保証したいこと 何を確認するのか 使うツール E2E シナリオテスト お客様がやりたいことが実現できるか ユースケースが正しく実現できている Autify & Playwright(UI テストとは別物) ページ UI テスト 操作画面が想定通りに表示され、操作できるか 1. 操作するページが想定と異なっていない 2. ページを想定通り操作できる Playwright © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ 一般的な概念をベースに、「私たちの言葉」として明文化 各レイヤーで 「何を保証して、何を確認するのか」 を定義 保証したいことの明文化で、大まかに境界線を定義 確認することの明文化で、テストの内容を定義 各レイヤーで主に使うツールを定義 12 / 16 

設計プロセスを経て得られた「効能」 © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ テストピラミッドを自分達で定義することにより得た効能 効能 ①：テスト実装時の「迷い」が解消された 効能 ②：組織全体のツール整備が加速した 効能 ③：コミュニケーションが円滑になり、共通言語が生まれた 効能 ④：ワークフローへの統合とフィードバックの高速化 詳しくは「テストピラミッド定義がもたらした LayerX バクラク開発チームの変化と効能」というブログ記事を公開済みです ので、ブログを参照ください 13 / 16 

定義は継続的に見直す © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ 作成したテストピラミッドの定義は継続的に見直す必要がある テストの増加によるテストツールの変化 例: Autify だけから Autify と playwright の併用 新たなフレームワークやテストツールの導入による変化 例: jest から Vitest への移行 確認したいことの変化 14 / 16 

まとめ 

テストピラミッドを自組織で設計してみてはいかがでしょうか © LayerX Inc. 自組織にあったテストピラミッドを設計しよう！ 「自組織の文脈に合わせた定義を、複数人で共に創るプロセス」そのものが重要！ 共通認識が生まれる 実際の活用が進む 組織文化が醸成される テストピラミッドは「完成形」を目指すものではない 完璧を目指さず、小さく始めることがおすすめ 今日から始められる第一歩 現状のテストの棚卸しから始める チームで 1 時間のワークショップを設定 小さな範囲（1 プロジェクト）から始める 16 / 16