Submit Search
Upload
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
•
22 likes
•
6,097 views
Yusuke Suzuki
Follow
デブサミ2011での講演内容です。
Read less
Read more
Technology
Business
Report
Share
Report
Share
1 of 45
Download now
Download to read offline
Recommended
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
Mizuki Tanno
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Yusuke Suzuki
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
kumiko koshiro
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
Recommended
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
プロダクトマネージャーにたちはだかる壁を、どう乗り越えるか
Mizuki Tanno
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について-DevLOVE関西 #DevKan
Yusuke Suzuki
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
kumiko koshiro
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
DX時代のITエンジニアに送る、アジャイル式「いきいき」ヘルスマネジメント
DX時代のITエンジニアに送る、アジャイル式「いきいき」ヘルスマネジメント
Takeshi Kakeda
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
Mharu
Lean coffee
Lean coffee
Takeshi Arai
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
もしプロダクトマネージャー・プロダクトチームにUXリサーチのメンターがついたら
もしプロダクトマネージャー・プロダクトチームにUXリサーチのメンターがついたら
Yoshiki Hayama
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
Yusuke Suzuki
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Yoshiki Hayama
【人事向け勉強会(1.19)】Retty社 奥田様 ご登壇スライド
【人事向け勉強会(1.19)】Retty社 奥田様 ご登壇スライド
Poole Team
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
User storymapping in 10 minutes
User storymapping in 10 minutes
Yasunobu Kawaguchi
ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
Yoshiki Hayama
成功と失敗に学ぶアジャイル受託開発の極意
成功と失敗に学ぶアジャイル受託開発の極意
Yukio Okajima
人生で大事なことは XP白本と参考文献に教わった
人生で大事なことは XP白本と参考文献に教わった
Takeshi Kakeda
UXデザインの理論・プロセス・手法の体系とポイント
UXデザインの理論・プロセス・手法の体系とポイント
Masaya Ando
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
UXデザイン・UXリサーチってだいぶ広まったよね?
UXデザイン・UXリサーチってだいぶ広まったよね?
Yoshiki Hayama
ユーザーインタビューからその後どうするの?得られた情報を「UXデザイン」に落とし込む方法 | UXデザイン基礎セミナー 第3回
ユーザーインタビューからその後どうするの?得られた情報を「UXデザイン」に落とし込む方法 | UXデザイン基礎セミナー 第3回
Yoshiki Hayama
Hadoop入門とクラウド利用
Hadoop入門とクラウド利用
Naoki Yanai
VSUG DAY 2012 winter Architect Academy
VSUG DAY 2012 winter Architect Academy
Yusuke Suzuki
More Related Content
What's hot
DX時代のITエンジニアに送る、アジャイル式「いきいき」ヘルスマネジメント
DX時代のITエンジニアに送る、アジャイル式「いきいき」ヘルスマネジメント
Takeshi Kakeda
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
Mharu
Lean coffee
Lean coffee
Takeshi Arai
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
もしプロダクトマネージャー・プロダクトチームにUXリサーチのメンターがついたら
もしプロダクトマネージャー・プロダクトチームにUXリサーチのメンターがついたら
Yoshiki Hayama
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
Yusuke Suzuki
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Yoshiki Hayama
【人事向け勉強会(1.19)】Retty社 奥田様 ご登壇スライド
【人事向け勉強会(1.19)】Retty社 奥田様 ご登壇スライド
Poole Team
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
User storymapping in 10 minutes
User storymapping in 10 minutes
Yasunobu Kawaguchi
ユーザーストーリーの分割
ユーザーストーリーの分割
Arata Fujimura
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
Yoshiki Hayama
成功と失敗に学ぶアジャイル受託開発の極意
成功と失敗に学ぶアジャイル受託開発の極意
Yukio Okajima
人生で大事なことは XP白本と参考文献に教わった
人生で大事なことは XP白本と参考文献に教わった
Takeshi Kakeda
UXデザインの理論・プロセス・手法の体系とポイント
UXデザインの理論・プロセス・手法の体系とポイント
Masaya Ando
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
UXデザイン・UXリサーチってだいぶ広まったよね?
UXデザイン・UXリサーチってだいぶ広まったよね?
Yoshiki Hayama
ユーザーインタビューからその後どうするの?得られた情報を「UXデザイン」に落とし込む方法 | UXデザイン基礎セミナー 第3回
ユーザーインタビューからその後どうするの?得られた情報を「UXデザイン」に落とし込む方法 | UXデザイン基礎セミナー 第3回
Yoshiki Hayama
What's hot
(20)
DX時代のITエンジニアに送る、アジャイル式「いきいき」ヘルスマネジメント
DX時代のITエンジニアに送る、アジャイル式「いきいき」ヘルスマネジメント
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
プロジェクトマネジメントは仕組み化が9割
プロジェクトマネジメントは仕組み化が9割
Lean coffee
Lean coffee
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
もしプロダクトマネージャー・プロダクトチームにUXリサーチのメンターがついたら
もしプロダクトマネージャー・プロダクトチームにUXリサーチのメンターがついたら
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
【人事向け勉強会(1.19)】Retty社 奥田様 ご登壇スライド
【人事向け勉強会(1.19)】Retty社 奥田様 ご登壇スライド
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
User storymapping in 10 minutes
User storymapping in 10 minutes
ユーザーストーリーの分割
ユーザーストーリーの分割
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
“UXデザイン”のキモ『ユーザーインタビュー』の具体的テクニックを詳解!| UXデザイン基礎セミナー 第2回
成功と失敗に学ぶアジャイル受託開発の極意
成功と失敗に学ぶアジャイル受託開発の極意
人生で大事なことは XP白本と参考文献に教わった
人生で大事なことは XP白本と参考文献に教わった
UXデザインの理論・プロセス・手法の体系とポイント
UXデザインの理論・プロセス・手法の体系とポイント
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
UXデザイン・UXリサーチってだいぶ広まったよね?
UXデザイン・UXリサーチってだいぶ広まったよね?
ユーザーインタビューからその後どうするの?得られた情報を「UXデザイン」に落とし込む方法 | UXデザイン基礎セミナー 第3回
ユーザーインタビューからその後どうするの?得られた情報を「UXデザイン」に落とし込む方法 | UXデザイン基礎セミナー 第3回
Viewers also liked
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
Viewers also liked
(12)
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
Similar to なぜソフトウェアアーキテクトが必要なのか - デブサミ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
Similar to なぜソフトウェアアーキテクトが必要なのか - デブサミ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法のワークショップ-
設計品質とアーキテクチャ
設計品質とアーキテクチャ
More from Yusuke Suzuki
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
Yusuke Suzuki
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
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
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
Yusuke Suzuki
More from Yusuke Suzuki
(20)
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
マイクロサービスに至る歴史とこれから - 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について
エナジャイル設立によせて
エナジャイル設立によせて
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
Recently uploaded
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Recently uploaded
(7)
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
なぜソフトウェアアーキテクトが必要なのか - デブサミ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 鈴木雄介
Download now