kintoneエンジニアが紹介する品質向上のための取り組み / kintone engineer's take on quality improvement

Transcript

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 5min 5min 並列実行 並列実行
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
40. ご清聴 ありがとうございました！ 40