Slide 1
Slide 1 text
新規プロダクトの
開発速度と品質の両立を
支える自動テスト
SaaS 新規プロダクトの技術
#RAKUSMeetup
福岡憲治
Slide 2
Slide 2 text
自己紹介
● 福岡 憲治（ふくおか けんじ）
● 2018 年に中途でラクスへ入社
○ 楽楽精算の開発を経て、現在は楽楽労務の開発/運用
○ 定期的なバージョンアップのための仕組みやルール作りに
奮闘中
○ テレワーク Now !
2
Slide 3
Slide 3 text
新規プロダクトならではの悩み
3
Slide 4
Slide 4 text
新規プロダクトならではの悩み
1. ドメインに対する理解が不十分・アジャイルに機能開発をして
いくので作り直しが発生する
2. チーム増員の際、新メンバーにも設計指針を浸透させるのが
難しい
3. ユニットテストだけでは結合レベルの品質が不安で、手動テス
トが減らない
4
Slide 5
Slide 5 text
本日お話しすること
新規プロダクトに、スピード感のある開発はとても重要
品質を保ちつつ、開発速度を両立するために自動テストは不可欠
です
● 自動テストって何をしているの？
● どういうとき嬉しいの？
5
Slide 6
Slide 6 text
目次
1. 楽楽労務のプロダクト概要
2. 楽楽労務の技術スタック概要
3. 開発速度と品質の両立を支える自動テスト
3.1. ユニットテスト
3.2. アーキテクチャテスト
3.3. E2E テスト
3.4. 自動テストの恩恵
4. テストコードを書くことが当たり前のチーム文化
6
Slide 7
Slide 7 text
1. 楽楽労務のプロダクト概要
7
Slide 8
Slide 8 text
楽楽労務のプロダクト概要
人事労務業にかかわる人のストレスをゼロに。
8
https://www.rakurakuroumu.jp/
Slide 9
Slide 9 text
2. 楽楽労務の技術スタック概要
9
Slide 10
Slide 10 text
楽楽労務の技術スタック概要
10
Frontend Backend
Vue.js Vuetify.js
Spring Boot
Batch
Slide 11
Slide 11 text
楽楽労務の技術スタック概要
11
Slide 12
Slide 12 text
3. 開発速度と品質の両立を支える
自動テスト
12
Slide 13
Slide 13 text
開発速度と品質の両立を支える自動テスト
● ユニットテスト
○ JUnit, Jest
● アーキテクチャテスト
○ ArchUnit
● E2Eテスト
○ Puppeteer
13
Slide 14
Slide 14 text
3.1. ユニットテスト（JUnit）
Slide 15
Slide 15 text
ユニットテスト（JUnit）
JUnit を用いて、Java プログラムのメソッドレベルの入出力が期
待どおりの動作をしているかを確認する
● テストカバレッジが約90%
15
Slide 16
Slide 16 text
ユニットテスト（JUnit）
マージリクエスト時に、レビューイ・レビューア共に
● 既存機能にデグレがないことに一定の安心感がある
● 既存機能にデグレがないか確認の時間を削減できる
※マージリクエスト・・・GitHubでいうとプルリクエストのこと 16
Slide 17
Slide 17 text
ユニットテスト（JUnit）
依存ライブラリを更新する際に、アプリケーションが壊れていない
ことに一定の安心感がある
● 特に、JDK と Spring Boot
17
Slide 18
Slide 18 text
3.2. アーキテクチャテスト（ArchUnit）
Slide 19
Slide 19 text
アーキテクチャテスト（ArchUnit）
ArchUnit を用いて、Java アプリケーションのパッケージやクラス
が設計方針（依存関係）に沿っているかを確認する
こんな悩みが解決できます
● 設計方針が納期優先、メンバ増加により泥団子に
● どのパッケージにクラスを置いたらよいか迷う
19
Slide 20
Slide 20 text
20
@Test
void ドメイン層のクラスは他の層のクラスに依存しない() {
noClasses(). that().resideInAPackage(“com.example.domain..”)
.should()
.dependOnClassedThat().resideInAnyPackage(
“com.example.infrastructure..”,
“com.example...”,
“com.example.application..”
)
.check(CLASSES);
インフラストラクチャ層
UI層
アプリケーション層
ドメイン層
Slide 21
Slide 21 text
アーキテクチャテスト（ArchUnit）
パッケージやクラスの設計方針のレビュー自動化
● 設計者の負担（ドキュメント作成/周知、レビュー指摘）の削減
● 開発メンバーはどのパッケージにクラスを置けいたらいいか迷
う時間がなくなる
21
Slide 22
Slide 22 text
詳しく知りたい方は...
22
https://speakerdeck.com/kawanamiyuu/jjug-ccc-2019-spring
Slide 23
Slide 23 text
3.3. E2Eテスト（Puppeteer）
Slide 24
Slide 24 text
E2Eテスト（Puppeteer）
E2E テストとは
● フロントエンド⇔バックエンドを結合したエンドツーエンドの動
作を、ブラウザ操作で確認するテスト
Puppeteer を用いて、ハッピーパスのブラウザ操作を自動化して
いる
※ハッピーパス・・・正常系の代表ケース 24
Slide 25
Slide 25 text
E2Eテスト（Puppeteer）
ハッピーパスが動いていることに一定の安心感がある
● 従業員登録
● 入社申請依頼
● etc...
25
Slide 26
Slide 26 text
3.4. 自動テストの恩恵
Slide 27
Slide 27 text
自動テストの恩恵
新規プロダクトならではの悩み
1. ドメインに対する理解が不十分・アジャイルに機能開発をして
いくので作り直しが発生する
2. チーム増員の際、新メンバーにも設計指針を浸透させるのが
難しい
3. ユニットテストだけでは結合レベルの品質が不安で、手動テス
トが減らない 27
Slide 28
Slide 28 text
自動テストの恩恵
新規プロダクトならではの悩み
1. ドメインに対する理解が不十分・アジャイルに機能開発をして
いくので作り直しが発生する
28
Slide 29
Slide 29 text
自動テストの恩恵
新規プロダクトならではの悩み
1. ドメインに対する理解が不十分・アジャイルに機能開発をして
いくので作り直しが発生する
→ 既存機能のデグレを一早く検知し、メインブランチへのマー
ジを防げる
29
Slide 30
Slide 30 text
自動テストの恩恵
新規プロダクトならではの悩み
2. チーム増員の際、新メンバーにも設計指針を浸透させるのが
難しい
30
Slide 31
Slide 31 text
自動テストの恩恵
新規プロダクトならではの悩み
2. チーム増員の際、新メンバーにも設計指針を浸透させるのが
難しい
→ 技術的にばらつきがある開発チームで、一定の強制力を
もってアーキテクチャの設計品質を担保できる
31
Slide 32
Slide 32 text
自動テストの恩恵
新規プロダクトならではの悩み
3. ユニットテストだけでは結合レベルの品質が不安で、手動テス
トが減らない
32
Slide 33
Slide 33 text
自動テストの恩恵
新規プロダクトならではの悩み
3. ユニットテストだけでは結合レベルの品質が不安で、手動テス
トが減らない
→ E2E テストも活用することで、アプリケーションが壊れてい
ないことに一定の安心感をもつことができる
33
Slide 34
Slide 34 text
自動テストの恩恵
リリーススプリントの結果を分析してみたところ、
● 回帰テストは
○ バグは多く発見できているが、軽微なものがほとんど
○ 時間効率が非常に低く、成果も小さい
新機能 既存機能 備考
リリーススプリント 工数（人日） バグ件数 工数（人日） バグ件数
単体テスト 5 11
回帰テスト 27 18 軽微なバグが多い
※リリーススプリント・・・リリース直前にテストやリリース準備を行う期間 34
Slide 35
Slide 35 text
自動テストの恩恵
これまで
○ 約1ヶ月半もの期間、リリーススプリントを実施
■ 「自動テストで一定の品質担保できているのでは？」と
いう気づき
● 今後は
○ リリーススプリントでのテストの実施方法を見直し、約1ヶ月
に短縮することにチャレンジ！
35
Slide 36
Slide 36 text
4. テストコードを書くことが
当たり前のチーム文化
36
Slide 37
Slide 37 text
テストコードを書くことが当たり前のチーム文化
プロジェクト立ち上げ時からテストコードを書くことを前提として始
めていたことが大きい
● プロジェクトの開発ガイドラインとして定めている
37
Slide 38
Slide 38 text
テストコードを書くことが当たり前のチーム文化
根底のモチベーションは何？
● 前身のチームから、ポジティブな印象が強かった
行動 結果
テストコードを書く
自動テストの結果から
● デグレをいち早く検知
● デグレがないことを即座に確認可
● 単体・結合テストの前にバグを潰せる
● アプリが壊れていないという安心感 38
Slide 39
Slide 39 text
おわりに
39
Slide 40
Slide 40 text
おわりに
新規プロダクトの「開発速度」と「品質」の両立を支える自動テスト
についてお話しました。
自動テストがなければ、テストフェーズでのバグ発生、手戻り多発
でリリースまでのスピードが落ちていたかも....
出来るところから、自動テストを書いていきませんか？
40