だいたいわかる DevOps

DASA Exchange TOKYO 2019 Copyright © Tomoharu Nagasawa All Rights Reserved. DASA Ambassador

Copyright © Tomoharu Nagasawa All Rights Reserved. 自己紹介 DASA Ambassador (2019.06 ～)

Copyright © Tomoharu Nagasawa All Rights Reserved. 自己紹介｜事業 顧問・所属: エバンジェリスト Service Evangelism Lead 顧問 アンバサダー クライアント: ～上場企業からスタートアップまで～ 協力: ご依頼・ご相談はどうぞお気軽に evangelism.jp

Copyright © Tomoharu Nagasawa All Rights Reserved. 自己紹介｜略歴 長沢 智治 NAGASAWA Tomoharu ソフトウェア エンジニア 改善コンサルタント エバンジェリスト 独立・脱サラ ‘96 ‘00 ‘07 ‘18

Copyright © Tomoharu Nagasawa All Rights Reserved. 自己紹介｜基調講演 アジャイル DevOps Regional SCRUM Gathering Tokyo 2017 JaSST ’16 Niigata DevOps Days Tokyo 2017 Developers Summit 2013 Summer2013 DevOps Summer

Copyright © Tomoharu Nagasawa All Rights Reserved. 自己紹介｜書籍（アジャイル＆DevOpsのみ） 監訳 監訳 監訳 協力

Copyright © Tomoharu Nagasawa All Rights Reserved. 自己紹介｜生放送＆配信（Schoo） schoo.jp/teacher/1709 開発プロセス入門 はじめてのスクラムマスター これからの プロジェクトマネジメント チーム開発入門 相互理解からはじめる DevOps

Copyright © Tomoharu Nagasawa All Rights Reserved. 本セッションの内容 WHY WHAT HOW

Copyright © Tomoharu Nagasawa All Rights Reserved. 本セッションのゴール アジャイル・DevOps の をだいたい抑えて、 自分の言葉で伝えるきっかけとなる WHY WHAT HOW

Copyright © Tomoharu Nagasawa All Rights Reserved. Why

Copyright © Tomoharu Nagasawa All Rights Reserved. ビジネスの変化とテクノロジーの進化 ビジネス IT 1990 20102000 2020 IT 便利 IT 不可欠IT 有効 IT コア 既存のビジネスモデル 新しいビジネスモデル IT部門が主導 経営陣が主導 マーケットが主導 守るプロダクト 攻めるプロダクト コード品質 システム品質 ビジネス品質 データ品質 client/server web cloud & devices IoT & AI ビジネス 意思決定 システム特性 品質 技術 Copyright © 2018 Tomoharu Nagasawa, All rights reserved. 本図解を入手・利用いただけます

Copyright © Tomoharu Nagasawa All Rights Reserved. アジャイル / DevOps ビジネス IT 1990 20102000 2020 IT 便利 IT 不可欠IT 有効 IT コア アジャイル宣言 DevOps アジャイル DevOps DevOps (第一次) (第二次)

Copyright © Tomoharu Nagasawa All Rights Reserved. デバイス クラウド IoT デジタル トランスフォーメーション (DX) 攻めるプロダクト マーケットが主導 2010 IT は不可欠 IT はコア 2020 直接タッチ 競争の激化 ビジネスに学習機会を提供 継続的な投資とデリバリー

Copyright © Tomoharu Nagasawa All Rights Reserved. Build ▶ Measure ▶ Learn (BML) ｜ ビジネスとITが同期 データ アイデア プロダクトBUILD MEASURE LEARN

Copyright © Tomoharu Nagasawa All Rights Reserved. プロダクトにフォーカス Biz OpsDev Product

Copyright © Tomoharu Nagasawa All Rights Reserved. 不確実性を受け入れる 無秩序 単純 やや 複雑 やや 複雑 複雑 技術の不確実性 合意の難しさ 低 高 低 高 出典: Stacy Matrix, 『アジャイルソフトウェアエンジニアリング』日経BP社

Copyright © Tomoharu Nagasawa All Rights Reserved. (アジャイル)マネジメント相互依存宣言 継続的な価値の流れによる投資対効果 顧客との信頼関係と確かな成果 透明性による不確実性の予測 個人の力を発揮する環境 責務を共有するチーム 状況に応じた戦略と改善 pmdoi.org ©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.

Copyright © Tomoharu Nagasawa All Rights Reserved. 共通の目的 やり方を共有 フォロー関係 形式知 ▶ 集合知 ｜チーム指向

Copyright © Tomoharu Nagasawa All Rights Reserved. 集団とチームの違い それぞれの目的 成果は総和 それぞれのやり方 それぞれの作業と価値観 共通の目的と成果 やり方を共有 フォロー関係 集団 チーム 同じ景色をみているか？

Copyright © Tomoharu Nagasawa All Rights Reserved. チーム｜生物的組織 または 超個体 ビジネス チーム 開発 運用 チーム チーム チーム ( IT ) チーム ( ビジネス ) 進化ではなく、変化 https://nabechan38.naturum.ne.jp/e1628548.html

Copyright © Tomoharu Nagasawa All Rights Reserved. SECI モデル (参考) 引用: SECI プロセスモデル

Copyright © Tomoharu Nagasawa All Rights Reserved. 信頼とコストのバランスの変化

Copyright © Tomoharu Nagasawa All Rights Reserved. WHY のまとめ ビジネスの要請 アジャイル/DevOpsの必然性 チームによるスピード

Copyright © Tomoharu Nagasawa All Rights Reserved. What

Copyright © Tomoharu Nagasawa All Rights Reserved. アジャイル コンセンサス 透明性 価値の流れ ムダとり チーム

Copyright © Tomoharu Nagasawa All Rights Reserved. 鉄の三角形 C D S Scope範囲 Q Delivery 期日 Quality 品質 Cost 費用 C・D・S のすべては固定できない

Copyright © Tomoharu Nagasawa All Rights Reserved. 何を固定するべきか？ C D S Scope 範囲 Q Delivery 期日 Quality 品質 Cost 費用 C D S Scope 範囲 Q Delivery 期日 Quality 品質 Cost 費用 従来型 アジャイル

Copyright © Tomoharu Nagasawa All Rights Reserved. 鉄の三角形 C D S Scope 範囲 Q Delivery 期日 Quality 品質 Cost 費用 C D S Scope 範囲 Q Delivery 期日 Quality 品質 Cost 費用 従来型 アジャイル

Copyright © Tomoharu Nagasawa All Rights Reserved. 従来型の計画と変更への応対 S 範囲 ＝ 要件 C 費用 ＝ 人月 D 期日 ＝ 納期 費用 ＝ 人月 (工数)

Copyright © Tomoharu Nagasawa All Rights Reserved. アジャイルの計画と変更への応対 S 範囲 ＝ バックログ C 費用 ＝ チーム D 期日 ＝ タイムボックス #1 #2 #3 #4 #5 費用 ＝ チーム数 #1 #2 #3 #4 #5

Copyright © Tomoharu Nagasawa All Rights Reserved. アジャイルの計画と予測可能性 #1 #2 #3 #4スプリント ベロシティ #1 #2 #3 #4 1 2 3 4 5 6 7 予測値 実績値 7 5 5 6 6 6 6 6 ポイント 6

Copyright © Tomoharu Nagasawa All Rights Reserved. 仕掛かり(WIP) とフィードバック ウォーターフォール スクラム カンバン 6か月のプロジェクト / 36機能 ✓ リリース: 1 回 ✓ WIP: 36 個 ✓ フィードバック機会: 1 回 ✓ リリース: 6m ÷ タイムボックス (2w) = 12 回 ✓ WIP: 36 個 ÷ 12 回 = 3 (2 ～ 4) 個 ✓ フィードバック機会: 12 回 ✓ リリース: MMF (Minimal Marketing Feature) = およそ 36 回 ✓ WIP: 1 個 ✓ フィードバック機会: 36 回 ✓ (WIP制限: 4 個)

Copyright © Tomoharu Nagasawa All Rights Reserved. スループットと仕掛かりの関係｜リトルの法則 リードタイム アイデア 価値 仕掛かり作業 (WIP) スループット ＝リードタイム 仕掛かり作業 (WIP) スループット

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps｜ビジネス駆動なムーブメント Biz OpsDev Product

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps｜ビジネス駆動なムーブメント Biz OpsDev Product

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps｜メトリクス Biz OpsDev Product • 売り上げ / 利益率 • MAU / App DL • 満足度 / NPS • 安定稼働 • 低コスト • SLI/SLO/SLA • 要求の実現度 • サイクルタイム • 品質

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps｜機会損失と継続性 映画 ドラマ 数年単位のサイクル 莫大な予算と準備期間 3ヶ月単位のサイクル 1週間単位の見直し 継続可能な予算と準備期間 文化庁著作権 Q&A に基づく引用 文化庁著作権 Q&A に基づく引用

Copyright © Tomoharu Nagasawa All Rights Reserved. Biz, Dev, Ops の生物的組織（＝ チーム） ビジネス チーム 開発 運用 チーム チーム 集団 ( IT ) 集団 ( ビジネス ) ビジネス チーム 開発 運用 チーム チーム チーム ( IT ) チーム ( ビジネス ) 共通の目的と成果 やり方を共有 フォロー関係

Copyright © Tomoharu Nagasawa All Rights Reserved. CLAMS (参考) C L A M S 文化 Culture リーン Lean 自動化 Automation 計測 Measure 共有 Sharing Biz OpsDev Product

Copyright © Tomoharu Nagasawa All Rights Reserved. WHAT のまとめ アジャイル コンセンサス 従来型とのアプローチの違い 勝ち続けるスピードと意思をもったチーム

Copyright © Tomoharu Nagasawa All Rights Reserved. How

Copyright © Tomoharu Nagasawa All Rights Reserved. 協調による問題解決と結束（生物的組織の成長） エクササイズ！ ❶ ペアを組んでください ❷ 左の人が【Dev】右の人は【Ops】です ❸【Dev】は折り紙を 3分の2 にしてください ❹ 完成したら【Ops】に渡してください 非公開 ワークショップの実施を承ります https://evangelism.jp/contact/

Copyright © Tomoharu Nagasawa All Rights Reserved. 認知バイアス 確証バイアス 正常性バイアス 後知恵バイアス 起きたことが 予測可能だったと みてしまう傾向 都合の悪い情報を 無視してしまう 傾向 自分の都合がよい 情報だけを 集めてしまう 「前にうまくいった」 「大丈夫」 「やっぱり」 協調による建設的相互作用でバイアスから抜け出す

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

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps の始め方 K.I.S.S. Keep it short & simple. 小さくはじめる、小さく失敗する、小さく進める 大きな計画は呪い 費用対効果より機会損失 小さくないと費用効果も測れない

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps の５ステップ

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps の５ステップ

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps の５ステップ

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps の５ステップ

Copyright © Tomoharu Nagasawa All Rights Reserved. DevOps の始め方 ワークショップを活用して共通体験、共通認識、共通言語を得る フェニックス プロジェクト プロジェクト テーマパーク /www.creationline.com/lab/devops/28961

Copyright © Tomoharu Nagasawa All Rights Reserved. HOW のまとめ 現場を理解する 協調による学習と実践 K.I.S.S ～ 関係者を減らして取り組みましょう

Copyright © Tomoharu Nagasawa All Rights Reserved. 最後に宿題 『アジャイル』『DevOps』を使わないで 説明できるようにしましょう 学習と実践のサイクルを 小さく、短くやってみましょう

Copyright © Tomoharu Nagasawa All Rights Reserved. evangelism.jp nagasawa@evangelism.jp ～ 名刺交換やお話をしましょう ～ 感謝