2014-03-13（木）の、情報処理学会　第７６回全国大会のセッション『ビッグデータ時代に立ち向かうイノベイティブなシステム開発～Agile, Big-data, Cloud, DevOpsのプラクティスから ～』の発表資料です。 http://www.ipsj.or.jp/event/taikai/76/event_1-6.html 現場は難しく、面白いです。 唯一絶対の答えはなく、予測不可能な問題が多発し、何らかの改善を行なっても、問題はなくならずに移動していきます。 一方で、適切な知識・情報を見つけて行動することで、いくらでも変えていくことが出来る可能性も持っています。 このセッションでは、日々プロジェクト・プロダクトを俯瞰し、課題を見つけて解決策を講じるサイクルを短く繰り返して現場を改善していった、現場でのリーン開発とアジャイルの実践について、アジャイルコーチとしての自身の経験・事例に基づいてお話させていただきます。 現場毎に答えが異なることと、それゆえの面白さがあることとを、皆さんと共に考えていければと思います。

1. 現場実践主義としての
リーン開発とアジャイル
Mar/13/2014
Hiroyuki Ito
IT Department, Rakuten, Inc.
http://www.rakuten.co.jp/

2. 2
情報技術部
プロセス・品質課
テスト駆動開発グループ
@hageyahhoo
Hiroyuki Ito （伊藤 宏幸、The Hiro）

3. 3
今回のテーマ
• リーン開発
• アジャイル

4. 4
問１．リーン開発とは？

5. 5
（解答例１） リーン開発の原則
Optimize the Whole
Energize Workers
Eliminate Waste
Learn First
Deliver FastFocus on Customers
http://www.poppendieck.com/
Build Quality In
Keep Getting Better

6. 6
（解答例２） かんばん
http://www.slideshare.net/daipresents/kanban-and-lean-from-the-trenches

7. 7
問２．アジャイルとは？

8. 8
（解答例） アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/
個人と対話をプロセスやツールよりも
顧客との協調を契約交渉よりも
変化への対応を計画に従うことよりも
動くソフトウェアを包括的なドキュメントよりも

9. 9
https://www.flickr.com/photos/ptofnoretrn77/22896629/

10. 10
結局何をすれば
よいのか分からない。

11. 11
ならば
現場のホンモノを
お見せしましょう。

12. 12
アジェンダ
1. 現場の概要
3. 結論：現場の最前線で得たもの
2. 問題解決の事例

13. 13
1. 現場の概要
3. 結論：現場の最前線で得たもの
2. 問題解決の事例

14. 14
チーム構成
ビジネス
アナリスト
アジャイルコーチ
（私）
UI/UX
デザイナー
開発者

15. 15
（概要） プロダクト開発の流れ
要件定義
開発
• プログラミング
• 単体テスト
• 結合テスト
受入テスト
操作性テスト
これを１ヶ月毎に繰り返す
（スプリント・イテレーション）
スワイプの方が
操作しやすいよ
ここにリンク置いて
ユーザを誘導しよう
while (homura) { 出来てるかな～？

16. 16
1. 現場の概要
3. 結論：現場の最前線で得たもの
2. 問題解決の事例

17. 17
仕事が全体的に遅い
最初の課題

18. 18
最初の課題
• システムの機能追加／修正の頻度が高い
• 機能追加／修正の都度、
「回帰テスト」（既存システムに影響がないことの確認）を
手動で実施していた
• 機能追加／修正の都度、
「ステークホルダー」（ビジネスアナリストらプロジェクト関係者）の
端末に、最新版のアプリを１つ１つ手動でインストールしていた
仕事が全体的に遅い

19. 19
要件定義
開発
• プログラミング
• 単体テスト
• 結合テスト
受入テスト
操作性テスト
プロダクト開発の流れ

20. 20
数値計測による仮説検証
• インストール作業時間 ： ０．５時間（＋α）／回
• ６人（延べ） × ５分
• バージョンミスなどがあった場合はやり直し
• 回帰テストの実行時間 ： ４．０時間（＋α）／回
• 一人がかかりっきりで、半日はかかる
• バグを見つけた場合はやり直し
• 機能追加／修正の頻度 ： ３回／週
１３．５時間／週

21. 21
解決策：ビルド・テスト・リリースの自動化
更新のチェック
（１時間おき） 私のノート PC
毎日の朝礼で、
最新版のアプリを
ステークホルダーにデモする
チームメンバー全員に
最新版のアプリを配信
ビルドと回帰テストを自動実行

22. 22

23. 23
• インストール作業時間 ： ２分／回
• 人数に関係なく、一律同じ時間で実施可能
• 回帰テストの実行時間 ： ３分／回
• 機能追加／修正の頻度 ： ３回／週
１５分／週
数値計測による仮説検証 （施策実行後）

24. 24
ビルド・テスト・リリース
を自動化した！

25. 25
思っていたよりも
楽になっていない？

26. 26
数値計測による現状把握
• スプリントの最初に計画したタスクのうち、
実に７５％のものがスプリント内に終えられなかった
• 割り込み率 ： ５０％
• Stash(GitHub) でのマージミスや既存サービスのトラブル対応などで、
チーム外からチームメンバーに対して
多くの割り込み作業があることが分かった
• タスクの完了率 ： ２５％

27. 27
作業に
集中できないことで、
プロダクト開発が
阻害されている

28. 28
ボトルネックが
移動している (´･ω･｀)
要件定義
開発
• プログラミング
• 単体テスト
• 結合テスト
受入テスト
操作性テスト

29. 29
解決策
• 割り込み作業依頼の内容を精査し、
本当に緊急なもの以外はお断りするようにした
• トラブル対応を出来る人をチーム外に増やし、
チームメンバーの負荷を分散した
• 誰にいつ何回割り込み作業依頼があるかを
チームメンバー全員に見えるようにした
• メンバーの負荷を他メンバーが把握できるようにすることが目的
• 改めて確認してみると、実際には緊急でないものも
「緊急」として依頼されていることがあった

30. 30
• 割り込み作業防止の効果アリ
• 一方で、まだ半分のタスクを終えられない原因が他にありそう
• 割り込み率 ： ２０％
• 安直な「緊急」依頼は激減した
• 本当の緊急対応も、ほぼチーム外だけで解決できるようになってきた
• タスクの完了率 ： ５０％
数値計測による施策の検証 （１月後）

31. 31
作業に
集中できるように
なり始めてきた！

32. 32
何かがおかしい？

33. 33
とある機能で
バグが頻発している

34. 34
数値計測による現状把握
• 元々難易度が高い機能だった
• 既存の単体テストレベルの自動回帰テストでは検知できなかった
• 機能追加／修正の頻度 ： ５倍
• 最初から要件が確定しておらず、やりながら決めていこうとした
• 作っていくうちにやりたいことが見えてきたため、修正が頻発した
• 「あれもこれも追加したい」と、要望が止まらなくなってきた
他の機能と比較して…
• デグレードの頻度 ： ５倍
• バグ報告件数 ： ３倍
• 既存の単体テストレベルの自動回帰テストでは検知できなかった

35. 35
ボトルネックが
移動している orz
要件定義
開発
• プログラミング
• 単体テスト
• 結合テスト
受入テスト
操作性テスト

36. 36
解決策
• 変更要望の受付期限を設けた
• ATDD（≒受入テストの自動化）を導入し、
この機能のテストを重点的に整備した
• 画面遷移やユースケースの一連の処理の流れもテストできる仕組みを、
これまでの単体テストとは別に導入した
• 発見したバグやデグレードは、全て ATDD のケースとして整備し、
問題が再発しても即検知できるようにした
• ステークホルダーに対して、
要望を無制限に出してくることに歯止めをかけた

37. 37
（例） ATDD のテストケース
Feature: Input
Scenario: Input today’s data
Given I kick drumroll
Then drumroll show today
When press next
Then I should see ”xxx" screen
When I press keys and calculator should show like this:
| 2 | 2 |
| 0 | 20 |
| 0 | 200 |
| * | 200 |
| 3 | 3 |
| = | 600 |
Then take photo
…
テストケースの名称です
このレベルの記述で
自動実行できます
読みやすさを考慮した
記述ができます

38. 38
数値計測による施策の検証 （１月後）
• ATDD による自動回帰テストを整備した成果
• 機能追加／修正の頻度 ： １．５倍
• 歯止めは必要だった
他の機能と比較して…
• デグレードの頻度 ： ２倍
• バグ報告件数 ： １倍
• デグレード自体はまだ発生することがあったが、
あっても即検知・対応できるため、
対応時間は以前の１／５程度になった

39. 39
1. 現場の概要
3. 結論：現場の最前線で得たもの
2. 問題解決の事例

40. 40
1) 答えは一つではない
現場は難しい
2) 事前に予測不可能な問題が多発する
• 唯一絶対の答えはまずない
• エンジニアリングだけでは解決できない問題が無数にある
3) 何らかの改善を行なっても、
問題は無くならずに移動していく
• 全てを事前に予測・計画し、その通りに実施するということは非現実的
• 特に新技術ではなおさら

41. 41
1) 自分たちが発見したものを答えにできる
現場は面白い
3) 問題を１つ１つ解決していく毎に、自分・メンバー・
チームが成長していくことがはっきりと分かる
2) 少しずつ試しながら変えていくことが出来る
• 工夫次第で、いかようにも問題の解決が可能
• 試しながら答えを見つけていくことが面白い
• 短期の予測ならば、当たる可能性はまだ高い
• 短期での失敗なら、すぐにリカバリー・改善できる
• やり方次第で、状況をコントロールすることが可能になる

42. 42
自動化の恩恵に全力であずかろう

43. 43
数値を計測して行動し、成果を確認しよう
テストの実行時間機能追加／修正の頻度
デグレードの頻度バグ報告件数
残タスク数テスト網羅率
割り込み率タスクの完了率
などなど…

44. 44
「振り返り」によるチームの学習の促進

45. 45
いずれも現場で試しながら
考え行動し見つけた答え。
答えは現場にある。
現場実践主義

46. 46
現場実践主義
≒
• リーン開発
• アジャイル

47. 47
更なる新技術の登場
https://www.flickr.com/photos/taedc/9276625962

48. 48
無限とも言える選択肢
https://www.flickr.com/photos/3059349393/3786855827/

49. 49
やってみないと
分からない

50. 50
ならば、
やってみれば
いいんです。

51. 51
今回のテーマ
• リーン開発
• アジャイル

52. 52
１つ１つ試しながら
考え行動し続け、
あなたの答えを
みつけてみましょう。

53. 53
楽しく
天下を