Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Yasuharu.S

May 23, 2016
Tweet

More Decks by Yasuharu.S

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

  3. 自己紹介
    3

    View full-size slide

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

    View full-size slide

  5. 品質とは
    5

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  20. 大規模データ対応
    20

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. kintoneチームで実践
    30

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  35. みんなハッピー!
    35

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide