Soumettre la recherche
Mettre en ligne
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
•
22 j'aime
•
6,097 vues
Yusuke Suzuki
Suivre
デブサミ2011での講演内容です。
Lire moins
Lire la suite
Technologie
Business
Signaler
Partager
Signaler
Partager
1 sur 45
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
まじめに!できる!LT
まじめに!できる!LT
Akabane Hiroyuki
はじめてのPRD
はじめてのPRD
Takuya Oikawa
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
kumiko koshiro
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
Recommandé
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
まじめに!できる!LT
まじめに!できる!LT
Akabane Hiroyuki
はじめてのPRD
はじめてのPRD
Takuya Oikawa
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
kumiko koshiro
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
Python製BDDツールで自動化してみた
Python製BDDツールで自動化してみた
KeijiUehata1
アイデアソン・ハッカソン運営ガイドブック
アイデアソン・ハッカソン運営ガイドブック
エイチタス株式会社 H-tus Ltd.
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
Mharu
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
モダンフロントエンド開発者に求められるスキルとは
モダンフロントエンド開発者に求められるスキルとは
Takuya Tejima
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
GitLabのAutoDevOpsを試してみた
GitLabのAutoDevOpsを試してみた
富士通クラウドテクノロジーズ株式会社
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
gree_tech
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Shin Ohno
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
Yoshiki Hayama
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
Jenkinsではじめる継続的インテグレーション
Jenkinsではじめる継続的インテグレーション
Masanori Satoh
アジャイルジャーニー
アジャイルジャーニー
toshihiro ichitani
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Yusuke Suzuki
Hadoop入門とクラウド利用
Hadoop入門とクラウド利用
Naoki Yanai
Contenu connexe
Tendances
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
Python製BDDツールで自動化してみた
Python製BDDツールで自動化してみた
KeijiUehata1
アイデアソン・ハッカソン運営ガイドブック
アイデアソン・ハッカソン運営ガイドブック
エイチタス株式会社 H-tus Ltd.
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
Mharu
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
モダンフロントエンド開発者に求められるスキルとは
モダンフロントエンド開発者に求められるスキルとは
Takuya Tejima
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
GitLabのAutoDevOpsを試してみた
GitLabのAutoDevOpsを試してみた
富士通クラウドテクノロジーズ株式会社
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
gree_tech
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Shin Ohno
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
Yoshiki Hayama
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
Jenkinsではじめる継続的インテグレーション
Jenkinsではじめる継続的インテグレーション
Masanori Satoh
アジャイルジャーニー
アジャイルジャーニー
toshihiro ichitani
Tendances
(20)
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Python製BDDツールで自動化してみた
Python製BDDツールで自動化してみた
アイデアソン・ハッカソン運営ガイドブック
アイデアソン・ハッカソン運営ガイドブック
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
モダンフロントエンド開発者に求められるスキルとは
モダンフロントエンド開発者に求められるスキルとは
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
GitLabのAutoDevOpsを試してみた
GitLabのAutoDevOpsを試してみた
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Jenkinsではじめる継続的インテグレーション
Jenkinsではじめる継続的インテグレーション
アジャイルジャーニー
アジャイルジャーニー
En vedette
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Yusuke Suzuki
Hadoop入門とクラウド利用
Hadoop入門とクラウド利用
Naoki Yanai
VSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect Academy
Yusuke Suzuki
Asakusa Enterprise Batch Processing Framework for Hadoop
Asakusa Enterprise Batch Processing Framework for Hadoop
Takashi Kambayashi
Scrum Gathering 2008 Stockholm - Salesforce.com
Scrum Gathering 2008 Stockholm - Salesforce.com
Steve Greene
View customize pluginを使いこなす
View customize pluginを使いこなす
onozaty
アジャイルな地図づくり User Story Mapping for Agile Team
アジャイルな地図づくり User Story Mapping for Agile Team
Takeshi Kakeda
Redmineを使ってみよう
Redmineを使ってみよう
mrgoofy33 .
さくさく要件定義セミナー in 大阪
さくさく要件定義セミナー in 大阪
Zenji Kanzaki
Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.
Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.
Kuniharu(州晴) AKAHANE(赤羽根)
超簡単!!なTestLinkの使い方
超簡単!!なTestLinkの使い方
Cake YOSHIDA
[18-A-1] ハッカー中心の企業文化を日本で根付かせる
[18-A-1] ハッカー中心の企業文化を日本で根付かせる
Hiro Yoshioka
Salesforce.com Agile Transformation - Agile 2007 Conference
Salesforce.com Agile Transformation - Agile 2007 Conference
Steve Greene
En vedette
(13)
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Hadoop入門とクラウド利用
Hadoop入門とクラウド利用
VSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect Academy
Asakusa Enterprise Batch Processing Framework for Hadoop
Asakusa Enterprise Batch Processing Framework for Hadoop
Scrum Gathering 2008 Stockholm - Salesforce.com
Scrum Gathering 2008 Stockholm - Salesforce.com
View customize pluginを使いこなす
View customize pluginを使いこなす
アジャイルな地図づくり User Story Mapping for Agile Team
アジャイルな地図づくり User Story Mapping for Agile Team
Redmineを使ってみよう
Redmineを使ってみよう
さくさく要件定義セミナー in 大阪
さくさく要件定義セミナー in 大阪
Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.
Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.
超簡単!!なTestLinkの使い方
超簡単!!なTestLinkの使い方
[18-A-1] ハッカー中心の企業文化を日本で根付かせる
[18-A-1] ハッカー中心の企業文化を日本で根付かせる
Salesforce.com Agile Transformation - Agile 2007 Conference
Salesforce.com Agile Transformation - Agile 2007 Conference
Similaire à なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
Yusuke Suzuki
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
Yusuke Suzuki
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
Yusuke Suzuki
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
Yusuke Suzuki
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
Yusuke Suzuki
第5回SIA研究会(例会)プレゼン資料
第5回SIA研究会(例会)プレゼン資料
Tae Yoshida
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
Hironori Washizaki
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Hironori Washizaki
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
智治 長沢
Information20120312
Information20120312
b-slash
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
Yoshiyuki Ueda
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
Hironori Washizaki
メトリクスによるソフトウェア品質評価・改善および製品品質実態
メトリクスによるソフトウェア品質評価・改善および製品品質実態
Hironori Washizaki
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age and casual astah models
Kenji Hiranabe
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
【18-C-3】システムアーキテクチャ構築の実践手法
【18-C-3】システムアーキテクチャ構築の実践手法
Developers Summit
サービス開発における工程
サービス開発における工程
Hidetoshi Mori
Application Development Oveview
Application Development Oveview
Shinya Yanagihara
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
Hironori Washizaki
設計品質とアーキテクチャ
設計品質とアーキテクチャ
Toru Koido
Similaire à なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
(20)
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
ITサービス運営におけるアーキテクチャ設計 - 要求開発アライアンス 4月定例会
第5回SIA研究会(例会)プレゼン資料
第5回SIA研究会(例会)プレゼン資料
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Information20120312
Information20120312
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
メトリクスによるソフトウェア品質評価・改善および製品品質実態
メトリクスによるソフトウェア品質評価・改善および製品品質実態
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age and casual astah models
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
【18-C-3】システムアーキテクチャ構築の実践手法
【18-C-3】システムアーキテクチャ構築の実践手法
サービス開発における工程
サービス開発における工程
Application Development Oveview
Application Development Oveview
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
設計品質とアーキテクチャ
設計品質とアーキテクチャ
Plus 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
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
Yusuke Suzuki
エナジャイル設立によせて
エナジャイル設立によせて
Yusuke Suzuki
Plus 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講座
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
エナジャイル設立によせて
エナジャイル設立によせて
Dernier
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
WSO2
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
Toru Tamaki
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
atsushi061452
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
sn679259
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Toru Tamaki
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
Dernier
(10)
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
1.
【18-C-1】 なぜソフトウェアアーキテクトが 必要なのか ~未知なるソフトウェアに形を与えよ~
グロースエクスパートナーズ株式会社 事業推進本部 本部長 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.
宣伝 • 「アーキテクチャとクラウド~情報によ
る空間の変容」 – 建築家とソフトウェアアーキテクトの対談と してイベントを実施 – トゥギャっていただきました • http://togetter.com/li/102207 翔泳社ブースで 売ってます
5.
本講演の目的 • アーキテクチャについて理解を深める • プロジェクトマネジメントにおけるアー
キテクチャ設計の役割について理解する • ソフトウェアアーキテクトの役割につい て理解する • ユーザーとの協業について理解する
6.
アジェンダ •
アーキテクチャとは • マネジメントとアーキテクチャ • ユーザーとアーキテクト • まとめ
7.
アーキテクチャとは
• ソフトウェアとは何か • アーキテクチャとは何か http://www.flickr.com/photos/left-hand/3510633193/
8.
ソフトウェアとは何か
影響を与える 利用時の 利用時の プロセス 内部 外部 利用時 品質 品質 行動 構造 振る舞い 依存する JISX0129-1 ソフトウェア製品の品質 第1部 品質モデル
9.
ソフトウェアとは何か
特徴 例 利用時の品質 ・利用状況によって評価が異な ・ユーザーAさんと る ユーザーBさんで評価 が異なる 外部品質 ・システムの振る舞い ・テストケース ・誰がテストしても同じ結果 ・外部仕様 ・一般的な仕様策定の対象 内部品質 ・システムを構成している要素 ・クラス図 すべて(含ドキュメント) ・フレームワーク ・後に残り、評価が可能 ・ドキュメント ・エンジニアがこだわるところ プロセス品質 ・後に残らない ・コミュニケーション ・
10.
ソフトウェアとは何か
プログラマの視点 利用時の 利用時の コーデ インス クラス 品質 ユーザー 品質 ィング タンス 行動 構造 振る舞い テスト ユニットテスト 自動テスト
11.
アーキテクチャとは何か • システムの基盤であり、コンポーネント
群、コンポーネント間の相互関係と環境 との関係、設計と改良を管理する原則に より構成される IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems(アーキテクチャ記述の推奨プラクティス)
12.
アーキテクチャとは何か • 基本は分割と統合 –
全体をどのように分けて、分けた部分をどの ように関係づけるか これ? 利用時の 利用時の 振る プロセス 構造 利用 品質 品質 舞い NO。それはストラクチャー
13.
アーキテクチャとは何か
IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems(アーキテクチャ記述の推奨プラクティス)
14.
アーキテクチャとは何か
ミッション システム 制約(環境) ビュー モデルによって記述 利害関係者の 関心事 ビューポイント
15.
アーキテクチャとは何か • アーキテクチャとは –
システムのミッションに従い、システムのお かれた制約を前提としながら – システムに関わる複数の利害関係者の関心事 を整合させ、 • 経営者、オーナー、ユーザー、プログラマ、 DBA、 インフラ屋、PM、上司 – ライフサイクル(設計から保守)まで意識し た – システムの分け方と組合せ方のこと
16.
アーキテクチャとは何か
利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 事前的な“つなぎ方”がアーキテクチャ
17.
マジメントとアーキテクチャ • マネジメントとは何か • PMとアーキテクチャ
http://www.flickr.com/photos/drift-words/10434156/
18.
Good managers do the
things right Good leadership does the right thing
19.
マネジメントとは何か • マネージャーは「物事を正しくする」 –
目標と目的、 どうやって?いつ?、組織と構 造、リスク回避 … – 現実、複雑さへの対応、成功、教育 • リーダーシップは「正しい事をする」 – ビジョン、何を?なぜ?、チャレンジ、イノ ベーション、リスクは機会… – 変革、未来、変化、進歩、現状への不満
20.
マネジメントとは何か • PMBOK(A
Guide to the Project Management Body of Knowledge) 立ち上げ 計画 実行 管理 終結 統合 計画策定 計画実行 統合変更管理 スコープ 立ち上げ スコープ計画/定義 スコープ検証/変更管理 (目的と範囲) 時間(期間) アクティビティ定義/順序設 スケジュールコントロール 定/期間見積 スケジュール作成 コスト(予算) 資源管理 コストコントロール コストの見積/予算化 品質 人的資源 品質計画 組織計画 計画 実行 品質保証 チーム育成 品質管理 調整 要員調達 コミュニケー コミュニケーション計画 情報配布 実行報告 完了手続き ション リスク リスク・マネジメント計画 リスクの監視・コントロー リスク識別 ル 定性的/定量的リスク分析 調達 調達/引合計画 引合 契約完了 発注先選定 契約管理
21.
なぜPMは記事になるの?
「危機を救うヒーローだから」 そもそも危機になるのがいけないんじゃ… http://www.flickr.com/photos/hobby_blog/2162966860/
22.
将来について分かっていることはただひとつ、 現在と同じではないだろう、という点だけだ。
「マネジメント 努め、責任、実践 Ⅰ」 P132 ピーター々ドラッカー 正しい計画を立てることができるのか? http://www.flickr.com/photos/garyhayes/305475097/
23.
「運転で大切なのは〃車を正しい方向に進 めることじゃないのよ〄大切 なのは〃常
に注意を払って細かく左右に方向修正し ていくことなの〄」 XPエクストリーム々プログラミング入門 ケント々ベック http://www.flickr.com/photos/jontintinjordan/420270797/
24.
PMとアーキテクチャ • アジャイルマネジメント –
「変化ヲ抱擁セヨ」 • 基本手法 – イテレーティブなタイムボックス管理 • 完成していなくても棚卸しをして評価する – リスク主導 • 不確定な部分から手を付ける。プロトタイピング、 継続的統合 ズレを許容しながら、 正しさを探索するテクニック
25.
PMとアーキテクチャ • アジャイルを機能させるには –
機能の分割と実施順がそれなりに正しい – 不確定な部分をうまく取り出す • 全体の計画は正しくなくても良いが、正 しさを見つけるプロセスはきちんと決め る必要がある
26.
PMとアーキテクチャ • プロセスを決めるには要求まで遡る必要
がある プロセス 構造 作りたいもの 要求 この絵、どこかで見ましたよね
27.
PMとアーキテクチャ • アジャイルはアーキテクチャ設計を内包
している – というか、すべてのマネジメントはアーキテ クチャ設計を前提とする 実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 計画 アーキテクチャ設計
28.
未知への変化が大きければ大きいほど、 飛躍のための土台を確かなものにしておく 必要がある。
「マネジメント 努め、責任、実践 Ⅰ」 P132 ピーター々ドラッカー http://www.flickr.com/photos/chausinho/3104627075/
29.
PMとアーキテクチャ
• トヨタの新車開発マネジメント – 1人のチーフアーキテクト – 過去のデータを参考にしながら、3万点の部 品個別で見積もりとレビューを行なう • 前回と違うところはリスクをみて計画を行なう – これが可能なのは車の基本構造が変わってい ないから http://www.flickr.com/photos/toyotauk/5117989415/ http://www.flickr.com/photos/dok1/3909484847/
30.
PMとアーキテクチャ
実行と調整 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い 計画 アーキテクチャ設計 アーキテクチャが安定するなら マネジメントも安定する
31.
ソフトウェア開発の アーキテクチャは安定している?
32.
PMとアーキテクチャ • ソフトウェア開発では、 –
同じアーキテクチャを使い回すほうが正しく 見積もれる – しかし、現在のソフトウェア開発では新しい アーキテクチャによる効率化が、繰り返しの 効率化を上回ることがある • アーキテクチャを変えることが多い – 変えない場合はアーキテクチャが安定するの でマネジメント主導(ウォーターフォール型 での効率化)でよい。パッケージ導入など
33.
PMとアーキテクチャ • マネジメントとアーキテクチャ設計 –
変化を許容するためには土台としてのアーキ テクチャが重要 – ところがソフトウェア開発ではプロジェクト 毎にアーキテクチャが変わってしまう – そこで、プロジェクト毎にアーキテクチャを 設計し、それによってプロセスや構造の分割 と統合を行なう必要がある ソフトウェアアーキテクチャ設計の プロが必要になる
34.
PMとアーキテクチャ • ソフトウェアアーキテクトはアーキテク
チャ設計を通じてマネジメントの土台を 提供する • ソフトウェアアーキテクトがいないと計 画を立てられない=何をマネジメントし ていいかが分からない – 「『正しさ』を見つけるための方法」を見つ ける – リーダーシップ的な素養
35.
PMとアーキテクチャ • アーキテクトとマネジメントは職能が違
う – マネージャーは「物事を正しくする」 • 目標と目的、 どうやって?いつ?、組織と構造、 リスク回避 … • 現実、複雑さへの対応、成功、教育 – リーダーシップは「正しい事をする」 • ビジョン、何を?なぜ?、チャレンジ、イノベー ション、リスクは機会… • 変革、未来、変化、進歩、現状への不満 アーキテクトは父、マネージャーは母
36.
ユーザーとアーキテクト
http://www.flickr.com/photos/pgoyette/2819175465/
37.
ユーザーとアーキテクト • ユーザーとビルダーの間には越えがたい
壁がある – アーキテクチャがビューポイントを基本にし ているとはいえ、ユーザーのビューポイント を取り込むのは難しい 越えられない壁 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い
38.
ユーザーとアーキテクト • 外圧と内圧モデル
外圧 内圧 使うコト 作るコト ビジョン/要求/要件 戦術/設計/実装
39.
ユーザーとアーキテクト • 外圧と内圧モデル
つなぐコト アーキテクチャ/戦略/バランス 外圧 内圧 使うコト 作るコト ビジョン/要求/要件 戦術/設計/実装
40.
ユーザーとアーキテクト • 使うコトと作るコトをつなぐ手法 –
アーキテクチャ設計ではDDD • ドメインエキスパートとドメインモデル – マネジメントでは「スクラム」 • プロダクトオーナーとスクラムマスター スクラム 利用時の 利用時の プロ 振る 構造 ユーザー 品質 品質 セス 舞い DDD
41.
ユーザーとアーキテクト • つまりスクラムやDDDは「ユーザーとビ
ルダーの関心事をリンクさせる」枠組み – これはまさにプロジェクトの”アーキテク チャ”と呼べる • アーキテクトがプロジェクトのあり方す ら決めていくのではないか – 少なくともアーキテクト的発想が重要 – プロジェクトアーキテクトという職種が生ま れる?(もう生まれている?)
42.
まとめ • アーキテクチャは「分割と統合」 • プロジェクトマネジメントにアーキテク
チャ設計が含まれる – 変化をするためには安定した土台が必要 – ソフトウェア開発では毎回アーキテクチャ設 計をする必要がある • アーキテクトはアーキテクチャ設計を通 じてマネジメントの土台を提供する • アーキテクトは父、マネージャーは母
43.
まとめ • ユーザーとアーキテクト –
DDDやスクラムによってユーザーをビルダー をつないでいく – プロジェクトアーキテクト – アーキテクト的発想力(関係者の関心事をリ ンクさせる力)が重要になっていく
44.
宣伝 • Qcon Tokyo
2011 – http://qcontokyo.com/ – Eric Evans氏(Domain-Driven Design著 者)と和智氏(和訳者)とのパネルディス カッションでモデレータをやります
45.
【18-C-1】 なぜソフトウェアアーキテクトが 必要なのか ~未知なるソフトウェアに形を与えよ~
グロースエクスパートナーズ株式会社 事業推進本部 本部長 JJUG/JSUG 鈴木雄介
Télécharger maintenant