2016年7月末にアメリカのアトランタで開催されました、「Agile2016」の参加レポートです。 世界の最新のアジャイル事情、DevOps・メトリクス・テストに関する知見、および「モダンなアジャイル」について、少し踏み込んで説明しています。 みなさんのアジャイルの適用・活用のプラスになれば幸いです。

1. 2016年10月8日
伊藤 宏幸
世界最大級の
アジャイルカンファレンス
報告
2016年9月7日

2. Agile2016
2

3. 開催地：米ジョージア州アトランタ
3

4. 自己紹介
4
伊藤 宏幸（The Hiro）
@hageyahhoo
システム統括本部 技術支援本部
 アジャイルコーチ
 自動化コーチ

5. Agile2014に登壇もしています
5
→ プレゼン資料

6. アジェンダ
6
1. カンファレンスの概要
2. 世界における最新のアジャイルの動向
3. DevOps・メトリクス・テストに関する知見
4. Tech Giantを目指す方法論
5. 結論

7. 1. カンファレンスの概要

8. 基本情報
8
項目 詳細
期間 7/25（月） - 7/29（金）午前中
セッション数 287
セッションのジャンル数 20
最大同時並行トラック数 19
参加者数 約2,500名
参加者の国籍 42か国
ボランティア数 約300名

9. 主催者
9
Agile Alliance
https://www.agilealliance.org/
全世界で８万人以上の会員を持つ、
文字通り世界のアジャイルを代表する組織。

10. プラチナスポンサー
10

11. カンファレンス分析 (1)
11
ジャンル セッション数 ジャンル セッション数
Agile Bootcamp 9 Leadership 23
Audacious Salon 14 Learning 19
Coaching & Mentoring 20 Lightning Talks 3
Collaboration Culture & Teams 25 Open Jam 5
Development Practices &
Craftsmanship
19
Project Program and Portfolio
Management
21
DevOps 18 Stalwarts 6
Enterprise Agile 27 Testing & Quality 12
Experience Reports 23
The Future of Agile Software
Development (IEEE Software)
5
Government 10 User Experience 11
Keynotes 3 Working with Customers 14

12. カンファレンス分析 (1)
12
ジャンル セッション数 ジャンル セッション数
Agile Bootcamp 9 Leadership 23
Audacious Salon 14 Learning 19
Coaching & Mentoring 20 Lightning Talks 3
Collaboration Culture & Teams 25 Open Jam 5
Development Practices &
Craftsmanship
19
Project Program and Portfolio
Management
21
DevOps 18 Stalwarts 6
Enterprise Agile 27 Testing & Quality 12
Experience Reports 23
The Future of Agile Software
Development (IEEE Software)
5
Government 10 User Experience 11
Keynotes 3 Working with Customers 14

13. カンファレンス分析 (2)
13
• 世界的な有名人が複数名登壇。
• 『レガシーコード改善ガイド』の著者など
• 一方ここ数年で、有名人の登壇者は徐々に減少傾
向にある。
• 一般参加者としてこれまで参加していた人が、
成長して登壇しているケースが増えている。

14. Yahoo! Inc.（アメリカ）の方も登壇
14

15. 2. 世界における最新の
アジャイルの動向

16. 3種類のアジャイル
16
1. 技術のアジャイル
• DevOps、Craftmanship、テスト
2. プロセスのアジャイル
• スクラム、チームのスケール
3. マインドセットのアジャイル
• より良く学習するチームにするには？
※特にこのカンファレンスでは、後者2つが多め。

17. 議論の傾向
17
• DevOpsはもはや当たり前に。
• メトリクス（KPI）による改善も当たり前に。
• チーム・組織がより良いアクションを選択するた
めにどう活用すべきか？という側面を強調する
議論が増えてきている。
• DevOpsをメトリクスで改善するという議論も盛んに
なってきている。

18. スクラムチームのスケール
18
LeSS
(Large
Scale
Scrum)
Nexus
Framework
SAFe
(Scaled Agile
Framework)

19. 「モダンな」アジャイルの再定義・活用
19
アジャイル・スクラム・DevOpsなどの方法論やツール
が揃ってきたので、それらをベースに「モダンな」
アジャイルを再定義しようという議論も出てきている。
「モダンな」アジャイルを再定義し活用することで、
「ハイウェイ効果」を実現してはどうか？

20. 3. DevOps・メトリクス・
テストに関する知見

21. 21
DevOpsについて

22. 運用チーム開発チーム ユーザー
（参考）DevOpsとは（導入前）
22
リリース
開発
ビルド デプロイ
サーバ群
手作業中心
組織が分かれているので非効率

23. 開発・運用チーム（なのでDevOps） ユーザー
（参考）DevOpsとは（導入後）
23
リリースビルド デプロイ
サーバ群
開発
手作業中心から、全面的な自動化へ！

24. DevOpsの一般的な効果
24
市場へサービスを展開する時間を短くすることで、
• 経営判断を迅速に実施・反映できる
• 迅速・的確な営業をかけやすくなる
• ユーザの興味を引くデザインを試しやすくなる

25. DevOpsの議論の傾向
25
• 技術・ツール面は既に前提条件扱い。
• DevOpsを成功させるためのプロセスやマインドセッ
トを重視する議論が目立った。
• DevOpsを成功させるための、プロセスとしてのメト
リクスの活用の議論が活発。

26. 26
DevOpsとメトリクス
についての知見

27. パイプライン毎のメトリクス
27
開発・CI QA デプロイ リリース 運用
開発の
リード・タイム
非稼働時間
デプロイの
リード・タイム
リリース頻度 MTTR
欠陥・ビルド失敗・シス
テムダウンに
伴う再作業
検出・見逃した欠陥の
割合、および
欠陥の影響度合い
デプロイ頻度と
かかる時間
リリース毎の
時間とコストの割合
システムダウン時の
コストと頻度の割合
非稼働時間
MTTD
(検知にかかる時間)
（システム）変更の
成功率
（リリース成功の）
予測可能性
営業時間後の
緊急呼び出しの頻度
進行中の作業と
技術負債
MTTR
性能と利用時間の
割合
サイクル・タイム

28. パイプライン全体のメトリクス
28
サイクル・タイム（各工程・パイプラインに要す
る時間）
状況・状態の「見える化」（≒数値化）
（インフラの）拡張性

29. パイプライン毎の改善策
29
開発・CI QA デプロイ リリース 運用
Trunkベースの開発・
Git-flow
テスト自動化 全てを自動化すること
リリースパイプライン
をモデル化し、再利用性・
予測可能性・見える化を
保証すること
すべての成果物を
バージョン管理する
こと
環境構築の
セルフサービス形式の
自動化
本番環境に合致した
テスト環境を
構築すること
最初のデプロイは
本番環境に対しては
行わないこと
ツール・プロセス・
環境の全てを
合致させること
システムと
アプリケーションの
ヘルスチェック
*-as-code
環境構築の
セルフサービス形式の
自動化
継続的デリバリー
によるデプロイ頻度・
信頼性の改善
見える化
環境構築の
セルフサービス形式の
自動化
品質の作り込み
継続的デリバリー
（CD）
成果物を
バージョン管理する
こと
運営費・設備投資を
抑えるために、共有
インフラを使うこと
セキュリティの
作り込み
*-as-code

30. パイプライン毎の改善策
30
開発・CI QA デプロイ リリース 運用
Trunkベースの開発・
Git-flow
テスト自動化 全てを自動化すること
リリースパイプライン
をモデル化し、再利用性・
予測可能性・見える化を
保証すること
すべての成果物を
バージョン管理する
こと
環境構築の
セルフサービス形式の
自動化
本番環境に合致した
テスト環境を
構築すること
最初のデプロイは
本番環境に対しては
行わないこと
ツール・プロセス・
環境の全てを
合致させること
システムと
アプリケーションの
ヘルスチェック
*-as-code
環境構築の
セルフサービス形式の
自動化
継続的デリバリー
によるデプロイ頻度・
信頼性の改善
見える化
環境構築の
セルフサービス形式の
自動化
品質の作り込み
継続的デリバリー
（CD）
成果物を
バージョン管理する
こと
運営費・設備投資を
抑えるために、共有
インフラを使うこと
セキュリティの
作り込み
*-as-code

31. ビジネスのメトリクス
31
リード・タイム （タスクの開始から終了までの
時間）
リリースしたユーザーストーリー数
顧客満足度
取得・保持コスト

32. 組織文化のメトリクス
32
従業員満足度
社員の在職期間

33. メトリクスはどうあるべきか
33
• 計測するものはゴールに直結すべき
• ゴールにつなげる戦略を導き出す道具
• 会話を促すものであるべき
• 行動につながるものであるべき
• 計測するものは少ない方が良い
• チーム・プロダクトを成長させる方向を見つけるた
めに使用すべき

34. 34
テストについての知見

35. 35
システマティックなコード削除術 (1)
『レガシーコード
改善ガイド』の著者の
Michael Feathersさん
による、テストのための
コード削除テクニック！

36. システマティックなコード削除術 (2)
36
TDDやリファクタリングを行っても、
コードは汚くなるもの。
ならばどうするか？
戦略的にコードを削除していく！

37. システマティックなコード削除術 (3)
37
削除すべきコードの候補
• 到達不能コード
• Dead Code
• 実行はされるが、その結果が使われないコード
• 価値の低いコード

38. システマティックなコード削除術 (4)
38
どうやって削除対象を見つけるか？
• コードカバレッジ
• プロファイラ
• 機能を使ってみる

39. システマティックなコード削除術 (5)
39
コード削除戦略
• コードを複製して余計なものを取り除く
• 検知した到達不能コード・Dead Codeを削除する
• エントリーポイントで、価値の低いコードを動作させ
ないようにする

40. 4. Tech Giantを目指す
方法論

41. 「モダンな」アジャイルの再定義・活用
41
アジャイル・スクラム・DevOpsなどの方法論やツール
が揃ってきたので、それらをベースに「モダンな」
アジャイルを再定義しようという議論も出てきている。
「モダンな」アジャイルを再定義し活用することで、
「ハイウェイ効果」を実現してはどうか？

42. モダンアジャイル
42
By Joshua Kerievsky / CC BY-SA

43. 「モダンアジャイル」の４つの軸
43
1. 人々を最高に輝かせる
2. 安全を必須条件にする
3. 高速に実験＆学習する
4. 継続的に価値を届ける
by Joshua Kerievsky

44. 44
1. 人々を最高に輝かせる
例）日本の新幹線 人々を圧倒的に幸せに
するプロダクトを作ろう。
また、プロダクトに
関わる人を尊重し
幸せにしよう。
写真：アフロ

45. 2. 安全を必須条件にする
45
• 恐怖感で支配された文化は何も生み出さない
• 安全というものを前提条件としよう
• 心理的な安全性を重視し実現しよう
• Blameless Culture（非難されない文化）
• システム的にも、セーフティネットを張ろう
例）かんばん、CI/CD、テスト自動化

46. 3. 高速に実験＆学習する
46
• 失敗から学ぼう
• フィードバック＝学習
• Fail Fast（迅速な失敗を通じて成長しよう）
• 「安全性」がこれを保障する
例）リーンスタートアップ、振り返り

47. 4. 継続的に価値を届ける
47
端的に言うと、
継続的デリバリー（CD）と
DevOpsが該当する。

48. 実現すべき「モダンな」アジャイル
48
1. DevOpsをベースとしたプロダクト開発
• 既に確立されたプラクティスを活用する
2. 失敗を学習に活用する態度と仕組み
3. 失敗を責めない文化
4. 大きな成功を収めること

49. 実現すべき「モダンな」アジャイル
49
1. DevOpsをベースとしたプロダクト開発
• 既に確立されたプラクティスを活用する
2. 失敗を学習に活用する態度と仕組み
3. 失敗を責めない文化
4. 大きな成功を収めること

50. 5. 結論

51. アジャイル：Tech Giantへのハイウェイ
51
1. DevOpsをベースとしたプロダクト開発
• 既に確立されたプラクティスを活用する
2. 失敗を学習に活用する態度と仕組み
3. 失敗を責めない文化
4. 大きな成功を収めること

52. アジャイルへのアプローチ方法
52
• アジャイルを知ろう
• アジャイルを活用しよう
• アジャイルでTech Giantになろう

53. 53
BEST
IN THE
WORLD