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

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

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

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

序章（本質）

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

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

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

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

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

ビジネス 再確認：世界は変わっていないのか 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

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

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

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

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

アジャイル開発

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

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

アジャイルの計画と予測可能性 スプリント ポイント ベロシティ #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

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

フィードバックの機会 ＝ 学びと改善 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

36

37

38

39

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

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