現場実践主義としてのリーン開発とアジャイル

現場実践主義としての リーン開発とアジャイル

Mar/13/2014

Hiroyuki Ito

IT Department, Rakuten, Inc.

http://www.rakuten.co.jp/

2

情報技術部

プロセス・品質課

テスト駆動開発グループ

@hageyahhoo

Hiroyuki Ito （伊藤 宏幸、The Hiro）

3

今回のテーマ

• リーン開発

• アジャイル

4

問１．リーン開発とは？

5

（解答例１） リーン開発の原則

Optimize the Whole

Energize Workers

Eliminate Waste

Learn First

Deliver Fast Focus on Customers

http://www.poppendieck.com/

Build Quality In

Keep Getting Better

6

（解答例２） かんばん

http://www.slideshare.net/daipresents/kanban-and-lean-from-the-trenches

7

問２．アジャイルとは？

8

（解答例） アジャイルソフトウェア開発宣言

http://agilemanifesto.org/iso/ja/

個人と対話を プロセスやツールよりも

顧客との協調を 契約交渉よりも

変化への対応を 計画に従うことよりも

動くソフトウェアを 包括的なドキュメントよりも

9

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

10

結局何をすれば

よいのか分からない。

11

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

12

アジェンダ

1. 現場の概要

3. 結論：現場の最前線で得たもの

2. 問題解決の事例

13

1. 現場の概要

3. 結論：現場の最前線で得たもの

2. 問題解決の事例

14

チーム構成

ビジネス

アナリスト

アジャイルコーチ

（私）

UI/UX

デザイナー

開発者

15

（概要） プロダクト開発の流れ

要件定義

開発 • プログラミング

• 単体テスト

• 結合テスト

受入テスト

操作性テスト

これを１ヶ月毎に繰り返す

（スプリント・イテレーション）

スワイプの方が

操作しやすいよ

ここにリンク置いて

ユーザを誘導しよう while (homura) { 出来てるかな～？

16

1. 現場の概要

3. 結論：現場の最前線で得たもの

2. 問題解決の事例

17

仕事が全体的に遅い

最初の課題

18

最初の課題

• システムの機能追加／修正の頻度が高い

• 機能追加／修正の都度、

「回帰テスト」（既存システムに影響がないことの確認）を

手動で実施していた

• 機能追加／修正の都度、

「ステークホルダー」（ビジネスアナリストらプロジェクト関係者）の

端末に、最新版のアプリを１つ１つ手動でインストールしていた

仕事が全体的に遅い

19

要件定義

開発 • プログラミング

• 単体テスト

• 結合テスト

受入テスト

操作性テスト

プロダクト開発の流れ

20

数値計測による仮説検証

• インストール作業時間 ： ０．５時間（＋α）／回 • ６人（延べ） × ５分

• バージョンミスなどがあった場合はやり直し

• 回帰テストの実行時間 ： ４．０時間（＋α）／回 • 一人がかかりっきりで、半日はかかる

• バグを見つけた場合はやり直し

• 機能追加／修正の頻度 ： ３回／週

１３．５時間／週

21

解決策：ビルド・テスト・リリースの自動化

更新のチェック

（１時間おき） 私のノート PC

毎日の朝礼で、

最新版のアプリを

ステークホルダーにデモする

チームメンバー全員に

最新版のアプリを配信

ビルドと回帰テストを自動実行

22

23

• インストール作業時間 ： ２分／回 • 人数に関係なく、一律同じ時間で実施可能

• 回帰テストの実行時間 ： ３分／回

• 機能追加／修正の頻度 ： ３回／週

１５分／週

数値計測による仮説検証 （施策実行後）

24

ビルド・テスト・リリース

を自動化した！

25

思っていたよりも

楽になっていない？

26

数値計測による現状把握

• スプリントの最初に計画したタスクのうち、

実に７５％のものがスプリント内に終えられなかった

• 割り込み率 ： ５０％ • Stash(GitHub) でのマージミスや既存サービスのトラブル対応などで、

チーム外からチームメンバーに対して

多くの割り込み作業があることが分かった

• タスクの完了率 ： ２５％

27

作業に

集中できないことで、

プロダクト開発が

阻害されている

28

ボトルネックが

移動している (´･ω･｀)

要件定義

開発 • プログラミング

• 単体テスト

• 結合テスト

受入テスト

操作性テスト

29

解決策

• 割り込み作業依頼の内容を精査し、

本当に緊急なもの以外はお断りするようにした

• トラブル対応を出来る人をチーム外に増やし、

チームメンバーの負荷を分散した

• 誰にいつ何回割り込み作業依頼があるかを

チームメンバー全員に見えるようにした • メンバーの負荷を他メンバーが把握できるようにすることが目的

• 改めて確認してみると、実際には緊急でないものも

「緊急」として依頼されていることがあった

30

• 割り込み作業防止の効果アリ

• 一方で、まだ半分のタスクを終えられない原因が他にありそう

• 割り込み率 ： ２０％ • 安直な「緊急」依頼は激減した

• 本当の緊急対応も、ほぼチーム外だけで解決できるようになってきた

• タスクの完了率 ： ５０％

数値計測による施策の検証 （１月後）

31

作業に

集中できるように

なり始めてきた！

32

何かがおかしい？

33

とある機能で

バグが頻発している

34

数値計測による現状把握

• 元々難易度が高い機能だった

• 既存の単体テストレベルの自動回帰テストでは検知できなかった

• 機能追加／修正の頻度 ： ５倍 • 最初から要件が確定しておらず、やりながら決めていこうとした

• 作っていくうちにやりたいことが見えてきたため、修正が頻発した

• 「あれもこれも追加したい」と、要望が止まらなくなってきた

他の機能と比較して…

• デグレードの頻度 ： ５倍

• バグ報告件数 ： ３倍

• 既存の単体テストレベルの自動回帰テストでは検知できなかった

35

ボトルネックが

移動している orz

要件定義

開発 • プログラミング

• 単体テスト

• 結合テスト

受入テスト

操作性テスト

36

解決策

• 変更要望の受付期限を設けた

• ATDD（≒受入テストの自動化）を導入し、

この機能のテストを重点的に整備した • 画面遷移やユースケースの一連の処理の流れもテストできる仕組みを、

これまでの単体テストとは別に導入した

• 発見したバグやデグレードは、全て ATDD のケースとして整備し、

問題が再発しても即検知できるようにした

• ステークホルダーに対して、

要望を無制限に出してくることに歯止めをかけた

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

数値計測による施策の検証 （１月後）

• ATDD による自動回帰テストを整備した成果

• 機能追加／修正の頻度 ： １．５倍 • 歯止めは必要だった

他の機能と比較して…

• デグレードの頻度 ： ２倍

• バグ報告件数 ： １倍

• デグレード自体はまだ発生することがあったが、

あっても即検知・対応できるため、

対応時間は以前の１／５程度になった

39

1. 現場の概要

3. 結論：現場の最前線で得たもの

2. 問題解決の事例

40

1) 答えは一つではない

現場は難しい

2) 事前に予測不可能な問題が多発する

• 唯一絶対の答えはまずない

• エンジニアリングだけでは解決できない問題が無数にある

3) 何らかの改善を行なっても、

問題は無くならずに移動していく

• 全てを事前に予測・計画し、その通りに実施するということは非現実的

• 特に新技術ではなおさら

41

1) 自分たちが発見したものを答えにできる

現場は面白い

3) 問題を１つ１つ解決していく毎に、自分・メンバー・ チームが成長していくことがはっきりと分かる

2) 少しずつ試しながら変えていくことが出来る

• 工夫次第で、いかようにも問題の解決が可能

• 試しながら答えを見つけていくことが面白い

• 短期の予測ならば、当たる可能性はまだ高い

• 短期での失敗なら、すぐにリカバリー・改善できる

• やり方次第で、状況をコントロールすることが可能になる

42

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

43

数値を計測して行動し、成果を確認しよう

テストの実行時間 機能追加／修正の頻度

デグレードの頻度 バグ報告件数

残タスク数 テスト網羅率

割り込み率 タスクの完了率

などなど…

44

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

45

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

現場実践主義

46

現場実践主義

≒

• リーン開発

• アジャイル

47

更なる新技術の登場

https://www.flickr.com/photos/taedc/9276625962

48

無限とも言える選択肢

https://www.flickr.com/photos/3059349393/3786855827/

49

やってみないと

分からない

50

ならば、

やってみれば

いいんです。

51

今回のテーマ

• リーン開発

• アジャイル

52

１つ１つ試しながら

考え行動し続け、 あなたの答えを

みつけてみましょう。

53

楽しく 天下を