Enviar búsqueda
Cargar
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
•
40 recomendaciones
•
50,268 vistas
Yusuke Suzuki
Seguir
2011年4月23日の「DevLOVE 今、未来に繋がるために帆を立てるとき」での講演内容です。 http://kokucheese.com/event/index/9778/
Leer menos
Leer más
Tecnología
Empresariales
Vista de diapositivas
Denunciar
Compartir
Vista de diapositivas
Denunciar
Compartir
1 de 49
Descargar ahora
Descargar para leer sin conexión
Recomendados
[SAPPORO CEDEC] サービスの効果を高めるグリー内製ツールの技術と紹介
[SAPPORO CEDEC] サービスの効果を高めるグリー内製ツールの技術と紹介
gree_tech
Amazon Kinesis Video Streams WebRTC 使ってみた
Amazon Kinesis Video Streams WebRTC 使ってみた
mganeko
MLflowで学ぶMLOpsことはじめ
MLflowで学ぶMLOpsことはじめ
Kenichi Sonoda
GraphQLのsubscriptionで出来ること
GraphQLのsubscriptionで出来ること
Shingo Fukui
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました —結果編—
市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました —結果編—
Yusuke Amano
Data-Centric AIの紹介
Data-Centric AIの紹介
Kazuyuki Miyazawa
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
Recomendados
[SAPPORO CEDEC] サービスの効果を高めるグリー内製ツールの技術と紹介
[SAPPORO CEDEC] サービスの効果を高めるグリー内製ツールの技術と紹介
gree_tech
Amazon Kinesis Video Streams WebRTC 使ってみた
Amazon Kinesis Video Streams WebRTC 使ってみた
mganeko
MLflowで学ぶMLOpsことはじめ
MLflowで学ぶMLOpsことはじめ
Kenichi Sonoda
GraphQLのsubscriptionで出来ること
GraphQLのsubscriptionで出来ること
Shingo Fukui
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました —結果編—
市場価値で給料が決まるサイボウズの社員だけど、転職ドラフトに参加して給与交渉に挑戦してみました —結果編—
Yusuke Amano
Data-Centric AIの紹介
Data-Centric AIの紹介
Kazuyuki Miyazawa
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
Amazon SageMakerでscikit-learnで作ったモデルのEndpoint作成
Amazon SageMakerでscikit-learnで作ったモデルのEndpoint作成
西岡 賢一郎
chatGPTの驚くべき対話能力.pdf
chatGPTの驚くべき対話能力.pdf
YamashitaKatsushi
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
NTT DATA Technology & Innovation
Azure Service Fabric 概要
Azure Service Fabric 概要
Daiyu Hatakeyama
ChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くない
Carnot Inc.
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
Preferred Networks
設計品質とアーキテクチャ
設計品質とアーキテクチャ
Toru Koido
Mixed Reality Toolkit V3について
Mixed Reality Toolkit V3について
Takahiro Miyaura
Google Cloud ベストプラクティス:Google BigQuery 編 - 01 : BigQuery とは?
Google Cloud ベストプラクティス:Google BigQuery 編 - 01 : BigQuery とは?
Google Cloud Platform - Japan
第79回 Machine Learning 15minutes ! 生成AIをエンタープライズで活用するWatsonx.aiの紹介
第79回 Machine Learning 15minutes ! 生成AIをエンタープライズで活用するWatsonx.aiの紹介
Tsuyoshi Hirayama
MLOpsはバズワード
MLOpsはバズワード
Tetsutaro Watanabe
MLOps入門
MLOps入門
Hiro Mura
NTT研究所におけるYammerの取り組みと、社内Twitterの統計解析
NTT研究所におけるYammerの取り組みと、社内Twitterの統計解析
Tokoroten Nakayama
コンテナ環境でJavaイメージを小さくする方法!
コンテナ環境でJavaイメージを小さくする方法!
オラクルエンジニア通信
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Yasuharu Nishi
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
Trainocate Japan, Ltd.
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
Preferred Networks
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
Preferred Networks
AWSではじめるMLOps
AWSではじめるMLOps
MariOhbuchi
地域における観光情報サービス提供のアーキテクチャ
地域における観光情報サービス提供のアーキテクチャ
Hidekazu Kasahara
京都におけるオープンデータプラットフォームの構築可能性検討- 成果報告 -
京都におけるオープンデータプラットフォームの構築可能性検討- 成果報告 -
Hidekazu Kasahara
Más contenido relacionado
La actualidad más candente
Amazon SageMakerでscikit-learnで作ったモデルのEndpoint作成
Amazon SageMakerでscikit-learnで作ったモデルのEndpoint作成
西岡 賢一郎
chatGPTの驚くべき対話能力.pdf
chatGPTの驚くべき対話能力.pdf
YamashitaKatsushi
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
NTT DATA Technology & Innovation
Azure Service Fabric 概要
Azure Service Fabric 概要
Daiyu Hatakeyama
ChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くない
Carnot Inc.
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
Preferred Networks
設計品質とアーキテクチャ
設計品質とアーキテクチャ
Toru Koido
Mixed Reality Toolkit V3について
Mixed Reality Toolkit V3について
Takahiro Miyaura
Google Cloud ベストプラクティス:Google BigQuery 編 - 01 : BigQuery とは?
Google Cloud ベストプラクティス:Google BigQuery 編 - 01 : BigQuery とは?
Google Cloud Platform - Japan
第79回 Machine Learning 15minutes ! 生成AIをエンタープライズで活用するWatsonx.aiの紹介
第79回 Machine Learning 15minutes ! 生成AIをエンタープライズで活用するWatsonx.aiの紹介
Tsuyoshi Hirayama
MLOpsはバズワード
MLOpsはバズワード
Tetsutaro Watanabe
MLOps入門
MLOps入門
Hiro Mura
NTT研究所におけるYammerの取り組みと、社内Twitterの統計解析
NTT研究所におけるYammerの取り組みと、社内Twitterの統計解析
Tokoroten Nakayama
コンテナ環境でJavaイメージを小さくする方法!
コンテナ環境でJavaイメージを小さくする方法!
オラクルエンジニア通信
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Yasuharu Nishi
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
Trainocate Japan, Ltd.
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
Preferred Networks
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
Preferred Networks
AWSではじめるMLOps
AWSではじめるMLOps
MariOhbuchi
La actualidad más candente
(20)
Amazon SageMakerでscikit-learnで作ったモデルのEndpoint作成
Amazon SageMakerでscikit-learnで作ったモデルのEndpoint作成
chatGPTの驚くべき対話能力.pdf
chatGPTの驚くべき対話能力.pdf
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
Azure Service Fabric 概要
Azure Service Fabric 概要
ChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くない
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
設計品質とアーキテクチャ
設計品質とアーキテクチャ
Mixed Reality Toolkit V3について
Mixed Reality Toolkit V3について
Google Cloud ベストプラクティス:Google BigQuery 編 - 01 : BigQuery とは?
Google Cloud ベストプラクティス:Google BigQuery 編 - 01 : BigQuery とは?
第79回 Machine Learning 15minutes ! 生成AIをエンタープライズで活用するWatsonx.aiの紹介
第79回 Machine Learning 15minutes ! 生成AIをエンタープライズで活用するWatsonx.aiの紹介
MLOpsはバズワード
MLOpsはバズワード
MLOps入門
MLOps入門
NTT研究所におけるYammerの取り組みと、社内Twitterの統計解析
NTT研究所におけるYammerの取り組みと、社内Twitterの統計解析
コンテナ環境でJavaイメージを小さくする方法!
コンテナ環境でJavaイメージを小さくする方法!
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
AWSではじめるMLOps
AWSではじめるMLOps
Destacado
地域における観光情報サービス提供のアーキテクチャ
地域における観光情報サービス提供のアーキテクチャ
Hidekazu Kasahara
京都におけるオープンデータプラットフォームの構築可能性検討- 成果報告 -
京都におけるオープンデータプラットフォームの構築可能性検討- 成果報告 -
Hidekazu Kasahara
Configuration As Code - Adoption of the Job DSL Plugin at Netflix
Configuration As Code - Adoption of the Job DSL Plugin at Netflix
Justin Ryan
DevOps Practices:Configuration as Code
DevOps Practices:Configuration as Code
Doug Seven
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
Yusuke Suzuki
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
Yusuke Suzuki
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
Yusuke Suzuki
日本Javaグループ2017年定期総会 #jjug
日本Javaグループ2017年定期総会 #jjug
日本Javaユーザーグループ
Destacado
(8)
地域における観光情報サービス提供のアーキテクチャ
地域における観光情報サービス提供のアーキテクチャ
京都におけるオープンデータプラットフォームの構築可能性検討- 成果報告 -
京都におけるオープンデータプラットフォームの構築可能性検討- 成果報告 -
Configuration As Code - Adoption of the Job DSL Plugin at Netflix
Configuration As Code - Adoption of the Job DSL Plugin at Netflix
DevOps Practices:Configuration as Code
DevOps Practices:Configuration as Code
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
日本Javaグループ2017年定期総会 #jjug
日本Javaグループ2017年定期総会 #jjug
Similar a なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
Yusuke Suzuki
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
Yusuke Suzuki
VSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect Academy
Yusuke Suzuki
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
Yusuke Suzuki
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
Yusuke Suzuki
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
Yusuke Suzuki
ドメイン駆動設計と要求開発
ドメイン駆動設計と要求開発
Kent Ishizawa
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
Hironori Washizaki
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age and casual astah models
Kenji Hiranabe
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
Yoshiyuki Ueda
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
Unicast Inc.
Information20120312
Information20120312
b-slash
To be sn agile enterprise
To be sn agile enterprise
Rakuten Group, Inc.
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
サービス開発における工程
サービス開発における工程
Hidetoshi Mori
[Biz reach qa meetup] qa team_build
[Biz reach qa meetup] qa team_build
久仁朗 山本(旧姓 村上)
Introduction of Business Models in Requirement Development
Introduction of Business Models in Requirement Development
Kent Ishizawa
チケット駆動開発の概要と体験談
チケット駆動開発の概要と体験談
Makoto SAKAI
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
Similar a なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
(20)
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
VSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect Academy
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ドメイン駆動設計と要求開発
ドメイン駆動設計と要求開発
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age and casual astah models
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
Information20120312
Information20120312
To be sn agile enterprise
To be sn agile enterprise
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
サービス開発における工程
サービス開発における工程
[Biz reach qa meetup] qa team_build
[Biz reach qa meetup] qa team_build
Introduction of Business Models in Requirement Development
Introduction of Business Models in Requirement Development
チケット駆動開発の概要と体験談
チケット駆動開発の概要と体験談
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Más de 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
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
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
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
Yusuke Suzuki
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
Yusuke Suzuki
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
Yusuke Suzuki
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
Yusuke Suzuki
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
Yusuke Suzuki
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
Yusuke Suzuki
エナジャイル設立によせて
エナジャイル設立によせて
Yusuke Suzuki
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
Yusuke Suzuki
Más de Yusuke Suzuki
(20)
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏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
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
エナジャイル設立によせて
エナジャイル設立によせて
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
1.
再演
#devlove0423 なぜソフトウェゕゕーキテクトが 必要なのか ~未知なるソフトウェゕに形を与えよ~ グロースエクスパートナーズ株式会社 事業推進本部 本部長 JJUG/JSUG 鈴木雄介
2.
自己紹介 1/2 • グロースエクスパートナーズ株式会社
– 事業推進本部 本部長 – チーフITゕーキテクト – ソリューションデリバリー事業 統括 http://www.gxp.co.jp
3.
自己紹介 2/2 •
日本Javaユーザー会、日本Springユーザー会 • Twitter: http://twitter.com/yusuke_arclamp • ブログ:http://www.arclamp.jp/ • 「ソフトウェゕゕーキテクトが知るべき97のこと」監修 • 「拡張する空間」共著(藤本壮介氏) 第一きのこ
4.
本講演の目的 • ゕーキテクチャについて理解を深める • プロジェクトマネジメントにおけるゕー
キテクチャ設計の役割について理解する • ソフトウェゕゕーキテクトの役割につい て理解する • ユーザーとの協業について理解する
5.
ゕジェンダ •
ゕーキテクチャとは • マネジメントとゕーキテクチャ • ユーザーとゕーキテクト • まとめ
6.
アーキテクチャとは
• ソフトウェアとは何か • アーキテクチャとは何か http://www.flickr.com/photos/left-hand/3510633193/
7.
ソフトウェゕとは何か
影響を与える 利用時の 利用時の プロセス 内部 外部 利用時 品質 品質 行動 構造 振る舞い 依存する JISX0129-1 ソフトウェア製品の品質 第1部 品質モデル
8.
ソフトウェゕとは何か
特徴 例 利用時の品質 ・利用状況によって評価が異な ・ユーザーAさんと る ユーザーBさんで評価 が異なる 外部品質 ・システムの振る舞い ・テストケース ・誰がテストしても同じ結果 ・外部仕様 ・一般的な仕様策定の対象 内部品質 ・システムを構成している要素 ・クラス図 すべて(含ドキュメント) ・フレームワーク ・後に残り、評価が可能 ・ドキュメント ・エンジニゕがこだわるところ プロセス品質 ・後に残らない ・コミュニケーション ・
9.
ソフトウェゕとは何か
プログラマの視点 利用時の 利用時の コーデ インス クラス 品質 ユーザー 品質 ィング タンス 行動 構造 振る舞い テスト ユニットテスト 自動テスト
10.
ゕーキテクチャとは何か • システムの基盤であり、コンポーネント
群、コンポーネント間の相互関係と環境 との関係、設計と改良を管理する原則に より構成される IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems(ゕーキテクチャ記述の推奨プラクテゖス)
11.
ゕーキテクチャとは何か • 基本は分割と統合 –
全体をどのように分けて、分けた部分をどの ように関係づけるか これ? 利用時の 利用時の 振る プロセス 構造 利用 品質 品質 舞い NO。それはストラクチャー
12.
ゕーキテクチャとは何か
IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems(ゕーキテクチャ記述の推奨プラクテゖス)
13.
ゕーキテクチャとは何か
ミッション システム 制約(環境) ビュー モデルによって記述 利害関係者の 関心事 ビューポイント
14.
ゕーキテクチャとは何か • ゕーキテクチャとは –
システムのミッションに従い、システムのお かれた制約を前提としながら – システムに関わる複数の利害関係者の関心事 を整合させ、 • 経営者、オーナー、ユーザー、プログラマ、 DBA、 ンフラ屋、PM、上司 – ラフサクル(設計から保守)まで意識し た – システムの分け方と組合せ方のこと
15.
ゕーキテクチャとは何か
利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 事前的な“つなぎ方”がアーキテクチャ
16.
マジメントとアーキテクチャ • マネジメントとは何か • PMとアーキテクチャ
http://www.flickr.com/photos/drift-words/10434156/
17.
Good managers do the
things right Good leadership does the right thing
18.
マネジメントとは何か • マネージャーは「物事を正しくする」 –
目標と目的、 どうやって?いつ?、組織と構 造、リスク回避 … – 現実、複雑さへの対応、成功、教育 • リーダーシップは「正しい事をする」 – ビジョン、何を?なぜ?、チャレンジ、ノ ベーション、リスクは機会… – 変革、未来、変化、進歩、現状への不満
19.
マネジメントとは何か • PMBOK(A
Guide to the Project Management Body of Knowledge) 立ち上げ 計画 実行 管理 終結 統合 計画策定 計画実行 統合変更管理 スコープ 立ち上げ スコープ計画/定義 スコープ検証/変更管理 (目的と範囲) 時間(期間) ゕクテゖビテゖ定義/順序設 スケジュールコントロール 定/期間見積 スケジュール作成 コスト(予算) 資源管理 コストコントロール コストの見積/予算化 品質 人的資源 品質計画 組織計画 計画 実行 品質保証 チーム育成 品質管理 調整 要員調達 コミュニケー コミュニケーション計画 情報配布 実行報告 完了手続き ション リスク リスク・マネジメント計画 リスクの監視・コントロー リスク識別 ル 定性的/定量的リスク分析 調達 調達/引合計画 引合 契約完了 発注先選定 契約管理
20.
なぜPMは記事になるの?
「危機を救うヒーローだから」 そもそも危機になるのがいけないんじゃ… http://www.flickr.com/photos/hobby_blog/2162966860/
21.
将来について分かっていることはただひとつ、 現在と同じではないだろう、という点だけだ。
「マネジメント 努め、責任、実践 Ⅰ」 P132 ピーター々ドラッカー 正しい計画を立てることができるのか? http://www.flickr.com/photos/garyhayes/305475097/
22.
「運転で大切なのは〃車を正しい方向に進 めることじゃないのよ〄大切 なのは〃常
に注意を払って細かく左右に方向修正し ていくことなの〄」 XPエクストリーム々プログラミング入門 ケント々ベック http://www.flickr.com/photos/jontintinjordan/420270797/
23.
PMとゕーキテクチャ • ゕジャルマネジメント –
「変化ヲ抱擁セヨ」 • 基本手法 – テレーテゖブなタムボックス管理 • 完成していなくても棚卸しをして評価する – リスク主導 • 不確定な部分から手を付ける。プロトタピング、 継続的統合 ズレを許容しながら、 正しさを探索するテクニック
24.
PMとゕーキテクチャ • ゕジャルを機能させるには –
機能の分割と実施順がそれなりに正しい – 不確定な部分をうまく取り出す • 全体の計画は正しくなくても良いが、正 しさを見つけるプロセスはきちんと決め る必要がある
25.
PMとゕーキテクチャ • プロセスを決めるには要求まで遡る必要
がある プロセス 構造 作りたいもの 要求 この絵、どこかで見ましたよね
26.
PMとゕーキテクチャ • ゕジャルはゕーキテクチャ設計を内包
している – というか、すべてのマネジメントはゕーキテ クチャ設計を前提とする 実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 計画 アーキテクチャ設計
27.
未知への変化が大きければ大きいほど、 飛躍のための土台を確かなものにしておく 必要がある。
「マネジメント 努め、責任、実践 Ⅰ」 P132 ピーター々ドラッカー http://www.flickr.com/photos/chausinho/3104627075/
28.
PMとゕーキテクチャ
• トヨタの新車開発マネジメント – 1人のチーフゕーキテクト – 過去のデータを参考にしながら、3万点の部 品個別で見積もりとレビューを行なう • 前回と違うところはリスクをみて計画を行なう – これが可能なのは車の基本構造が変わってい ないから http://www.flickr.com/photos/toyotauk/5117989415/ http://www.flickr.com/photos/dok1/3909484847/
29.
PMとゕーキテクチャ
実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 計画 アーキテクチャ設計 アーキテクチャが安定するなら マネジメントも安定する
30.
ソフトウェア開発の アーキテクチャは安定している?
31.
PMとゕーキテクチャ • ソフトウェゕ開発では、 –
同じゕーキテクチャを使い回すほうが正しく 見積もれる – しかし、現在のソフトウェゕ開発では新しい ゕーキテクチャによる効率化が、繰り返しの 効率化を上回ることがある • ゕーキテクチャを変えることが多い – 変えない場合はゕーキテクチャが安定するの でマネジメント主導(ウォーターフォール型 での効率化)でよい。パッケージ導入など
32.
PMとゕーキテクチャ • マネジメントとゕーキテクチャ設計 –
変化を許容するためには土台としてのゕーキ テクチャが重要 – ところがソフトウェゕ開発ではプロジェクト 毎にゕーキテクチャが変わってしまう – そこで、プロジェクト毎にゕーキテクチャを 設計し、それによってプロセスや構造の分割 と統合を行なう必要がある ソフトウェアアーキテクチャ設計の プロが必要になる
33.
PMとゕーキテクチャ • ソフトウェゕゕーキテクトはゕーキテク
チャ設計を通じてマネジメントの土台を 提供する • ソフトウェゕゕーキテクトがいないと計 画を立てられない=何をマネジメントし ていいかが分からない – 「『正しさ』を見つけるための方法」を見つ ける – リーダーシップ的な素養
34.
PMとゕーキテクチャ • ゕーキテクトとマネジメントは職能が違
う – マネージャーは「物事を正しくする」 • 目標と目的、 どうやって?いつ?、組織と構造、 リスク回避 … • 現実、複雑さへの対応、成功、教育 – リーダーシップは「正しい事をする」 • ビジョン、何を?なぜ?、チャレンジ、ノベー ション、リスクは機会… • 変革、未来、変化、進歩、現状への不満 アーキテクトは父、マネージャーは母
35.
PMとゕーキテクチャ • 重要なのは「ユーザーとビルダーの関心
事をリンクさせる」枠組みの策定 – これはまさにプロジェクトの”ゕーキテク チャ”と呼べる • ゕーキテクトがプロジェクトのあり方す ら決めていくのではないか – 少なくともゕーキテクト的発想が重要 – プロジェクトゕーキテクトという職種が生ま れる?(もう生まれている?)
36.
ユーザーとアーキテクト
http://www.flickr.com/photos/pgoyette/2819175465/
37.
ユーザーとゕーキテクト • ユーザーとビルダーの間には越えがたい
壁がある – ゕーキテクチャがビューポントを基本にし ているとはいえ、ユーザーのビューポント を取り込むのは難しい 越えられない壁 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い
38.
ユーザーとゕーキテクト • DDD –
使うコトと作るコトをつなぐ手法の1つ – ドメンを通じて、ユーザーとビルダーが会 話をしていく – どうやってドメンをモデリングするのか? DDD 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い
39.
ユーザーとゕーキテクト • ドメンエキスパートを巻き込む –
暇なドメンエキスパートに注意 – 良い(より難しく、より重要な)シナリオを 探す。具体的な状況を聞き出す。「なぜ」を 繰り返す – ビジネス戦略を理解し、コゕドメンを蒸留 させる – “確立された形式”を利用するが、そこで表現 されない固有なものが問題の中核 – コミュニケーションスキルを磨く • モデルで会話する、フゔシリテーションスキル
40.
ユーザーとゕーキテクト • Ericの提唱する渦巻きモデル
41.
まとめ • ゕーキテクチャは「分割と統合」 • プロジェクトマネジメントにゕーキテク
チャ設計が含まれる – 変化をするためには安定した土台が必要 – ソフトウェゕ開発では毎回ゕーキテクチャ設 計をする必要がある • ゕーキテクトはゕーキテクチャ設計を通 じてマネジメントの土台を提供する • ゕーキテクトは父、マネージャーは母
42.
まとめ • プロジェクトゕーキテクト • ゕーキテクト的発想力(関係者の関心事
をリンクさせる力)が重要になっていく • ユーザーとゕーキテクト – DDDのコゕはユーザーとのコミュニケーショ ン
43.
Post 3.11
http://www.flickr.com/photos/pgoyette/2819175465/
44.
Post 3.11 • 最近の周辺トピックス
– BCP(事業継続性計画)、DR(災害時復旧) • 新規開発予算の削減 – 省電力 • DRを兼ねてDCの移設 • 営業時間が短くなる? – クラウドへの興味 • (でも、思ったほどではない?)
45.
Post 3.11 • 質に対する考え方の変化
– 専用線の復旧が一番遅れた • ンターネットや無線の方が品質が高い? • 「質の高さ」が安定した社会ンフラを前提とし ていた – 完璧なBCP/DRはあり得ない • 完璧ではなく”最適”な対応を考える – これまでとは違う価値観の提示 • 慣性力に逆らう必要がある
46.
Post 3.11 • ゕーキテクトの在り方
– ゕーキテクチャは全ての要素から客観的 – ゕーキテクトは全ての要素を客観視する • “神の視座”に立つことを前提とする – これまで以上にビジョンを明示する必要があ る – でも、そんなことは可能なの?
47.
Post 3.11 • 可能なのか、ではなく、その覚悟が必要
– 自らの説明責任を果たす • であれば、デザンの中心は、システム でも、人(誰か)でもなく、”自らの想い” であることに自覚的でいたい • オレオレでしかない現実を受け入れつつ、ナニカ が別にあることを意識する • 不遜であることに、謙虚でいられるか
48.
「デザンとは色や形 ではなく、人の世界 観を拡げる仕事で
しょう?」 by 西村佳哲
49.
再演
#devlove0423 なぜソフトウェゕゕーキテクトが 必要なのか ~未知なるソフトウェゕに形を与えよ~ グロースエクスパートナーズ株式会社 事業推進本部 本部長 JJUG/JSUG 鈴木雄介
Descargar ahora