サーバントワークス株式会社

アジャイルマネジメント

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

© 長沢智治 講演日 （みんなのPython勉強会#56） 全 41 ページ 2026-10-20 公開 v1（最新版）

2 ページ：© Servant Works Inc. Who I am. 2 ソフトウェア エンジニア 改善コンサルタント エバンジェリスト 独立・脱サラ ‘96 ‘00 ‘07 ‘18 ‘20 会社設立 現場支援 プレゼンテーションマーケティング アジャイル・DevOps | 働...
/ 41

5,400 回閲覧
B! はてブ

この資料について

アジャイルとDevOpsをはじめるにあたって必要となるエッセンスについて

全ページのテキスト
  1. p.1
    アジャイルと DevOps © Servant Works Inc. 長沢 智治 サーバントワークス株式会社 代表取締役｜ DASA Ambassador｜ @tnagasawa
  2. p.2
    © Servant Works Inc. Who I am. 2 ソフトウェア エンジニア 改善コンサルタント エバンジェリスト 独立・脱サラ ‘96 ‘00 ‘07 ‘18 ‘20 会社設立 現場支援 プレゼンテーションマーケティング アジャイル・DevOps | 働き方 | 人材育成 アドバイザー | エバンジェリスト 言語化 | 企画の価値化支援
  3. p.3
    © Servant Works Inc. DASA 3 DevOps Agile Skills Association (DASA) DevOps とアジャイルのスキル開発を目的としたオープンかつグローバルな業界団体。 DASA における DevOps の原則 • 顧客中心の活動 • 目標を意識した創造 • エンド・ツー・エンドの責任 • 機能横断的な自律型チーム • 継続的改善 • 自動化できるものはすべて自動化 japan.devopsagileskills.org/
  4. p.4
    序章（本質）
  5. p.5
    今回のテーマとゴール 5 テーマ: 初学者向け 方法論や技術の 深掘りしません コンセンサス ゴール: 自分事に！ 誰かと議論
  6. p.6
    © Servant Works Inc. アジャイルと DevOps 6 アジャイル宣言 DevOps アジャイル DevOps DevOps (第一次) (第二次)
  7. p.7
    © Servant Works Inc. 変化しない世界から変化する世界へ 7 ビジネス サービス/アプリ チーム
  8. p.8
    © Servant Works Inc. テクノロジーが変える 8 デバイス クラウド IoT 直接タッチ 競争の激化 AI
  9. p.9
    © Servant Works Inc. テクノロジーとビジネスの不確実性 9 無秩序 単純 やや 複雑 やや 複雑 複雑 技術の不確実性 合意の難しさ 低 高 低 高 出典: Stacy Matrix, 『アジャイルソフトウェアエンジニアリング』日経BP社
  10. p.10
    © Servant Works Inc. 再確認：世界は変わっていないのか 10 ビジネス IT 1990 20102000 2020 IT 便利 IT 不可欠IT 有効 IT コア 既存のビジネスモデル 新しいビジネスモデル IT部門が主導 経営陣が主導 マーケットが主導 守るプロダクト 攻めるプロダクト コード品質 システム品質 ビジネス品質 データ品質 client/server web cloud & devices IoT & AI ビジネス 意思決定 システム特性 品質 技術 Copyright © 2018 Tomoharu Nagasawa, All rights reserved.
  11. p.11
    © Servant Works Inc. 安定していたもの 11 ビジネスモデル 組織 顧客
  12. p.12
    © Servant Works Inc. もともと安定していなかったもの 12 ソフトウェア 人由来のもの • ビジネス • 開発 • 運用 • モチベーション • 能力とスキル • 教育
  13. p.13
    © Servant Works Inc. 実証主義（経験主義） 13 ビジネス • 仮説と検証 • リーンスタートアップ • デザイン指向 • アジャイル (バリューアップ) • 検査と適応 • チーム BUILD MEASURE LEARN 開発
  14. p.14
    © Servant Works Inc. 機会損失に対する戦略の転換 14 映画 ドラマ 数年単位のサイクル 公開 or 中止 莫大な予算と準備期間 3ヶ月単位のサイクル 1週間単位の見直し 継続可能な予算と準備期間
  15. p.15
    アジャイル開発
  16. p.16
    © Servant Works Inc. 従来の開発の計画 16 S 範囲 ＝ 要件 C 費用 ＝ 人月 D 期日 ＝ 納期
  17. p.17
    © Servant Works Inc. アジャイルの計画 17 C 費用 ＝ チーム固定 D 期日 ＝ 反復 (タイムボックス) 範囲 ＝ 要件S#1 #2 #3 #4 #5 Ready な要件 Ready でない 要件は先送り
  18. p.18
    © Servant Works Inc. アジャイルの計画と予測可能性 18 #1 #2 #3 #4スプリント ベロシティ #1 #2 #3 #4 1 2 3 4 5 6 7 予測値 実績値 7 5 5 6 6 6 6 6 ポイント 6
  19. p.19
    © Servant Works Inc. アジャイルチームはブラックボックスでいい 19 アイデア 価値 アジャイルチーム 自己組織化した機能横断的なチーム INPUT OUTPUT （前提: ゴールに対して最善を尽くす）
  20. p.20
    © Servant Works Inc. フィードバックの機会 ＝ 学びと改善 20 ウォーターフォール スクラム カンバン 6か月のプロジェクト / 36機能 ✓ リリース: 1 回 ✓ 仕掛かり: 36 個 ✓ フィードバック機会: 1 回 ✓ リリース: 6m ÷ タイムボックス (2w) = 12 回 ✓ 仕掛かり: 36 個 ÷ 12 回 = 3 (2 ～ 4) 個 ✓ フィードバック機会: 12 回 ✓ リリース: MMF (Minimal Marketing Feature) = およそ 36 回 ✓ 仕掛かり: 1 個 ✓ フィードバック機会: 36 回 ✓ (仕掛かり制限: 4 個)
  21. p.21
    © Servant Works Inc. リトルの法則 21 リードタイム アイデア 価値 仕掛かり作業 (WIP) スループット ＝リードタイム 仕掛かり作業 (WIP) スループット
  22. p.22
    © Servant Works Inc. スループットを上げるには 22 それぞれの目的 成果は総和 それぞれのやり方 それぞれの作業と価値観 共通の目的と成果 やり方を共有 フォロー関係 グループ チーム 同じ景色をみているか？
  23. p.23
    © Servant Works Inc. チーム 23 透明性 価値の流れ ムダとり チーム
  24. p.24
    © Servant Works Inc. 繰り返し、構築・学び・改善 24 ビジネス • 仮説と検証 • リーンスタートアップ • デザイン指向 • アジャイル • 検査と適応 • チーム BUILD MEASURE LEARN 開発
  25. p.25
    © Servant Works Inc. クリエイティブとルーティーンを分ける 25 クリエイティブなワーク • 顧客やチームとの対話 • 設計や開発 • 計画・ふりかえり・改善 ルーティーンなワーク • スクラムのイベント（ゲームのルール） • CI/CD (パイプライン) • 改善のきっかけとデータを提供
  26. p.26
    © Servant Works Inc. スクラムチーム 26 PO SM Dev Team 1人 1人6±3人 プロダクトの責任者 開発の責任者 プロセスの責任者 プロダクトオーナー 開発チーム スクラムマスター 自己組織的、機能横断的、持続可能なチーム
  27. p.27
    © Servant Works Inc. スクラム 27 プロダクト バックログ スプリント バックログ インクリメント スプリント計画 デイリースクラム スプリント スプリントレビュー レトロスペクティブ •３つのロール •３つの作成物 •５つのイベント
  28. p.28
    © Servant Works Inc. CI/CD パイプライン 28 アイデア 価値 企画 要件項目 タスク コード ビルド 機能 ソフトウェア 継続的インテグレーション (CI) 継続的デリバリー (CD, 狭義) 継続的デプロイメント (CD)
  29. p.29
    開発と運用のムーブメント
  30. p.30
    © Servant Works Inc. DevOps に至る課題 30 開発 • アジャイル • 頻繁な機能追加 • チーム • 安定重視 • 厳格な変更管理 • グループ 運用 ビジネスの成功 市場をリード 事業継続 ミッション メトリクス 方法論とツール
  31. p.31
    © Servant Works Inc. DevOps それぞれのメトリクス 31 Biz OpsDev Product • 売り上げ / 利益率 • MAU / App DL • 満足度 / NPS • 安定稼働 • 低コスト • SLI/SLO/SLA • 要求の実現度 • サイクルタイム • 品質
  32. p.32
    ビジネス チーム 開発 運用 チーム チーム グループ ( IT ) グループ ( ビジネス ) © Servant Works Inc. DevOps グループからチームへ 32 ビジネス チーム 開発 運用 チーム チーム チーム ( IT ) チーム ( ビジネス ) 共通の目的と成果 やり方を共有 フォロー関係
  33. p.33
    © Servant Works Inc. クリエイティブとルーティーンを分ける 33 クリエイティブなワーク • 開発と運用での対話 • やり方、メトリクス • 計画・ふりかえり・改善 ルーティーンなワーク • 自動化 • データ共有と自動分析
  34. p.34
    © Servant Works Inc. DevOps 目標の設定 34 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
  35. p.35
    © Servant Works Inc. DevOps のはじめかた 35 K.I.S.S. Keep it short & simple. 小さくはじめる、小さく失敗する、小さく進める 大きな計画は呪い 費用対効果より機会損失 小さくないと費用効果も測れない
  36. p.36
    36
  37. p.37
    37
  38. p.38
    38
  39. p.39
    39
  40. p.40
    まとめ • 費用対効果より機会損失 • ビジネス指向 • チーム指向 • B.M.L. • クリティブワークとルーティンワーク • 協調/協働による建設的相互作用 • 自動化によるムダ取り 40
  41. p.41
    the Agility Consulting company サーバントワークス株式会社 servantworks.co.jp nagasawa@servantworks.co.jp 感謝 ＠tnagasawa ～ 次の一歩へのお手伝いいたします ～

共有

共有先を開く前に、共有する URL を確定します。投稿は共有先の画面で、ご自身が確定してください。

共有する範囲
X でポスト はてなブックマーク

埋め込む

ほかのサイトに、ページ送りのできるビューアを表示します。WordPress では資料の URL を貼るだけでも埋め込めます。

このページを引用

スライドを覆わず、外側の下部に「引用」・資料名・ページ・著作権表示・出典 URL を付けた PNG 画像を作ります。

「引用」の表示や出典の付記だけで、利用の適法性が保証されるわけではありません。引用の要件（主従関係・必要性など）と、写真・図版などの第三者の権利をご確認ください。