Submit Search
Upload
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
•
7 likes
•
3,237 views
満徳 関
Follow
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版です。
Read less
Read more
Internet
Report
Share
Report
Share
1 of 96
Download now
Download to read offline
Recommended
プロダクトマネジメント再入門 20170305版 #postudy
プロダクトマネジメント再入門 20170305版 #postudy
満徳 関
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
満徳 関
【B-3】 創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について
【B-3】 創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
XP祭り2014「アジャイルを手放して得られたこと」
XP祭り2014「アジャイルを手放して得られたこと」
Yusuke Suzuki
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Yusuke Suzuki
初アジャイル×初オフショアでとった工夫 Jean-Baptiste Vasseur #comebackjapan
初アジャイル×初オフショアでとった工夫 Jean-Baptiste Vasseur #comebackjapan
満徳 関
Agile overview
Agile overview
Tsuyoshi Ushio
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
満徳 関
Recommended
プロダクトマネジメント再入門 20170305版 #postudy
プロダクトマネジメント再入門 20170305版 #postudy
満徳 関
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
満徳 関
【B-3】 創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について
【B-3】 創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
XP祭り2014「アジャイルを手放して得られたこと」
XP祭り2014「アジャイルを手放して得られたこと」
Yusuke Suzuki
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Yusuke Suzuki
初アジャイル×初オフショアでとった工夫 Jean-Baptiste Vasseur #comebackjapan
初アジャイル×初オフショアでとった工夫 Jean-Baptiste Vasseur #comebackjapan
満徳 関
Agile overview
Agile overview
Tsuyoshi Ushio
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD
満徳 関
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
Yusuke Suzuki
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
満徳 関
プロジェクト管理における課題管理ツール運用の”勘所”
プロジェクト管理における課題管理ツール運用の”勘所”
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
Yusuke Suzuki
チケット駆動で加速する顧客と協業するプロジェクトマネジメント
チケット駆動で加速する顧客と協業するプロジェクトマネジメント
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
JIRA Agileを活用したアジャイル開発実践事例 #AUGJ
JIRA Agileを活用したアジャイル開発実践事例 #AUGJ
満徳 関
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
リーンソフトウェア開発とは
リーンソフトウェア開発とは
StudyTech
【TFSUG】プロダクトオーナーシップ
【TFSUG】プロダクトオーナーシップ
shibao800
チケット駆動でプロジェクトチームを加速せよ!(2014年5月14日/ソフトウェア開発環境展)
チケット駆動でプロジェクトチームを加速せよ!(2014年5月14日/ソフトウェア開発環境展)
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
Why Agile Now ? - leanstartup and ARC
Why Agile Now ? - leanstartup and ARC
Kenji Hiranabe
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
Yusuke Suzuki
超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0
正善 大島
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Kenji Hiranabe
ユーザー事例紹介:ソフトウェア開発でのJIRA活用実践!
ユーザー事例紹介:ソフトウェア開発でのJIRA活用実践!
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
Agile Guts We Have Had and Will Have
Agile Guts We Have Had and Will Have
Kenji Hiranabe
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
Yusuke Suzuki
SIerとクラウドの付き合い方
SIerとクラウドの付き合い方
Yusuke Suzuki
マネジメントにおいて知っておくべき、ツールを活用したアジャイル開発の実践事例
マネジメントにおいて知っておくべき、ツールを活用したアジャイル開発の実践事例
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug
エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug
満徳 関
ソフトウェア品質向上の 変 2015江戸~今、改革のとき~ 20150204
ソフトウェア品質向上の 変 2015江戸~今、改革のとき~ 20150204
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
More Related Content
What's hot
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
Yusuke Suzuki
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
満徳 関
プロジェクト管理における課題管理ツール運用の”勘所”
プロジェクト管理における課題管理ツール運用の”勘所”
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
Yusuke Suzuki
チケット駆動で加速する顧客と協業するプロジェクトマネジメント
チケット駆動で加速する顧客と協業するプロジェクトマネジメント
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
JIRA Agileを活用したアジャイル開発実践事例 #AUGJ
JIRA Agileを活用したアジャイル開発実践事例 #AUGJ
満徳 関
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
リーンソフトウェア開発とは
リーンソフトウェア開発とは
StudyTech
【TFSUG】プロダクトオーナーシップ
【TFSUG】プロダクトオーナーシップ
shibao800
チケット駆動でプロジェクトチームを加速せよ!(2014年5月14日/ソフトウェア開発環境展)
チケット駆動でプロジェクトチームを加速せよ!(2014年5月14日/ソフトウェア開発環境展)
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
Why Agile Now ? - leanstartup and ARC
Why Agile Now ? - leanstartup and ARC
Kenji Hiranabe
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
Yusuke Suzuki
超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0
正善 大島
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Kenji Hiranabe
ユーザー事例紹介:ソフトウェア開発でのJIRA活用実践!
ユーザー事例紹介:ソフトウェア開発でのJIRA活用実践!
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
Agile Guts We Have Had and Will Have
Agile Guts We Have Had and Will Have
Kenji Hiranabe
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
Yusuke Suzuki
SIerとクラウドの付き合い方
SIerとクラウドの付き合い方
Yusuke Suzuki
マネジメントにおいて知っておくべき、ツールを活用したアジャイル開発の実践事例
マネジメントにおいて知っておくべき、ツールを活用したアジャイル開発の実践事例
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
What's hot
(20)
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
プロジェクト管理における課題管理ツール運用の”勘所”
プロジェクト管理における課題管理ツール運用の”勘所”
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
チケット駆動で加速する顧客と協業するプロジェクトマネジメント
チケット駆動で加速する顧客と協業するプロジェクトマネジメント
JIRA Agileを活用したアジャイル開発実践事例 #AUGJ
JIRA Agileを活用したアジャイル開発実践事例 #AUGJ
リーン開発の本質 公開用
リーン開発の本質 公開用
リーンソフトウェア開発とは
リーンソフトウェア開発とは
【TFSUG】プロダクトオーナーシップ
【TFSUG】プロダクトオーナーシップ
チケット駆動でプロジェクトチームを加速せよ!(2014年5月14日/ソフトウェア開発環境展)
チケット駆動でプロジェクトチームを加速せよ!(2014年5月14日/ソフトウェア開発環境展)
Why Agile Now ? - leanstartup and ARC
Why Agile Now ? - leanstartup and ARC
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
ユーザー事例紹介:ソフトウェア開発でのJIRA活用実践!
ユーザー事例紹介:ソフトウェア開発でのJIRA活用実践!
Agile Guts We Have Had and Will Have
Agile Guts We Have Had and Will Have
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
SIerとクラウドの付き合い方
SIerとクラウドの付き合い方
マネジメントにおいて知っておくべき、ツールを活用したアジャイル開発の実践事例
マネジメントにおいて知っておくべき、ツールを活用したアジャイル開発の実践事例
Similar to リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug
エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug
満徳 関
ソフトウェア品質向上の 変 2015江戸~今、改革のとき~ 20150204
ソフトウェア品質向上の 変 2015江戸~今、改革のとき~ 20150204
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
Microsoft Dynamics CRMで営業力と組織対応力を強化
Microsoft Dynamics CRMで営業力と組織対応力を強化
kumo2010
Hybrid appmeetssecurity kdl20171017-20
Hybrid appmeetssecurity kdl20171017-20
龍弘 岡
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation
Yasuhiro Araki, Ph.D
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
Yoshihito Kuranuki
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
Unicast Inc.
プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処 #eaug
プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処 #eaug
満徳 関
スマホ向けWebアプリ開発で使えるフロントエンド高速化手法
スマホ向けWebアプリ開発で使えるフロントエンド高速化手法
Eiji Kodama
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
Yoshihito Kuranuki
Base 20141011 1_for_slideshre
Base 20141011 1_for_slideshre
正善 大島
【13-B-4】事例から学ぶdev ops実現のためのプラクティス(黒川敦〔日本アイ・ビー・エム〕)
【13-B-4】事例から学ぶdev ops実現のためのプラクティス(黒川敦〔日本アイ・ビー・エム〕)
Developers Summit
リーンスタートアップの奇妙な冒険
リーンスタートアップの奇妙な冒険
Kakigi Katuyuki
ERPのデータをフロントシステムでどう活かすか
ERPのデータをフロントシステムでどう活かすか
Ryuji Enoki
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)
IMJ Corporation
デジタルマーケティング時代の横断プロジェクトのあり方とは(アドテック東京2014セッションから)
デジタルマーケティング時代の横断プロジェクトのあり方とは(アドテック東京2014セッションから)
Go Sugihara
20120622 data conference
20120622 data conference
managami
Digital strategy in Japanese
Digital strategy in Japanese
Yoshinori Kawamura
大規模データプロダクトでの 0->1から1->100開発に向けた チームビルディング
大規模データプロダクトでの 0->1から1->100開発に向けた チームビルディング
Takao Kashima
20140627 agile japan_embrace change for unchangeability
20140627 agile japan_embrace change for unchangeability
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
Similar to リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
(20)
エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug
エンジニアのためのプロダクトマネジメント入門 XP祭り2018 #xpjug
ソフトウェア品質向上の 変 2015江戸~今、改革のとき~ 20150204
ソフトウェア品質向上の 変 2015江戸~今、改革のとき~ 20150204
Microsoft Dynamics CRMで営業力と組織対応力を強化
Microsoft Dynamics CRMで営業力と組織対応力を強化
Hybrid appmeetssecurity kdl20171017-20
Hybrid appmeetssecurity kdl20171017-20
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処 #eaug
プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処 #eaug
スマホ向けWebアプリ開発で使えるフロントエンド高速化手法
スマホ向けWebアプリ開発で使えるフロントエンド高速化手法
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
Base 20141011 1_for_slideshre
Base 20141011 1_for_slideshre
【13-B-4】事例から学ぶdev ops実現のためのプラクティス(黒川敦〔日本アイ・ビー・エム〕)
【13-B-4】事例から学ぶdev ops実現のためのプラクティス(黒川敦〔日本アイ・ビー・エム〕)
リーンスタートアップの奇妙な冒険
リーンスタートアップの奇妙な冒険
ERPのデータをフロントシステムでどう活かすか
ERPのデータをフロントシステムでどう活かすか
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)
デジタルマーケティング時代の横断プロジェクトのあり方とは(アドテック東京2014セッションから)
デジタルマーケティング時代の横断プロジェクトのあり方とは(アドテック東京2014セッションから)
20120622 data conference
20120622 data conference
Digital strategy in Japanese
Digital strategy in Japanese
大規模データプロダクトでの 0->1から1->100開発に向けた チームビルディング
大規模データプロダクトでの 0->1から1->100開発に向けた チームビルディング
20140627 agile japan_embrace change for unchangeability
20140627 agile japan_embrace change for unchangeability
More from 満徳 関
なんちゃってアジャイルをアジャイルにした話 ~ライトニングトーク版~ #xpjug
なんちゃってアジャイルをアジャイルにした話 ~ライトニングトーク版~ #xpjug
満徳 関
XPプラクティスをオンラインで体験しよう!計画ゲーム(ストーリーの作成、リリース計画) #xpjug
XPプラクティスをオンラインで体験しよう!計画ゲーム(ストーリーの作成、リリース計画) #xpjug
満徳 関
Agile Tech EXPO mini #0 - 僕らが伝えたいあじゃてく - #agiletechexpo
Agile Tech EXPO mini #0 - 僕らが伝えたいあじゃてく - #agiletechexpo
満徳 関
Q思考 シンプルな問いで本質をつかむ思考法 ITコンサルタントへの第一歩シリーズ #eLV勉強会
Q思考 シンプルな問いで本質をつかむ思考法 ITコンサルタントへの第一歩シリーズ #eLV勉強会
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ:正しい疑問をもつ技術 #eLv勉強会
【eLV】ITコンサルタントへの第一歩シリーズ:正しい疑問をもつ技術 #eLv勉強会
満徳 関
制約を外そう!XPからその先へ #xpjug
制約を外そう!XPからその先へ #xpjug
満徳 関
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
満徳 関
Visual Studio 2019 / Visual Studio Code + Live Shareではじめるモブ・プログラミング #vs2019
Visual Studio 2019 / Visual Studio Code + Live Shareではじめるモブ・プログラミング #vs2019
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ ~セルフブランディング戦略~
【eLV】ITコンサルタントへの第一歩シリーズ ~セルフブランディング戦略~
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ ~システム思考(SystemThinking)②~ #elv勉強会 「システム原型図」を使ってビジネスに影...
【eLV】ITコンサルタントへの第一歩シリーズ ~システム思考(SystemThinking)②~ #elv勉強会 「システム原型図」を使ってビジネスに影...
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ ~システム思考(SystemThinking)①~ 「因果ループ図」を使ってビジネスに影響を与える変数を見...
【eLV】ITコンサルタントへの第一歩シリーズ ~システム思考(SystemThinking)①~ 「因果ループ図」を使ってビジネスに影響を与える変数を見...
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案③~ #elv勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案③~ #elv勉強会
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案②~ 課題候補を課題にするために
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案②~ 課題候補を課題にするために
満徳 関
知識集約型の製品開発においてプロダクトオーナーがやるべき3つのこと #agilejapan #agilejapannagasaki #agilejapan...
知識集約型の製品開発においてプロダクトオーナーがやるべき3つのこと #agilejapan #agilejapannagasaki #agilejapan...
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案①~ #elv勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案①~ #elv勉強会
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案③~ 課題立案10本ノック #eLV勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案③~ 課題立案10本ノック #eLV勉強会
満徳 関
ヘビプロのすゝめ XP祭り2018 LTトーク #xpjug
ヘビプロのすゝめ XP祭り2018 LTトーク #xpjug
満徳 関
[終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座 ~課題発見からバックログ作成へ~ #postudy
[終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座 ~課題発見からバックログ作成へ~ #postudy
満徳 関
【eLV】ITコンサルタントへの第一歩シリーズ ~自分ブランディング戦略~ #eLV勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~自分ブランディング戦略~ #eLV勉強会
満徳 関
モダンアジャイルワークショップ - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイルワークショップ - Agile Japan 2017 地方サテライト版 #agilejapan
満徳 関
More from 満徳 関
(20)
なんちゃってアジャイルをアジャイルにした話 ~ライトニングトーク版~ #xpjug
なんちゃってアジャイルをアジャイルにした話 ~ライトニングトーク版~ #xpjug
XPプラクティスをオンラインで体験しよう!計画ゲーム(ストーリーの作成、リリース計画) #xpjug
XPプラクティスをオンラインで体験しよう!計画ゲーム(ストーリーの作成、リリース計画) #xpjug
Agile Tech EXPO mini #0 - 僕らが伝えたいあじゃてく - #agiletechexpo
Agile Tech EXPO mini #0 - 僕らが伝えたいあじゃてく - #agiletechexpo
Q思考 シンプルな問いで本質をつかむ思考法 ITコンサルタントへの第一歩シリーズ #eLV勉強会
Q思考 シンプルな問いで本質をつかむ思考法 ITコンサルタントへの第一歩シリーズ #eLV勉強会
【eLV】ITコンサルタントへの第一歩シリーズ:正しい疑問をもつ技術 #eLv勉強会
【eLV】ITコンサルタントへの第一歩シリーズ:正しい疑問をもつ技術 #eLv勉強会
制約を外そう!XPからその先へ #xpjug
制約を外そう!XPからその先へ #xpjug
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
Visual Studio 2019 / Visual Studio Code + Live Shareではじめるモブ・プログラミング #vs2019
Visual Studio 2019 / Visual Studio Code + Live Shareではじめるモブ・プログラミング #vs2019
【eLV】ITコンサルタントへの第一歩シリーズ ~セルフブランディング戦略~
【eLV】ITコンサルタントへの第一歩シリーズ ~セルフブランディング戦略~
【eLV】ITコンサルタントへの第一歩シリーズ ~システム思考(SystemThinking)②~ #elv勉強会 「システム原型図」を使ってビジネスに影...
【eLV】ITコンサルタントへの第一歩シリーズ ~システム思考(SystemThinking)②~ #elv勉強会 「システム原型図」を使ってビジネスに影...
【eLV】ITコンサルタントへの第一歩シリーズ ~システム思考(SystemThinking)①~ 「因果ループ図」を使ってビジネスに影響を与える変数を見...
【eLV】ITコンサルタントへの第一歩シリーズ ~システム思考(SystemThinking)①~ 「因果ループ図」を使ってビジネスに影響を与える変数を見...
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案③~ #elv勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案③~ #elv勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案②~ 課題候補を課題にするために
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案②~ 課題候補を課題にするために
知識集約型の製品開発においてプロダクトオーナーがやるべき3つのこと #agilejapan #agilejapannagasaki #agilejapan...
知識集約型の製品開発においてプロダクトオーナーがやるべき3つのこと #agilejapan #agilejapannagasaki #agilejapan...
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案①~ #elv勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案①~ #elv勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案③~ 課題立案10本ノック #eLV勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~課題の仮説立案③~ 課題立案10本ノック #eLV勉強会
ヘビプロのすゝめ XP祭り2018 LTトーク #xpjug
ヘビプロのすゝめ XP祭り2018 LTトーク #xpjug
[終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座 ~課題発見からバックログ作成へ~ #postudy
[終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座 ~課題発見からバックログ作成へ~ #postudy
【eLV】ITコンサルタントへの第一歩シリーズ ~自分ブランディング戦略~ #eLV勉強会
【eLV】ITコンサルタントへの第一歩シリーズ ~自分ブランディング戦略~ #eLV勉強会
モダンアジャイルワークショップ - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイルワークショップ - Agile Japan 2017 地方サテライト版 #agilejapan
リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy
1.
リーンスタートアップとスマートな エンジニアリングの葛藤 2017/06 改訂版 グロースエクスパートナーズ株式会社 関 満徳
2.
撮影可 録音可 Copyright© Growth
xPartners, Inc. All rights reserved. 1
3.
今日お話したいこと • 「リーンスタートアップ」と「スマートなエン ジニアリング」の間に生じるズレや葛藤 • 企画サイドや開発サイドがこの悩みに対しどの ように動くべきか Copyright©
Growth xPartners, Inc. All rights reserved. 2
4.
アジェンダ • 今、起きていること • ズレや葛藤について考える •
どう動くとよさそうか • まとめ Copyright© Growth xPartners, Inc. All rights reserved. 3
5.
アジェンダ • 今、起きていること • ズレや葛藤について考える •
どう動くとよさそうか • まとめ Copyright© Growth xPartners, Inc. All rights reserved. 4
6.
• 「作る」から「使い続ける」へ • モノとコトの実現プロセス 今、起きていること Copyright©
Growth xPartners, Inc. All rights reserved. 5
7.
参考資料(1/1) – モノ消費ではなくコト消費の時代へ » http://www.nikkeibp.co.jp/article/matome/20140220/384639/ –
Naoya Ito - System of Record と System of Engagement » https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98c cecd6?slide=4# – 赤間 信幸 - 拝啓『変わらない開発現場』を嘆く皆様へ ~変わっていくエンタープライズ系業務システム開発とマイ クロソフトエンタープライズサービスの取り組み~ » https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmod ernization/ – 小野 和俊 - わたしのバイモーダル戦略 » http://blog.livedoor.jp/lalha/archives/50524676.html – 十返 文子 - プロジェクトマネジメント再入門 ~PjMは何であって何でないのか~ » https://www.slideshare.net/togaeri/pjm-72819087/12 Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 6
8.
• 「作る」から「使い続ける」へ • モノとコトの実現プロセス 今、起きていること Copyright©
Growth xPartners, Inc. All rights reserved. 7
9.
「作る」から「使い続ける」へ • モノからコトへのパラダイムシフト –幅広い業界で市場は成熟し、すでに必要なモノは ほとんど手に入った –人々の関心はモノの所有欲を満たすことから、 経験、思い出、人間関係、サービスなどの 目に見えない価値であるコトに移行してきている Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 8モノ消費ではなくコト消費の時代へ http://www.nikkeibp.co.jp/article/matome/20140220/384639/
10.
「作る」から「使い続ける」へ • モノからコトへのパラダイムシフト –モノを作る –作ったモノを使い続けてコトを得る Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 9
11.
「作る」から「使い続ける」へ • モノからコトへのパラダイムシフト –一度作ったモノは、作ったらおしまい –目に見えない価値であるコトは変わっていくので、 追随していく必要がある Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 10
12.
「作る」から「使い続ける」へ • モノからコトへのパラダイムシフト –一度作ったモノは、成長しない –一度作ったモノは、リリース後も成長し続ける Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 11 リリース1回目 ↓ リリースn回目 ↓ 成 長 度 時間 成長しない 成長し続ける
13.
「作る」から「使い続ける」へ • モノからコトへのパラダイムシフト –一度作ってリリースしたら、改修されない –リリース後も改修し続ける Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 12 リリース1回目 ↓ リリースn回目 ↓ 成 長 度 改修されない 改修し続ける 時間
14.
「作る」から「使い続ける」へ • モノからコトへのパラダイムシフト –モノの提供=数年間に一度のリリースの時代 –コトの提供=数ヶ月/数週間/数日に1回、または 1日数回のリリースの時代へ Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 13 時間 時間 リ リ ー ス リ リ ー ス
15.
「作る」から「使い続ける」へ • モノからコトへのパラダイムシフト –単一リリースのためのアーキテクチャ 単一リリース アーキテクチャ –複数リリース毎に改善するアーキテクチャ 複数リリース 改善するアーキテクチャ Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 14 …
16.
「作る」から「使い続ける」へ • モノからコトへのパラダイムシフト –単一プロジェクトのためのプロダクトマネジメント 単一プロジェクト プロダクトマネジメント –複数プロジェクトに跨がるプロダクトマネジメント 複数プロジェクト プロダクトマネジメント Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 15 …
17.
「作る」から「使い続ける」へ • マネジメント領域における役割 Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 16 プロダクト マネジメント (PdM) Do the right thing: 正しいことをする プロダクト・マネージャー プロダクト・オーナー リーダー プロジェクト マネジメント (PjM) Do things right: 正しく実行する プロジェクト・マネジャー マネジャー 十返 文子 - プロジェクトマネジメント再入門 ~PjMは何であって何でないのか~ https://www.slideshare.net/togaeri/pjm-72819087/14
18.
「作る」から「使い続ける」へ • マネジメント領域におけるマネジメント対象 Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 17 プロジェクトマネジメント プロダクトマネジメント スコープ マネジメント コスト マネジメント コミュニ ケーション マネジメント 統合 マネジメント ステーク ホルダー マネジメント リスク マネジメント 調達 マネジメント 資源 マネジメント タイム マネジメント 品質 マネジメント What How How much When HowHow How Why How WhoWhere プロダクト マネジメント 顧客(市場) マネジメント What Who Who ほぼ一緒? やや重なる? =分析・戦略… 十返 文子 - プロジェクトマネジメント再入門 ~PjMは何であって何でないのか~ https://www.slideshare.net/togaeri/pjm-72819087/12
19.
「作る」から「使い続ける」へ • SoR (System
of Record) –情報を正しく 「記録」 するためのシステム –想起するもの ・・・ バックエンド、予約、在庫、カー ド決済、ポイント処理、管理画面 • SoE (System of Engagement) –ユーザーや取引先との「絆」を作るためのシステム –想起するもの ・・・ UI、デザイン、アプリ、スマート フォン、ダイレクトマーケティング、CRM Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 18Naoya Ito - System of Record と System of Engagement https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98ccecd6?slide=4#
20.
「作る」から「使い続ける」へ Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~.
All rights reserved. 19 SoR 型システム(モード1) SoE 型システム(モード2) 用語 • System of Record • System of Engagement 定義 • 事実を記録することに主眼を置いたシステ ム・サービス • お客様との関係(絆)を強化するための システム・サービス 主役 • データ • 利用者 システム領域 • バックエンド • 認証、在庫管理、決済、個人情報保護 • フロントエンド、スマートフォンアプリ • UI、CRM、ダイレクトメール 開発手法 • 比較的ウォーターフォール寄り • 開発前に要件を明確に定義 • 品質の確保を優先 • 比較的アジャイル、リーン寄り • トライ&エラーで正しい問題・論点を 探り当てる • 迅速なリリースを優先 性向 / 適合 • 安定性重視 • 予測可能業務 • リスクを抑えて安全運転 • 要件を事前に明確化 • ユーザーインタフェース品質、開発速度重視 • 探索型業務 • スピード重視で運転 • トライ&エラー、プロトタイピング マネジメント • トップダウン寄り • 「正しい仕様」に基づいたプロジェクト管理 • 経営や開発部門が主導することが多い • ボトムアップ寄り • 「正しい仕様」は存在しない • マーケティング、デザインが主導することも ケイパ ビリティ • 要件定義力、調整力、プロジェクトマネジメ ント • SIのみなさんが得意そう • ユーザー視点、デザイン思考、アナリティク ス • Web系が得意そう ケイパビリティ Naoya Ito - System of Record と System of Engagement https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98ccecd6?slide=4# 赤間 信幸 - 拝啓『変わらない開発現場』を嘆く皆様へ~変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み~ https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmodernization/
21.
「作る」から「使い続ける」へ • バイモーダルで実現する企業IT Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 20 モード1 方向 転換 馬力 モード2 小野 和俊 - わたしのバイモーダル戦略 http://blog.livedoor.jp/lalha/archives/50524676.html
22.
• 「作る」から「使い続ける」へ • モノとコトの実現プロセス 今、起きていること Copyright©
Growth xPartners, Inc. All rights reserved. 21
23.
モノとコトの実現プロセス • 日本的プロダクトオーナーの現状 Copyright© POStudy
~アジャイル・プロダクトマネジメント研究会~. All rights reserved. 22 スクラム マスター 開発チーム 開発 日本的プロダクトオーナー 経営層 情シス 営業 広報コールセンター 現場 作業者管理 部門 法務 財務 顧客 意思決定 促進 現場調整 Dev/Ops 視点 ビジネス 視点 意思決定者 現場 日本的プロダクトオーナーの苦労のポイ ント 日本的プロダクトオーナーは、 スクラ ムで定義されるプロダクトオーナーより、 より多く、複数の視点の結節点で調整力 を求められる場面が多い。 プロダクトオーナーの現状 プロダクトオーナーは、様々な部 署から任命されることが多く、実 は必要なスキルや経験と案件が マッチしていないことも多い。
24.
モノとコトの実現プロセス Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~.
All rights reserved. 23 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT
25.
モノとコトの実現プロセス Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~.
All rights reserved. 24 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT リーン スクラム アーキ テクチャ 本番運用
26.
モノとコトの実現プロセス Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~.
All rights reserved. 25 プロダクト Log 仮説 スプリント 計画 ふりかえり スプリント スプリント バックログ デイリー スクラム プロダクト バックログ 評価用 成果物 仮説検討 価値検討 仕様検討 オポチュニティ バックログ 価値評価 リーン キャンバス ..... ::::: ::::: ::::: ::::: ::::: ::::: ..... ::::: ::::: ::::: ::::: ::::: ::::: ..... ::::: ::::: ::::: ::::: ::::: ::::: ペルソナ カスタマー ジャーニーマップ インセプション デッキ サービス ブループリント アーキテクチャ 設計 アーキテクチャビジョン & デザイン設計 テクニカル ソリューション技術 検討 スプリント レビュー ToDo Ready In Progress Done Feedback かんばん 価値計測 出荷 プロダクト 利用
27.
モノとコトの実現プロセス Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~.
All rights reserved. 26 プロダクト Log 仮説 スプリント 計画 ふりかえり スプリント スプリント バックログ デイリー スクラム プロダクト バックログ 評価用 成果物 仮説検討 価値検討 仕様検討 オポチュニティ バックログ 価値評価 リーン キャンバス ..... ::::: ::::: ::::: ::::: ::::: ::::: ..... ::::: ::::: ::::: ::::: ::::: ::::: ..... ::::: ::::: ::::: ::::: ::::: ::::: ペルソナ カスタマー ジャーニーマップ インセプション デッキ サービス ブループリント アーキテクチャ 設計 アーキテクチャビジョン & デザイン設計 テクニカル ソリューション技術 検討 スプリント レビュー ToDo Ready In Progress Done Feedback かんばん 価値計測 出荷 プロダクト 利用 リーン スクラム アーキ テクチャ 本番運用
28.
モノとコトの実現プロセス Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~.
All rights reserved. 27 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT 思い込みにより発生 する各種ムダを省く ためにリーンにやる ムダなモノを省き 必要なモノを素早く 作り続ける エンジニアリング モノを支え るアーキ テクチャ ムダなく本番運用を まわし続ける
29.
モノとコトの実現プロセス Copyright© POStudy ~アジャイル・プロダクトマネジメント研究会~.
All rights reserved. 28 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ 対応しなければ ならないコト
30.
モノとコトの実現プロセス Copyright© Growth xPartners,
Inc. All rights reserved. 29 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ 葛藤 葛藤 対応しなければ ならないコト
31.
アジェンダ • 今、起きていること • ズレや葛藤について考える •
どう動くとよさそうか • まとめ Copyright© Growth xPartners, Inc. All rights reserved. 30
32.
• アーキテクチャから見た葛藤 • リーンから見た葛藤 ズレや葛藤について考える Copyright©
Growth xPartners, Inc. All rights reserved. 31
33.
• アーキテクチャから見た葛藤 • リーンから見た葛藤 ズレや葛藤について考える Copyright©
Growth xPartners, Inc. All rights reserved. 32
34.
アーキテクチャ設計から見た葛藤 Copyright© Growth xPartners,
Inc. All rights reserved. 33 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ 葛藤 対応しなければ ならないコト
35.
アーキテクチャ設計から見た葛藤 Copyright© Growth xPartners,
Inc. All rights reserved. 34 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ 葛藤 アーキテクチャ設計の ジレンマ 対応しなければ ならないコト
36.
アーキテクチャ設計から見た葛藤 • アーキテクチャ設計とは –システムの構造と振る舞いを定義すること » 構造
システムの分け方と組み方 » 振る舞い 稼働しているシステムが利用できる状態で 外部に対して行うこと Copyright© Growth xPartners, Inc. All rights reserved. 35 IT サービス 機能 非機能 静的構造 動的構造 構造のパターン 振る舞い
37.
アーキテクチャ設計から見た葛藤 • 構造と振る舞いの関係 » 静的構造
時間軸にとらわれない要素の配置と関係性 » 動的構造 時間軸の中で現れる要素の配置と関係性 » 機能 インプットに対するアウトプット » 非機能 振る舞いの質 Copyright© Growth xPartners, Inc. All rights reserved. 36 IT サービス 機能 非機能 静的構造 動的構造 構造のパターン 振る舞い
38.
アーキテクチャ設計から見た葛藤 • 構造と振る舞いの関係 Copyright© Growth
xPartners, Inc. All rights reserved. 37 振る舞いの 初期要求 システム開発の流れ 振る舞い 振る舞い システムの設計 システムの実装 システムのテスト アーキテクチャの 設計構造構造構造 定義定義 参照 参照 定義 実現 確認 利用 評価
39.
アーキテクチャ設計から見た葛藤 • アーキテクチャ設計のジレンマ –本来はシステムを作り始める前にアーキテクチャを 定義すべき –その時点で得られる要求が正しいかわからない Copyright© Growth
xPartners, Inc. All rights reserved. 38 振る舞いの 初期要求 システム開発の流れ 振る舞い 振る舞い システムの設計 システムの実装 アーキテクチャの 設計構造構造構造 定義定義 参照 参照 定義 実現 利用
40.
アーキテクチャ設計から見た葛藤 • アーキテクチャ設計のジレンマ –要求が定まらなければ構造が決まらない –要求を定めるためには作らなければならない –作るためには構造が決まっていないといけない Copyright© Growth
xPartners, Inc. All rights reserved. 39 振る舞いの 初期要求 構造 振る舞い 構造が決まって いないと作れない 振る舞いを見ないと 要求がわからない 要求が曖昧では 決定できない
41.
• アーキテクチャから見た葛藤 • リーンから見た葛藤 ズレや葛藤について考える Copyright©
Growth xPartners, Inc. All rights reserved. 40
42.
リーンから見た葛藤 Copyright© Growth xPartners,
Inc. All rights reserved. 41 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ 葛藤 対応しなければ ならないコト
43.
リーンから見た葛藤 Copyright© Growth xPartners,
Inc. All rights reserved. 42 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ やりたいコトのサイクルと 用意するサイクルの タイミングがあわない 用意するサイクルに 乗らないタスクは どうすればいいのか 葛藤 対応しなければ ならないコト
44.
アジェンダ • 今、起きていること • ズレや葛藤について考える •
どう動くとよさそうか • まとめ Copyright© Growth xPartners, Inc. All rights reserved. 43
45.
• アーキテクチャ設計でできること • リーンでできること •
改善活動でできること どう動くとよさそうか Copyright© Growth xPartners, Inc. All rights reserved. 44
46.
• アーキテクチャ設計でできること • リーンでできること •
改善活動でできること どう動くとよさそうか Copyright© Growth xPartners, Inc. All rights reserved. 45
47.
アーキテクチャ設計から見た葛藤 Copyright© Growth xPartners,
Inc. All rights reserved. 46 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ 葛藤 アーキテクチャ設計の ジレンマ 対応しなければ ならないコト
48.
アーキテクチャ設計でできること • ジレンマに対するアーキテクチャ戦略 –戦略1 変化に対応出来る構造の導入 –戦略2
構造パターン追加への対応 –戦略3 犠牲的な構造パターンの導入 Copyright© Growth xPartners, Inc. All rights reserved. 47
49.
アーキテクチャ設計でできること • 戦略1 変化に対応出来る構造の導入 –要求の変化を可能な限り予測 –変化に対応出来る構造にしておく Copyright©
Growth xPartners, Inc. All rights reserved. 48 構造 機能A 機能B 機能C 構造 機能A 変化を予測し、 変化に対応出来る作りにする 変化に合わせて 機能を追加していく
50.
アーキテクチャ設計でできること Copyright© Growth xPartners,
Inc. All rights reserved. 49 構造 機能A 機能B 機能C 構造 機能A 変化を予測し、 変化に対応出来る作りにする 変化に合わせて 機能を追加していく メリット デメリット 【戦略1】 変化に対応出来る 構造の導入 変化に効率的に 対応出来る 変化が発生しない と保守的に大きな 影響が出る
51.
アーキテクチャ設計でできること • 戦略2 構造パターン追加への対応 –構造パターンの追加に対応できるようにしておく Copyright©
Growth xPartners, Inc. All rights reserved. 50 構造1 機能A 機能B 機能C 構造1 機能A 機能に適した構造を用意するが、 構造の拡張性を残す 変化に合わせて 機能を追加していく 構造2
52.
アーキテクチャ設計でできること Copyright© Growth xPartners,
Inc. All rights reserved. 51 構造1 機能A 機能B 機能C 構造1 機能A 機能に適した構造を用意するが、 構造の拡張性を残す 変化に合わせて 機能を追加していく 構造2 メリット デメリット 【戦略2】 構造パターン追加 への対応 変化が発生した 時点で適切な構造 を導入できる 使われなくなった 構造パターンが 技術的負債となる
53.
アーキテクチャ設計でできること • 戦略3 犠牲的な構造パターンの導入 –意図的に簡易的な構造パターンを導入 –本当に必要になったタイミングで作り直すことを 前提 Copyright©
Growth xPartners, Inc. All rights reserved. 52 構造2 機能A 機能B 機能C 構造1 機能A 機能に適した構造を用意し、 最小限な機能にしていく 変化に合わせて機能と 構造を追加していく 機能A 構造1
54.
アーキテクチャ設計でできること Copyright© Growth xPartners,
Inc. All rights reserved. 53 構造2 機能A 機能B 機能C 構造1 機能A 機能に適した構造を用意し、 最小限な機能にしていく 変化に合わせて機能と 構造を追加していく 機能A 構造1 メリット デメリット 【戦略3】 犠牲的な構造 パターンの導入 もっと効率的に 実装できる 早く限界が来て しまうと作り直す 無駄が出る
55.
アーキテクチャ設計でできること • 戦略のメリットとデメリット まとめ Copyright©
Growth xPartners, Inc. All rights reserved. 54 メリット デメリット 【戦略1】 変化に対応出来る 構造の導入 変化に効率的に 対応出来る 変化が発生しない と保守的に大きな 影響が出る 【戦略2】 構造パターン追加 への対応 変化が発生した 時点で適切な構造 を導入できる 使われなくなった 構造パターンが 技術的負債となる 【戦略3】 犠牲的な構造 パターンの導入 もっと効率的に 実装できる 早く限界が来て しまうと作り直す 無駄が出る
56.
• アーキテクチャ設計でできること • リーンでできること •
改善活動でできること どう動くとよさそうか Copyright© Growth xPartners, Inc. All rights reserved. 55
57.
リーンから見た葛藤 Copyright© Growth xPartners,
Inc. All rights reserved. 56 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ やりたいコトのサイクルと 用意するサイクルの タイミングがあわない 用意するサイクルに 乗らないタスクは どうすればいいのか 葛藤 対応しなければ ならないコト
58.
リーンでできること • 管理するものを分類する • リズムを合わせて見通しを共有する Copyright©
Growth xPartners, Inc. All rights reserved. 57
59.
リーンでできること • 管理するものを分類する • リズムを合わせて見通しを共有する Copyright©
Growth xPartners, Inc. All rights reserved. 58
60.
管理するものを分類する Copyright© Growth xPartners,
Inc. All rights reserved. 59 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT リーン スクラム アーキ テクチャ 本番運用
61.
管理するものを分類する Copyright© Growth xPartners,
Inc. All rights reserved. 60 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHATリーン スクラム アーキ テクチャ 本番運用 スプリント バックログ プロダクト バックログ オポチュニティ バックログ ToDo Ready In Progress Done Feedback かんばん • アイディア出し中 • 問題が本当にあるか確認中 • プロトタイプによる検証中 で、開発着手前のものは、 「オポテュニティバックログ」 で管理 現在、開発チームが 着手中のタスクは 「スプリントバックログ」 で管理 開発計画のサイクルに 入らないタスクは 「かんばん」 で管理 今後開発予定のものは、 「プロダクトバックログ」 で管理
62.
管理するものを分類する Copyright© Growth xPartners,
Inc. All rights reserved. 61 プロダクト Log 仮説 スプリント 計画 ふりかえり スプリント スプリント バックログ デイリー スクラム プロダクト バックログ 評価用 成果物 仮説検討 価値検討 仕様検討 オポチュニティ バックログ 価値評価 リーン キャンバス ..... ::::: ::::: ::::: ::::: ::::: ::::: ..... ::::: ::::: ::::: ::::: ::::: ::::: ..... ::::: ::::: ::::: ::::: ::::: ::::: ペルソナ カスタマー ジャーニーマップ インセプション デッキ サービス ブループリント アーキテクチャ 設計 アーキテクチャビジョン & デザイン設計 テクニカル ソリューション技術 検討 スプリント レビュー ToDo Ready In Progress Done Feedback かんばん 価値計測 出荷 プロダクト 利用 リーン スクラム アーキ テクチャ 本番運用 • アイディア出し中 • 問題が本当にあるか確認中 • プロトタイプによる検証中 で、開発着手前のものは、 「オポテュニティバックログ」 で管理 現在、開発チームが 着手中のタスクは 「スプリントバックログ」 で管理 今後開発予定のものは、 「プロダクトバックログ」 で管理 ToDo Ready In Progress Done Feedback スプリント バックログ プロダクト バックログ オポチュニティ バックログ かんばん開発計画のサイクルに 入らないタスクは 「かんばん」 で管理
63.
リーンでできること • 管理するものを分類する • リズムを合わせて見通しを共有する Copyright©
Growth xPartners, Inc. All rights reserved. 62
64.
リズムを合わせて見通しを共有する Copyright© Growth xPartners,
Inc. All rights reserved. 63 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT リーン スクラム アーキ テクチャ 本番運用
65.
リズムを合わせて見通しを共有する • 1週間の仕事量 Copyright© Growth
xPartners, Inc. All rights reserved. 64 使い続け させる 作る計画を 立てて 作る計画を まわす 作る スクラム ~スプリントバックログ~ 本番運用 ~かんばん~ 月 火 水 木 金 計 午前 ○ ○ ○ ○ ○ 午後1 ○ ○ ○ ○ ○ 午後2 ○ ○ ○ ○ ○ 1人 3 3 3 3 3 15 5人 15 15 15 15 15 75
66.
リズムを合わせて見通しを共有する • スプリントバックログとかんばんの比率を計画 Copyright© Growth
xPartners, Inc. All rights reserved. 65 1スプリント =2週間 スプリント X スプリント X+1 スプリント X+2 スプリント X+3 スプリント X+4 スプリント バックログ 100 60 80 100 85 かんばん 50 90 70 50 65 合計 75×2週間= 150 150 150 150 150 本番リリース後は、 障害対応や調査依頼が増えるので かんばんの割合を増やす 本番リリースがない時は スプリントバックログの 割合を増やす
67.
リズムを合わせて見通しを共有する • スプリントバックログとかんばんの比率を計画 –数スプリント先/数ヶ月後までの期間 –その結果、企画チームから見れば、 「いつまでに要件を伝えれば、リリースしたい時期 にリリース可能なのかがわかる」 Copyright© Growth
xPartners, Inc. All rights reserved. 66 スプリント X スプリント X+1 スプリント X+2 スプリント X+3 スプリント X+4 スプリント X+5 スプリント X+6 スプリント X+7 スプリント バックログ 100 35 80 100 85 55 80 40 かんばん 50 85 70 50 65 80 70 95 合計 150 120 150 150 150 135 150 135 祝日や予定休・突発休の分だけ 合計ポイントを減らして計画 プロダクトロードマップに あわせてリリースしたい時期 リリースしたい時期に間に合わせる為に 開発をはじめる時期を、逆算して計画 少なくともこの時期までに企画側内で承認 を取り、Goを出せば良いことがわかる リリース前の非機能要件等の確認結果への 対応工数を、かんばん側にあらかじめ計画 リリース後の対応工数を かんばん側に計画
68.
リズムを合わせて見通しを共有する Copyright© Growth xPartners,
Inc. All rights reserved. 67 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHATリーン スクラム アーキ テクチャ 本番運用 スプリント バックログ プロダクト バックログ オポチュニティ バックログ ToDo Ready In Progress Done Feedback かんばん • アイディア出し中 • 問題が本当にあるか確認中 • プロトタイプによる検証中 で、開発着手前のものは、 「オポテュニティバックログ」 で管理 現在、開発チームが 着手中のタスクは 「スプリントバックログ」 で管理 開発計画のサイクル に入らないタスクは 「かんばん」 で管理 今後開発予定のものは、 「プロダクトバックログ」 で管理 次のスプリント計画前までに、 • バックログ見直し • ユーザーストーリー見直し • ストーリーテスト作成 • ストーリーポイント見直し • 価値・リスク観点での優先順位見直し を実施しておく
69.
リズムを合わせて見通しを共有する Copyright© Growth xPartners,
Inc. All rights reserved. 68 プロダクト Log 仮説 スプリント 計画 ふりかえり スプリント スプリント バックログ デイリー スクラム プロダクト バックログ 評価用 成果物 仮説検討 価値検討 仕様検討 オポチュニティ バックログ 価値評価 リーン キャンバス ..... ::::: ::::: ::::: ::::: ::::: ::::: ..... ::::: ::::: ::::: ::::: ::::: ::::: ..... ::::: ::::: ::::: ::::: ::::: ::::: ペルソナ カスタマー ジャーニーマップ インセプション デッキ サービス ブループリント アーキテクチャ 設計 アーキテクチャビジョン & デザイン設計 テクニカル ソリューション技術 検討 スプリント レビュー ToDo Ready In Progress Done Feedback かんばん 価値計測 出荷 プロダクト 利用 リーン スクラム アーキ テクチャ 本番運用 • アイディア出し中 • 問題が本当にあるか確認中 • プロトタイプによる検証中 で、開発着手前のものは、 「オポテュニティバックログ」 で管理 現在、開発チームが 着手中のタスクは 「スプリントバックログ」 で管理 今後開発予定のものは、 「プロダクトバックログ」 で管理 ToDo Ready In Progress Done Feedback スプリント バックログ プロダクト バックログ オポチュニティ バックログ かんばん開発計画のサイクル に入らないタスクは 「かんばん」 で管理 次のスプリント計画前までに、 • バックログ見直し • ユーザーストーリー見直し • ストーリーテスト作成 • ストーリーポイント見直し • 価値・リスク観点での優先順位見直し を実施しておく
70.
• アーキテクチャ設計でできること • リーンでできること •
改善活動でできること どう動くとよさそうか Copyright© Growth xPartners, Inc. All rights reserved. 69
71.
改善活動でできること • ふりかえりを共有する Copyright© Growth
xPartners, Inc. All rights reserved. 70
72.
ふりかえりの進め方 1. ふりかえりの全体説明(6分) 2. 個人ふりかえり(6分) 3.
個人ふりかえりのチーム内共有(6分) 4. チーム別ふりかえり(30分) 5. チーム別ふりかえり結果の共有(15分) 6. ふりかえりのふりかえり(8分) Copyright© Growth xPartners, Inc. All rights reserved. 71
73.
用意するもの Copyright© Growth xPartners,
Inc. All rights reserved. 72 No. 道具名 数 必須 備考 1 個人ふりかえり(A3) 人数分 必須 2 サインペン(黒) 人数分 必須 裏写りしにくいペンならなおよい 3 付箋 人数分 必須 4 模造紙 チーム数分 必須 ホワイトボードでも可 5 養生テープ 2個 必須 6 タイマー 1個 必須 スマフォアプリでも可 7 カメラ 1個 必須 スマフォアプリでも可 8 9 10 11 12 13
74.
ふりかえりとは Copyright© Growth xPartners,
Inc. All rights reserved. 73
75.
ふりかえりの目的 • もっとうまくできるようにする –定期的に検査して、ちょっとずつ良くする • 強制的に仕事を停止する –強制的に立ち止まって、本当にこのままでいいのか 考える余裕を持つ –定期的な予定として組み込む Copyright©
Growth xPartners, Inc. All rights reserved. 74
76.
ふりかえりの大前提 • 心理的安全性の確保 –「あなた vs
わたし」 → 「問題 vs わたしたち」 –安全でないと、失敗を認めたり、問題を明らかに したり、新しいことに挑戦しにくくなる –高い心理的安全性を持つチームは、それぞれが 同じくらいの持ち時間で話す傾向がある –心理的安全性の確保のため、無記名で実施 Copyright© Growth xPartners, Inc. All rights reserved. 75
77.
ふりかえりのコツ • 意見ではなく、事実を –例)品質が悪い –例)情報共有が不足している –意見だけをもとにしてアクションを決めると、 本質的な問題が解決しない –解決策の欠如を問題として語るのは、 場の安全性、チームの信頼の欠如を示すシグナル Copyright© Growth
xPartners, Inc. All rights reserved. 76
78.
個人ふりかえり Copyright© Growth xPartners,
Inc. All rights reserved. 77
79.
個人ふりかえりのステップ 1. 企画チームと開発チームが半分ずつ混合した グループA・グループBに分かれて着席いただ いた後、個人でふりかえりをします 2. チーム内で、個人ふりかえり結果を 共有します Copyright©
Growth xPartners, Inc. All rights reserved. 78 グループA グループB スクリーン
80.
個人ふりかえり Copyright© Growth xPartners,
Inc. All rights reserved. 79 スプリントを通し て、今回私が改善 できたこと スプリント中に、 今回私が改善でき なかったこと スプリントゴール を達成するために、 私がやったこと 今回のスプリント を通して、私が学 んだこと 今回のスプリント 中に、私が感じた こと 次のスプリントで、 私が改善したいと 考えていること
81.
個人ふりかえりのチーム内共有 1. 企画チームと開発チームが半分ずつ混合した グループA・グループBに分かれて着席いただ いた後、個人でふりかえりをします 2. チーム内で、個人ふりかえり結果を 共有します Copyright©
Growth xPartners, Inc. All rights reserved. 80 グループA グループB スクリーン
82.
チーム別ふりかえり Copyright© Growth xPartners,
Inc. All rights reserved. 81
83.
チーム別ふりかえりのステップ 1. 企画チームと開発チームが半分ずつ混合した グループA・グループBに分かれて、最初は別 々にふりかえりを実施します –それぞれのグループにファシリテーターがつきます 2. チーム別ふりかえり結果を共有します Copyright©
Growth xPartners, Inc. All rights reserved. 82 グループA グループB スクリーン
84.
チーム別ふりかえりのステップ Copyright© Growth xPartners,
Inc. All rights reserved. 83 Keep 続けたいこと、 よいこと Try 改善策、 工夫したいこと Action 次のスプリントで 行動すること Problem 不満点、 問題点 (1)続けたいこと、 よいこと (2)不満点、問題点 (3)Problemに 効きそうな改善策 (4)Keepを 強化する改善策 (6)次のスプリントで 行動することを合意し、 具体化する
85.
チーム別ふりかえり Copyright© Growth xPartners,
Inc. All rights reserved. 84 Keep 続けたいこと、 よいこと Try 改善策、 工夫したいこと Action 次のスプリントで 行動すること Problem 不満点、 問題点
86.
チーム別ふりかえりのステップ 1. 企画チームと開発チームが半分ずつ混合した グループA・グループBに分かれて、最初は別 々にふりかえりを実施します –それぞれのグループにファシリテーターがつきます 2. チーム別ふりかえり結果を共有します Copyright©
Growth xPartners, Inc. All rights reserved. 85 グループA グループB スクリーン
87.
ふりかえりのふりかえり Copyright© Growth xPartners,
Inc. All rights reserved. 86
88.
ふりかえりのふりかえり <個人ワークショップ> • A3用紙を2枚用意します • 以下をそれぞれ1枚ずつ書き出してください –今日、気づいたこと –次回のふりかえりで改善したいこと Copyright©
Growth xPartners, Inc. All rights reserved. 87 <A3用紙> ■次回、改善すること xxxxxx <A3用紙> ■今日、気づいたこと xxxxxx
89.
アジェンダ • 今、起きていること • ズレや葛藤について考える •
どう動くとよさそうか • まとめ Copyright© Growth xPartners, Inc. All rights reserved. 88
90.
まとめ Copyright© Growth xPartners,
Inc. All rights reserved. 89
91.
モノとコトの実現プロセス Copyright© Growth xPartners,
Inc. All rights reserved. 90 なぜ やるべきか 土台 づくり 使い続け させる作って 仮説検証 作る計画を 立てて 作る計画を まわす 作らずに 仮説検証 作る WHY HOW アイ ディア モノ コト データ 計測 する 学習 する 構築 する アイ ディア モノ コト データ 計測 する 学習 する 構築 する WHAT やりたいコト 用意しなければなら ないモノ 用意しな ければなら ないモノ 葛藤 葛藤
92.
どう動くとよさそうか • アーキテクチャ設計でできること –アーキテクチャ戦略を立てる • リーンでできること –管理するものを分類する –リズムを合わせる •
改善活動でできること –ふりかえりを共有する Copyright© Growth xPartners, Inc. All rights reserved. 91
93.
お知らせ • アーキテクチャについてもう少し 全体感が知りたいなら –Cloud First
Architecture 設計ガイド » 第1章 クラウドファーストの意味 » 第2章 クラウド技術の構成 » 第3章 クラウドファーストに至るまでの歴史 » 第4章 エンタープライズとクラウドファースト » 第5章 アーキテクチャー設計ガイド » 第6章 クラウドファーストにおけるエンジニア » https://www.amazon.co.jp/dp/4822237818 Copyright© Growth xPartners, Inc. All rights reserved. 92
94.
Copyright© Growth xPartners,
Inc. All rights reserved. 93 一緒に働く仲間を募集中です http://gxp.co.jp/recruit/career.html
95.
リーンスタートアップとスマートな エンジニアリングの葛藤 2017/06 改訂版 グロースエクスパートナーズ株式会社 関 満徳
96.
ご清聴ありがとうございました! コンタクト先 URL Blog http://fullvirtue.com/ Twitter
https://twitter.com/fullvirtue Facebook https://www.facebook.com/fullvirtue Email fullvirtue@gmail.com 資料公開場所 http://slideshare.net/fullvirtue/ これまで登壇してきた資料はこちらで公開しています! 是非ご覧ください! 関 満徳せき みつのり グロースエクスパートナーズ株式会社 ITアーキテクト Microsoft MVP for Visual Studio and Development Technologies ITサービス開発のコンサルティング、開発、運用を一貫 して手掛けながら、「顧客価値の創造」と「持続可能な 仕組み創り」をテーマとしたアジャイル・プロダクトマ ネジメントのワークショップデザインを数多く実施。全 国各地でファシリテーターとしても活躍。
Download now