第6回Ques 2015年5月14日(木) @KDDI株式会社 「KDDI Business IDにおけるアジャイル開発と検証フロー」KDDI株式会社　クラウドサービス企画開発部　鈴木隆昭様 Quesとは、Software品質保証に関わるQAエンジニアの活性化を目的としたQA専門イベントです。 http://quesqa.com/

1. KDDI Business ID における
アジャイル開発と検証フロー
〜第6回 Ques〜
鈴木隆昭
KDDI株式会社 プラットフォーム開発本部
クラウドサービス開発部

2. はじめに
改善のための現状分析
スプリントスケジュールと検証フロー
まとめ
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d2

3. はじめに

4. 自己紹介

5. ■ 所属
プラットフォーム開発本部 クラウドサービス開発部 開発4G
- アジャイル開発(スクラム)によるサービスの開発
■ 略歴
・2010/04 〜 2014/10 @コンテンツプロバイダ
- B2C, B2B, B2B2C 向けWeb系フロントエンド、API、バッチ開発
等々
・2014/11 〜 現在 @KDDI株式会社
- KDDI Business IDの開発
- 開発、オフショア対応、検証フロー整備等々
鈴木 隆昭(すずき たかあき)
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d5

6. KDDI Business ID (IDentity as a Service)
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d6
Identity管理は今、パーソナルFWな時代
Multi
Use
Multi
Device
Multi
Network

7. なぜアジャイル？

8. Moving Target
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d8
破壊的なまでの市場の変化スピード

9. アウトカム(成果)
Moving Target
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d9
アウトプット(成果物)よりも

10. アジャイルは必然の選択
Moving Target
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d10

11. スクラム概論

12. スクラム開発の登場人物
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d12
プロダクト
オーナー
スクラム
マスター
開発
チーム

13. アジャイルな開発チームは職能横断的なメンバーで構成されており、顧客の望む
フィーチャをリリース可能なソフトウェアにするために集められる。アナリスト。
プログラマ。テスター。データベース管理者。他にもユーザーストーリーをちゃ
んと動くソフトウェアとして実現するために必要なメンバーをすべて揃える
※ Jonathan Rasmusson アジャイルサムライ ー 達人開発者への道
スクラム開発の登場人物
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d13
プロダクト
オーナー
スクラム
マスター
開発
チーム

14. スクラムのスプリント
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d14
振り
返り
実装
試験
1 Sprint
プロダクト
バックログ
スプリント
バックログ
レビ
ュー
設計
計画
スプリント
成果物

15. 与えられたミッション

16. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d16
鈴木って何ができるの？
事前にGLからスキルセット
聞いてないのよ

17. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d17
鈴木って何ができるの？
事前にGLからスキルセット
聞いてないのよ
既読
既読
あ、そうなんですね。
前職ではJavaやGroovyをメ
インに…

18. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d18
クライアント側は
CoffeeScriptやSassを中心に..
Pythonとか、bashも少々
既読
既読
テストとか、どうなの？
あー、はい。
既読
既読

19. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d19
テストコードも、書けます
よ。

20. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d20
テストコードも、書けます
よ。
既読
そうか。
じゃあ、テスト、やってく
れ。

21. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d21
テストコードも、書けます
よ。
既読
そうか。
じゃあ、テスト、やってく
れ。
はい。
既読
既読

22. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d22
「テストやってくれ」

23. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d23
「テストやってくれ」
||
「テストコードでも書いて
早く現場のコードに慣れたまえ」

24. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d24
「テストやってくれ」
||
「テストコードでも書いて
早く現場のコードに慣れたまえ」

25. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d25
「テストやってくれ」
||
「テストコードでも書いて
早く現場のコードに慣れたまえ」

26. 今回のミッション
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d26
「テストやってくれ」
||
「受入試験を改善してくれ」

27. 改善のための現状分析

28. 開発の体制と役割
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d28
企画
（3人）
開発
（15人）
v
テスター
（2人）
スプリント計画の事前準備
成果物のレビューを受入試験という形で実施
外部調整、開発予算確保
全員プログラム＆テスト実装できる
受入試験項目の作成〜実施
別グループからのレンタル（部門を跨いだ共有リソース）
物理的にも若干の距離あり

29. ヒアリング
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d29
企画
開発 テスター

30. ヒアリング(to 開発)
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d30
企画
開発 テスター
• 早い段階で成果物のレビューをして欲しい
• リリース直前での仕様変更依頼は困る

31. ヒアリング(to 企画)
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d31
企画
開発 テスター
• 成果物をレビューできてなくてすみません。。

32. ヒアリング(to テスター)
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d32
企画
開発 テスター
• スプリント計画でのインプット情報が少ない
• 決まらない要求仕様。テスターが議論に参加するわけでもない。
• 知らないうちに仕様が変わっている
• 仕様確認のコミニケーションコストが高い
• 期待する受入試験ができているか不明
• 試験観点のすり合わせが無い、検証のFB機会も特にない

33. 受入試験が抱えていた問題
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d33
• 担当が曖昧
• 企画とテスターがそれぞれ実施
• 受入試験対象のインプット情報の不足
• スプリント計画の事前準備不足による議論の消化不良
• スプリントバックログの中の検証対象はどれ？
• スプリント中の仕様変更に気づけない
• 伝達忘れ→コミュニケーションの問題
• テスターと他メンバーとの距離感
• スプリント計画の場にいるだけ
• オフィス内でも物理的な距離が遠い

34. 受入試験改善のために
スプリントサイクルを改善する

35. C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d35
スプリントサイクルを改善するには
企画は受入試験をしない

36. C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d36
スプリントサイクルを改善するには
企画は受入試験をしない
なぜならば
POとしての役割に注力

37. C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d37
スプリントサイクルを改善するには
企画は受入試験をしない
POとしての役割に注力
受入試験をテスターが実施
なぜならば
そのために

38. C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d38
テスターが受入試験を実施するには
開発+企画と同じ鮮度の
仕様の理解が必要

39. C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d39
テスターが受入試験を実施するには
開発+企画と同じ鮮度の
仕様の理解が必要
①スプリント計画終了段階で十分な仕様の議論がされている状態にする
②受入試験表作成のための過不足ないドキュメントをメンテナンスする
③開発途中で変更された仕様・開発スコープを共有する場を設ける
④受入試験表をPOがレビューし、受入条件が網羅されていることを担保する
そのために

40. C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d40
スクラムチーム内の連携を取りやすくするために
テスターを専任にする

41. C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d41
スクラムチーム内の連携を取りやすくするために
テスターを専任にする
ことができなかった

42. C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d42
スクラムチーム内の連携を取りやすくするために
テスターを専任にする
ことができなかった
2week/月の稼働で調整
受入試験実施＋仕様のインプット工数は
最低限の必須要求
とはいえ
そのために

43. スプリントスケジュールと検証フロー

44. Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター
1スプリントの進め方
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d44
• 1スプリント = 2week
• 仕様検討〜検証まで行う
• タスク管理はチケットで行う
• アナログにカンバンを用いて視覚化

45. 前スプリント振り返り＆スプリント計画
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d45
• 前スプリントの振り返り
• 成果物の全体レビュー
• 受入試験結果の報告
• 企画からのプロダクトの状況共有
• 振り返り（KPT）
• スプリント計画
• 対応ユーザストーリーの説明と仕様ディスカッション
• 対応工数の見積もり、タスク割り振り、カンバン作成
Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター

46. 前スプリント振り返り＆スプリント計画
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d46
Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター
• 前スプリントの振り返り
• 成果物の全体レビュー
• 受入試験結果の報告
• 企画からのプロダクトの状況共有
• 振り返り（KPT）
• スプリント計画
• 対応ユーザストーリーの説明と仕様ディスカッション
• 対応工数の見積もり、タスク割り振り、カンバン作成

47. 前スプリント振り返り＆スプリント計画
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d47
Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター
• 前スプリントの振り返り
• 成果物の全体レビュー
• 受入試験結果の報告
• 企画からのプロダクトの状況共有
• 振り返り（KPT）
• スプリント計画
• 対応ストーリーの説明と仕様ディスカッション
• 対応工数の見積もり、タスク割り振り、カンバン作成

48. Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター
ドキュメントの整備
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d48
• 画面項目定義書の整備
• 入出力項目
• アクション
• 特記事項
• 画面仕様のラフイメージ
※ 画面仕様はプロトタイプをベースに決まることもあるため、
仕様変更の都度更新

49. Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター
開発
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d49
• ユーザストーリー実装を詳細にタスク分割
• ① 設計&開発用ドキュメント更新
• ② 結合テスト試験表作成(実装担当者以外が実施)
• ③ 実装(ペアプロ&TDD)
• ④ 単体テスト
• ⑤ 第三者コードレビュー（pull-request）
• ⑥ 結合テスト

50. Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター
仕様変更・開発スコープの共有
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d50
• スプリント計画以降で変更された仕様の共有
• ストーリー消化具合を基に開発スコープ決定
この間の変更分の仕様 変更があれば都度共有

51. Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター
受入試験表作成＆レビュー
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d51
• インプット情報を基に受入試験表作成
• スプリント計画 (Day 1)
• ドキュメント (Day 2〜6)
• 仕様変更・開発スコープ共有 (Day 7)
• 試験表のレビュー
• 期待した受入条件が網羅されているかPOがチェック
• 結合テストとの観点の癒着を避けるため、開発は参加しない

52. 受入試験環境準備
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d52
• 全開発メンバーでのソースレビュー
• 指摘事項修正＆リファクタリング
• リグレッションテスト
• E2Eテストが自動化されているため、工数は膨れない
• 受入試験環境にデプロイ
• 受入試験可能になったらチケットのステータスを更新
Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター

53. Day 1 2 3 4 5 6 7 8 9 10
企画
開発
テス
ター
受入試験
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d53
• 受入試験実施
• 試験項目数や手順の複雑さによって企画や開発とも連携
• スプリント内で試験終了

54. 受入試験時のチケット管理

55. 不具合チケット管理
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d55

56. 要望チケット管理
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d56

57. まとめ

58. Day 1 2 3 4 5 6 7 8 9 10
企画
受入試験表レビュー
開発プロセス中で品質を作りこむ
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d58
テス
ター
TDD 単体テスト 結合テスト
受入試験
入念なストーリー検討
開発
適切な量のドキュメント
回帰テスト 静的解析
スプリント計画
で仕様を議論
仕様変更の
インプット
試験表作成

59. 『品質保証』は誰がしている？
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d59

60. 『品質保証』は誰がしている？
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d60
チームで行っている

61. チームで行っている
『品質保証』は誰がしている？
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d61
KDDI Business IDの場合

62. チームで行っている
『品質保証』は誰がしている？
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d62
KDDI Business IDの場合
• チームメンバー全員が品質を意識して活動
• スプリント計画の事前準備から品質は左右さ
れる
• アジャイルなテストを阻害する要因との融和

63. 今後の予定

64. Delivery & Pivot
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d64
計画
設計
1 Sprint
市場反応への迅速な対応のための高速なデリバリー
設計
設計
設計
設計
計画 計画
設計
設計
設計
設計
設計
計画 計画
設計
設計
設計
設計
設計
計画 計画
設計
設計
設計
設計
設計
計画 計画
設計
設計
設計
設計
設計
計画 計画
設計
設計
設計
設計
設計
計画
1 Sprint 1 Sprint 1 Sprint 1 Sprint 1 Sprint
Market
delivery
development development
reaction

65. 現在のスプリントの進め方
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d65
回帰
試験
計画
設計
実装
単体試験
結合試験
受入
試験
回帰
試験
計画
設計
実装
単体試験
結合試験
受入
試験
1 Sprint 1 Sprint

66. 現在のスプリントの進め方
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d66
回帰
試験
計画
設計
実装
単体試験
結合試験
受入
試験
回帰
試験
計画
設計
実装
単体試験
結合試験
受入
試験
1 Sprint 1 Sprint
Bug Fix
翌スプリントに持ち越しバグ発見

67. Rapid Application Development
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d67
回帰試験
計画
設計
実装
単体試験
結合試験
受入
試験
1 Sprint 1 Sprint
Bug Fix
回帰試験
計画
設計
実装
単体試験
結合試験
受入
試験
Bug Fix
• BugFixをスプリント内に収める
• ユーザーストーリーが確実にDoneする状態を維持する
• というかBugFixですらないかも

68. Rapid Application Development
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d68
回帰試験
計画
設計
実装
単体試験
結合試験
受入
試験
1 Sprint 1 Sprint
Bug Fix
回帰試験
計画
設計
実装
単体試験
結合試験
受入
試験
Bug Fix
より前衛的なQA
• BugFixをスプリント内に収める
• ユーザーストーリーが確実にDoneする状態を維持する

69. Quality Cloud