XPFes2023_DevOps business-briefing_Hasegawa
•Download as PPTX, PDF•
0 likes•13 views
DevOps business briefing case study and basic knowledges.
Recommended
Recommended
More Related Content
Similar to XPFes2023_DevOps business-briefing_Hasegawa
Similar to XPFes2023_DevOps business-briefing_Hasegawa (20)
More from Tokyo, Japan
More from Tokyo, Japan (20)
Recently uploaded
Recently uploaded (12)
XPFes2023_DevOps business-briefing_Hasegawa
- 5. アジェンダ の前に DevOps 認識合わせ DevOps Cloud DevOps DevOps Monitoring and Operations DevOps Security Tools CI/CD DevOps Testing Organizati on Altering
- 6. その昔は・・ 監視 Monitor ing 保守 Mainten ance デプロイ Deploy 運用 Operati ons 開発 Dev 要件定義 RD 設計 BD,SD テスト Testing リリース / Release アジェンダ の前に DevOps 認識合わせ
- 7. 監視 Monitor ing 保守 Mainten ance デプロイ Deploy 運用 Operati ons 開発 Dev 要件定義 RD 設計 BD,SD テスト Testing ﾌｨｰﾄﾞﾊﾞｯｸ ﾘﾘｰｽ ﾌﾟﾗﾝ Feedback, Plan アジェンダ の前に DevOps 認識合わせ
- 8. アジェンダ の前に DevOps 認識合わせ デザインシンキング 正しいものを決める アジャイル 正しいものを正しく作る DevOps 正しく作ることを高速化する リーン 全プロセスでムダを排除する
- 9. Taku Hasegawa @tac_cha_ インド資本の受託Sier 開発案件支援のコンサルタント 社内アジャイルエバンジェリスト STEM教育講師ボランティア 12年前に半年育休経験 アジェンダ の前に 自己紹介
- 12. 小さな事例 01
- 14. 解決したい課題 01
- 15. 組織のサイロ化によるスピードダウン 部分最適化されている現在の組織からプロダクトベースチームへの改革 企画/研究部門 事業/製造部門 営業部門 システム部門 バトンリレー状態で行われている個別の部門内のプロセス改善をしてもスピードは速くなりません 1 2 3 4 プロダクト初期段階から 関係者が集まり 相互理解しながら進める ワンチーム体制 DevOpsツールの 多くは 組織横断で利用することで パフォーマンスを発揮します
- 17. 事例 02
- 19. 最初の状態 監視 保守 デプロイ 運用 開発 要件定義 設計 テスト 分 断 アイツらが何やってるか分からん 私たちのことに干渉しない でくれ アイツらのことはアイツらに任せよう パンパンだから人増やして アイツらが何やってるか分からん 私たちのことに干渉しない でくれ アイツらのことはアイツらに任せよう パンパンだから人増やして
- 20. 遅い、高い、不便 最初のリリース 開発会社 ユーザー企業 アプリ部門 開発 運用保守 システム部 事業部 管理部 営業 あれやりたい これやりたい →改善案件
- 21. 遅い、高い、不便 変化のきっかけは 断られて から 開発会社 ユーザー企業 アプリ部門 開発 運用保守 システム部 事業部 管理部 営業 開発 ＆ 運用保守
- 22. 開発 ＆ 運用保守 遅い、高い、不便 早い、安い、便利 に 開発会社 ユーザー企業 アプリ部門 システム部 事業部 管理部 営業
- 24. 早い、安い、便利 ！ ずっと？ 1月 2月 3月 4月 5月 6月 7月 8月 9月 Aさん Bさん Cさん Dさん 1月 2月 3月 4月 5月 6月 7月 8月 9月 Aさん Bさん Cさん Dさん ①~⑤案件 40人月 元々の契約・計画 バラした契約・計画 やってみた ら
- 25. 早い、安い、便利 ！ ずっと？ 開発会社 ユーザー企業 アプリ部門 開発 ＆ 運用保守 システム部 事業部 管理部 営業 ユーザー行脚
- 26. 早い、安い、便利 ！ ずっと？ 開発会社 ユーザー企業 アプリ部門 開発 ＆ 運用保守 システム部 事業部 管理部 営業 ユーザー行脚
- 27. 早い、安い、便利 ！ ずっと？ 開発会社 ユーザー企業 アプリ部門 開発 ＆ 運用保守 システム部 事業部 管理部 営業 ユーザー行脚
- 28. 早い、安い、便利 ！ ずっと？ 開発会社 ユーザー企業 アプリ部門 システム部 事業部 管理部 開発 ＆ 運用保守 ＆ 営業
- 30. 早い、安い、便利 ！ エビ → タイ？ 準委任PoC → 請負WF？
- 32. 混成ワンチーム 共有し合う
- 37. 01 02 03 04 05 CULTURE 責任の共有と組織間の コラボレーション AUTOMATION 継 続 的 イ ンテグ レ ー ションとテスト自動化 LEAN ムダの排除と W.I.P最小化 MEASUREMENT 現時点の把握と改善余地 の特定 SHARING チーム内外に オープンな情報公開をす る C A L M S DevOpsで使用されるCALMSフレームワーク
- 38. AUTOMATION コンティニュアスデリバリーパ イプラインの自動化 環境設定、開発、テスト、デプ ロイ、リリース、監視など多岐 に渡る LEAN FLOW バッチサイズを小さく保つ、WIP の制限、徹底的な可視化の提供 RECOVERY 迅速なリカバリーと低リスクの リリースを可能にするアーキテ クチャ MEASUREMENT パイプライン全体のフローの計 測。フルスタックの遠隔測定の 実装 CULTURE システム開発、オペレーションなど 企業のバリューストリームにおける 責任共有とツールを最大限活用する ための組織横断型コラボレーション の確立 01 02 03 04 05 出典：Scaled Agile Framework https://scaledagileframework.com/calmr/ C A L M R DevOpsのCALMRアプローチ
- 41. エクストリーム・プログラミング XPプロジェクトが成功するのを阻む最大の障壁は、(中略) 企業文化である。 第1版 第26章 XPを試すべきではないとき 組織の実際の価値が、秘密性、分離性、複雑性、臆病さ、軽蔑であれば、 (中略) 正反対の価値を突然表現すると、改善ではなく問題を引き起こすことになる。 第2版 第20章 XPの運用 XPを使用すべきでないとき 註：文章は都合よく切り取っています
- 42. マネジメント 課題 02
- 44. 01 ポートフォリオ
- 46. 取り組むべき課題 Step 3 Step 4 Step 1 Step 2 業務変革 プ ロ ダ ク ト ベ ー ス チームオペレーショ ンの実施 組織改革 プロセス分解と共同 化 人材育成 専門人材だけでなく 多能工型人材を育成 準備計画 スキル定義、人材育 成計画立案 業務統合計画 例１ ポートフォリオレベルでの導入
- 47. マスタースケジュール 1月 2月 3月 4月 5月 6月 7月 8月 9月 10 月 11 月 12 月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10 月 11 月 12 月 1月 2月 3月 4月 5月 6月 7月 現状分析、課題定義 推進体制構築 ツール準備 人材育成 初期導入 プロセス改善 ナレッジ頒布 拡張定着 Start End 例１ ポートフォリオレベルでの導入
- 48. 02 Ci/CDパイプライン
- 49. 環境参考例 Jenkins ※ロゴ、名称はそれぞれの登録商標です GitHub AWS CodeBuild AWS ECR AWS ECS AWS CloudWatch AWS lambda Circle CI Slack Image push Image deploy Unit Test Notice post 例２ CI/CDパイプライン導入
- 51. 脆弱性とリスクを特定し継続的開発のサイクルに組み込みます。 ソースコミッ ト コミット通知 ビルド デプロイ 結果取得 脆弱性対処 脆弱性診断 自動テスト 01 02 03 04 05 06 07 08 GitHub AWS CodeBuild AWS CodeDeploy Selenium Contrast Agent Contrast Server Jira Slack VSCode DevSecOpsの例 例２ CI/CDパイプライン導入
- 53. マスタースケジュール 例２ CI/CDパイプライン導入 JANUARY FEBRUARY MARCH APRIL MAY JUNE JULY AUGUST SEPTEMBER OCTOBER NOVEMBER DECEMBER PROJECT 1 --- Phase 1 --- Phase 2 --- Phase 3 --- Phase 4 PROJECT 2 --- Phase 1 --- Phase 2 --- Phase 3 --- Phase 4 QUARTER 1 QUARTER 2 QUARTER 3 QUARTER 4 推進組織立ち上げ ツール類選定 導入準備 導入後検証 拡張計画
- 54. プラクティス 03
- 61. フィーチャーフラグ 概要：プログラムソースレベルで有効/無効をハンドリングする 目的：コードデプロイと機能リリースを分離する 仮説検証(価値、効果) リリース デプロ イ Go Live デプロイ フラグ変更 Go Live ＝ → → フラグにセグメント要素を入れる・・・ヘビーユーザーのみ、年代、地域etc 同じVer.で異なる動きをする フラグ変更 デプロイ → Not Appear Appear → リリース管理
- 64. ずっとコード書き続けられ る 後戻りが少ないアプローチ 常にOSやミドルウェア更新 できる 生産性向上 早期のバグ課題検出 MW更新迅速化 変更リードタイムは、バッチサイズの大きさとチームのデリバ リー能力を測定します。 変更リードタイムが長すぎる場合は、 開発/デプロイプロセスが特定の段階で非効率的であるか、 パフォーマンスのボトルネックがあることを示しています。 継続的インテグレーションの利点 メトリクス：変更リードタイム 継続開発
- 65. ブランチ管理：目的の異なる開発を同時並行で実施可能 ・コードマージのとき、コンフリクトを最小限にする ・開発パイプラインで、変更をトレースできる Version 1.0 Version 1.1 A Master HotFix Release Develop Feature1 Feature2 １ P W X Q B C Version 1.2 R Y Z ２ G Version 1.3 F S T DT D 継続開発
- 66. https://www.freetimelearning.com/online-quiz/devops- quiz.php コードマージの競合を最小限に抑えることは、 ブランチ管理の目標の1つです。 True or False ミニクイズ 答えは True です Merge conflict
- 72. A環境 B環境 常時デプロイが可能な環境管理 Active Active Active Active Active Active Active Active Active 継続デプロイ A B C
- 73. https://www.freetimelearning.com/online-quiz/devops- quiz.php 〇〇〇 は､ チームが短いサイクルでソフトウェアを作成し、 いつでも確実にリリースできるようにするソフトウェアエンジニアリングアプローチです。 a.継続的デリバリー b.継続的デプロイ c.継続的インテグレーション ミニクイズ 答えは b. です Code Build Integrate Test Release Deploy Continuous Integration Continuous Delivery Continuous Deployment
- 77. メトリクス 変更失敗率、平均修復時間 モニタリング 変更失敗率は、障害率の尺度です。 平均修復時間 (MTTR) は、デプロイの価値を測る尺度で す。 これらは、コードの複雑さ､ 追加される機能数、 および環境の変更によって影響を受けます。
- 79. https://www.freetimelearning.com/online-quiz/devops- quiz.php 変更失敗率はアーキテクチャとテスト品質の判断指標です。 True or False ミニクイズ 答えは True です 4 keys 平均修復時間 MTTR 変更失敗率 リードタイム デプロイ頻度
- 81. 継続的なテスト DevOpsの継続的テストプラクティスは、テスト/QA/ビジネスが 三位一体となり、プロセスをシフトレフトし最適化します。 テスト自動化 https://www.techtarget.com/searchsoftwarequality/ tip/How-to-hold-Three-Amigos-meetings-in- Agile-development 開発 例)4週間スプリント 1W 2w 3w 4w 受入 QA ビジネス (開発者)開発完了！ →(QA)仕様と違う・・ (QA)品質担保！ →(ビジネス)仕様通りだけど、 ちょっと・・ 開発 & QA &ビジネス 開発 & QA &ビジネス 開発しながらQA ビジネス観点から フィードバック 2週間スプリントへの短縮
- 84. 機能テスト ストーリーテスト プロトタイプ シミュレーション 探索的テスト システムテスト ユーザビリティテスト 受入テスト 単体テスト コンポーネントテスト パフォーマンステスト 負荷テスト セキュリティテスト 当 た り 前 品 質 魅 力 品 質 自動 ツール 自動/手動 手動 TCS Confidential 参考)アジャイルテスティング4象限 テスト自動化
- 88. まとめ 04
- 90. エクストリーム・プログラミング XPは、 私(ケント・ベック)が不安に思っていることが反映され、 不安に思っていないことも反映されている。 第1版 27章 結論 より 自分自身を最初に改善しなければ何の改善も無いということ 第2版 25章 結論 より 註：文章は都合よく切り取っています
- 91. エクストリーム・プログラミング XP Practice Fine-scale Feedback Continuous process Shared understanding Programer wellfare Coding standards Collective Code ownership Sustainable pace Continuous integration Refactoring Small release Pair programing Planning Game Test-driven development
- 93. DevOps オススメのトレーニング、カンファレンス ITプレナーズさん https://www.itpreneurs.co.jp/training/tpp/ サーバントワークスさん https://www.servantworks.co.jp/posts/tag/devops/ DevOpsDaysTokyo https://www.devopsdayst okyo.org/