Slide 1
Slide 1 text
「開発チーム」とQA
Cybozu Meetup #11
サイボウズ株式会社
東京品質保証部 小山 晃久
1
Slide 2
Slide 2 text
About me
● 小山 晃久
● 2016年4月 新卒入社（人文系院卒）
● QAとしてGaroonのお問い合わせ対応 → 2017年7月からス
クラムチームに参加
● 趣味は読書
○ 最近読んだ: フロイト『精神分析入門』、ゴールドラット『ザ・ゴール』
○ 今読んでる: ギャロウェイ『プロトコル』
2
Slide 3
Slide 3 text
What is Scrum?
「スクラムガイド――スクラム公式ガイド: ゲームのルール」
著: Ken Schwaber and Jeff Sutherland
訳: 角征典
http://www.scrumguides.org/docs/scrumguide/v2017/20
17-Scrum-Guide-Japanese.pdf
3
Slide 4
Slide 4 text
Garoon開発
● 中堅・大規模組織向けのグループウェア
● 日本・ベトナム・中国で多拠点開発
● ウォーターフォール → スクラム
4
Slide 5
Slide 5 text
5
Slide 6
Slide 6 text
スクラムチームの構成
6
Slide 7
Slide 7 text
3拠点 / 8チーム
● 日本3チーム・ベトナム4チーム・上海1チーム
● 日本の3チームのうち1チームは “Nexus”
○ チーム間を取り持つ
7
Slide 8
Slide 8 text
Our team
8
PG
PG
SM
PG
QA
QA
Slide 9
Slide 9 text
開発プロセス
9
Slide 10
Slide 10 text
スクラム以前
● ウォーターフォール
● リリースは6か月に1度
● 開発期間 → 試験期間（機能試験 → 回帰試験）
10
Slide 11
Slide 11 text
スクラム以後
● リリースは3か月に1度
● 1リリース = 約6, 7スプリント
● 1スプリント = 3週間
● 1スプリント内で開発も試験もやる
● 各リリースの最終スプリントは（原則）新規開発しない
11
Slide 12
Slide 12 text
QAがやっていること
12
Slide 13
Slide 13 text
● スクラムイベントへの参加
● 仕様書レビュー
● 試験設計・試験仕様書作成
● 試験実施
● 不具合管理
● リリース関連作業
● （場合によっては）仕様書作成
13
Slide 14
Slide 14 text
● スクラムイベントへの参加
● 仕様書レビュー
● 試験設計・試験仕様書作成
● 試験実施
● 不具合管理
● リリース関連作業
● （場合によっては）仕様書作成
14
Slide 15
Slide 15 text
スクラムイベントへの参加
15
Slide 16
Slide 16 text
スプリントプランニング
● 試験という観点からタスクの分割方法を提案
○ 「この機能を一度に実装するとテストケース数が膨大にな
るので、分けて実装してほしい」
○ 「試験を簡単にするために、試験用の API を作るタスクを
追加したい」
16
Slide 17
Slide 17 text
リファインメント
● 現段階で決めておくべき仕様に漏れがないか調査
○ 「このケースではバリデーションエラーを返す？それとも不
正な値が無視されるだけ？」
○ 「もしユーザーが○○の操作をしたらどうなる？」
● 過去の不具合情報を掘り出す
17
Slide 18
Slide 18 text
レトロスペクティブ
（ふりかえり）
● チーム内でふりかえり → KAIZEN
○ 開発中のブランチで動作確認したい
● → 開発環境の作り方をレクチャーしてもらう
○ ○○の試験に時間がかかった
● → 次スプリントでは試験する単位を変えてみる
○ もっと情報共有したい
● → Slack、分報の導入
18
Slide 19
Slide 19 text
試験設計・試験仕様書作成
19
Slide 20
Slide 20 text
● 実装と同時に開始
● できるだけ早く動くものを触ってみる
○ 試験対象を学ぶ
● よくわからないことがあれば都度聞く
● 仕様の漏れが見つかったらフィードバック・提案
● 実装者にテストケースについて相談（ただしうのみにはしない）
○ Aを試験すればBは試験しなくてもよい？
○ これはすべての動作環境で確認すべき？
20
Slide 21
Slide 21 text
Good
21
Slide 22
Slide 22 text
● スケジュール（以前は試験期間にしわ寄せが）
● チーム内での連携
○ 相談しやすい
○ 品質への関心の向上
● QAのスキルを活かせている（気がする）
○ 不具合が出そうな点を事前に指摘
○ ユーザーが機能をどう使うか考える
○ あとで読んでも意味の分かる仕様書
22
Slide 23
Slide 23 text
課題
23
Slide 24
Slide 24 text
● 試験設計の成果物はスクラム以前のまま
○ テスト対象・テスト目的・テストケースを含むスプレッドシ
ート
○ 自動テストと探索的テストで何ができるのか知る必要あり
（銀の弾丸ではない）
● チーム間での情報共有
● 明確な成果はまだこれから
○ 適応に時間がかかる（一時的に生産性が下がる）
○ 技術的負債との闘い
○ ふりかえりで地道に KAIZEN を重ねる
24
Slide 25
Slide 25 text
最後に:
「開発チーム」とQA
25
Slide 26
Slide 26 text
スクラムガイドにおける「開
発チーム」
26
Slide 27
Slide 27 text
● ある人にしかできない作業があったとし
ても、スクラムにおける開発チームのメ
ンバーに肩書きはない。
● テスティング、アーキテクチャ、運用、ビジ
ネス分析のような専門領域であっても、
スクラムは開発チームのサブチームを認
めていない。
27
（Ken Schwaber and Jeff Sutherland著、角征典訳「スクラムガイド」p.6
http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf）
Slide 28
Slide 28 text
Our team
28
PG
PG
SM
PG
QA
QA
Slide 29
Slide 29 text
Our team
29
開発チームの
メンバー
開発チームのメンバー
SM
開発チームのメンバー
開発チームのメンバー
開発チームのメンバー
Slide 30
Slide 30 text
30
Question
● 開発チーム「の」QA は（役職・職能の意味では）存在
しない？
● 開発チーム「と」QA（品質保証担当者あるいは品質
保証という活動）はどのように付き合っていけばよい
のか？