SlideShare a Scribd company logo
わんくま同盟 名古屋勉強会 #51
アジャイルの30年
(Lv.2くまー)
2024/06/08(土)
You&I
わんくま同盟 名古屋勉強会 #51
ジコ、ショウカイ。
• H/N: You&I(読み:ユーアンドアイ)
• SNS: @you_and_i
• 出身: 生まれも育ちも名古屋市
• 年齢: 40代
• 本職: 商学部出身の職業プログラマ
• 言語: Go, C++, C#他
•所属: プロ生勉強会 名古屋支部
名古屋アジャイル勉強会
わんくま同盟 名古屋勉強会
2
わんくま同盟 名古屋勉強会 #51
はじめに
• デンマークのアジャイルコーチであるソーレ
ン・ラーシュさんが今年の3/12に書いたブログ
記事が興味深い内容なので、読み解いてみ
ましょうという試みです。
Three Decades of Agile
http://www.managecomplexity.dk/blog/2024/03/
12/three-decades-of-agile/
わんくま同盟 名古屋勉強会 #51
まえがき
アジャイルの30年
わんくま同盟 名古屋勉強会 #51
まえがき
• 2001年に作成されたアジャイルソフトウェア
開発宣言は、ソフトウェア開発に大きな変化を
もたらしました。
– https://agilemanifesto.org/iso/ja/manifesto.html
• 以降、この価値観と原則は、進化・拡大してお
り、これを実装する為のより良い方法を発見し
続けています。
• この変化は前向きなもので、ソフトウェア業界
に引き続き利益をもたらしています。
わんくま同盟 名古屋勉強会 #51
まえがき
• このブログ記事では、過去数十年に渡って歩
んで来た道のりについて説明し、今後何が起
こるかを予測します。
• 各組織やチームは、独自の課題に直面してお
り、対処すべきレガシーがあります。
• 2000年代レベルのチームについて言及する
ことは、チームの構造的な問題に対処するよ
りも、変革の観点から有用であるとわかりまし
た。
わんくま同盟 名古屋勉強会 #51
2000年代のふりかえり
アジャイルの30年
わんくま同盟 名古屋勉強会 #51
2000年代のふりかえり
• アジャイル開発手法がもたらした最も顕著な
変化は、開発チームに焦点が移ったことです。
2000年以前 2000年代
チームメンバー 多くの場合、複数プロジェ
クト掛け持ちの各専門部門
の個人の集まり
実行する為に何でもこなせ
る、一カ所に常駐するフル
タイム開発者のチーム
フィードバック頻度 年間
ポートフォリオ計画
4週間
自動化テスト + CI/CD
チーム/ユーザーの交流 要求分析時のみに、多くの
場合、プロマネなどの複数
の代理人を介して
各イテレーション終了時に、
POが代理人として
チームの価値創造 プロジェクト仕様に準拠し
て提供
効率的に優先順位付けさ
れたユーザーストーリー
わんくま同盟 名古屋勉強会 #51
2000年代のふりかえり
• アジャイル開発手法がもたらしたもう1つの顕著
な変化は、動くソフトウェアに焦点を当てたことで
す。
• 特にXtreme Programmingでは、自動化テストと
CI/CDに注目しました。
• これによりチームは、年単位なプロジェクトの最
後に一度ユーザーからフィードバックを得る従来
の形から、頻繁なリリースから継続的なフィード
バックを得ることができるようになりました。優れ
たチームはこれを4週間毎に実行しました。
わんくま同盟 名古屋勉強会 #51
2000年代のふりかえり
• またXPの取り組みは、品質の向上だけでなく、
効率化ももたらしました。
• 頻繁なリリースにより、ユーザーとより緊密な
対話が可能になりましたが、その恩恵を受け
た人は殆どいませんでした。
• なぜなら、リリースしたものを本番投入せずに、
ユーザーの代理人であるPOや社内のビジネ
ス担当者からのフィードバックに止まっていた
為です。
わんくま同盟 名古屋勉強会 #51
2000年代のふりかえり
• このフィードバックの問題を受けて、2000年以
前には主流だった要件範囲の固定化から、
POがユーザーの価値(認識)を最大化する為
に、定期的にバックログを調整して優先順位
付けするようになりました。
• このバックログはユーザーストーリーのリスト
で構成されます。(2004年にマイク・コーンに
よって広められました)
わんくま同盟 名古屋勉強会 #51
2000年代のふりかえり
• 但し、POに委譲された権限が限られており、
従来のプロジェクト統治下にあった為に、開発
チームが初期分析に参加することがなく、
ユーザーニーズをより深く理解できない状態
になっていました。
わんくま同盟 名古屋勉強会 #51
2000年代のふりかえり
• この時代は、以下のことに苦労していました
– リソースのボトルネック
• チームメンバーがプロジェクトの掛け持ちでチームに割
り当てられていた
– CD(継続的デリバリー)
• クラウドサービスのようなデプロイを行う環境や技術が
殆ど存在していなかった
• 動くソフトウェアを4週間ごとに体系的にリリー
スするのは非常に困難だった
わんくま同盟 名古屋勉強会 #51
2010年代のふりかえり
アジャイルの30年
わんくま同盟 名古屋勉強会 #51
2010年代のふりかえり
• 2010年代のアジャイルコミュニティは、3つの
異なる波によって支配されました。
1. DevOps
2. Discovery
3. Scaling
わんくま同盟 名古屋勉強会 #51
2010年代のふりかえり
• DevOps
– 開発チームに運用(Ops)が組み込まれ、開発から
運用への引き継ぎがなくなり、より速く反復できる
ようになり、リリースは2週間ごとになりました。
わんくま同盟 名古屋勉強会 #51
2010年代のふりかえり
• Discovery
– Eric Ries「Lean Startup」、Jeff Gothelf, Josh
Seiden「Lean UX」のような、実ユーザーに対し
て仮説検証アプローチを反復することで、ユー
ザー価値を発見する手法が出てきました。
– Jeff Pattonは、2014年にバックログを順序付け
する方法としてユーザーストーリーマッピングを導
入しました。
わんくま同盟 名古屋勉強会 #51
2010年代のふりかえり
• DevOps/Discoveryは、2000年代に起こった
事の延長線上。
2000年代 2010年代
チームメンバー 実行する為に何でもこなせ
る、一カ所に常駐するフル
タイム開発者のチーム
発見・開発・運用を行う
チーム
フィードバック頻度 4週間
自動化テスト + CI/CD
数日~2週間
即時のバグ修正
チーム/ユーザーの交流 各イテレーション終了時に、
POが代理人として
自動フィードバック、発見
や使用方法計測に関与
チームの価値創造 効率的に優先順位付けさ
れたユーザーストーリー
発見に基づくユーザー成
果
わんくま同盟 名古屋勉強会 #51
2010年代のふりかえり
• DevOpsでは、従来の運用とは大きく異なった
為に、必要なスキルが希少なものであった。
• 未だ従来のプロジェクト統治に固執しており、
チームが発見から学ぶ統治は十分に説明さ
れていなかった。
わんくま同盟 名古屋勉強会 #51
2010年代のふりかえり
• Scaling
– 昨今のソフトウェア製品は、単一のチームで処理
できるものよりも、遙かに大きく複雑です。
– 大規模アジャイルフレームワークとして、LeSS
(2008),SAFe(2011), Nexus(2015), Scrum@
Scale(2017)があり、SAFe(Scaled Agile
Framework)が勝者となりました。
– SAFeが成功した理由として、従来の管理層も取
り込んだ事が考えられます。
– Scalingとして、Scrumを拡張する事が正しい方法
なのでしょうか?
わんくま同盟 名古屋勉強会 #51
2010年代のふりかえり
• 大規模アジャイルフレームワークは、2000年
代と2010年代に行われた進化の多くが失わ
れており、これらのアプローチは前進ではなく、
後退するものであると考えます。
• ある日潜在的なユーザー成果を学習し、翌日
にソリューションをリリースできる、大規模ア
ジャイルフレームワークを実践するチームを
見たことがありません。
わんくま同盟 名古屋勉強会 #51
2020年代~
アジャイルの30年
わんくま同盟 名古屋勉強会 #51
2020年代~
• スクラムの経済的成功とその拡大の先に目を向
けた場合、開発組織が2020年代に向けて取る
べきステップは何でしょうか?
• 過去20年間で私たちが成し遂げてきた下記の進
歩を考慮する価値があると、私は信じています。
– チームの規模が拡大
– 反復が短くなる
– ユーザーに近くなる
– 価値創造に対する責任が増大
• これを踏まえた予測は・・・。
わんくま同盟 名古屋勉強会 #51
2020年代~
• チーム規模の拡大
– 2010年代に、ソリューションをスムーズかつ効率
的に運用し(DevOps)し、ユーザーニーズをより適
切に満たすようになりました(Delivery)。
– チームはソリューションで収益を上げる事に責任
を負う、つまりマーケティングと販売に広がります。
わんくま同盟 名古屋勉強会 #51
2020年代~
• 反復が短くなる
– 製品戦略をチームの責任に組み込むことで、これ
まで経験したことのない速度で戦略的前提を検証
することも可能になります。
わんくま同盟 名古屋勉強会 #51
2020年代~
• ユーザーに近くなる
– 迅速なフィードバックを作成するチームの能力と
戦略化プロセスを組み合わせることで、ビジネス
機会を検証する時間が短くなります。
– 従って、チームのバックログには、決定された内
容だけでなく、特定された関連する機会も含める
必要があります。
– バックログ拡張の一例として、Gojko Adzic(2012)
によるインパクトマップがあります。
わんくま同盟 名古屋勉強会 #51
2020年代~
• ユーザーに近くなる(続き)
– インパクトマップは、機能(赤い四角)がどのように
目標(黄色)を達成できるかについての仮定を表し
ます。
わんくま同盟 名古屋勉強会 #51
2020年代~
• ユーザーに近くなる
– 迅速なフィードバックを作成するチームの能力と
戦略化プロセスを組み合わせることで、ビジネス
機会を検証する時間が短くなります。
– 従って、チームのバックログには、決定された内
容だけでなく、特定された関連する機会も含める
必要があります。
わんくま同盟 名古屋勉強会 #51
2020年代~
• 価値創造に対する責任が増大
– オンラインマーケティングとアプリケーション内販
売の責任を拡張すると想像してください。開発者
は多くのデータ型に直接アクセスし、より迅速に
学習するために低コストの実験を作成できます。
個々のユーザーの購入決定プロセスを監視した
り、さまざまなオプション を並行してテストしたりで
きます。
– 上記は既にB2C製品に当てはまります。B2B製
品でもゆっくりと起こる可能性があります。
わんくま同盟 名古屋勉強会 #51
2020年代~
• チームは、ビジネスに直接的な影響を与える
ようになる。
2010年代 2020年代
チームメンバー 発見・開発・運用を行う
チーム
製品戦略、マーケティング、
販売で拡大するチーム
フィードバック頻度 数日~2週間
即時のバグ修正
継続的に実施
チーム/ユーザーの交流 自動フィードバック、発見
や使用方法計測に関与
ライフサイクルの間
チームの価値創造 発見に基づくユーザー成
果
プロダクトオーナーシップ
のビジネスインパクト
わんくま同盟 名古屋勉強会 #51
2030年代~
アジャイルの30年
わんくま同盟 名古屋勉強会 #51
2030年代~
• 2020年代に予測した発展を続けると、2020
年代の企業内チームは1つの中小企業のよう
なものになるでしょう。
• 大きな飛躍をしないかぎり、2000年代、2010
年代、2020年代の課題に直面することになり
ます。
わんくま同盟 名古屋勉強会 #51
読み解いてみて
アジャイルの30年
わんくま同盟 名古屋勉強会 #51
読み解いてみて
• ソーレン・ラーシュさんの言い分としては、ア
ジャイルの進化形として、大規模アジャイルフ
レームは間違いだよね?ってことでした。
• でもチームの役割・責任が拡大するって予測
は、チームの肥大化に繋がるのでは?と思い
ました。

More Related Content

Similar to アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)

システム設計の原則
システム設計の原則システム設計の原則
システム設計の原則
You&I
 
瀬戸内旅行
瀬戸内旅行瀬戸内旅行
瀬戸内旅行
You&I
 
シン・君主論を読んで
シン・君主論を読んでシン・君主論を読んで
シン・君主論を読んで
You&I
 
並列処理について
並列処理について並列処理について
並列処理について
You&I
 
初めてのDocker
初めてのDocker初めてのDocker
初めてのDocker
You&I
 
ECMA-376の活用を考える(XLSX編)
ECMA-376の活用を考える(XLSX編)ECMA-376の活用を考える(XLSX編)
ECMA-376の活用を考える(XLSX編)
You&I
 
4DX
4DX4DX
すぱこーに学ぶアプリ開発の第一歩
すぱこーに学ぶアプリ開発の第一歩すぱこーに学ぶアプリ開発の第一歩
すぱこーに学ぶアプリ開発の第一歩
You&I
 
Visual Studio 2017の一部を使ってみた
Visual Studio 2017の一部を使ってみたVisual Studio 2017の一部を使ってみた
Visual Studio 2017の一部を使ってみた
You&I
 
MS MATRIX STRATEGY
MS MATRIX STRATEGYMS MATRIX STRATEGY
MS MATRIX STRATEGY
You&I
 
ApiPortで.NETアプリの依存関係を調べよう
ApiPortで.NETアプリの依存関係を調べようApiPortで.NETアプリの依存関係を調べよう
ApiPortで.NETアプリの依存関係を調べよう
You&I
 
日産の会議に学ぶファシリテーション
日産の会議に学ぶファシリテーション日産の会議に学ぶファシリテーション
日産の会議に学ぶファシリテーション
You&I
 
GPSレシーバーでGPS時刻による時刻合わせした話
GPSレシーバーでGPS時刻による時刻合わせした話GPSレシーバーでGPS時刻による時刻合わせした話
GPSレシーバーでGPS時刻による時刻合わせした話
You&I
 
ペーパークラフトで学ぶフィードバックと改善(鬼)
ペーパークラフトで学ぶフィードバックと改善(鬼)ペーパークラフトで学ぶフィードバックと改善(鬼)
ペーパークラフトで学ぶフィードバックと改善(鬼)
You&I
 
当日のお楽しみ
当日のお楽しみ当日のお楽しみ
当日のお楽しみ
You&I
 
第77回 名古屋アジャイル勉強会「リーダーを語る」カイワヤ会
第77回 名古屋アジャイル勉強会「リーダーを語る」カイワヤ会第77回 名古屋アジャイル勉強会「リーダーを語る」カイワヤ会
第77回 名古屋アジャイル勉強会「リーダーを語る」カイワヤ会
You&I
 
名古屋アジャイル勉強会 活動紹介
名古屋アジャイル勉強会 活動紹介名古屋アジャイル勉強会 活動紹介
名古屋アジャイル勉強会 活動紹介
You&I
 
しょうぎアプリ
しょうぎアプリしょうぎアプリ
しょうぎアプリ
You&I
 
Coderetreat素振り会
Coderetreat素振り会Coderetreat素振り会
Coderetreat素振り会
You&I
 
第75回 名古屋アジャイル勉強会「納涼・実際にあったコワイ話」カイワヤ会
第75回 名古屋アジャイル勉強会「納涼・実際にあったコワイ話」カイワヤ会第75回 名古屋アジャイル勉強会「納涼・実際にあったコワイ話」カイワヤ会
第75回 名古屋アジャイル勉強会「納涼・実際にあったコワイ話」カイワヤ会
You&I
 

Similar to アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約) (20)

システム設計の原則
システム設計の原則システム設計の原則
システム設計の原則
 
瀬戸内旅行
瀬戸内旅行瀬戸内旅行
瀬戸内旅行
 
シン・君主論を読んで
シン・君主論を読んでシン・君主論を読んで
シン・君主論を読んで
 
並列処理について
並列処理について並列処理について
並列処理について
 
初めてのDocker
初めてのDocker初めてのDocker
初めてのDocker
 
ECMA-376の活用を考える(XLSX編)
ECMA-376の活用を考える(XLSX編)ECMA-376の活用を考える(XLSX編)
ECMA-376の活用を考える(XLSX編)
 
4DX
4DX4DX
4DX
 
すぱこーに学ぶアプリ開発の第一歩
すぱこーに学ぶアプリ開発の第一歩すぱこーに学ぶアプリ開発の第一歩
すぱこーに学ぶアプリ開発の第一歩
 
Visual Studio 2017の一部を使ってみた
Visual Studio 2017の一部を使ってみたVisual Studio 2017の一部を使ってみた
Visual Studio 2017の一部を使ってみた
 
MS MATRIX STRATEGY
MS MATRIX STRATEGYMS MATRIX STRATEGY
MS MATRIX STRATEGY
 
ApiPortで.NETアプリの依存関係を調べよう
ApiPortで.NETアプリの依存関係を調べようApiPortで.NETアプリの依存関係を調べよう
ApiPortで.NETアプリの依存関係を調べよう
 
日産の会議に学ぶファシリテーション
日産の会議に学ぶファシリテーション日産の会議に学ぶファシリテーション
日産の会議に学ぶファシリテーション
 
GPSレシーバーでGPS時刻による時刻合わせした話
GPSレシーバーでGPS時刻による時刻合わせした話GPSレシーバーでGPS時刻による時刻合わせした話
GPSレシーバーでGPS時刻による時刻合わせした話
 
ペーパークラフトで学ぶフィードバックと改善(鬼)
ペーパークラフトで学ぶフィードバックと改善(鬼)ペーパークラフトで学ぶフィードバックと改善(鬼)
ペーパークラフトで学ぶフィードバックと改善(鬼)
 
当日のお楽しみ
当日のお楽しみ当日のお楽しみ
当日のお楽しみ
 
第77回 名古屋アジャイル勉強会「リーダーを語る」カイワヤ会
第77回 名古屋アジャイル勉強会「リーダーを語る」カイワヤ会第77回 名古屋アジャイル勉強会「リーダーを語る」カイワヤ会
第77回 名古屋アジャイル勉強会「リーダーを語る」カイワヤ会
 
名古屋アジャイル勉強会 活動紹介
名古屋アジャイル勉強会 活動紹介名古屋アジャイル勉強会 活動紹介
名古屋アジャイル勉強会 活動紹介
 
しょうぎアプリ
しょうぎアプリしょうぎアプリ
しょうぎアプリ
 
Coderetreat素振り会
Coderetreat素振り会Coderetreat素振り会
Coderetreat素振り会
 
第75回 名古屋アジャイル勉強会「納涼・実際にあったコワイ話」カイワヤ会
第75回 名古屋アジャイル勉強会「納涼・実際にあったコワイ話」カイワヤ会第75回 名古屋アジャイル勉強会「納涼・実際にあったコワイ話」カイワヤ会
第75回 名古屋アジャイル勉強会「納涼・実際にあったコワイ話」カイワヤ会
 

アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)

  • 2. わんくま同盟 名古屋勉強会 #51 ジコ、ショウカイ。 • H/N: You&I(読み:ユーアンドアイ) • SNS: @you_and_i • 出身: 生まれも育ちも名古屋市 • 年齢: 40代 • 本職: 商学部出身の職業プログラマ • 言語: Go, C++, C#他 •所属: プロ生勉強会 名古屋支部 名古屋アジャイル勉強会 わんくま同盟 名古屋勉強会 2
  • 3. わんくま同盟 名古屋勉強会 #51 はじめに • デンマークのアジャイルコーチであるソーレ ン・ラーシュさんが今年の3/12に書いたブログ 記事が興味深い内容なので、読み解いてみ ましょうという試みです。 Three Decades of Agile http://www.managecomplexity.dk/blog/2024/03/ 12/three-decades-of-agile/
  • 5. わんくま同盟 名古屋勉強会 #51 まえがき • 2001年に作成されたアジャイルソフトウェア 開発宣言は、ソフトウェア開発に大きな変化を もたらしました。 – https://agilemanifesto.org/iso/ja/manifesto.html • 以降、この価値観と原則は、進化・拡大してお り、これを実装する為のより良い方法を発見し 続けています。 • この変化は前向きなもので、ソフトウェア業界 に引き続き利益をもたらしています。
  • 6. わんくま同盟 名古屋勉強会 #51 まえがき • このブログ記事では、過去数十年に渡って歩 んで来た道のりについて説明し、今後何が起 こるかを予測します。 • 各組織やチームは、独自の課題に直面してお り、対処すべきレガシーがあります。 • 2000年代レベルのチームについて言及する ことは、チームの構造的な問題に対処するよ りも、変革の観点から有用であるとわかりまし た。
  • 8. わんくま同盟 名古屋勉強会 #51 2000年代のふりかえり • アジャイル開発手法がもたらした最も顕著な 変化は、開発チームに焦点が移ったことです。 2000年以前 2000年代 チームメンバー 多くの場合、複数プロジェ クト掛け持ちの各専門部門 の個人の集まり 実行する為に何でもこなせ る、一カ所に常駐するフル タイム開発者のチーム フィードバック頻度 年間 ポートフォリオ計画 4週間 自動化テスト + CI/CD チーム/ユーザーの交流 要求分析時のみに、多くの 場合、プロマネなどの複数 の代理人を介して 各イテレーション終了時に、 POが代理人として チームの価値創造 プロジェクト仕様に準拠し て提供 効率的に優先順位付けさ れたユーザーストーリー
  • 9. わんくま同盟 名古屋勉強会 #51 2000年代のふりかえり • アジャイル開発手法がもたらしたもう1つの顕著 な変化は、動くソフトウェアに焦点を当てたことで す。 • 特にXtreme Programmingでは、自動化テストと CI/CDに注目しました。 • これによりチームは、年単位なプロジェクトの最 後に一度ユーザーからフィードバックを得る従来 の形から、頻繁なリリースから継続的なフィード バックを得ることができるようになりました。優れ たチームはこれを4週間毎に実行しました。
  • 10. わんくま同盟 名古屋勉強会 #51 2000年代のふりかえり • またXPの取り組みは、品質の向上だけでなく、 効率化ももたらしました。 • 頻繁なリリースにより、ユーザーとより緊密な 対話が可能になりましたが、その恩恵を受け た人は殆どいませんでした。 • なぜなら、リリースしたものを本番投入せずに、 ユーザーの代理人であるPOや社内のビジネ ス担当者からのフィードバックに止まっていた 為です。
  • 11. わんくま同盟 名古屋勉強会 #51 2000年代のふりかえり • このフィードバックの問題を受けて、2000年以 前には主流だった要件範囲の固定化から、 POがユーザーの価値(認識)を最大化する為 に、定期的にバックログを調整して優先順位 付けするようになりました。 • このバックログはユーザーストーリーのリスト で構成されます。(2004年にマイク・コーンに よって広められました)
  • 12. わんくま同盟 名古屋勉強会 #51 2000年代のふりかえり • 但し、POに委譲された権限が限られており、 従来のプロジェクト統治下にあった為に、開発 チームが初期分析に参加することがなく、 ユーザーニーズをより深く理解できない状態 になっていました。
  • 13. わんくま同盟 名古屋勉強会 #51 2000年代のふりかえり • この時代は、以下のことに苦労していました – リソースのボトルネック • チームメンバーがプロジェクトの掛け持ちでチームに割 り当てられていた – CD(継続的デリバリー) • クラウドサービスのようなデプロイを行う環境や技術が 殆ど存在していなかった • 動くソフトウェアを4週間ごとに体系的にリリー スするのは非常に困難だった
  • 15. わんくま同盟 名古屋勉強会 #51 2010年代のふりかえり • 2010年代のアジャイルコミュニティは、3つの 異なる波によって支配されました。 1. DevOps 2. Discovery 3. Scaling
  • 16. わんくま同盟 名古屋勉強会 #51 2010年代のふりかえり • DevOps – 開発チームに運用(Ops)が組み込まれ、開発から 運用への引き継ぎがなくなり、より速く反復できる ようになり、リリースは2週間ごとになりました。
  • 17. わんくま同盟 名古屋勉強会 #51 2010年代のふりかえり • Discovery – Eric Ries「Lean Startup」、Jeff Gothelf, Josh Seiden「Lean UX」のような、実ユーザーに対し て仮説検証アプローチを反復することで、ユー ザー価値を発見する手法が出てきました。 – Jeff Pattonは、2014年にバックログを順序付け する方法としてユーザーストーリーマッピングを導 入しました。
  • 18. わんくま同盟 名古屋勉強会 #51 2010年代のふりかえり • DevOps/Discoveryは、2000年代に起こった 事の延長線上。 2000年代 2010年代 チームメンバー 実行する為に何でもこなせ る、一カ所に常駐するフル タイム開発者のチーム 発見・開発・運用を行う チーム フィードバック頻度 4週間 自動化テスト + CI/CD 数日~2週間 即時のバグ修正 チーム/ユーザーの交流 各イテレーション終了時に、 POが代理人として 自動フィードバック、発見 や使用方法計測に関与 チームの価値創造 効率的に優先順位付けさ れたユーザーストーリー 発見に基づくユーザー成 果
  • 19. わんくま同盟 名古屋勉強会 #51 2010年代のふりかえり • DevOpsでは、従来の運用とは大きく異なった 為に、必要なスキルが希少なものであった。 • 未だ従来のプロジェクト統治に固執しており、 チームが発見から学ぶ統治は十分に説明さ れていなかった。
  • 20. わんくま同盟 名古屋勉強会 #51 2010年代のふりかえり • Scaling – 昨今のソフトウェア製品は、単一のチームで処理 できるものよりも、遙かに大きく複雑です。 – 大規模アジャイルフレームワークとして、LeSS (2008),SAFe(2011), Nexus(2015), Scrum@ Scale(2017)があり、SAFe(Scaled Agile Framework)が勝者となりました。 – SAFeが成功した理由として、従来の管理層も取 り込んだ事が考えられます。 – Scalingとして、Scrumを拡張する事が正しい方法 なのでしょうか?
  • 21. わんくま同盟 名古屋勉強会 #51 2010年代のふりかえり • 大規模アジャイルフレームワークは、2000年 代と2010年代に行われた進化の多くが失わ れており、これらのアプローチは前進ではなく、 後退するものであると考えます。 • ある日潜在的なユーザー成果を学習し、翌日 にソリューションをリリースできる、大規模ア ジャイルフレームワークを実践するチームを 見たことがありません。
  • 23. わんくま同盟 名古屋勉強会 #51 2020年代~ • スクラムの経済的成功とその拡大の先に目を向 けた場合、開発組織が2020年代に向けて取る べきステップは何でしょうか? • 過去20年間で私たちが成し遂げてきた下記の進 歩を考慮する価値があると、私は信じています。 – チームの規模が拡大 – 反復が短くなる – ユーザーに近くなる – 価値創造に対する責任が増大 • これを踏まえた予測は・・・。
  • 24. わんくま同盟 名古屋勉強会 #51 2020年代~ • チーム規模の拡大 – 2010年代に、ソリューションをスムーズかつ効率 的に運用し(DevOps)し、ユーザーニーズをより適 切に満たすようになりました(Delivery)。 – チームはソリューションで収益を上げる事に責任 を負う、つまりマーケティングと販売に広がります。
  • 25. わんくま同盟 名古屋勉強会 #51 2020年代~ • 反復が短くなる – 製品戦略をチームの責任に組み込むことで、これ まで経験したことのない速度で戦略的前提を検証 することも可能になります。
  • 26. わんくま同盟 名古屋勉強会 #51 2020年代~ • ユーザーに近くなる – 迅速なフィードバックを作成するチームの能力と 戦略化プロセスを組み合わせることで、ビジネス 機会を検証する時間が短くなります。 – 従って、チームのバックログには、決定された内 容だけでなく、特定された関連する機会も含める 必要があります。 – バックログ拡張の一例として、Gojko Adzic(2012) によるインパクトマップがあります。
  • 27. わんくま同盟 名古屋勉強会 #51 2020年代~ • ユーザーに近くなる(続き) – インパクトマップは、機能(赤い四角)がどのように 目標(黄色)を達成できるかについての仮定を表し ます。
  • 28. わんくま同盟 名古屋勉強会 #51 2020年代~ • ユーザーに近くなる – 迅速なフィードバックを作成するチームの能力と 戦略化プロセスを組み合わせることで、ビジネス 機会を検証する時間が短くなります。 – 従って、チームのバックログには、決定された内 容だけでなく、特定された関連する機会も含める 必要があります。
  • 29. わんくま同盟 名古屋勉強会 #51 2020年代~ • 価値創造に対する責任が増大 – オンラインマーケティングとアプリケーション内販 売の責任を拡張すると想像してください。開発者 は多くのデータ型に直接アクセスし、より迅速に 学習するために低コストの実験を作成できます。 個々のユーザーの購入決定プロセスを監視した り、さまざまなオプション を並行してテストしたりで きます。 – 上記は既にB2C製品に当てはまります。B2B製 品でもゆっくりと起こる可能性があります。
  • 30. わんくま同盟 名古屋勉強会 #51 2020年代~ • チームは、ビジネスに直接的な影響を与える ようになる。 2010年代 2020年代 チームメンバー 発見・開発・運用を行う チーム 製品戦略、マーケティング、 販売で拡大するチーム フィードバック頻度 数日~2週間 即時のバグ修正 継続的に実施 チーム/ユーザーの交流 自動フィードバック、発見 や使用方法計測に関与 ライフサイクルの間 チームの価値創造 発見に基づくユーザー成 果 プロダクトオーナーシップ のビジネスインパクト
  • 32. わんくま同盟 名古屋勉強会 #51 2030年代~ • 2020年代に予測した発展を続けると、2020 年代の企業内チームは1つの中小企業のよう なものになるでしょう。 • 大きな飛躍をしないかぎり、2000年代、2010 年代、2020年代の課題に直面することになり ます。
  • 34. わんくま同盟 名古屋勉強会 #51 読み解いてみて • ソーレン・ラーシュさんの言い分としては、ア ジャイルの進化形として、大規模アジャイルフ レームは間違いだよね?ってことでした。 • でもチームの役割・責任が拡大するって予測 は、チームの肥大化に繋がるのでは?と思い ました。