SlideShare a Scribd company logo
1 of 47
Download to read offline
アジャイルと
ウォーターフォールを考える
2016/6/21
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
ITアーキテクトワークショップ
#ita_ws
自己紹介
鈴木雄介
• グロースエクスパートナーズ(株)
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
• SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1
はじめに
今日、話さないこと
• 顧客との信頼関係構築とか
• 精神論
»広義のアジャイル的ななにか
• 多重下請けとか契約とか分業とか
• ただ、例のあれには言及します
2
アジェンダ
• プロジェクトマネジメント
• ウォーターフォールのアプローチ
• アジャイルのアプローチ
• アーキテクチャのこと
• 例のあれ
3
プロジェクトマネジメント
4
プロジェクトマネジメント
目標達成のための活動
• プロジェクトとは、独自の製品、サービス、所
産を創造するために実施される有期性の業務
»特定の成果を達成するために組織
»期間が限定されている : 有期性
»個別にユニークで同じものはない : 独自性
»相互に関連する作業の調整がなされる:相互関連性
• 対としては「プロダクト」
»プロダクトが終了までの継続的な活動
5
プロジェクトマネジメント
基本はPDCA
• 計画する:QCDSを決める
• 実行する:計画従って作業する
• 計測する:計画と実績のズレを測る
• 調整する:ズレに対応する(QCDSの変更)
※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能)
6
プロジェクトマネジメント
失敗あるある
• 計画の失敗:そもそも計画が正しくない
• 実行の失敗:計画された通りに作れない
• 計測の失敗:正しく進捗を測れない
• 調整の失敗:ズレがあっても調整できない
7
ウォーターフォールの
アプローチ
8
ウォーターフォール
PMBOK
• 国際標準のプロジェクトマネジメントの知識体
系(ガイド、手法、メソドロジー、ベストプラ
クティス)。建設、製造、ソフトウェア開発な
どに適用できる。1996年に初版
• 5個の基本的なプロセス群と10個の知識エリア
とに分類する。
9
ウォーターフォール
10
立ち上げ 計画 実行 監視・コントロール 終結
統合 計画策定 計画実行 統合変更管理
スコープ
(目的と範囲)
立ち上げ スコープ計画/定義 スコープ検証/変更管理
時間(期間) アクティビティ定義/順序設
定/期間見積
スケジュール作成
スケジュールコントロール
コスト(予算) 資源管理
コストの見積/予算化
コストコントロール
品質 品質計画 品質保証 品質管理
人的資源 組織計画
要員調達
チーム育成
コミュニケー
ション
コミュニケーション計画 情報配布 実行報告 完了手続き
リスク リスク・マネジメント計画
リスク識別
定性的/定量的リスク分析
リスクの監視・コントロー
ル
調達 調達/引合計画 引合
発注先選定
契約管理
契約完了
ステークホル
ダー
特定 ステークホルダー計画 関与促進 関与のコントロール
計画 実行 調整
ウォーターフォール
PMBOK:5つのプロセス
11
スコープ
定義
スケ
ジュール
作成
コスト
積算
PJ計画
策定
PJ計画
実施
進捗報告 変更管理
計画プロセス
遂行プロセス監視・コントロールプロセス
終結
プロセス
立ち上げ
プロセス
リスク管理
計画
品質
計画
コミュニケーション
計画
調達
計画
ウォーターフォール
PDCAをフェーズで管理する
• 計画:全体を定義し、計画立案
• 実行:計画に沿って実行
• 計測:計画従って実績を監視
• 調整:計画と実績のズレをコントロールする
• フェーズで管理する
»プロジェクトのライフサイクルをフェーズに分ける
»フェーズごとに完了判定し、次に進む(進まない)
12
ウォーターフォール
ウォーターフォールあるある
• 計画の失敗:そもそも計画が正しくない
• 実行の失敗:計画された通りに作れない
• 計測の失敗:正しく進捗を測れない
• 調整の失敗:ズレがあっても調整できない
• フェーズが完了していないのに次に進む
»そもそも完了基準も完了判定も曖昧で、結局、日付
でしか見てない
13
アジャイルの
アプローチ
14
アジャイル
ウォーターフォールへの反省(私見)
• 最初の計画がある程度は正しい必要がある
»計画通りが前提で、どうしてもバイアスがかかる
• 最初にフェーズやプロセスへの分解が行われて
しまうので、それを実行することが目的化する
• PMが知識職になってしまった
»本来は技術的な計画能力と政治的な調整能力が重要
なはず
15
アジャイル
逆転の発想
• 計画:精度が出るぐらい小さな計画にする
• 実行:計画通りに実行する
• 計測:計画終了時に動くソフトウェアで判断
• 調整:定期的に関係者全員で話し合う
»実行中にはスコープ調整は行わない
• 失敗するにしても範囲が小さい
»うまくいかないことも成果の1つ
16
アジャイル
PMがいない、フェーズがない
• PMがやるべきことを全員でやる
»PMの能力に依存しなくなる
»プロセスそのものがマネジメント行為になる
• 「終わるまで」ではなく「時間制限の中で」
»時は金なり
»唯一明確な完了基準は「時間」
17
アジャイル
制約というか前提
• チーム能力を重視する
»チームとして習熟させていく必要がある
»(スキルの出し入れが困難になる)
• 「全体の終了」という概念がない
»全体が分からないから
»プロダクトが終わるまで続ければいい
▸プロダクトが終わるというのも明確な完了基準
18
ウォータフォールとの違い
計画駆動か変化駆動か
• 計画駆動=ウォーターフォール
»予測可能なプロジェクトの場合は、計画を重視する
方が効率が良い
• 変化駆動=アジャイル
»探索的なプロジェクトの場合は、変化を重視する方
が効率が良い
19
アジャイル
PMBOKとアジャイル
• 2013年の第5版ではアジャイルにも言及
»「ライフサイクルが違うだけで適用可能」
• ライフサイクルのタイプ
»予測型ライフサイクル(計画駆動型)
»反復型ライフサイクル/漸進型ライフサイクル
»適応型ライフサイクル(変化駆動型/アジャイル手法
)
20
アジャイル
アジャイルでないもの
• マネジメントがないもの
»マネジメント=計画>実行>計測>調整
• コミュニケーションが健全でないもの
»顧客も含めたチームとの信頼感は前提
»必要なドキュメントは作るべき
• これはウォーターフォールでも同じ
21
アーキテクチャのこと
22
アーキテクチャ
アーキテクチャは基盤
• アーキテクチャ:システムの分け方と組合せ方
»分け方:構造、組み合わせ方:構成
»構造には工法(プロセス・手順)が必要
• 「スコープからタスクへの分解」がある以上、
そこには必ずアーキテクチャがある
»ウォーターフォールもアジャイルも、マネジメント
の基盤はアーキテクチャが決定する
23
アーキテクチャ
アーキテクチャは選択肢を残す
• 現在的なアーキテクチャは「決めない」
»変化を許容できるようにする
• 大切なのはモジュールを決めること
»変化の境界線で分け、適切に組み合わせる
▸標準化
▸交換可能、増減可能、拡張可能
»モジュールごとに交換を可能にする
24
MSA
サービスの分割
• モジュール化の最先端がマイクロサービスアー
キテクチャ
• システムを疎結合なサービスに分割する
»クラウド技術やDevOpsが前提
»サービスごとにライフサイクルを変えられる
▸技術もマネジメントスタイルも自由にしていい
»チームはサービスを管理する
25
この話は別の機会に
例のあれ
26
例のあれ
27
例のあれ
ウォーターフォールのメリットは?
• 「ウォーターフォールは何のメリットも無い」
はダウト
»特定の文脈ではメリットがある
• では「いまどきのシステム開発においてウォー
ターフォールを採用するメリットはない」は?
»今日のワークのネタはこれで
28
まとめ
29
まとめ
基本はPDCA
• 計画する:QCDSを決める
• 実行する:計画従って作業する
• 計測する:計画と実績のズレを測る
• 調整する:ズレに対応する(QCDSの変更)
※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能)
30
まとめ
ウォータフォール
• 計画:全体を定義し、計画立案
• 実行:計画に沿って実行
• 計測:計画従って実績を監視
• 調整:計画と実績のズレをコントロールする
• フェーズで管理する
31
まとめ
アジャイル
• 計画:精度が出るぐらい小さな計画にする
• 実行:計画通りに実行する
• 計測:計画終了時に動くソフトウェアで判断
• 調整:定期的に関係者全員で話し合う
»実行中にはスコープ調整は行わない
• PMがいない、フェーズがない
32
まとめ
計画駆動か変化駆動か
• 計画駆動=ウォーターフォール
»予測可能なプロジェクトの場合は、計画を重視する
方が効率が良い
• 変化駆動=アジャイル
»探索的なプロジェクトの場合は、変化を重視する方
が効率が良い
33
まとめ
アーキテクチャ重要
• 「スコープからタスクへの分解」がある以上、
そこには必ずアーキテクチャがある
»ウォーターフォールもアジャイルも、マネジメント
の基盤はアーキテクチャが決定する
• モジュール化の最先端はマイクロサービスアー
キテクチャ
»サービスを疎結合化し、独立したマネジメントを許
容できるようにする
34
まとめ
ウォーターフォールかアジャイルか
• マネジメント手法は道具
• 道具の適用を判断するのは人間
• 個別の現場の文脈で正しい判断をしてください
35
後半1時間の全体ディスカッション
ワーク
36
テーマ
では「いまどきのシステム開発におい
てウォーターフォールを採用するメリ
ットはない」か?
37
そもそもWFは必要なのか?
• スコープ確定すればWFという話ではない。「
スコープはできるかぎり決める」というのは大
前提。決まっててもアジャイルでやればいい
»WFはフェーズごとに中間成果物を作るのが無駄にな
る。コードという最終成果物を軸にするなら、アジ
ャイルになる。 XPの「コードの共同所有」が重要
38
とはいえWFを採用するケースは?
• メンバーの力量が読めない場合
• 約束されたリリースがある(法律改定など)
• スコープが確定的
• 基幹システム連携がある(基幹側がWF)
• チームやプロジェクトが永続的ではない
• パッケージの横展開
• 発注者が公共(計画レビューありき)
39
とはいえWFを採用するケースは?
• 実現性検証が十分にできている
• 研究開発ではない
• 期間に対して量が多い(大量要員投入が必要)
• 業務のパターンが読み切れている
40
なぜアジャイルにできない?
• 保守開発(メンバーが決まっている)なら、や
りやすい
• パッケージベンダーの指定でアジャイルをやっ
たが、うまくいかなかった
• そもそもユーザー/開発者にやる気がない
»都度「スコープを決めて見積もり」という仕事の仕
方では難しい
»開発会社としても、年初に請負の売上計画を作るこ
とになるとWF型にしたくなる
▸かといって、派遣契約はモチベーションが下がるからいや
41
なぜアジャイルにできない?
• やはり、請負契約ではやりにくい
»発注側が稟議のために事前のスコープ確定を要求し
てくるなら難しい
• 準委任でアジャイルして、スコープ確定したら
WFというパターンもある=アジャフォール
»請負契約だが「先行発注の作業」でスコープ確定し
、確定後に再見積もりして稟議を通してもらうこと
もできる
42
どうやってチームを組成する?
• コードが書けることは前提として、どういう性
格や姿勢の人がいるとよいのか?
»素直で若い子を半分いれたい。変にこだわりすぎず
、すぐに聞いてくれた方がチームが回る
»ただし、バックエンドなど安全に作りたいところは”
おっさん”をいれて経験とコダワリを行かしてもらう
»コードを書けない人がいてもいい
▸テスター、デザイナー、スクラムマスター、教育目的
»そもそもチーム組成ができてから案件提案するのだ
から、いる人でやるしかないのでは
43
アジャイルとはいえ、PMっぽい人が必要になるケ
ースがある
• 全体計画を見る人が必要になる場合はいる
• 進捗がぐずぐずになるチーム/人がいる場合
»毎回、見積もりに失敗するチーム/人がいた
»それぐらい「どう?」って声をかける人がいれば十
分では
• なんらかの仕切ったりが必要になる場合にいる
• 全体的な要求コントロールが必要な場合
»プロダクトオーナーがやるべきでは?
»WF慣れしたPOがやるとスコープが無限に広がる
44
アジャイルとはいえ、PMっぽい人が必要になるケ
ースがある
• 逆にPMでも手を動かすのが好きならアジャイ
ル型がいかもしれない
• チーム同士が仲が悪くて調整役が必要になった
場合
• スクラムマスターやプロダクトオーナーとの違
いは?
»お世話係ならスクラムマスターでいいのでは
»現場に手を出し始めたらスクラムマスターがPMっぽ
くなっちゃう
45
チームの立ち上げ
• WF/PMに慣れてる人はチームとして動けない
のでは?
»本だけのオレオレアジャイルは無理。最初はコンサ
ルやコーチをいれよう
• コーチは役に立ったの?
»ある程度のアドバイスは必要
»週1回でも「これでいいのか?」という議論に参加し
てくれるだけでうれしい
▸結局「自分たちのことは自分たちで考えないといけない」
ことが学べたけど、それはそれで意味があった
▸メンター的な要素だね
46

More Related Content

What's hot

「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へYoheiGibo
 
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチマイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ増田 亨
 
アジャイルにモデリングは必要か
アジャイルにモデリングは必要かアジャイルにモデリングは必要か
アジャイルにモデリングは必要かHiromasa Oka
 
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門Masahito Zembutsu
 
ナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるためにナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるためにRecruit Lifestyle Co., Ltd.
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方増田 亨
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツpospome
 
俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門Fumihiko Kinoshita
 
概念モデリング再入門 + DDD
概念モデリング再入門 + DDD概念モデリング再入門 + DDD
概念モデリング再入門 + DDDHiroshima JUG
 
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019Tokoroten Nakayama
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)増田 亨
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドHiroyuki Ito
 
XPは何を伝えたかったんだと思う?
XPは何を伝えたかったんだと思う?XPは何を伝えたかったんだと思う?
XPは何を伝えたかったんだと思う?Masanori Kado
 
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018Yusuke Suzuki
 
DX 組織デザインパターン
DX 組織デザインパターンDX 組織デザインパターン
DX 組織デザインパターンOsaka University
 
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割Mharu
 
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of VeinTokoroten Nakayama
 

What's hot (20)

「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
 
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチマイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
 
アジャイルにモデリングは必要か
アジャイルにモデリングは必要かアジャイルにモデリングは必要か
アジャイルにモデリングは必要か
 
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
 
ナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるためにナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるために
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツ
 
俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門俺も エクストリームプログラミング入門
俺も エクストリームプログラミング入門
 
概念モデリング再入門 + DDD
概念モデリング再入門 + DDD概念モデリング再入門 + DDD
概念モデリング再入門 + DDD
 
WayOfNoTrouble.pptx
WayOfNoTrouble.pptxWayOfNoTrouble.pptx
WayOfNoTrouble.pptx
 
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
 
XPは何を伝えたかったんだと思う?
XPは何を伝えたかったんだと思う?XPは何を伝えたかったんだと思う?
XPは何を伝えたかったんだと思う?
 
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
 
DX 組織デザインパターン
DX 組織デザインパターンDX 組織デザインパターン
DX 組織デザインパターン
 
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
 
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
 

Similar to ウォーターフォールとアジャイルを考える #ita_ws

アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016Yusuke Suzuki
 
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016Yusuke Suzuki
 
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会Yusuke Suzuki
 
開発現場から考える プロジェクトで活躍する 新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考える プロジェクトで活躍する 新入社員の育て方とは?CASAREAL, Inc.
 
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016Yusuke Suzuki
 
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャYusuke Suzuki
 
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukuiクラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukuiYusuke Suzuki
 
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016Yusuke Suzuki
 
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjugJavaOne 2016総括 #jjug
JavaOne 2016総括 #jjugYusuke Suzuki
 
エナジャイル設立によせて
エナジャイル設立によせてエナジャイル設立によせて
エナジャイル設立によせてYusuke Suzuki
 
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナーユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナーYusuke Suzuki
 
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJPMicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJPYusuke Suzuki
 
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについてITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについてYusuke Suzuki
 
マイクロサービスアーキテクチャ とは何か
マイクロサービスアーキテクチャとは何かマイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャ とは何かYusuke Suzuki
 
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018Yusuke Suzuki
 
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementationビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
ビジネスロジック実装進化論 - An Evolution of Business Logic ImplementationTadayoshi Sato
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進めRakuten Group, Inc.
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進めDai FUJIHARA
 
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010Yusuke Suzuki
 
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」Yusuke Suzuki
 

Similar to ウォーターフォールとアジャイルを考える #ita_ws (20)

アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
 
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
 
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
 
開発現場から考える プロジェクトで活躍する 新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考える プロジェクトで活躍する 新入社員の育て方とは?
 
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
 
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
 
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukuiクラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
 
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
 
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjugJavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
 
エナジャイル設立によせて
エナジャイル設立によせてエナジャイル設立によせて
エナジャイル設立によせて
 
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナーユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
 
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJPMicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
 
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについてITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
 
マイクロサービスアーキテクチャ とは何か
マイクロサービスアーキテクチャとは何かマイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャ とは何か
 
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
 
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementationビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
ビジネスロジック実装進化論 - An Evolution of Business Logic Implementation
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
 
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
 
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」
 

More from Yusuke Suzuki

アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチアーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチYusuke Suzuki
 
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023Yusuke Suzuki
 
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022Yusuke Suzuki
 
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021Yusuke Suzuki
 
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020Yusuke Suzuki
 
エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020Yusuke Suzuki
 
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのかなぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのかYusuke Suzuki
 
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏Yusuke Suzuki
 
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18Yusuke Suzuki
 
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのかJavaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのかYusuke Suzuki
 
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座Yusuke Suzuki
 
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017Yusuke Suzuki
 
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考えるJavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考えるYusuke Suzuki
 
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演Yusuke Suzuki
 

More from Yusuke Suzuki (14)

アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチアーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
 
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
 
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
 
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
 
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
 
エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
 
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのかなぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
 
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
 
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
 
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのかJavaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
 
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
 
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
 
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考えるJavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
 
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演「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 DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Danieldanielhu54
 
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムsugiuralab
 
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxIoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxAtomu Hidaka
 
UPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdfUPWARD_share_company_information_20240415.pdf
UPWARD_share_company_information_20240415.pdffurutsuka
 
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介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] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略Ryo Sasaki
 
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000Shota Ito
 

Recently uploaded (7)

Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman 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.pptxIoT 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.pdfUPWARD_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」の紹介Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
 
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
 

ウォーターフォールとアジャイルを考える #ita_ws