アジャイルとDevOps - はじめる前に

スライド概要

本資料は、「みんなのPython勉強会#56」で講演した内容になります。

ご質問やご支援についてはお気軽にご連絡くださいませ。

お問い合わせ:
https://www.servantworks.co.jp/contact/
contact@servantworks.co.jp

profile-image

長沢 智治

@nagasawa

作者について:

サーバントワークス株式会社 代表取締役/チーフアジャイルコーチ/エバンジェリスト DASA Ambassador DASA DevOps 認定トレーナー NOTA株式会社 アドバイザー 講演や支援のご相談はぜひお気軽に(ご相談は無料です)! PSPO II, PSM II, SPS, PAL-EBM, PAL I, PSU I, PSK I, PSD I, PSPO I, PSM I, CSM

スライド一覧
シェア
埋め込む»CMSなどでJSが使えない場合

公開日

2020-04-14 15:00:00

各ページのテキスト

1. アジャイルと DevOps 長沢 智治 サーバントワークス株式会社 代表取締役| DASA Ambassador| © Servant Works Inc. @tnagasawa

2. Who I am. ʻ96 ソフトウェア エンジニア ʻ00 改善コンサルタント ʻ07 エバンジェリスト ʻ18 独立・脱サラ ʻ20 会社設立 現場支援 アジャイル・DevOps | 働き方 | 人材育成 マーケティング プレゼンテーション アドバイザー | エバンジェリスト 言語化 | 企画の価値化支援 © Servant Works Inc. 2

3. DASA DevOps Agile Skills Association (DASA) DevOps とアジャイルのスキル開発を目的としたオープンかつグローバルな業界団体。 DASA における DevOps の原則 • 顧客中心の活動 • 機能横断的な自律型チーム • 目標を意識した創造 • 継続的改善 • エンド・ツー・エンドの責任 • 自動化できるものはすべて自動化 japan.devopsagileskills.org/ © Servant Works Inc. 3

4. 序章(本質)

5. 今回のテーマとゴール テーマ: コンセンサス 初学者向け 方法論や技術の 深掘りしません ゴール: 自分事に! 誰かと議論 5

6. アジャイルと DevOps アジャイル宣言 DevOps アジャイル © Servant Works Inc. DevOps (第一次) DevOps (第二次) 6

7. 変化しない世界から変化する世界へ ビジネス サービス/アプリ © Servant Works Inc. チーム 7

8. テクノロジーが変える 直接タッチ デバイス 競争の激化 クラウド © Servant Works Inc. IoT AI 8

9. テクノロジーとビジネスの不確実性 合意の難しさ 高 無秩序 やや 複雑 単純 低 低 複雑 やや 複雑 技術の不確実性 高 出典: Stacy Matrix, 『アジャイルソフトウェアエンジニアリング』日経BP社 © Servant Works Inc. 9

10. ビジネス 再確認:世界は変わっていないのか IT 便利 ビジネス 意思決定 システム特性 品質 技術 2010 2000 1990 既存のビジネスモデル IT部門が主導 client/server システム品質 web IT コア 新しいビジネスモデル 経営陣が主導 守るプロダクト コード品質 2020 IT 不可欠 IT 有効 IT マーケットが主導 攻めるプロダクト ビジネス品質 cloud & devices データ品質 IoT & AI Copyright © 2018 Tomoharu Nagasawa, All rights reserved. © Servant Works Inc. 10

11. 安定していたもの ビジネスモデル 組織 © Servant Works Inc. 顧客 11

12. もともと安定していなかったもの ソフトウェア 人由来のもの • ビジネス • モチベーション • 開発 • 能力とスキル • 運用 • 教育 © Servant Works Inc. 12

13. 実証主義(経験主義) ビジネス 開発 BUILD LEARN MEASURE • 仮説と検証 • アジャイル (バリューアップ) • リーンスタートアップ • 検査と適応 • デザイン指向 • チーム © Servant Works Inc. 13

14. 機会損失に対する戦略の転換 映画 ドラマ 数年単位のサイクル 3ヶ月単位のサイクル 公開 or 中止 1週間単位の見直し 莫大な予算と準備期間 継続可能な予算と準備期間 © Servant Works Inc. 14

15. アジャイル開発

16. 従来の開発の計画 C 費用 = 人月 D 期日 = 納期 S 範囲 = 要件 © Servant Works Inc. 16

17. Ready でない 要件は先送り C 費用 = チーム固定 Ready な要件 アジャイルの計画 D 期日 = 反復 (タイムボックス) #1 #2 #3 #4 #5 © Servant Works Inc. S 範囲 = 要件 17

18. アジャイルの計画と予測可能性 スプリント ポイント ベロシティ #3 #2 #1 #4 予測値 7 7 6 5 4 6 5 6 6 6 実績値 6 5 3 2 6 1 #1 #2 © Servant Works Inc. #3 #4 18

19. アジャイルチームはブラックボックスでいい INPUT OUTPUT アジャイルチーム 価値 アイデア 自己組織化した機能横断的なチーム (前提: ゴールに対して最善を尽くす) © Servant Works Inc. 19

20. フィードバックの機会 = 学びと改善 6か月のプロジェクト / 36機能 ✓ リリース: 1 回 ✓ 仕掛かり: 36 個 ✓ フィードバック機会: 1 回 ✓ リリース: 6m ✓ 仕掛かり: 36 個 ✓ フィードバック機会: 12 回 ✓ リリース: MMF ✓ 仕掛かり: 1 個 ✓ フィードバック機会: 36 回 ✓ (仕掛かり制限: 4 個) ウォーターフォール タイムボックス (2w) = 12 回 12 回 = 3 (2 〜 4) 個 スクラム (Minimal Marketing Feature) = およそ 36 回 カンバン © Servant Works Inc. 20

21. リトルの法則 リードタイム アイデア 価値 スループット 仕掛かり作業 (WIP) 仕掛かり作業 (WIP) リードタイム = スループット © Servant Works Inc. 21

22. スループットを上げるには グループ チーム それぞれの目的 共通の目的と成果 成果は総和 それぞれのやり方 やり方を共有 それぞれの作業と価値観 フォロー関係 同じ景色をみているか? © Servant Works Inc. 22

23. チーム 価値の流れ 透明性 チーム ムダとり © Servant Works Inc. 23

24. 繰り返し、構築・学び・改善 ビジネス 開発 BUILD LEARN MEASURE • 仮説と検証 • アジャイル • リーンスタートアップ • 検査と適応 • デザイン指向 • チーム © Servant Works Inc. 24

25. クリエイティブとルーティーンを分ける クリエイティブなワーク • 顧客やチームとの対話 • 設計や開発 • 計画・ふりかえり・改善 ルーティーンなワーク • スクラムのイベント(ゲームのルール) • CI/CD (パイプライン) • 改善のきっかけとデータを提供 © Servant Works Inc. 25

26. スクラムチーム PO SM Dev Team 1人 6 3人 1人 プロダクトオーナー 開発チーム スクラムマスター プロダクトの責任者 開発の責任者 プロセスの責任者 自己組織的、機能横断的、持続可能なチーム © Servant Works Inc. 26

27. スクラム デイリースクラム •3つのロール •3つの作成物 •5つのイベント スプリント計画 プロダクト バックログ スプリント スプリントレビュー スプリント バックログ レトロスペクティブ © Servant Works Inc. インクリメント 27

28. CI/CD パイプライン 価値 アイデア 企画 要件項目 タスク コード ビルド 機能 ソフトウェア 継続的インテグレーション (CI) 継続的デリバリー (CD, 狭義) 継続的デプロイメント (CD) © Servant Works Inc. 28

29. 開発と運用のムーブメント

30. DevOps に至る課題 開発 運用 ビジネスの成功 市場をリード 事業継続 ミッション • アジャイル • 頻繁な機能追加 • チーム メトリクス 方法論とツール © Servant Works Inc. • 安定重視 • 厳格な変更管理 • グループ 30

31. DevOps それぞれのメトリクス • 売り上げ / 利益率 • MAU / App DL • 満足度 / NPS Biz Product • 要求の実現度 • サイクルタイム • 品質 • 安定稼働 Dev Ops © Servant Works Inc. • 低コスト • SLI/SLO/SLA 31

32. DevOps グループからチームへ ビジネス 開発 運用 ビジネス 開発 運用 チーム チーム チーム チーム チーム チーム グループ ( IT ) チーム ( IT ) グループ ( ビジネス ) 共通の目的と成果 チーム ( ビジネス ) やり方を共有 © Servant Works Inc. フォロー関係 32

33. クリエイティブとルーティーンを分ける クリエイティブなワーク • 開発と運用での対話 • やり方、メトリクス • 計画・ふりかえり・改善 ルーティーンなワーク • 自動化 • データ共有と自動分析 © Servant Works Inc. 33

34. DevOps 目標の設定 ビジネス O O Objective KR Key Result 口コミでより早く広めて競合に勝つ! KR KR NPS: 7.5+ ・・・ O サービスの継続的な運営 KR KR リードタイム: 3 d MTTR: 3 h Dev O バックログの適切な意思決定 KR KR IT O バックログ調整: 1/ d 特急レーン サービス監視の自動化 KR KR 検知率: 10 % ・・・ Ops © Servant Works Inc. 34

35. DevOps のはじめかた K.I.S.S. Keep it short & simple. 小さくはじめる、小さく失敗する、小さく進める 大きな計画は呪い 費用対効果より機会損失 小さくないと費用効果も測れない © Servant Works Inc. 35

36. 36

37. 37

38. 38

39. 39

40. まとめ • 費用対効果より機会損失 • ビジネス指向 • チーム指向 • B.M.L. • クリティブワークとルーティンワーク • 協調/協働による建設的相互作用 • 自動化によるムダ取り 40

41. 感謝 〜 次の一歩へのお手伝いいたします 〜 サーバントワークス株式会社 servantworks.co.jp the Agility Consulting company nagasawa@servantworks.co.jp @tnagasawa