DXに取り組むためにアジャイルとDevOpsで武装する

スライド概要

BBTナイトGYMで講演した資料です。

profile-image

長沢 智治

@nagasawa

作者について:

サーバントワークス株式会社 代表取締役/チーフアジャイルコーチ/エバンジェリスト DASA Ambassador DASA DevOps 認定トレーナー NOTA株式会社 アドバイザー 講演や支援のご相談はぜひお気軽に(ご相談は無料です)! PSPO II, PSM II, SPS, PAL-EBM, PAL I, PSU I, PSK I, PSD I, PSPO I, PSM I, CSM

スライド一覧
シェア
埋め込む»CMSなどでJSが使えない場合

公開日

2021-09-03 06:59:14

各ページのテキスト

1. 長沢 智治 サーバントワークス 代表取締役|DASAアンバサダー|NOTA Inc. アドバイザー

2. 長沢 智治 INTEC ▷ Rational Software ▷ IBM ▷ Borland ▷ Microsoft ▷ Atlassian ▷ 独立・起業 (パラレルワーカー) サーバントワークス株式会社 代表取締役 DASA Ambassador in Japan NOTA Inc. アドバイザリーボード • Regional SCRUM Gathering Tokyo 2017 基調講演 • DevOps Days Tokyo 2017 基調講演 • Developers Summit 2013 基調講演 監訳 協力 執筆 監訳 監訳 共著 監訳

3. 内容 複雑さへの対応方法 アジャイル/DevOpsの必然 正解のないビジネスへ DXに向けたフローの見直し

4. ざっくりわかる

5. ソフトウェア開発の世界 契約 設計 実装 検証 配置 QA リリース担当者 運用 Scope </> 設計者 Cost Delivery 全体計画 統制管理 開発者 プロジェクト管理者 運用担当者 ユーザーに提供

6. ソフトウェア開発の世界 契約 設計 実装 検証 配置 QA リリース担当者 運用 Scope </> 設計者 Cost Delivery 全体計画 統制管理 開発者 プロジェクト管理者 運用担当者 ユーザーに提供

7. ソフトウェア開発の世界 契約 設計 実装 検証 配置 QA リリース担当者 運用 Scope </> 設計者 Cost Delivery 全体計画 統制管理 開発者 プロジェクト管理者 運用担当者 ユーザーに提供

8. ソフトウェア開発の世界 設計 契約 実装 検証 配置 QA リリース担当者 運用 Scope </> 設計者 Cost Delivery 全体計画 統制管理 開発者 プロジェクト管理者 運用担当者 ユーザーに提供

9. ソフトウェア開発の世界 契約 設計 実装 検証 配置 QA リリース担当者 運用 Scope </> 設計者 Cost Delivery 全体計画 統制管理 開発者 プロジェクト管理者 運用担当者 ユーザーに提供

10. ソフトウェア開発は発展途上、理想どおりに行かない 分業 契約 設計 実装 検証 配置 QA リリース担当者 運用 Scope </> 設計者 Cost Delivery 開発者 統制管理 プロジェクト管理者 運用担当者 全体計画 数ヶ月 ユーザーに提供 数ヶ月 数ヶ月 壮大な伝言ゲームの末に… 数ヶ月 数ヶ月 〇〇年 半数以上の機能が ユーザーに使われていない!

11. ソフトウェア開発は発展途上、理想どおりに行かない

12. アジャイルソフトウェア開発宣言 (2001) 私たちは、ソフトウェア開発の実践あるいは実践を手助けする活動を通じて、 よりよい開発方法を見つけだそうとしている。この活動を通じて、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを認めながらも、 私たちは右記のことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

13. ソフトウェア開発の現実世界 実現できる範囲で実現し、顧客からのフィードバックを得るサイクルを回し続ける Delivery Cost Scope 逐次で計画 1週間 1週間 理想主義から、経験主義へ 1週間

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

15. DASA による DevOps の定義と原則 DevOpsは、ビジネス目標を達成するためにハイパフォーマンスなITを可能 にするためのコラボレーションを促進するムーブメント 顧客中心の活動 ビジネスに対する DevOps の利点: ü 市場への投入速度と頻度の向上 ü より高い品質、より少ない障害、より高い安全性 ü イノベーション ü 従業員の積極参加と満足 ü ムダ取り ü リソースとコストの削減 目標を意識した創造 エンドツーエンドの 責任 機能横断的な 自律型チーム 継続的な改善 自動化できるもの はすべて自動化 開発と運用などの組織間の壁を取り除く

16. チームによる集合知・実践知を活かした活動 透明性 価値の流れ チーム ムダとり

17. 複雑な問題に対する共通している主要な価値観 顧客に価値を提供し続けるために 中間成果物より成果に価値をおく • • • • 複雑な問題・状況に対して 透明性と(短い)フィードバックサイクルで 検査と適応していき、経験から学び変化し続ける それを当事者意識を持つ自律したチームで遂行する

18. 正解のない時代 VUCA

19. 正解主義 予定調和 自前主義 丸投げ主義 根強く信じられていること

20. V Volatility ‒‒‒‒‒ 変動性 U Uncertainty ‒‒ 不確実性 正解のない時代 C Complexity ‒‒‒ 複雑性 A Ambiguity ‒‒‒‒ 曖昧性

21. V Volatility ‒‒‒‒‒ 変動性 社会の変化 U Uncertainty ‒‒ 不確実性 C Complexity ‒‒‒ 複雑性 A Ambiguity ‒‒‒‒ 曖昧性 テクノロジーの 進化

22. Software is eating the world. Marc Andreessen, 2011

23. ビジネス IT 2000 1990 IT 便利 IT 有効 IT はコストセンター 2010 IT 不可欠 2020 IT コア IT はビジネス戦略 Ø 既存のビジネスモデル Ø 新しいのビジネスモデル Ø 自社内で意思決定 Ø 市場が意思決定 Ø 守るプロダクト Ø 攻めるプロダクト Ø システムの品質 Ø ビジネスとデータの品質

24. 直接タッチ 競争激化 デバイス AI クラウド IoT テクノロジーが時代を変える

25. 正解主義 予定調和 複雑な状況での闘い方 自前主義 丸投げ主義 コアは自前、他は協創と利用 ここから脱することが不可欠

26. Q. 主戦場はどこか? 不可知の未知 既知の未知 未知の既知 未知の未知 既知の既知 Cynefin Framework 『More Effective Agile “ソフトウェアリーダー”になるための28の道標』(日経BP, 2020)

27. Idea BUILD LEARN Product Data MEASURE 出典: 『リーンスタートアップ』

28. 複雑な問題と規模感 規模の経済 規模の 経済 一次請け 固有 固有 固有 二次請け 共通する部分 三次請け 自前主義による不経済 丸投げ主義による不経済

29. コンウェイの法則 システムの設計は、その組織構造を反映させたものになる 固有 〇〇部 △△部 組織構造 固有 固有 □□部 システム設計 複雑な世界に適応するには、 機敏に意思決定できる小さな自律したチームの集合体

30. DXに取り組む 地に足つけて取り組むエッセンス

31. Q. クモがゾウのように大きく進化したらどうなるのか? ? スティーブン・ジェイ・グルード (1977)

32. Q. クモがゾウのように大きく進化したらどうなるのか? スティーブン・ジェイ・グルード (1977)

33. Q. クモがゾウのように大きく進化したらどうなるのか? スティーブン・ジェイ・グルード (1977)

34. 現状と実状を知る 外部の変化速度が組織内の変化速度を上回っているのであれば、 その組織の終わりは近い ジャック・ウェルチ 内部 ビジネス 外部 テクノロジー 組織

35. 顧客中心で考える 顧客 従業員 (DX for internal) 社内外の諸事情 中間成果より顧客価値 生産 担当者 ・・・ ・・・ ・・・ 流通 在庫 店舗 倉庫 注文 窓口 • 人や物が介在 • 他者解決型 • レコメンド • 自己解決型 他の顧客 顧客にとっての価値

36. 例: 切符販売機「目的地に行きたい」 人に頼んで買う(手配してもらう) LEVEL 0. 値段を調べて買う(380円の切符購入) LEVEL 1. 行先指定で買う(ここから新宿まで) LEVEL 2. SUICAでタッチ(いくらかかるかはしらなくてもよい) LEVEL 3.

37. 例: 商品購入「いい感じのものがほしい」 お店で店員さんにあれこれ聞いて買う(逃げにくい) LEVEL 0. お店で自分で見て回って買う(逃げられるがいい物が買えるか?) LEVEL 1. 気になる商品をお店でみて、ネットで最安値で買う(逃げる) LEVEL 2. ○マゾンなどで勧められた物を買う LEVEL 3.

38. DXで避けて通れない フローを変える

39. 顧客中心で考えてフローを改善していく セルフサービスモデルへの道|顧客が本当に知りたかったもの 従来: 〇〇です 知りたい! おもてなし対応 DX時代: 〇〇です 知りたい! 待てない! 対客コスト高い

40. 顧客はそこに答えがあると思ってアクセスする セルフサービスモデルへの道|顧客が本当に知りたかったもの 従来 わからないから聞く 対面対応=助かる

41. 顧客はそこに答えがあると思ってアクセスする セルフサービスモデルへの道|顧客が本当に知りたかったもの 従来 わからないから聞く 対面対応=助かる DX時代 わからないから退く 対面対応=辛い

42. フローは必ずといっていいほど見直す セルフサービスモデルへの道|顧客が本当に知りたかったもの フロー見直しのコツ 同期 非同期 ヒト・モノ 情報・データ 疎結合

43. 顧客中心で問い合わせフローを考える(現状分析) セルフサービスモデルへの道|顧客が本当に知りたかったもの 同期コミュニケーションでの問い合わせ対応(電話など) 顧客 窓口 専門家 問い合わせ連絡 専門家手配 専門家手配完了 質問 回答 回答

44. 顧客中心で問い合わせフローを考える(デジタル化) セルフサービスモデルへの道|顧客が本当に知りたかったもの 同期コミュニケーションでの問い合わせ対応(電話など) 顧客 窓口 専門家 KB 問い合わせ連絡 専門家手配 専門家手配完了 質問 検索 回答 回答 蓄積

45. 顧客中心で問い合わせフローを考える(フロー見直し) セルフサービスモデルへの道|顧客が本当に知りたかったもの 同期コミュニケーションでの問い合わせ対応(電話など) 顧客 窓口 KB 専門家 ナレッジ追加・更新 問い合わせ連絡 回答 質問 回答 (非同期) フィードバック ナレッジ追加・更新 (非同期) (非同期)

46. 顧客中心で問い合わせフローを考える(DX!) セルフサービスモデルへの道|顧客が本当に知りたかったもの 非同期コミュニケーションでの問い合わせ対応(FAQなど) 顧客 FAQ(KB) 専門家 ナレッジ追加・更新 閲覧・検索 (非同期) (非同期) 分析結果によるフィードバック (非同期) 顧客 閲覧・検索 (非同期) ? 質問 回答 窓口 質問 回答

47. ü 非常に身近ですぐできそうな DX のひとつ ü フローを見直すきっかけであり好例のひとつ ü 自前主義からの脱却の好例のひとつ ü ユニークな技術で技術の必要性がわかりやすい

48. まとめ Ø 複雑な時代だからこそのDX Ø アジャイルやDevOpsは必然/先例 Ø 中間成果より、顧客体験に着目 Ø フローの見直しを必ず検討する Ø 正解はない、予定調和もない Ø コアは自前、それ以外は、協創・利用

49. 感謝 お役に立てることがございましたら、ぜひお気軽にご連絡ください サーバントワークス株式会社 https://servantworks.co.jp/ nagasawa@servantworks.co.jp @tnagasawa