Submit Search
Upload
ウォーターフォールとアジャイルを考える #ita_ws
•
13 likes
•
16,758 views
Yusuke Suzuki
Follow
2016/6/21に開催した勉強会「ウォーターフォールとアジャイルを考える」の資料とワークのディスカッションメモです。
Read less
Read more
Technology
Report
Share
Report
Share
1 of 47
Download now
Download to read offline
Recommended
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
Yusuke Suzuki
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
Yusuke Suzuki
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
Yusuke Suzuki
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
Yusuke Suzuki
Recommended
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
Yusuke Suzuki
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
Yusuke Suzuki
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
Yusuke Suzuki
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
Yusuke Suzuki
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
YoheiGibo
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
アジャイルにモデリングは必要か
アジャイルにモデリングは必要か
Hiromasa Oka
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
ナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるために
Recruit Lifestyle Co., Ltd.
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
REST API のコツ
REST API のコツ
pospome
俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門
Fumihiko Kinoshita
概念モデリング再入門 + DDD
概念モデリング再入門 + DDD
Hiroshima JUG
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
増田 亨
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
XPは何を伝えたかったんだと思う?
XPは何を伝えたかったんだと思う?
Masanori Kado
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
Yusuke Suzuki
DX 組織デザインパターン
DX 組織デザインパターン
Osaka University
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
Mharu
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
Yusuke Suzuki
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
Yusuke Suzuki
More Related Content
What's hot
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
YoheiGibo
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
アジャイルにモデリングは必要か
アジャイルにモデリングは必要か
Hiromasa Oka
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
ナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるために
Recruit Lifestyle Co., Ltd.
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
REST API のコツ
REST API のコツ
pospome
俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門
Fumihiko Kinoshita
概念モデリング再入門 + DDD
概念モデリング再入門 + DDD
Hiroshima JUG
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
増田 亨
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
XPは何を伝えたかったんだと思う?
XPは何を伝えたかったんだと思う?
Masanori Kado
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
Yusuke Suzuki
DX 組織デザインパターン
DX 組織デザインパターン
Osaka University
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
Mharu
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
What's hot
(20)
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
アジャイルにモデリングは必要か
アジャイルにモデリングは必要か
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
ナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるために
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
REST API のコツ
REST API のコツ
俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門
概念モデリング再入門 + DDD
概念モデリング再入門 + DDD
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
XPは何を伝えたかったんだと思う?
XPは何を伝えたかったんだと思う?
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
DX 組織デザインパターン
DX 組織デザインパターン
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Similar to ウォーターフォールとアジャイルを考える #ita_ws
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
Yusuke Suzuki
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
Yusuke Suzuki
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
Yusuke Suzuki
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
CASAREAL, Inc.
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Yusuke Suzuki
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
Yusuke Suzuki
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
Yusuke Suzuki
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
Yusuke Suzuki
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
Yusuke Suzuki
エナジャイル設立によせて
エナジャイル設立によせて
Yusuke Suzuki
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
Yusuke Suzuki
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
Yusuke Suzuki
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
Yusuke Suzuki
マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャとは何か
Yusuke Suzuki
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
Yusuke Suzuki
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
Tadayoshi Sato
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
Yusuke Suzuki
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Yusuke Suzuki
Similar to ウォーターフォールとアジャイルを考える #ita_ws
(20)
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
エナジャイル設立によせて
エナジャイル設立によせて
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャとは何か
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
More from Yusuke Suzuki
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
Yusuke Suzuki
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
Yusuke Suzuki
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
Yusuke Suzuki
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
Yusuke Suzuki
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
Yusuke Suzuki
エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
Yusuke Suzuki
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
Yusuke Suzuki
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
Yusuke Suzuki
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Yusuke Suzuki
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
Yusuke Suzuki
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
Yusuke Suzuki
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
Yusuke Suzuki
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
Yusuke Suzuki
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
Yusuke Suzuki
More from Yusuke Suzuki
(14)
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
Recently uploaded
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Daniel
danielhu54
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
sugiuralab
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
Atomu Hidaka
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdf
furutsuka
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Yuma Ohgami
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
Ryo Sasaki
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
Shota Ito
Recently uploaded
(7)
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Daniel
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdf
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
ウォーターフォールとアジャイルを考える #ita_ws
1.
アジャイルと ウォーターフォールを考える 2016/6/21 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 ITアーキテクトワークショップ #ita_ws
2.
自己紹介 鈴木雄介 • グロースエクスパートナーズ(株) » 執行役員/アーキテクチャ事業本部長 »
http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
3.
はじめに 今日、話さないこと • 顧客との信頼関係構築とか • 精神論 »広義のアジャイル的ななにか •
多重下請けとか契約とか分業とか • ただ、例のあれには言及します 2
4.
アジェンダ • プロジェクトマネジメント • ウォーターフォールのアプローチ •
アジャイルのアプローチ • アーキテクチャのこと • 例のあれ 3
5.
プロジェクトマネジメント 4
6.
プロジェクトマネジメント 目標達成のための活動 • プロジェクトとは、独自の製品、サービス、所 産を創造するために実施される有期性の業務 »特定の成果を達成するために組織 »期間が限定されている :
有期性 »個別にユニークで同じものはない : 独自性 »相互に関連する作業の調整がなされる:相互関連性 • 対としては「プロダクト」 »プロダクトが終了までの継続的な活動 5
7.
プロジェクトマネジメント 基本はPDCA • 計画する:QCDSを決める • 実行する:計画従って作業する •
計測する:計画と実績のズレを測る • 調整する:ズレに対応する(QCDSの変更) ※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能) 6
8.
プロジェクトマネジメント 失敗あるある • 計画の失敗:そもそも計画が正しくない • 実行の失敗:計画された通りに作れない •
計測の失敗:正しく進捗を測れない • 調整の失敗:ズレがあっても調整できない 7
9.
ウォーターフォールの アプローチ 8
10.
ウォーターフォール PMBOK • 国際標準のプロジェクトマネジメントの知識体 系(ガイド、手法、メソドロジー、ベストプラ クティス)。建設、製造、ソフトウェア開発な どに適用できる。1996年に初版 • 5個の基本的なプロセス群と10個の知識エリア とに分類する。 9
11.
ウォーターフォール 10 立ち上げ 計画 実行
監視・コントロール 終結 統合 計画策定 計画実行 統合変更管理 スコープ (目的と範囲) 立ち上げ スコープ計画/定義 スコープ検証/変更管理 時間(期間) アクティビティ定義/順序設 定/期間見積 スケジュール作成 スケジュールコントロール コスト(予算) 資源管理 コストの見積/予算化 コストコントロール 品質 品質計画 品質保証 品質管理 人的資源 組織計画 要員調達 チーム育成 コミュニケー ション コミュニケーション計画 情報配布 実行報告 完了手続き リスク リスク・マネジメント計画 リスク識別 定性的/定量的リスク分析 リスクの監視・コントロー ル 調達 調達/引合計画 引合 発注先選定 契約管理 契約完了 ステークホル ダー 特定 ステークホルダー計画 関与促進 関与のコントロール 計画 実行 調整
12.
ウォーターフォール PMBOK:5つのプロセス 11 スコープ 定義 スケ ジュール 作成 コスト 積算 PJ計画 策定 PJ計画 実施 進捗報告 変更管理 計画プロセス 遂行プロセス監視・コントロールプロセス 終結 プロセス 立ち上げ プロセス リスク管理 計画 品質 計画 コミュニケーション 計画 調達 計画
13.
ウォーターフォール PDCAをフェーズで管理する • 計画:全体を定義し、計画立案 • 実行:計画に沿って実行 •
計測:計画従って実績を監視 • 調整:計画と実績のズレをコントロールする • フェーズで管理する »プロジェクトのライフサイクルをフェーズに分ける »フェーズごとに完了判定し、次に進む(進まない) 12
14.
ウォーターフォール ウォーターフォールあるある • 計画の失敗:そもそも計画が正しくない • 実行の失敗:計画された通りに作れない •
計測の失敗:正しく進捗を測れない • 調整の失敗:ズレがあっても調整できない • フェーズが完了していないのに次に進む »そもそも完了基準も完了判定も曖昧で、結局、日付 でしか見てない 13
15.
アジャイルの アプローチ 14
16.
アジャイル ウォーターフォールへの反省(私見) • 最初の計画がある程度は正しい必要がある »計画通りが前提で、どうしてもバイアスがかかる • 最初にフェーズやプロセスへの分解が行われて しまうので、それを実行することが目的化する •
PMが知識職になってしまった »本来は技術的な計画能力と政治的な調整能力が重要 なはず 15
17.
アジャイル 逆転の発想 • 計画:精度が出るぐらい小さな計画にする • 実行:計画通りに実行する •
計測:計画終了時に動くソフトウェアで判断 • 調整:定期的に関係者全員で話し合う »実行中にはスコープ調整は行わない • 失敗するにしても範囲が小さい »うまくいかないことも成果の1つ 16
18.
アジャイル PMがいない、フェーズがない • PMがやるべきことを全員でやる »PMの能力に依存しなくなる »プロセスそのものがマネジメント行為になる • 「終わるまで」ではなく「時間制限の中で」 »時は金なり »唯一明確な完了基準は「時間」 17
19.
アジャイル 制約というか前提 • チーム能力を重視する »チームとして習熟させていく必要がある »(スキルの出し入れが困難になる) • 「全体の終了」という概念がない »全体が分からないから »プロダクトが終わるまで続ければいい ▸プロダクトが終わるというのも明確な完了基準 18
20.
ウォータフォールとの違い 計画駆動か変化駆動か • 計画駆動=ウォーターフォール »予測可能なプロジェクトの場合は、計画を重視する 方が効率が良い • 変化駆動=アジャイル »探索的なプロジェクトの場合は、変化を重視する方 が効率が良い 19
21.
アジャイル PMBOKとアジャイル • 2013年の第5版ではアジャイルにも言及 »「ライフサイクルが違うだけで適用可能」 • ライフサイクルのタイプ »予測型ライフサイクル(計画駆動型) »反復型ライフサイクル/漸進型ライフサイクル »適応型ライフサイクル(変化駆動型/アジャイル手法 ) 20
22.
アジャイル アジャイルでないもの • マネジメントがないもの »マネジメント=計画>実行>計測>調整 • コミュニケーションが健全でないもの »顧客も含めたチームとの信頼感は前提 »必要なドキュメントは作るべき •
これはウォーターフォールでも同じ 21
23.
アーキテクチャのこと 22
24.
アーキテクチャ アーキテクチャは基盤 • アーキテクチャ:システムの分け方と組合せ方 »分け方:構造、組み合わせ方:構成 »構造には工法(プロセス・手順)が必要 • 「スコープからタスクへの分解」がある以上、 そこには必ずアーキテクチャがある »ウォーターフォールもアジャイルも、マネジメント の基盤はアーキテクチャが決定する 23
25.
アーキテクチャ アーキテクチャは選択肢を残す • 現在的なアーキテクチャは「決めない」 »変化を許容できるようにする • 大切なのはモジュールを決めること »変化の境界線で分け、適切に組み合わせる ▸標準化 ▸交換可能、増減可能、拡張可能 »モジュールごとに交換を可能にする 24
26.
MSA サービスの分割 • モジュール化の最先端がマイクロサービスアー キテクチャ • システムを疎結合なサービスに分割する »クラウド技術やDevOpsが前提 »サービスごとにライフサイクルを変えられる ▸技術もマネジメントスタイルも自由にしていい »チームはサービスを管理する 25 この話は別の機会に
27.
例のあれ 26
28.
例のあれ 27
29.
例のあれ ウォーターフォールのメリットは? • 「ウォーターフォールは何のメリットも無い」 はダウト »特定の文脈ではメリットがある • では「いまどきのシステム開発においてウォー ターフォールを採用するメリットはない」は? »今日のワークのネタはこれで 28
30.
まとめ 29
31.
まとめ 基本はPDCA • 計画する:QCDSを決める • 実行する:計画従って作業する •
計測する:計画と実績のズレを測る • 調整する:ズレに対応する(QCDSの変更) ※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能) 30
32.
まとめ ウォータフォール • 計画:全体を定義し、計画立案 • 実行:計画に沿って実行 •
計測:計画従って実績を監視 • 調整:計画と実績のズレをコントロールする • フェーズで管理する 31
33.
まとめ アジャイル • 計画:精度が出るぐらい小さな計画にする • 実行:計画通りに実行する •
計測:計画終了時に動くソフトウェアで判断 • 調整:定期的に関係者全員で話し合う »実行中にはスコープ調整は行わない • PMがいない、フェーズがない 32
34.
まとめ 計画駆動か変化駆動か • 計画駆動=ウォーターフォール »予測可能なプロジェクトの場合は、計画を重視する 方が効率が良い • 変化駆動=アジャイル »探索的なプロジェクトの場合は、変化を重視する方 が効率が良い 33
35.
まとめ アーキテクチャ重要 • 「スコープからタスクへの分解」がある以上、 そこには必ずアーキテクチャがある »ウォーターフォールもアジャイルも、マネジメント の基盤はアーキテクチャが決定する • モジュール化の最先端はマイクロサービスアー キテクチャ »サービスを疎結合化し、独立したマネジメントを許 容できるようにする 34
36.
まとめ ウォーターフォールかアジャイルか • マネジメント手法は道具 • 道具の適用を判断するのは人間 •
個別の現場の文脈で正しい判断をしてください 35
37.
後半1時間の全体ディスカッション ワーク 36
38.
テーマ では「いまどきのシステム開発におい てウォーターフォールを採用するメリ ットはない」か? 37
39.
そもそもWFは必要なのか? • スコープ確定すればWFという話ではない。「 スコープはできるかぎり決める」というのは大 前提。決まっててもアジャイルでやればいい »WFはフェーズごとに中間成果物を作るのが無駄にな る。コードという最終成果物を軸にするなら、アジ ャイルになる。 XPの「コードの共同所有」が重要 38
40.
とはいえWFを採用するケースは? • メンバーの力量が読めない場合 • 約束されたリリースがある(法律改定など) •
スコープが確定的 • 基幹システム連携がある(基幹側がWF) • チームやプロジェクトが永続的ではない • パッケージの横展開 • 発注者が公共(計画レビューありき) 39
41.
とはいえWFを採用するケースは? • 実現性検証が十分にできている • 研究開発ではない •
期間に対して量が多い(大量要員投入が必要) • 業務のパターンが読み切れている 40
42.
なぜアジャイルにできない? • 保守開発(メンバーが決まっている)なら、や りやすい • パッケージベンダーの指定でアジャイルをやっ たが、うまくいかなかった •
そもそもユーザー/開発者にやる気がない »都度「スコープを決めて見積もり」という仕事の仕 方では難しい »開発会社としても、年初に請負の売上計画を作るこ とになるとWF型にしたくなる ▸かといって、派遣契約はモチベーションが下がるからいや 41
43.
なぜアジャイルにできない? • やはり、請負契約ではやりにくい »発注側が稟議のために事前のスコープ確定を要求し てくるなら難しい • 準委任でアジャイルして、スコープ確定したら WFというパターンもある=アジャフォール »請負契約だが「先行発注の作業」でスコープ確定し 、確定後に再見積もりして稟議を通してもらうこと もできる 42
44.
どうやってチームを組成する? • コードが書けることは前提として、どういう性 格や姿勢の人がいるとよいのか? »素直で若い子を半分いれたい。変にこだわりすぎず 、すぐに聞いてくれた方がチームが回る »ただし、バックエンドなど安全に作りたいところは” おっさん”をいれて経験とコダワリを行かしてもらう »コードを書けない人がいてもいい ▸テスター、デザイナー、スクラムマスター、教育目的 »そもそもチーム組成ができてから案件提案するのだ から、いる人でやるしかないのでは 43
45.
アジャイルとはいえ、PMっぽい人が必要になるケ ースがある • 全体計画を見る人が必要になる場合はいる • 進捗がぐずぐずになるチーム/人がいる場合 »毎回、見積もりに失敗するチーム/人がいた »それぐらい「どう?」って声をかける人がいれば十 分では •
なんらかの仕切ったりが必要になる場合にいる • 全体的な要求コントロールが必要な場合 »プロダクトオーナーがやるべきでは? »WF慣れしたPOがやるとスコープが無限に広がる 44
46.
アジャイルとはいえ、PMっぽい人が必要になるケ ースがある • 逆にPMでも手を動かすのが好きならアジャイ ル型がいかもしれない • チーム同士が仲が悪くて調整役が必要になった 場合 •
スクラムマスターやプロダクトオーナーとの違 いは? »お世話係ならスクラムマスターでいいのでは »現場に手を出し始めたらスクラムマスターがPMっぽ くなっちゃう 45
47.
チームの立ち上げ • WF/PMに慣れてる人はチームとして動けない のでは? »本だけのオレオレアジャイルは無理。最初はコンサ ルやコーチをいれよう • コーチは役に立ったの? »ある程度のアドバイスは必要 »週1回でも「これでいいのか?」という議論に参加し てくれるだけでうれしい ▸結局「自分たちのことは自分たちで考えないといけない」 ことが学べたけど、それはそれで意味があった ▸メンター的な要素だね 46
Download now