We got regarding DevOps so far - だいたいわかる DevOps

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

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

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

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

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

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

自己紹介｜生放送＆配信（Schoo） 開発プロセス入門 はじめてのスクラムマスター これからの プロジェクトマネジメント チーム開発入門 相互理解からはじめる DevOps schoo.jp/teacher/1709 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.

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

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

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

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

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

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

(アジャイル)マネジメント相互依存宣言 継続的な価値の流れによる投資対効果 顧客との信頼関係と確かな成果 透明性による不確実性の予測 個人の力を発揮する環境 責務を共有するチーム 状況に応じた戦略と改善 ©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. pmdoi.org 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.

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

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

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

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

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

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

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

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

DevOps｜機会損失と継続性 文化庁著作権 Q&A に基づく引用 映画 数年単位のサイクル 莫大な予算と準備期間 文化庁著作権 Q&A に基づく引用 3ヶ月単位のサイクル ドラマ 1週間単位の見直し 継続可能な予算と準備期間 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 Product Dev Ops 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 Objective KR Key Result ビジネス O 口コミでより早く広めて競合に勝つ！ 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 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 [email protected] 〜 名刺交換やお話をしましょう 〜 Copyright © Tomoharu Nagasawa All Rights Reserved.