DXに取り組むためにアジャイルとDevOpsで武装する
関連・おすすめの資料
The path to More Effective Agile
スティーブ・マコネル著、長沢智治 監訳の『More Effective Agile』（日経BP, 2020）になるためのみちしるべ的な内容です。
企業のアジリティに必要な意思決定・仕事の仕方・取り組み方
ビジネスアジリティを実現するために、ソフトウェア由来のアジャイルを活用する勘所を提示した資料です。
全ページのテキスト
- p.1
長沢 智治 サーバントワークス 代表取締役｜DASAアンバサダー｜NOTA Inc. アドバイザー
- p.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 基調講演 長沢 智治
- p.3
内容 複雑さへの対応方法 正解のないビジネスへ DXに向けたフローの見直し アジャイル/DevOpsの必然
- p.4
ざっくりわかる
- p.5
ソフトウェア開発の世界 全体計画 契約 Scope Cost Delivery 設計 設計者 実装 開発者 検証 QA 配置 リリース担当者 統制管理 プロジェクト管理者 運用 ユーザーに提供 </> 運用担当者
- p.6
ソフトウェア開発の世界 全体計画 契約 Scope Cost Delivery 設計 設計者 実装 開発者 検証 QA 配置 リリース担当者 統制管理 プロジェクト管理者 運用 ユーザーに提供 </> 運用担当者
- p.7
ソフトウェア開発の世界 全体計画 契約 Scope Cost Delivery 設計 設計者 実装 開発者 検証 QA 配置 リリース担当者 統制管理 プロジェクト管理者 運用 ユーザーに提供 </> 運用担当者
- p.8
ソフトウェア開発の世界 全体計画 契約 Scope Cost Delivery 設計 設計者 実装 開発者 検証 QA 配置 リリース担当者 統制管理 プロジェクト管理者 運用 ユーザーに提供 </> 運用担当者
- p.9
ソフトウェア開発の世界 全体計画 契約 Scope Cost Delivery 設計 設計者 実装 開発者 検証 QA 配置 リリース担当者 統制管理 プロジェクト管理者 運用 ユーザーに提供 </> 運用担当者
- p.10
ソフトウェア開発は発展途上、理想どおりに行かない 全体計画 契約 Scope Cost Delivery 設計 設計者 実装 開発者 検証 QA 配置 リリース担当者 統制管理 プロジェクト管理者 運用 ユーザーに提供 </> 運用担当者 数ヶ月 数ヶ月 数ヶ月 数ヶ月 数ヶ月 〇〇年 分業 壮大な伝言ゲームの末に… 半数以上の機能が ユーザーに使われていない！
- p.11
ソフトウェア開発は発展途上、理想どおりに行かない
- p.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, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
- p.13
ソフトウェア開発の現実世界 逐次で計画 Scope Cost Delivery 1週間 1週間 1週間 理想主義から、経験主義へ 実現できる範囲で実現し、顧客からのフィードバックを得るサイクルを回し続ける
- p.14
©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. 継続的な価値の流れによる投資対効果 顧客との信頼関係と確かな成果 透明性による不確実性の予測 個人の力を発揮する環境 責務を共有するチーム 状況に応じた戦略と改善 アジャイル相互依存宣言 (2005)
- p.15
DASA による DevOps の定義と原則 DevOpsは、ビジネス目標を達成するためにハイパフォーマンスなITを可能 にするためのコラボレーションを促進するムーブメント 顧客中心の活動 目標を意識した創造 エンドツーエンドの 責任 機能横断的な 自律型チーム 継続的な改善 自動化できるもの はすべて自動化 ü 市場への投入速度と頻度の向上 ü より高い品質、より少ない障害、より高い安全性 ü イノベーション ü 従業員の積極参加と満足 ü ムダ取り ü リソースとコストの削減 ビジネスに対する DevOps の利点: 開発と運用などの組織間の壁を取り除く
- p.16
チームによる集合知・実践知を活かした活動 透明性 価値の流れ ムダとり チーム
- p.17
中間成果物より成果に価値をおく 顧客に価値を提供し続けるために • 複雑な問題・状況に対して • 透明性と(短い)フィードバックサイクルで • 検査と適応していき、経験から学び変化し続ける • それを当事者意識を持つ自律したチームで遂行する 複雑な問題に対する共通している主要な価値観
- p.18
VUCA 正解のない時代
- p.19
根強く信じられていること 正解主義 自前主義 予定調和 丸投げ主義
- p.20
V U C A Volatility ‒‒‒‒‒ 変動性 Uncertainty ‒‒ 不確実性 Complexity ‒‒‒ 複雑性 Ambiguity ‒‒‒‒ 曖昧性 正解のない時代
- p.21
V U C A Volatility ‒‒‒‒‒ 変動性 Uncertainty ‒‒ 不確実性 Complexity ‒‒‒ 複雑性 Ambiguity ‒‒‒‒ 曖昧性 社会の変化 テクノロジーの 進化
- p.22
Software is eating the world. Marc Andreessen, 2011
- p.23
ビジネス IT 1990 20102000 2020 IT 便利 IT 不可欠IT 有効 IT コア IT はコストセンター IT はビジネス戦略 Ø 既存のビジネスモデル Ø 自社内で意思決定 Ø 守るプロダクト Ø システムの品質 Ø 新しいのビジネスモデル Ø 市場が意思決定 Ø 攻めるプロダクト Ø ビジネスとデータの品質
- p.24
直接タッチ 競争激化 テクノロジーが時代を変える デバイス クラウド IoT AI
- p.25
ここから脱することが不可欠 正解主義 自前主義 予定調和 丸投げ主義 複雑な状況での闘い方 コアは自前、他は協創と利用
- p.26
Cynefin Framework 既知の既知 既知の未知未知の未知 不可知の未知 未知の既知 『More Effective Agile “ソフトウェアリーダー”になるための２８の道標』(日経BP, 2020) Q. 主戦場はどこか？
- p.27
BUILD MEASURE LEARN Idea Product Data 出典: 『リーンスタートアップ』
- p.28
複雑な問題と規模感 規模の経済 規模の 経済 共通する部分 固有 固有 固有 自前主義による不経済 一次請け 二次請け 三次請け 丸投げ主義による不経済
- p.29
コンウェイの法則 システムの設計は、その組織構造を反映させたものになる 固有 固有 固有 〇〇部 △△部 □□部 組織構造 システム設計 複雑な世界に適応するには、 機敏に意思決定できる小さな自律したチームの集合体
- p.30
地に足つけて取り組むエッセンス DXに取り組む
- p.31
スティーブン・ジェイ・グルード (1977) Q. クモがゾウのように大きく進化したらどうなるのか？ ？
- p.32
スティーブン・ジェイ・グルード (1977) Q. クモがゾウのように大きく進化したらどうなるのか？
- p.33
スティーブン・ジェイ・グルード (1977) Q. クモがゾウのように大きく進化したらどうなるのか？
- p.34
現状と実状を知る 外部の変化速度が組織内の変化速度を上回っているのであれば、 その組織の終わりは近い ジャック・ウェルチ 内部 外部 ビジネス テクノロジー 組織
- p.35
顧客中心で考える 顧客 従業員 (DX for internal) 社内外の諸事情 在庫 流通 窓口 担当者 注文 他の顧客 顧客にとっての価値 店舗 倉庫 生産 ・・・ ・・・ ・・・ • レコメンド • 自己解決型 • 人や物が介在 • 他者解決型 中間成果より顧客価値
- p.36
例: 切符販売機「目的地に行きたい」 LEVEL 0. 人に頼んで買う（手配してもらう） LEVEL 1. 値段を調べて買う（380円の切符購入） LEVEL 2. 行先指定で買う（ここから新宿まで） LEVEL 3. SUICAでタッチ（いくらかかるかはしらなくてもよい）
- p.37
例: 商品購入「いい感じのものがほしい」 LEVEL 0. お店で店員さんにあれこれ聞いて買う（逃げにくい） LEVEL 1. お店で自分で見て回って買う（逃げられるがいい物が買えるか？） LEVEL 2. 気になる商品をお店でみて、ネットで最安値で買う（逃げる） LEVEL 3. ○マゾンなどで勧められた物を買う
- p.38
フローを変える DXで避けて通れない
- p.39
顧客中心で考えてフローを改善していく セルフサービスモデルへの道｜顧客が本当に知りたかったもの 従来: 知りたい！ 〇〇です おもてなし対応 DX時代: 知りたい！ 〇〇です 待てない！ 対客コスト高い
- p.40
顧客はそこに答えがあると思ってアクセスする 従来 わからないから聞く 対面対応＝助かる セルフサービスモデルへの道｜顧客が本当に知りたかったもの
- p.41
顧客はそこに答えがあると思ってアクセスする 従来 わからないから聞く 対面対応＝助かる DX時代 わからないから退く 対面対応＝辛い セルフサービスモデルへの道｜顧客が本当に知りたかったもの
- p.42
フローは必ずといっていいほど見直す フロー見直しのコツ 同期 非同期 ヒト・モノ 情報・データ セルフサービスモデルへの道｜顧客が本当に知りたかったもの 疎結合
- p.43
顧客中心で問い合わせフローを考える（現状分析） 同期コミュニケーションでの問い合わせ対応（電話など） 窓口 専門家 問い合わせ連絡 専門家手配 専門家手配完了 質問 回答 回答 顧客 セルフサービスモデルへの道｜顧客が本当に知りたかったもの
- p.44
顧客中心で問い合わせフローを考える（デジタル化） 同期コミュニケーションでの問い合わせ対応（電話など） 顧客 窓口 専門家 問い合わせ連絡 専門家手配 専門家手配完了 質問 回答 回答 KB 蓄積 検索 セルフサービスモデルへの道｜顧客が本当に知りたかったもの
- p.45
顧客中心で問い合わせフローを考える（フロー見直し） 同期コミュニケーションでの問い合わせ対応（電話など） 顧客 窓口 専門家 問い合わせ連絡 質問 回答 回答 KB ナレッジ追加・更新 フィードバック （非同期） ナレッジ追加・更新 （非同期） （非同期） セルフサービスモデルへの道｜顧客が本当に知りたかったもの
- p.46
顧客中心で問い合わせフローを考える（DX！） 非同期コミュニケーションでの問い合わせ対応（FAQなど） 顧客 窓口 専門家 閲覧・検索 質問 回答 FAQ(KB) ナレッジ追加・更新 分析結果によるフィードバック （非同期） （非同期） （非同期） 顧客 閲覧・検索 （非同期） ？ 質問 回答 セルフサービスモデルへの道｜顧客が本当に知りたかったもの
- p.47
ü 非常に身近ですぐできそうな DX のひとつ ü フローを見直すきっかけであり好例のひとつ ü 自前主義からの脱却の好例のひとつ ü ユニークな技術で技術の必要性がわかりやすい
- p.48
まとめ Ø 複雑な時代だからこそのDX Ø アジャイルやDevOpsは必然／先例 Ø 中間成果より、顧客体験に着目 Ø フローの見直しを必ず検討する Ø 正解はない、予定調和もない Ø コアは自前、それ以外は、協創・利用
- p.49
感謝 サーバントワークス株式会社 ＠tnagasawa nagasawa@servantworks.co.jp https://servantworks.co.jp/ お役に立てることがございましたら、ぜひお気軽にご連絡ください