2016年5月23日（月）のDevLOVE関西勉強会「サイボウズの開発現場」での発表資料です。 https://devlove-kansai.doorkeeper.jp/events/43106

1. kintoneエンジニアが紹介する
品質向上のための取り組み
2016/05/23
サイボウズ株式会社 大阪開発部
酒井康晴

2. 今日の内容
自己紹介
品質とは
kintoneチームの品質向上への取り組み
まとめ
2

3. 自己紹介
3

4. 自己紹介
酒井康晴 @sakay_y
サイボウズ株式会社 大阪開発部
Webアプリケーションエンジニア
kintoneチーム所属
愛媛生まれ、神戸大学卒。
もうすぐ31歳。一児の父。親バカ。
趣味：野球、コーヒー。
4

5. 品質とは
5

6. 品質とは
「品質とは誰かにとっての価値である」
ジェラルド・ワインバーグ
Quality Software Management: Systems Thinking v. 1
6

7. kintoneチームの
品質向上への取り組み
7

8. kintoneチームの品質向上への取り組み
自動テストとビルドパイプライン
大規模データ対応
ユーザー価値の探究
8

9. 自動テストと
ビルドパイプライン
9

10. 自動テストとビルドパイプライン
Jenkinsでビルドパイプラインを構築
10
コンパイル ユニット
テスト アーカイブ
作成
APIテスト
ブラウザ
テスト
デプロイ
チェック
開発環境
デプロイ
全体で約55分
JS 4500ケース
Java 4000ケース
1900ケース
1200ケース
10min
8min
2min
10min
25min
5min5min
並列実行
並列実行

11. 11
怒りのJenkins先生
テスト失敗にすぐ気づける

12. 12
喜びのJenkins先生
すぐドッグフーディングできる

13. 自動テストの構成
ユニットテスト
JavaScript
PhantomJS + karma + Sinon.JS + expect.js
Java
JUnit + Matchers + mockito
APIテスト（内部API、REST API）
ブラウザテスト（受入試験、JavaScript API）
JUnit + Selenium Web Driver + Jenkins + Selenium Grid
+ Docker + Google Cloud Platform
13

14. Notify!
自動テストの構成
ブラウザテストの構成
14
Push! Build!
Parallel!

15. 自動テスト・デプロイのメリット
バグが少なくなる
安心してリファクタリングしやすい
テスターの工数削減
即ドッグフーディング＆フィードバック
15

16. 自動テストの注意点
自動テストの時間が長くなりがち
特にブラウザテスト
本当に必要なテストだけにする、要らないテストは捨てる
並列化を駆使する
お金を積んで物理で殴る
自動テストが定着しない
壊したら優先して戻す
放置されると、そのまま廃れてしまう
メンテナブルなテストを心がける
ビルドパイプラインに組み込むと強制力↑
16

17. 今後の展望
ビルドパイプラインをもっと早くしたい
個人的には30分くらい
Jenkins 2.0、気になります
4月21日にリリース！
https://jenkins.io/
17

18. 自動テストの知見
@miyajan によるサイボウズのSelenium知見
kintoneチームを支えるSeleniumテスト
http://www.slideshare.net/miyajan/kintoneselenium
Selenium Antipatterns
http://www.slideshare.net/miyajan/selenium-antipatterns
Distributed Selenium Testing with Google Compute
Engine
http://www.slideshare.net/miyajan/distributed-selenium-
testing-with-google-compute-engine
18

19. 自動テストのまとめ
自動テストと正しいお付き合いで品質向上！
19

20. 大規模データ対応
20

21. 大規模データ対応
増えるデータ量
1日に作れられる
アプリ数
稼働中のアプリ数
21
案件管理
契約書管理
交通費申請
社内 FAQ
クレーム管理
728個（1日平均）
24万個以上（2016年2月）

22. 大規模データで発生している問題
大量データ処理によって速度が劣化する
複雑な絞り込みでレスポンスが返ってこない
想定してなかった利用方法で秘孔を突かれて死ぬ
22
障害・お問い合わせ

23. サブチームでの対応
メンテチーム（2～5人程度）：
障害や問い合わせは最優先で調査、対応
お客様の業務が止まってしまう
未知の不具合の可能性
既存不具合の改修、KAIZEN
下回り改善チーム（2人）：
そもそも、障害が発生しないようにしたい
大規模データに対応できるように活動中
23

24. 大規模データ対応のまとめと今後
障害でお客様にご迷惑をかけてしまう
一番の問題
障害やお問い合わせ対応に費やす時間が増えている
生産効率低下
メンテチームで障害の原因つぶしやチューニング対応
下回り改善チームでアーキテクチャレベルでの改善
大規模なデータでも安定＆高速！
24

25. ユーザー価値の探究
25

26. ユーザー価値の探究
上流工程の品質をあげる
ユーザーに価値が
提供できるか？
製品の理想へ
向かっているか？
26

27. 27
エンジニアが
上流工程？

28. ユーザー価値の探究
仕様検討はエンジニアの仕事
仕様を考えるには、ユーザーの価値を明確に
プロダクトマネージャーと協力
28

29. Impact Mapping 勉強会
ゴールを目指す
なぜ（Why）やるか
だれ（Who）に価値を届けるか
どのように（How）変わるか
何を（What）提供するか
ステークホルダーを巻き込む
社長、プロダクトマネージャー
29

30. kintoneチームで実践
30

31. ユーザーストーリー勉強会
エッセンシャル スクラム 第5章
良いユーザーストーリーがあれば
仕様検討で迷わなくなる
ユーザーの価値を明確にできる
ユーザーストーリー
＜役割＞として私は＜目的＞したい。
なぜなら＜利益＞だからだ。
31

32. ワークショップ
32
kintoneエンジニア＋kintoneプロダクトマネージャー

33. デザインプロセス勉強会
Goodpatchさん主催でプロトタイピングを学ぶ
33

34. 成果
実際の開発でモヤモヤしたところを勉強して納得感
言葉の認識が揃い、共通言語で話せるようになった
ユーザーストーリーを書き、価値が明確な状態で
仕様検討することができた
kintoneが長期で目指すところを意識して開発できる
34

35. みんなハッピー！
35

36. 今後の課題
まだユーザーストーリー作成が小慣れてない
ユーザーストーリーとバックログ管理アプリの対応付け
→ 経験を積んで、アプリ改修 or プロセス改善
長期的なImpact Mappingはまだ作成中
→ 継続して作成
プロトタイピングが実装期間を圧迫
→ 開発プロセスの改善
36

37. まとめ
37

38. まとめ
「品質とは誰かにとっての価値である」
kintoneチームの品質を高める活動
自動テスト
ソフトウェア品質の維持向上
大規模データ対応
チームを分割してKAIZEN中
ユーザー価値の探究
エンジニア以外も巻き込んで探究中
38

39. 39

40. ご清聴
ありがとうございました！
40