こんにちは。株式会社LayerX バクラク事業部 QAチームのteyamaguです。
私たちはバクラク事業部で、複雑なtoB向けSaaS開発において、品質保証と開発速度の両立を常に追求しています。以前からテストの重要性は認識しつつも、プロダクトや組織の拡大に対し、体系だったテストピラミッドの概念は明確には定義されていませんでした。その結果、現場でのテスト実装時に迷いが生じたり、ツール整備が組織横断で進めにくいという課題がありました。
この状況を改善すべく、私たちはバクラク事業部独自のテストピラミッドを、私のようなQAエンジニアと開発エンジニアが協力して定義しました。具体的な定義の内容については以前書いたブログである「バクラク事業部のテストピラミッド設計」 をご覧ください。また、定義に至るプロセスにご興味のある方は、2025年5月9-10日の「Scrum Fest Niigata 2025」での私たちの発表「自組織にあったテストピラミッドを設計しよう！」 もぜひご覧いただければ幸いです。
本記事では、テストピラミッドが定義されたことによる、その後の開発チームに起きた具体的な変化と効能に焦点を当てて紹介します。
1. テスト実装時の「迷い」が解消された
自分達のテストピラミッドが定義される以前は、テストの粒度や種類（ユニットか？結合か？E2Eか？）の判断が曖昧で、テストコードを書くエンジニアは迷うことがよくありました。チーム間でも基準が異なり、テスト実装に時間がかかったり、テストコードの一貫性が損なわれたりしていました。
テストピラミッドを定義し、各レイヤーの役割と範囲を明確にしたことで、この迷いが劇的に減少しました。「この機能のテストは、定義上この層に位置づけられる」「この層なら、推奨されるツールと書き方はこれだ」と、判断がスムーズになったのです。
これにより、テストコードを書く速度向上はもちろん、レビュー時のテストコードの実装方針の認識差異も低減し、開発効率が改善しました。
2. 組織全体のツール整備が加速した
定義がない状態では、テストに必要なツールの選定や実施手段の標準化も進みにくい課題がありました。テストピラミッドの定義に基づき、各レイヤーに最適な技術スタックを組織全体で選定・整備しました。
例えば、バックエンドのAPIテストとしては様々なツールがありますが、 runn を利用することを定め、runn の利用方法ガイドラインやCI実行のパイプライン作成などをおこないました。
開発エンジニアも巻き込んだワーキンググループでのツール選定や、共通設定・ドキュメントの整備を進めた結果、人・チームごとの環境差が少なくなり、開発環境をセットアップする標準的な手順内にテスト環境の構築も組み込めるようになりました。それにより、新しいメンバーもすぐにテスト開発に取り組めるようになり、開発効率向上に大きく貢献しています。
3. コミュニケーションが円滑になり、共通言語が生まれた
テストピラミッドの定義と共有は、チーム内のコミュニケーションにも良い変化をもたらしました。
共通のフレームワークがなかった以前は、例えば「E2Eテストツールで書かれたテスト」に対して、「これはユーザーシナリオ全体を確認したいんだっけ？それとも、特定のAPI連携がフロントに正しく反映されるかを見たいだけだっけ？」のように、「テストの確認手段（E2Eツールを使う、UIを操作するなど）」と「テストで本当に確認したい項目（特定の機能、API連携、UI表示の正しさなど）」が混同されがちでした。
しかし、ピラミッドの各レイヤーで「何を主な目的としてテストするのか」が定義されたことで、確認手段と確認項目を分けて議論できるようになりました。確認手段と確認項目が一致している場合には問題になりませんが、自動テストを作成する際には、確認手段と確認項目がずれることがあります。そのような際には、「これはE2Eツールで動かすけど、目的はAPI層に近い結合確認だからAPIテスト寄りの観点でレビューしよう」「このテストはUIを通すけど、見たいのはUIの崩れではなくバックエンドの処理結果だから、Page UIの正確性よりはデータ表示の正しさを重視しよう」といったように、テストコードの意図や目的を正確に伝え合い、意識した上での議論が可能になったのです。
全員が同じ「言葉」と「基準」でテストについて話せるようになった結果、不具合や仕様変更に関する議論で、「これは本来なら△△テストで検知されるべき」「この改修には〇〇テストを追加すべき」といった、ピラミッド上のレイヤーを明確にしながら会話できるようになりました。それにより、認識の齟齬が減り、議論の質が向上しました。私を含むQAと開発の連携も密になり、プロダクト品質に対する共通認識が深まっています。
4. ワークフローへの統合とフィードバックの高速化
テストピラミッドの定義とツール整備は、CI/CDパイプラインへのテスト組み込み方にも影響を与えました。各テストの特性が明確になったことで、CIワークフロー内での実行順序やタイミングを最適化しやすくなりました。未整備だった状態では、どのテストをCIのどのタイミングで実行するのが最も効率的か、判断が難しいこともありました。
例えば、高速に実行できるユニットテストやコンポーネントテストはPR作成時に実行して早期フィードバックを返し、時間のかかるテストはマージ時や定期実行とするなど、効率的なフローを構築。これにより、開発者はコード変更の影響を素早く確認でき、デプロイメントサイクル高速化にも繋がっています。
課題との向き合い、続く成長
ゼロから定義し、組織に浸透させる過程で、定義の解釈のブレやレガシーコードへの適用など、様々な課題にも直面しました。これらは、定期的な議論やドキュメント改善、実践の中での軌道修正を通じて乗り越えています。テストピラミッドは静的なものではなく、プロダクトと共に進化し続けるものです。
現在も、テスト実行のさらなる高速化やテストデータ管理など、品質向上のための探求は続いています。常に新しい課題に挑戦し、より良い開発体験とプロダクト品質を目指しています。
終わりに：変化を楽しみ、共に創る仲間を募集
LayerX バクラク事業部でのテストピラミッド定義を通じて、多くの学びを得ることができました。テスト効率向上だけでなく、コミュニケーション改善、共通認識の醸成という文化的な変化にも繋がっています。
私たちは、「自分たちの手で開発方法や文化を作り上げていく」プロセスを楽しみ、プロダクト品質に真摯に向き合う仲間を探しています。開発組織にはもともと品質を向上させていく意識が高く、その土台があったからこそ、テストピラミッド定義とその浸透を組織全体で進めることができました。
もし、この記事を読んで、私たちの品質へのこだわり、エンジニア主導の開発文化、そして変化を楽しむ姿勢に共感いただけたら、ぜひ一度お話ししましょう。テストピラミッドの「定義プロセス」に興味がある方は、Scrum Fest Niigata 2025 での発表もぜひ！ 以下のリンクより、私とのカジュアル面談をお申し込みいただけます。
