Submit Search
Upload
アジャイル開発を支えるアーキテクチャ設計とは
•
30 likes
•
26,983 views
Yusuke Suzuki
Follow
2017/12/15に開催されたエンタープライズアジャイル勉強会2017年12月セミナーでの講演資料です。 https://easg.smartcore.jp/
Read less
Read more
Technology
Report
Share
Report
Share
1 of 56
Download now
Download to read offline
Recommended
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか
Yoshiki Hayama
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
SEGADevTech
Recommended
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか
Yoshiki Hayama
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
「龍が如く7 光と闇の行方」の自動テスト活用事例とテスト自動化チーム(仮)による若手育成の取り組みについて
SEGADevTech
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版
Tokoroten Nakayama
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
Hironori Washizaki
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
探索的テスト入門
探索的テスト入門
H Iseri
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Ryo Mitoma
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
CASAREAL, Inc.
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
Yusuke Suzuki
More Related Content
What's hot
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版
Tokoroten Nakayama
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
Hironori Washizaki
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
探索的テスト入門
探索的テスト入門
H Iseri
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Ryo Mitoma
What's hot
(20)
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
ビジネスパーソンのためのDX入門講座エッセンス版
ビジネスパーソンのためのDX入門講座エッセンス版
リーン開発の本質 公開用
リーン開発の本質 公開用
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
ソフトウェアパターン概論およびパターンを活用したアーキテクチャ設計
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
探索的テスト入門
探索的テスト入門
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
作る人から作りながら運用する人になっていく
作る人から作りながら運用する人になっていく
Similar to アジャイル開発を支えるアーキテクチャ設計とは
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
CASAREAL, Inc.
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
Yusuke Suzuki
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
Yusuke Suzuki
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
Yusuke Suzuki
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
Yusuke Suzuki
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
Yusuke Suzuki
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
Yusuke Suzuki
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
Yusuke Suzuki
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
Yusuke Suzuki
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
Yusuke Suzuki
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
Yusuke Suzuki
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
Yusuke Suzuki
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
Yusuke Suzuki
マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャとは何か
Yusuke Suzuki
エンタープライズアジャイルを阻む組織やプロセスと、その処方
エンタープライズアジャイルを阻む組織やプロセスと、その処方
Graat(グラーツ)
エナジャイル設立によせて
エナジャイル設立によせて
Yusuke Suzuki
マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に
マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に
Yusuke Suzuki
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Yusuke Suzuki
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Yusuke Suzuki
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
Yusuke Suzuki
Similar to アジャイル開発を支えるアーキテクチャ設計とは
(20)
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャとは何か
エンタープライズアジャイルを阻む組織やプロセスと、その処方
エンタープライズアジャイルを阻む組織やプロセスと、その処方
エナジャイル設立によせて
エナジャイル設立によせて
マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に
マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
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
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
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
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
Yusuke Suzuki
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
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
(16)
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
アジャイル開発を支えるアーキテクチャ設計とは
1.
アジャイル開発を支える アーキテクチャ設計とは 2017/12/15 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 エンタープライズアジャイル勉強会 2017年12月セミナー https://easg.smartcore.jp/
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.
エンタープライズアジャイル アジャイルの目的 • アジャイル採用の理由 »製品のデリバリ速度の加速(62%) »優先順位の変更可能性(56%) »生産性向上(55%) • 採用した結果の効果 »優先順位の変更可能性(87%) »生産性向上(85%) »プロジェクトの可視性(84%) 5 参考:アジャイルの採用状況レポート2016の要約(The
10th Annual State Of Agile Report ) https://qiita.com/kenjihiranabe/items/b9540696b3a0198fcecd
7.
エンタープライズアジャイル アジャイル導入の難しさ • アジャイル採用の障害 »組織文化の変革(55%) »組織の変化への抵抗(42%) »既存のウォーターフォール手法(40%) • アジャイルが失敗した理由 »企業文化とアジャイルの価値観が合わない(46%) »アジャイルの経験不足(41%) 6 参考:アジャイルの採用状況レポート2016の要約(The
10th Annual State Of Agile Report ) https://qiita.com/kenjihiranabe/items/b9540696b3a0198fcecd
8.
エンタープライズアジャイル それだけじゃない難しさ • 確かに組織文化やプロセスも大事 • 一方で、技術面についても難しくなっている »トライアルは「なんとかする」でもよい »そこから本格的に展開しようとすると行き詰まることがある 7
9.
エンタープライズシステムの状況 8
10.
エンタープライズシステムの状況 ITサービスの境界線が曖昧に 9 新 サービス 商品 SSO 外部 商品 管理 商品 ポイント ユーザー カート 顧客 管理 顧客 在庫 管理 在庫 クレジッ トカード 物流 販売 管理 購買 物流 監査 外部 外部 コンタクト センター 問合せ監視
11.
エンタープライズシステムの状況 2種類のシステム • SoR(System of
Record)/mode 1 »情報を正しく「記録」するためのシステム »ユーザーは従業員が中心。取引情報を長期間にわたって保持し、 ビジネスの基幹となるシステム »変更頻度は低め、システム障害影響大 • SoE(System of Engagement)/mode 2 »顧客や取引先との「絆」を作るためにシステム »最新の状況を表示し、判断を行ってもらう。機能はユーザーごと に最適化され、高頻度で改善していく 10
12.
11https://www.flickr.com/photos/36008503@N03/3875243958/
13.
エンタープライズシステムの状況 システムは互いに依存し、影響する • ECサービスの改修が連携先システムに影響する »「サービス」の改修には「連携先システム」の対応が必要 »停止や変更を伴うリリース日は調整が必要になる • SoRとSoEはライフサイクルが異なる »本来ユーザーによる改善サイクルが異なる »システム規模も求められる安定性も異なる 12
14.
エンタープライズシステムの状況 エンタープライズもアジャイルしたいのに! • 「そのシステムがアジャイル」だけでは厳しい »連携先システムのスケジュールに強く影響される »結果「サービス」として求められるスピード感が出ない • かといって連携から逃げるとサービスの価値が下がる »トライアルはそれでもいいが商用に持って行きにくい •
これを「組織文化の違い」という表現もできる »情報システム部門 vs 新サービス開発部門 13
15.
アーキテクチャ設計 14
16.
アーキテクチャ設計 アーキテクチャ設計が大事です • アジャイルが機能するように技術的に支援する »アーキテクチャ設計によってエンタープライズアジャイルを有効 に機能させる 15
17.
アーキテクチャ設計 アーキテクチャ=システムの分割と統合 • システムは複数のコンポーネントの組み合わせで成立する »コンポーネント:部品、特定の機能を果たす単位 • アーキテクチャとは、システムが1.どのようなコンポーネ ントで構成され
2.それらがどのように連携するのか?を定 義したもの(≒システムの構造) 16 コンポーネント コンポーネント コンポーネント
18.
アーキテクチャ設計 コンポーネントの種類 • アプリケーション内部のライブラリ、クラスなど »UIであれはUI部品、テンプレートなど • DBMS、アプリケーションサーバなどのミドルウェア •
ハードウェア、ネットワークなどのインフラ • クラウド上の各種サービス • システム、アプリ、APIといったそのもの 17
19.
アーキテクチャ設計 アーキテクチャのレベル • 5つの階層(※エンタープライズシステムにおける) »企業全体システム »企業内/システム間 »システム内/アプリ間 »アプリ内/フレームワーク »コード 18
20.
アーキテクチャ設計 アーキテクチャのレベル 1/3 • 全体システム/企業 »企業内外のシステム配置やシステム連携 •
企業内/システム間 »あるシステムを中心とした連携先システムとの関係性 19 シス テム シス テム シス テム シス テム システム シス テム シス テム
21.
アーキテクチャのレベル 2/3 • システム内/アプリ間 »システム内のアプリ配置、アプリ間連携 »物理的なノード配置なども含む アプリ アーキテクチャ設計 20 アプリ システム アプリ アプリ
22.
アーキテクチャ設計 アーキテクチャのレベル 3/3 • アプリ内/フレームワーク »アプリケーションフレームワーク選定、パッケージ構成など •
コードレベル »クラス分割やメソッドコールの方法など 21 クラスアプリ クラス クラス クラス ライブ ラリ フレームワーク クラス ライブ ラリ mylist.stream().filter(v -> v > 1) .forEach(System.out::println);
23.
アーキテクチャ設計 大きなアーキテクチャと小さなアーキテクチャ • 5つの階層(※エンタープライズシステムにおける) »企業全体システム »企業内/システム間 »システム内/アプリ間 »アプリ内/フレームワーク »コード 22 大きなアーキテクチャ 小さなアーキテクチャ
24.
アーキテクチャ設計 大きなアーキテクチャ 23 新 サービス 商品 SSO 外部 商品 管理 商品 ポイント ユーザー カート 顧客 管理 顧客 在庫 管理 在庫 クレジッ トカード 物流 販売 管理 購買 物流 監査 外部 外部 コンタクト センター 問合せ監視
25.
アーキテクチャ設計 大きなアーキテクチャと小さなアーキテクチャ • 大きなアーキテクチャ »アジャイルチームの外で解決すべきこと(中とは協力) »アジャイルチームを機能させるために頑張る • 小さなアーキテクチャ »アジャイルチームの中で解決すべきこと »基本的には「好きにしてよし」 »そのアプリに最適な言語やフレームワークを選ぶべき 24
26.
大きなアーキテクチャ設計 何をするのか? 25
27.
何をするのか? サマリ • 様々な観点での社内標準とのすり合わせ »認証認可、セキュリティ、運用保守など • システム連携における機能適合性と時間軸の調整 »どこまでのことなら、いつできるのか? •
システム連携における性能や可用性 »どこまで負荷を掛けられるのか、障害発生時はどうするのか 26
28.
何をするのか? 社内標準 1/2 • 認証 »アカウント管理ポリシー(顧客/社内) »シングルサインオン(顧客/社内) •
認可 »組織と権限の管理の仕方 ▸特に業務側が使う機能でのデータ管理 »端末やアクセス経路制御 27
29.
何をするのか? 社内標準 2/2 • セキュリティ »PCIDSSや個人情報保護などによるデータ管理ポリシー ▸場合によってはマスキング »監査証跡 »ネットワーク経路 •
運用保守 »スケジューラー、監視、バックアップなど運用サービス適合 »インフラ構成や構築 28
30.
何をするのか? 機能適合性と時間軸 • 機能適合性「すぐに反映したい」 »適合度◎:APIを叩いてリアルタイムに反映 »適合度○:バッチで日次反映 »適合度△:手動でCSVダウンロート&アップロード »適合度×:自分で入力しなおし 29
31.
何をするのか? 機能適合性と時間軸 • 時間軸「いますぐやりたい」 »適合度◎:すでに機能があります »適合度○:3か月後には… »適合度△:6か月後には… »適合度×:1年は無理 30
32.
何をするのか? 連携における性能や可用性 • 性能 »データの送受信タイミングや量 »トランザクション量 ▸単位時間あたりのスループット • 可用性 »自システムのSLA »連携先システムがダウンしている場合の挙動 ▸瞬断、障害、メンテナンス(定期)、メンテナンス(不定期) 31
33.
何をするのか? 連携における性能や可用性 • システム連携になると性能と可用性や複雑になる • 性能と可用性 »性能を上げると可用性要求が上がることがある ▸リアルタイムに連携すると停止影響が大きくなる ▸例:基幹は日中しかオンラインがない »機能適合性とのバランスも難しい ▸手動連携をオンライン化する、など 32
34.
大きなアーキテクチャ設計 誰がやるのか? 33
35.
誰がやるのか? チームの外側に用意すべき • チームの外側で関連システムとの調整が可能な人 »チームは小さなアーキテクチャ設計に集中させてあげる »もちろん、チームと連携した判断は必要 »チーム内の人でやるならチーム内タスクとは切り分けて作業 • 専任でなくてよいが、それなりには稼働が必要 »フルコミットである必要はないし、1人でなくても良い »POやスクラムマスターが相談できる相手 34
36.
誰がやるのか? なぜ、チームの外側なのか? • チームが見積もれないことはチームに持ち込まない »外部と調整をしないと見積もれない→生産性が測れない »POが外部部門と調整している状況と同じこと • もちろん、チーム内との連携は必要 »連携手法の検証が必要になった ▸技術検証のための作業をする(スパイク) »連携の検討打ち合わせに出てもらう ▸打ち合わせに出る、というタスクにする 35
37.
その先にあるマイクロサービス 36
38.
その先にあるマイクロサービス マイクロサービスとは? • 大きなシステムを「小さなサービスの連携」で実現する »マイクロサービス同士はオンラインで連携を行う »クラウド(インフラのソフトウェア化)前提 37 サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) システム全体 サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ)
39.
その先にあるマイクロサービス モノリシックからマイクロサービスへ • 大きなシステムを「1つのアプリ」で実現する弊害 »モノリシック(一枚岩)になっていると機能の改善で影響調査や リグレッションテストが膨大にかかってくる »リリースも機能間の調整が必要になってしまう • マイクロサービスのメリット »小さなサービス単位で機能をいれかえられる ▸※小さなサービス同士が疎結合に連携していれば 38
40.
その先にあるマイクロサービス マイクロサービスは「マイクロ」必須か? • サービス粒度は? »ナノ: 0-3人月程度の単機能なAPI »マイクロ:3-20人月程度で複数のAPIを提供 »ミニ:20-100人月程度。3-6人でメンテ »中規模:100-300人月程度。7-10人がかりでメンテ »大規模:中規模以上 •
境界線は曖昧 39 大きなアーキテクチャ 小さなアーキテクチャ
41.
その先にあるマイクロサービス マイクロサービスと設計レベル • 小さなアーキテクチャとしてのマイクロサービス »ナノレベルのAPI設計(例:Serverless)の話 »マイクロレベルのサービス設計(例:SpringBoot)の話 • 大きなアーキテクチャとしてのマイクロサービス »システム間連携(例:ETL)の話 •
もはや、サービスやシステムの境界を決める意味が無い »連携しないサービスは存在しないのだから 40
42.
その先にあるマイクロサービス 大きなアーキテクチャが小さくなる • アプリ内においても「コンポーネントをネットワーク越し に連携させる手法」有効に »大きなアーキテクチャから小さなアーキテクチャまでシームレス • ただし、切り分けは必要 »チーム内でやるべきアーキテクチャか、チーム外でやるべきアー キテクチャか 41
43.
マイクロサービスに学ぶ大きな設計 42
44.
マイクロサービスに学ぶ大きな設計 サマリ • どのようにサービス同士の結合度を調整するか? »データ分離 »メッセージ連携 »無停止デプロイ »レジリエンス • ※細かい話なので、飛ばします。参考↓ »
https://www.slideshare.net/yusuke/aws-dev-day-tokyo-2017 43
45.
データ分離 データは各サービスが管理する • データをサービス間で共有することは避けるべき »テーブル構造の変更が強制的に同期されるから • とはいえ、データの特性や種類に応じて方式を選択 »RDBの機能は有効活用。ただし、2フェーズコミットを避ける »不整合の許容範囲を決めることが重要 ▸許容できないなら疎結合化は困難になる »メッセージングの仕組みとの組み合わせで検討 44
46.
データ分離 • 共有データ:テーブルを共有する。変更同期が必要 »カラム追加/変更などは段階的に対応 • ビュー:参照公開前提だが、変更同期が必要 •
トリガー/ストアド:変更同期は不要。非機能同期が必要 • ETL:全て非同期になる 45 サービスA サービスB サービスA サービスB サービスA サービスB 共有データ ビュー/マテビュー トリガー/ストアド サービスA サービスB ETL
47.
データ分離 • イベントソーシング »データのステートではなくデータへのイベントを共有する ▸非同期ではあるが、時間的ズレを小さくできる »CQRS/コマンドクエリ責務分離 ▸コマンド:更新などのロジックを含む処理 ▸クエリ:検索などの単純な処理 46 イベント ストア サービスA サービスB ステート イベントソーシング
48.
メッセージング サービス同士を連携させる • RESTful API
over HTTP »もっともシンプルで分かりやすい実装 • メッセージキューによる非同期化 »機能同士の非機能を分離することができる 47 サービスA サービスB サービスA サービスBキュー 同期型 非同期型 サービスA サービスB キュー Pub/Sub型 サービスC サービスD
49.
メッセージング 不整合の許容 • 非同期による不整合の許容 »サービス間の疎結合を重視する »運用でリカバリするほうがメリッ トが大きければクーポンもあり 48
50.
無停止デプロイ ブルーグリーンデプロイメント • 瞬断せずにリリースを行うための手法 »1.新verを重複して構築 »2.ルーティングを制御して新verを解放 »3.旧verを削除 49 1.0 1.1 1.0 1.1 1.0 1.1 1.0 1.1
51.
レジリエンス マイクロサービスにおける可用性 • 障害が発生しないようにする、ではない »レジリエンス=復元力 »個別サービスの障害でシステム全体が停止しないようにする »従来の「停止しない部分を積み重ねる方式」は限界 • 階層型障害を避ける事が重要 »サーキットブレーカー 50 サービスA
サービスB サービスC
52.
テスト戦略 サービス間のテスト戦略 • サービス間テスト »サービス内のテストは閉じているが、他のサービスを呼び出し部 分のテスト手法をどうするか? »モックの限界を超える?Consumer-Driven Contract
testing • 本番環境でのテスト »レジリエンスのテストは本番環境でやるしかない »Netflixのカオスモンキー 51
53.
まとめ 52
54.
まとめ エンタープライズアジャイルの状況 • エンタープライズアジャイルでは技術面も課題 »トライアルは「なんとかする」でもよい »そこから本格的に展開しようとすると行き詰まることがある • エンタープライズシステム同士の依存と影響 »連携先システムのスケジュールに強く影響される »結果「サービス」として求められるスピード感が出ない 53
55.
まとめ 大きなアーキテクチャと小さなアーキテクチャ • 大きなアーキテクチャ »アプリ間やシステム間連携 »チームの外側で設計し、チームと共同で選択する • 小さなアーキテクチャ »アジャイルチームが設計し、選択する »そのチームが担当するサービスにとって最適化すればいい 54
56.
まとめ アーキテクチャ設計は重要です • アジャイルを機能させるのにアーキテクチャ設計が必要 »エンタープライズでは大きなアーキテクチャ設計の比重が大きい • マイクロサービスで検討されることは参考になる »連携することを前提にシステムを作る、のが常識に »そうするとシステム間連携の結合度を調整するための手法が様々 に出てくる 55
Download now