「開発チーム」とQA /"Development Team" and QA

Cybozu Meetup #11 アジャイルQA で発表しました。
https://cybozu.connpass.com/event/79018/

Transcript

1. 「開発チーム」とQA
   Cybozu Meetup #11
   サイボウズ株式会社
   東京品質保証部 小山 晃久
   1
   

   View Slide

2. About me
   ● 小山 晃久
   ● 2016年4月 新卒入社（人文系院卒）
   ● QAとしてGaroonのお問い合わせ対応 → 2017年7月からス
   クラムチームに参加
   ● 趣味は読書
   ○ 最近読んだ: フロイト『精神分析入門』、ゴールドラット『ザ・ゴール』
   ○ 今読んでる: ギャロウェイ『プロトコル』
   2
   

   View Slide

3. What is Scrum?
   「スクラムガイド――スクラム公式ガイド: ゲームのルール」
   著: Ken Schwaber and Jeff Sutherland
   訳: 角征典
   http://www.scrumguides.org/docs/scrumguide/v2017/20
   17-Scrum-Guide-Japanese.pdf
   3
   

   View Slide

4. Garoon開発
   ● 中堅・大規模組織向けのグループウェア
   ● 日本・ベトナム・中国で多拠点開発
   ● ウォーターフォール → スクラム
   4
   

   View Slide

5. View Slide

6. スクラムチームの構成
   6
   

   View Slide

7. 3拠点 / 8チーム
   ● 日本3チーム・ベトナム4チーム・上海1チーム
   ● 日本の3チームのうち1チームは “Nexus”
   ○ チーム間を取り持つ
   7
   

   View Slide

8. Our team
   8
   PG
   PG
   SM
   PG
   QA
   QA
   

   View Slide

9. 開発プロセス
   9
   

   View Slide

10. スクラム以前
    ● ウォーターフォール
    ● リリースは6か月に1度
    ● 開発期間 → 試験期間（機能試験 → 回帰試験）
    10
    

    View Slide

11. スクラム以後
    ● リリースは3か月に1度
    ● 1リリース = 約6, 7スプリント
    ● 1スプリント = 3週間
    ● 1スプリント内で開発も試験もやる
    ● 各リリースの最終スプリントは（原則）新規開発しない
    11
    

    View Slide

12. QAがやっていること
    12
    

    View Slide

13. ● スクラムイベントへの参加
    ● 仕様書レビュー
    ● 試験設計・試験仕様書作成
    ● 試験実施
    ● 不具合管理
    ● リリース関連作業
    ● （場合によっては）仕様書作成
    13
    

    View Slide

14. ● スクラムイベントへの参加
    ● 仕様書レビュー
    ● 試験設計・試験仕様書作成
    ● 試験実施
    ● 不具合管理
    ● リリース関連作業
    ● （場合によっては）仕様書作成
    14
    

    View Slide

15. スクラムイベントへの参加
    15
    

    View Slide

16. スプリントプランニング
    ● 試験という観点からタスクの分割方法を提案
    ○ 「この機能を一度に実装するとテストケース数が膨大にな
    るので、分けて実装してほしい」
    ○ 「試験を簡単にするために、試験用の API を作るタスクを
    追加したい」
    16
    

    View Slide

17. リファインメント
    ● 現段階で決めておくべき仕様に漏れがないか調査
    ○ 「このケースではバリデーションエラーを返す？それとも不
    正な値が無視されるだけ？」
    ○ 「もしユーザーが○○の操作をしたらどうなる？」
    ● 過去の不具合情報を掘り出す
    17
    

    View Slide

18. レトロスペクティブ
    （ふりかえり）
    ● チーム内でふりかえり → KAIZEN
    ○ 開発中のブランチで動作確認したい
    ● → 開発環境の作り方をレクチャーしてもらう
    ○ ○○の試験に時間がかかった
    ● → 次スプリントでは試験する単位を変えてみる
    ○ もっと情報共有したい
    ● → Slack、分報の導入
    18
    

    View Slide

19. 試験設計・試験仕様書作成
    19
    

    View Slide

20. ● 実装と同時に開始
    ● できるだけ早く動くものを触ってみる
    ○ 試験対象を学ぶ
    ● よくわからないことがあれば都度聞く
    ● 仕様の漏れが見つかったらフィードバック・提案
    ● 実装者にテストケースについて相談（ただしうのみにはしない）
    ○ Aを試験すればBは試験しなくてもよい？
    ○ これはすべての動作環境で確認すべき？
    20
    

    View Slide

21. Good
    21
    

    View Slide

22. ● スケジュール（以前は試験期間にしわ寄せが）
    ● チーム内での連携
    ○ 相談しやすい
    ○ 品質への関心の向上
    ● QAのスキルを活かせている（気がする）
    ○ 不具合が出そうな点を事前に指摘
    ○ ユーザーが機能をどう使うか考える
    ○ あとで読んでも意味の分かる仕様書
    22
    

    View Slide

23. 課題
    23
    

    View Slide

24. ● 試験設計の成果物はスクラム以前のまま
    ○ テスト対象・テスト目的・テストケースを含むスプレッドシ
    ート
    ○ 自動テストと探索的テストで何ができるのか知る必要あり
    （銀の弾丸ではない）
    ● チーム間での情報共有
    ● 明確な成果はまだこれから
    ○ 適応に時間がかかる（一時的に生産性が下がる）
    ○ 技術的負債との闘い
    ○ ふりかえりで地道に KAIZEN を重ねる
    24
    

    View Slide

25. 最後に:
    「開発チーム」とQA
    25
    

    View Slide

26. スクラムガイドにおける「開
    発チーム」
    26
    

    View Slide

27. ● ある人にしかできない作業があったとし
    ても、スクラムにおける開発チームのメ
    ンバーに肩書きはない。
    ● テスティング、アーキテクチャ、運用、ビジ
    ネス分析のような専門領域であっても、
    スクラムは開発チームのサブチームを認
    めていない。
    27
    （Ken Schwaber and Jeff Sutherland著、角征典訳「スクラムガイド」p.6
    http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf）
    

    View Slide

28. Our team
    28
    PG
    PG
    SM
    PG
    QA
    QA
    

    View Slide

29. Our team
    29
    開発チームの
    メンバー
    開発チームのメンバー
    SM
    開発チームのメンバー
    開発チームのメンバー
    開発チームのメンバー
    

    View Slide

30. 30
    Question
    ● 開発チーム「の」QA は（役職・職能の意味では）存在
    しない？
    ● 開発チーム「と」QA（品質保証担当者あるいは品質
    保証という活動）はどのように付き合っていけばよい
    のか？
    

    View Slide