1.
Developers
Summit
Ricoh UCS
(Unified Communication System)
for iPad
でみる
エンタープライズ
アジャイル開発
株式会社 リコー
梅原 直樹
Naoki UMEHARA
Developers Summit 2013 14-E-7 14/2/2013 http://www.apple.com/ipad-mini/overview/

2.
梅原 直樹
うめはら なおき
Twitter:@numeha
http://numeha.hatenablog.com/

3.
仕事内容
ITサービス系の新規事業

4.
職業：ソフトウェア・エンジニア
•Leader 50% 愛されるチームリーダを目指して
•Developer 20% Ruby Java Objective-C
•Test Engineer 20% Jenkins RSpec Junit GHUnit
•雑用 10% (あれやこれや)

5.
よろしくお願いします
ハッピーバレンタイン

6.
2013/1/31
Release

7.
デブサミ当日は
ムービーを流しました

8.
そんなアプリ作りました
(売れればいいなw)

9.
Developers
Summit
Ricoh UCS
(Unified Communication System)
for iPad
でみる
エンタープライズ
アジャイル開発
株式会社 リコー
梅原 直樹
Naoki UMEHARA
Developers Summit 2013 14-E-7 14/2/2013 http://www.apple.com/ipad-mini/overview/

10.
壁
http://www.flickr.com/photos/nate/93376011/

11.
社内標準開発プロセス
×
従業員数多ければ多いほど
=

12.
社内標準開発プロセス
×
従業員数多ければ多いほど
=
染み付いた常識化

13.
良くも悪くも
滝
滝の絵
計画通りにヤレこら
餓死ウェイ
ウォーターフォール
http://www.flickr.com/photos/lutherankorean/5623695059

14.
全員同席 ペアプログラミング 継続的インテグレーション テスト駆動開発
ryuzee.com ryuzee.com ryuzee.com ryuzee.com
朝会 スプリント/イテレーション ふりかえり スプリント計画会議
計画ゲーム
ryuzee.com ryuzee.com ryuzee.com ryuzee.com
スプリントレビュー 妨害事項リスト バーンダウンチャート プロダクトバックログ
ryuzee.com ryuzee.com ryuzee.com ryuzee.com
リリース計画 Kanban リファクタリング Doneの定義
ryuzee.com ryuzee.com ryuzee.com h"p://bit.ly/wNYD0k ryuzee.com
短期リリース サイクルタイムの測定 相対見積り 受け入れテスト
@ryuzeeのAgile Buffet Cardより

15.
アジャイルなプラクティスはたくさんあるし
成功体験も溜まってきた

16.
Behaviors, Not Practices
プラクティスをやればうまくいくものではない
プラクティスを通じて行動を変え改善できることが重要

17.
Developers
Summit
ACTION!
何かを変えたいと思ったら
まずは自分が正しいと思うやり方でそれをやる
それが正しければいつか広まるさ
それが
僕のエンタープライズ・アジャイル開発

18.
Developers
Summit
ACTION!
本日は時間が無いので１つだけ

19.
1.
コードのコミットからバグ発見までを最小にせよ
Acceptance Test Driven Development

20.
滝
滝の絵
計画通りにヤレこら
餓死ウェイ
ウォーターフォール
http://www.flickr.com/photos/lutherankorean/5623695059

21.
後になればなるほどコストがかかるのに
要求 設計 (仕様) 実装 (&開発者テスト) テスト (受け入れテスト)
Bug Bug Bug Bug
プロジェクトの終盤に問題が見つかる
そして、わかっているのに繰り返す

22.
ここで発見
しても遅い

23.
QCD必達!!!
失敗は許さない
うるさい人

24.
疲れ果てる
デスマーチへGO
http://www.morguefile.com/archive/display/200867

25.
この期間が長いかつ数が多いと...
要求 設計 (仕様) 実装 (&開発者テスト) テスト (受け入れテスト)
Commit ← このコミットの問題だとして → Bug
バグが潜在している期間
修正範囲が大きくなる, 設計が壊れだす, コストがかかる
＝プロジェクトが失敗する

26.
Developers
Summit
コードを書いてから如何に
運用環境で受け入れテストを早く
実行できるかが勝負

27.
デブサミ当日は受け入れテスト
のムービーを流しました

28.
要求
設計 (仕様)
実装 (&開発者テスト)
テスト (受け入れテスト)

29.
要求
設計 (仕様)
実装 (&開発者テスト)
テスト (受け入れテスト)
リリース1 リリース2 リリース3 リリース4 リリース5
よくあるアジャイルの考え方だよね

30.
要求
テスト (受け入れテスト)
提供する価値ベースに常にテスト仕様(コード)が見直される
受け入れテスト仕様から詳細設計・実装が始まる
常にリファクタリングされ、安定化・高速化される
設計 (仕様)
実装 (&開発者テスト)

31.
仕様はあくまで仮説であって
ゴールするときに決まる

32.
はじめはスケッチだけでも
いいじゃない
http://www.flickr.com/photos/juhansonin/4543416563/

33.
1.
コードのコミットからバグ発見までを最小にせよ
Acceptance Test Driven Development
コードをコミットしたら
お客様に提供する価値を
壊していないかすぐ発見される

34.
受け入れテストが
皆好きになる

35.
障害が早く発見される
→障害総数が減る
→修正範囲が少なくなる
障害数 →設計が改善される
→コストをおさえられる
→...
Before
After
時間

36.
成功させるには何をすればよいのか
チームの行動が変わってくる

37.
やればできる
じゃないか
うるさい人

38.
Behaviors, Not Practices
プラクティスをやればうまくいくものではない
プラクティスを通じて行動を変え改善できることが重要

39.
Developers
Summit
ACTION!
何かを変えたいと思ったら
まずは自分が正しいと思うやり方でそれをやる
それが正しければいつか広まるさ
それが
僕のエンタープライズ・アジャイル開発

40.
Developers
Summit
Ricoh UCS
(Unified Communication System)
for iPad
でみる
エンタープライズ う ご ざ い ま し た
ご清聴ありがと
アジャイル開発
株式会社 リコー
梅原 直樹
Naoki UMEHARA
Developers Summit 2013 14-E-7 14/2/2013 http://www.apple.com/ipad-mini/overview/