2013.11.23 に開催されたオープンセミナー徳島 2013 でのセッション資料です。加筆/再編集してあります。

1. Tomoharu Nagasawa
Technical Evangelist, Microsoft
Certified Scrum Master (CSM)
これからのソフトウェア開発環境の話をしよう
開発現場力を高める環境づくり

3. これからの
開発の”現場”
Development “Gemba”

4. Your View
YOU

5. あなたのエンドユーザーのビジネス
あなたのチーム
YOU
あなたの関係者
あなたのエンドユーザー

6. あなたのエンドユーザーのビジネス
YOU
code
feature
Business

7. Code
Complete
フィードバック
サイクル
YOU
code
手戻り
コスト
feature
Business
x1
x10
x100

8. Feature
Complete
YOU
code
Your Team
feature
Business
x1
x10

9. Business
Technology

10. Business
Customer Development
Customer
Discovery
Customer
Validation
Iteration
Customer
Creation
Company
Building
Execution
Technology

11. Business
Lean Startup | Build – Measure - Learn
アイデア
LEARN
データ
BUILD
Dev Ops
Biz
プロダクト
MEASURE
Technology

13. 2010s
2000s
1990s
Cost Center
Key Infrastructure
Morphing IT

14. ビジネス モデル
Cost Center
IT に非依存
Key Infrastructure
IT が関与
Morphing IT
IT がドライバー

15. 意思決定
Cost 部門
IT Center
Key Infrastructure
経営者層
Morphing IT
顧客/市場が中心

16. テクノロジー
CostC/S
Center
Key / Web サービス
Web Infrastructure
Morphing IT
クラウドとデバイス

17. ビジネスモデル 顧客と市場への
をけん引
アジリティ
クラウド＆
Dev と Ops の
デバイスの活用 協調

18. 協調
協調ワークは非公開とさせていただきます。

19. Environment
環境
統制
Control
Environment

20. Environment
モチベーション
目的 / 規律 /
自律 / 見える化
よいものを取り入れる
“勇気”

21. 人
自立
Autonomy
相互作用
熟達
Mastery
動くソフトウェア
目的
Purpose
顧客との協調
変更/変化への反応
協調

22. これからの開発”現場”
code
feature
Business
ビジネス駆動 | 意味のあるフィードバック | 検査と適応

23. これからの
開発スタイル
Development Practices

24. Changes
効率化
Decade
Biz
App
ビジネス ＝確立
リリース ＝一括
意思決定 ＝開発
技術･手法＝経験済み
ビジネス化
Next Decade
Biz
App
ビジネス ＝変動
リリース ＝逐次
意思決定 ＝市場
技術･手法＝未経験

25. Delivery
Value
仕掛り
(WIP)
高 ROI
低 ROI
Time

26. Delivery
Value
適切な
仕掛り
(WIP)
定期的 (Time Box)
Time

27. View Points
変化
未経験
？
リズム
協調

28. Stacey Matrix
難
無秩序
やや
複雑
複雑
ビジネスモデル
(要求)
単純
やや
複雑
易
実績あり
未経験
テクノロジー

29. 定義されたプロセス モデル
Defined Process Model
例:
 建物の建築 (過去に経験があり、技術も安定している)
 ソフトウェア？ (過去に存在するものは調達すればよい)
実測駆動なプロセス モデル
Empirical Process Model
例:
 新製品開発 (過去に経験がない、ビジネス価値を創出)
 ソフトウェア！ (新たなチャレンジが多い)

30. テンプレート化しやすい
定義されたプロセス モデル
 見積もり可能で、計画を立てやすい
M1
Task 1
Defined Process Model
 WBS による計測がしやすい
 工程を区切り、成果物管理がしやすい
Task 3
例:
 自分の割り当てられた仕事に注力しやすい
Task 4
 建物の建築 (過去に経験があり、技術も安定している)
 I’m done の蓄積が全体成果になりやすい
Task 5
 ソフトウェア？ (過去に存在するものは調達すればよい)
 サイロに陥りやすい
Task 2
検査と適応
実測駆動なプロセス モデル
 価値と経験を基準にするしかない
Empirical Process Model
 見積もり、進捗、品質
Value
 定期的に見直すことで見極めるしかない
例:
 自分の割り当てられた仕事に価値は見いだせない
 We’re done でなければ、計測できない
 新製品開発 (過去に経験がない、ビジネス価値を創出)
 サイロがない
 ソフトウェア！ (新たなチャレンジが多い)

31. WIP (仕掛り) とフィードバックの比較
6 か月のプロジェクト / 36 機能
Value
6か月
36 個
WIP
 リリース: 1 回
 WIP: 36 個
 フィードバック機会: 1 回
Time
ウォーターフォール
Lead Time
Value
6か月
36 個
WIP
3
WIP
2
WIP
Time
Lead Lead Lead
Time Time Time
スクラム
Time Box (固定)
Value
Lead
Time
6か月
36 個
1
WIP
WIP
1
1
WIP
WIP
Time
カンバン
 リリース: 6m ÷ タイムボックス (2w) = 12 回
 WIP: 36 個 ÷ 12 回 = 3 (2 ～ 4) 個
 フィードバック機会: 12 回
Lead Lead Lead
Time Time Time
Lead Lead
Time Time




リリース: MMF (Minimal Marketing Feature) = 36 回
WIP: 1 個
フィードバック機会: 36 回
(WIP Limit: 4 個)

32. 主なムダな作り込みをしない戦術
MVP: Minimum Viable Product
 顧客ニーズの学習を主目的とした最小限の製品/サービス
を用いる戦術
 実用可能な最小セットを実際に使ってもらいフィード
バックを得る
MVP
Canary Release
カナリア リリース
 一部の協力的なユーザー (アーリーアダプター) に先行リ
リースし、フィードバックを得るリリース
 事前リリースのフィードバックにより、手戻りコストを
最小化する
A/B テスト
A
A/B テスト
B
 2 通りのランディング画面やバナー、サービスを用意し、
実際のユーザーの行動パターンを計測し最適な解を得る
 顧客開発 (開拓) の手法としても有効
(想定ユーザーと違う層にウケることがわかったなど)
TIPS:
実運用を伴わないデプロイ
を行うことが可能な場合も
ある。
例:
 別ブランドで実験
 インサイト顧客にのみ
提供
 期間限定のサービス
実際の行動/実績を伴うこ
とがポイントである。
 机上ではなく、事実に
基づく学習と検証が行
われる

33. Scrum
スクラムマスター
デイリー
スクラム
プロダクトバックログ
３
１
５
１
３
３
５
？
？
？
PRIORITIZE
プロダクトオーナー
スプリント
PLAN
EXECUTE
チーム
RESPOND

34. Scrum
スクラムマスター
プロダクトバックログ
３
１
１
３
５
？
？
？
PRIORITIZE
プロダクトオーナー
デイリー
スクラム
バーンダウン
３
５
３
５
PLAN
EXECUTE
チーム
RESPOND

35. Scrum
スクラムマスター
プロダクトバックログ
３
１
１
３
５
？
？
？
ベロシティ
８ ７ ８
１
３
２
２
２
５
５
３
PRIORITIZE
プロダクトオーナー
チーム

36. ツール活用の真価
Going Continuous Value Delivery with Tools

37. 透明性は、
チームメンバーの信頼のために、
自らが選択するものである
Tools for Agility
By Kent Beck, June. 2008
http://aka.ms/T4A
Transparency

38. Responsibility
Code
feature
Business
ツール: 個々の作業の効率化

39. Responsibility
Code
feature
Business
ツール: 作業間の効率化

40. ツールへの期待
チームの開発者には差がある！




設計能力
実装能力
テスト能力
情報把握能力

41. ツールへの期待
チームに求められる能力を把握

42. ツールへの期待
作業効率化ツール
でカバーする領域

43. ツールへの期待
デッドゾーンを何で補うか！？
作業効率化ツール
でカバーする領域
Team Foundation Server
一元管理 | 作業間の効率化 | プラクティス支援 | 透明性 | 情報共有

44. ツールへの期待
作業効率化ツール
でカバーする領域
作業間の移行の効率化と透明性
＝ プラクティスとツールチェーン

45. Future
Change❓
今後の開発環境の変化:
 作業間のスムーズな移行
 自動テストの対象の拡大
 リアルタイムな共同作業
 透明性
Tools for Agility
By Kent Beck, June. 2008
http://aka.ms/T4A

46. 開発者が得るべき透明性
正しいことを、正しく行う
これを正しくわかること
うそのない
開発
変化に機敏な
開発
ビジネス駆動
な開発
自分を磨く
開発

47. 情報リソース
Kent Beck 氏
ホワイトペーパー
書籍
スピーカーのブログ
Tools for Agility
『アジャイルソフトウェア
エンジニアリング』
日経BP社
SoftwareEngineeringPlatform.com
俊敏性のためのツール
http://aka.ms/T4A
http://twitter.com/AgileSEBook
http://aka.ms/tomohn

48. We are Pig !
for Customer Business
http://www.scrum.org/You-Are-a-Scrum-Pig
nagasawa@outlook.com | @tomohn
http://SoftwareEngineeringPlatform.com