Submit Search
Upload
Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス
•
12 likes
•
3,833 views
SORACOM, INC
Follow
Developer Summit 2010 【19-B-2】 Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス
Read less
Read more
Technology
Slideshow view
Report
Share
Slideshow view
Report
Share
1 of 65
Download now
Download to read offline
Recommended
Jenkins使ってみた~Windows編~
Jenkins使ってみた~Windows編~
Yuta Matsumura
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
【Unite Tokyo 2018】なんとっ!ユナイト!ミリシタをささえる『AKANE大作戦』とは?
【Unite Tokyo 2018】なんとっ!ユナイト!ミリシタをささえる『AKANE大作戦』とは?
UnityTechnologiesJapan002
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
Hironori Washizaki
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方
Shigenori Sagawa
WkWebViewのキャッシュについて調べた
WkWebViewのキャッシュについて調べた
firewood
Recommended
Jenkins使ってみた~Windows編~
Jenkins使ってみた~Windows編~
Yuta Matsumura
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
【Unite Tokyo 2018】なんとっ!ユナイト!ミリシタをささえる『AKANE大作戦』とは?
【Unite Tokyo 2018】なんとっ!ユナイト!ミリシタをささえる『AKANE大作戦』とは?
UnityTechnologiesJapan002
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
Hironori Washizaki
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方
Shigenori Sagawa
WkWebViewのキャッシュについて調べた
WkWebViewのキャッシュについて調べた
firewood
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動によるシステムテストの自動化について 2015
Toru Koido
探索的テスト入門
探索的テスト入門
H Iseri
アプリ開発へのOdc分析導入の取り組み
アプリ開発へのOdc分析導入の取り組み
NaokiKashiwagura
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
SEGADevTech
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
John Allspaw
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
コールバックと戦う話
コールバックと戦う話
torisoup
【Unite Tokyo 2018 Training Day】C#JobSystem & ECSでCPUを極限まで使い倒そう ~C# JobSystem 編~
【Unite Tokyo 2018 Training Day】C#JobSystem & ECSでCPUを極限まで使い倒そう ~C# JobSystem 編~
Unity Technologies Japan K.K.
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
SEGADevTech
インタフェース完全に理解した
インタフェース完全に理解した
torisoup
DevOps Overview
DevOps Overview
IIJ
そのスプリントレビューは、機能してますか? #agile_hiyoko
そのスプリントレビューは、機能してますか? #agile_hiyoko
Miho Nagase
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
Itsuki Kuroda
ゼロ幅スペースという悪夢
ゼロ幅スペースという悪夢
swamp Sawa
Unityでパフォーマンスの良いUIを作る為のTips
Unityでパフォーマンスの良いUIを作る為のTips
Unity Technologies Japan K.K.
初学者のためのプロンプトエンジニアリング実践.pptx
初学者のためのプロンプトエンジニアリング実践.pptx
Akifumi Niida
AJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasensei
Akiko Kosaka
アジャイル基礎再考
アジャイル基礎再考
Kanu orz
More Related Content
What's hot
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動によるシステムテストの自動化について 2015
Toru Koido
探索的テスト入門
探索的テスト入門
H Iseri
アプリ開発へのOdc分析導入の取り組み
アプリ開発へのOdc分析導入の取り組み
NaokiKashiwagura
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
SEGADevTech
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
John Allspaw
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
コールバックと戦う話
コールバックと戦う話
torisoup
【Unite Tokyo 2018 Training Day】C#JobSystem & ECSでCPUを極限まで使い倒そう ~C# JobSystem 編~
【Unite Tokyo 2018 Training Day】C#JobSystem & ECSでCPUを極限まで使い倒そう ~C# JobSystem 編~
Unity Technologies Japan K.K.
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
SEGADevTech
インタフェース完全に理解した
インタフェース完全に理解した
torisoup
DevOps Overview
DevOps Overview
IIJ
そのスプリントレビューは、機能してますか? #agile_hiyoko
そのスプリントレビューは、機能してますか? #agile_hiyoko
Miho Nagase
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
Itsuki Kuroda
ゼロ幅スペースという悪夢
ゼロ幅スペースという悪夢
swamp Sawa
Unityでパフォーマンスの良いUIを作る為のTips
Unityでパフォーマンスの良いUIを作る為のTips
Unity Technologies Japan K.K.
初学者のためのプロンプトエンジニアリング実践.pptx
初学者のためのプロンプトエンジニアリング実践.pptx
Akifumi Niida
What's hot
(20)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動によるシステムテストの自動化について 2015
探索的テスト入門
探索的テスト入門
アプリ開発へのOdc分析導入の取り組み
アプリ開発へのOdc分析導入の取り組み
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
コールバックと戦う話
コールバックと戦う話
【Unite Tokyo 2018 Training Day】C#JobSystem & ECSでCPUを極限まで使い倒そう ~C# JobSystem 編~
【Unite Tokyo 2018 Training Day】C#JobSystem & ECSでCPUを極限まで使い倒そう ~C# JobSystem 編~
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
開発もQAも自動テスト!「LOST JUDGMENT:裁かれざる記憶」のQAテスター参加で進化した「テスト自動化チーム(仮)」の取り組みについて
インタフェース完全に理解した
インタフェース完全に理解した
DevOps Overview
DevOps Overview
そのスプリントレビューは、機能してますか? #agile_hiyoko
そのスプリントレビューは、機能してますか? #agile_hiyoko
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
ゼロ幅スペースという悪夢
ゼロ幅スペースという悪夢
Unityでパフォーマンスの良いUIを作る為のTips
Unityでパフォーマンスの良いUIを作る為のTips
初学者のためのプロンプトエンジニアリング実践.pptx
初学者のためのプロンプトエンジニアリング実践.pptx
Similar to Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス
AJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasensei
Akiko Kosaka
アジャイル基礎再考
アジャイル基礎再考
Kanu orz
Vantan shinsuke miyaki_upload
Vantan shinsuke miyaki_upload
Shinsuke Miyaki
でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料
Tomohiro Fujii
テスト駆動開発の進化
テスト駆動開発の進化
Yukei Wachi
タイムボックス制約付きインクリメンタル開発
タイムボックス制約付きインクリメンタル開発
HIDEKAZU MATSUURA
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
Ken Azuma
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
Unicast Inc.
[G-Tech2014講演資料] 汎用プラクティスとしてのアジャイル開発 - グローバルナレッジ
[G-Tech2014講演資料] 汎用プラクティスとしてのアジャイル開発 - グローバルナレッジ
Trainocate Japan, Ltd.
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
Developers Summit
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
Ken Azuma
デブサミ2010 これからのアーキテクチャを見通す
デブサミ2010 これからのアーキテクチャを見通す
Yusuke Suzuki
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
Daisuke Nishino
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
masashi takehara
To be sn agile enterprise
To be sn agile enterprise
Rakuten Group, Inc.
ソフトウェア開発の現場風景
ソフトウェア開発の現場風景
Koichi ITO
X dev 20121106
X dev 20121106
Ken Azuma
Xp Terakoya No02
Xp Terakoya No02
takepu
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
Yusuke Suzuki
Information20120312
Information20120312
b-slash
Similar to Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス
(20)
AJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasensei
アジャイル基礎再考
アジャイル基礎再考
Vantan shinsuke miyaki_upload
Vantan shinsuke miyaki_upload
でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料
テスト駆動開発の進化
テスト駆動開発の進化
タイムボックス制約付きインクリメンタル開発
タイムボックス制約付きインクリメンタル開発
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
ウォーターフォールとアジャイル開発の比較
ウォーターフォールとアジャイル開発の比較
[G-Tech2014講演資料] 汎用プラクティスとしてのアジャイル開発 - グローバルナレッジ
[G-Tech2014講演資料] 汎用プラクティスとしてのアジャイル開発 - グローバルナレッジ
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
デブサミ2010 これからのアーキテクチャを見通す
デブサミ2010 これからのアーキテクチャを見通す
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
To be sn agile enterprise
To be sn agile enterprise
ソフトウェア開発の現場風景
ソフトウェア開発の現場風景
X dev 20121106
X dev 20121106
Xp Terakoya No02
Xp Terakoya No02
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
Information20120312
Information20120312
More from SORACOM, INC
IoT通信プラットフォーム SORACOM 説明資料
IoT通信プラットフォーム SORACOM 説明資料
SORACOM, INC
20140608 interlop keynote
20140608 interlop keynote
SORACOM, INC
AWS Cloud Design Pattenr (Korean) - CDP Seminar in Korea
AWS Cloud Design Pattenr (Korean) - CDP Seminar in Korea
SORACOM, INC
クラウドがもたらす破壊と創造 = Developer Summit 2014 =
クラウドがもたらす破壊と創造 = Developer Summit 2014 =
SORACOM, INC
CDP2.0 - cloudpack night #7 -
CDP2.0 - cloudpack night #7 -
SORACOM, INC
AWSクラウドデザインパターン - JEITA講演 -
AWSクラウドデザインパターン - JEITA講演 -
SORACOM, INC
いまさら聞けないAWSクラウド - Java Festa 2013
いまさら聞けないAWSクラウド - Java Festa 2013
SORACOM, INC
Kansumi2013 tamagawa
Kansumi2013 tamagawa
SORACOM, INC
Aws gameday tokyo_2013
Aws gameday tokyo_2013
SORACOM, INC
クラウドTCOの真実
クラウドTCOの真実
SORACOM, INC
AWSクラウドデザインパターン(CDP) - Eコマース編 -
AWSクラウドデザインパターン(CDP) - Eコマース編 -
SORACOM, INC
AWSクラウドデザインパターン(CDP) - 概要編 -
AWSクラウドデザインパターン(CDP) - 概要編 -
SORACOM, INC
Amazon DynamoDBの概要説明
Amazon DynamoDBの概要説明
SORACOM, INC
AWSアップデート 2月14日JAWS札幌
AWSアップデート 2月14日JAWS札幌
SORACOM, INC
AWS Storage Gateway 詳細 - AWSマイスターシリーズ
AWS Storage Gateway 詳細 - AWSマイスターシリーズ
SORACOM, INC
AWS Direct Connect 詳細 - AWSマイスターシリーズ Reloaded
AWS Direct Connect 詳細 - AWSマイスターシリーズ Reloaded
SORACOM, INC
はじめてのAWS - ビギナー編 -
はじめてのAWS - ビギナー編 -
SORACOM, INC
SimpleDB, SQS, SNS詳細 - AWSマイスターシリーズ
SimpleDB, SQS, SNS詳細 - AWSマイスターシリーズ
SORACOM, INC
JAWS-UG北陸第2回 AWSクラウド最新アップデート
JAWS-UG北陸第2回 AWSクラウド最新アップデート
SORACOM, INC
Amazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズ
SORACOM, INC
More from SORACOM, INC
(20)
IoT通信プラットフォーム SORACOM 説明資料
IoT通信プラットフォーム SORACOM 説明資料
20140608 interlop keynote
20140608 interlop keynote
AWS Cloud Design Pattenr (Korean) - CDP Seminar in Korea
AWS Cloud Design Pattenr (Korean) - CDP Seminar in Korea
クラウドがもたらす破壊と創造 = Developer Summit 2014 =
クラウドがもたらす破壊と創造 = Developer Summit 2014 =
CDP2.0 - cloudpack night #7 -
CDP2.0 - cloudpack night #7 -
AWSクラウドデザインパターン - JEITA講演 -
AWSクラウドデザインパターン - JEITA講演 -
いまさら聞けないAWSクラウド - Java Festa 2013
いまさら聞けないAWSクラウド - Java Festa 2013
Kansumi2013 tamagawa
Kansumi2013 tamagawa
Aws gameday tokyo_2013
Aws gameday tokyo_2013
クラウドTCOの真実
クラウドTCOの真実
AWSクラウドデザインパターン(CDP) - Eコマース編 -
AWSクラウドデザインパターン(CDP) - Eコマース編 -
AWSクラウドデザインパターン(CDP) - 概要編 -
AWSクラウドデザインパターン(CDP) - 概要編 -
Amazon DynamoDBの概要説明
Amazon DynamoDBの概要説明
AWSアップデート 2月14日JAWS札幌
AWSアップデート 2月14日JAWS札幌
AWS Storage Gateway 詳細 - AWSマイスターシリーズ
AWS Storage Gateway 詳細 - AWSマイスターシリーズ
AWS Direct Connect 詳細 - AWSマイスターシリーズ Reloaded
AWS Direct Connect 詳細 - AWSマイスターシリーズ Reloaded
はじめてのAWS - ビギナー編 -
はじめてのAWS - ビギナー編 -
SimpleDB, SQS, SNS詳細 - AWSマイスターシリーズ
SimpleDB, SQS, SNS詳細 - AWSマイスターシリーズ
JAWS-UG北陸第2回 AWSクラウド最新アップデート
JAWS-UG北陸第2回 AWSクラウド最新アップデート
Amazon ElastiCache - AWSマイスターシリーズ
Amazon ElastiCache - AWSマイスターシリーズ
Recently uploaded
【AI論文解説】Consistency ModelとRectified Flow
【AI論文解説】Consistency ModelとRectified Flow
Sony - Neural Network Libraries
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
ssuserbefd24
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
CRI Japan, Inc.
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
NTT DATA Technology & Innovation
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
atsushi061452
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
atsushi061452
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
keikoitakurag
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
yassun7010
20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf
Ayachika Kitazaki
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
iPride Co., Ltd.
Recently uploaded
(10)
【AI論文解説】Consistency ModelとRectified Flow
【AI論文解説】Consistency ModelとRectified Flow
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス
1.
Agility@Scale (ゕジャル開発のスケールゕップ) を実現する14のベストプラクテゖス 19-B-2
玉川 憲 (twitter.com/KenTamagawa) 日本ゕ・ビー・エム株式会社 Rational事業部テクニカルセールス部長 IBMソフトウェゕエバンジェリスト Developers Summit 2010
2.
なぜ今、アジリティが求められる? 経営戦略の寿命が短期化
世界売上高ランキング上位50社の平均滞留年 数4.8年 →ピーク迄は2年半 競争力を持続させていくには下記が求められる 商品・サービスの市場・顧客ニーズ変化への 俊敏な対応 業務提携による新規ビジネスの早期実現 経営統合によるシナジー効果の早期実現 出典:ITゕーキテクトVol.12 2007 Developers Summit 2010 2
3.
アジャイル導入の効果は魅力的
ゕジャル導入により、改善されたと答えている人の割合 生産性 品質 82% 87% 顧客 満足度 コスト 78% 72% Source: Dr Dobb’s 2008 Agile Adoption Survey Developers Summit 2010 3
4.
IBMソフトウェアグループでの 開発手法の変遷
ウォーターフォール 1980年代 • 要求の変更が少ない市場 • 最初に要求を決めて厳密な方法で開発 • 多くのメンフレームソフトウエゕ 反復型開発 1990年代 • 要求の変化が起こる市場 • 反復型開発でリスクを逓減 • 90年~2000年前半での 分散プラットフォームでの開発 ゕジャル開発 現在 • 要求の変化が非常に大きい市場 • 適応型開発で市場に迅速に反応 • Webゕプリケーション、 オープンソースの開発、Jazz Developers Summit 2010 4
5.
米国でのアジャイル普及度
1つ以上のゕジャルの技法を使っていますか? 18% of respondents indicated they’re still in the pilot stage 15% of “No” respondents hope to do Agile this year Source: Dr Dobb’s 2008 Agile Adoption Survey Developers Summit 2010 5
6.
本日のアジェンダ
ゕジャル開発の本質 ゕジャル開発を企業に導入する際の課題 規模に関係なく適用可能なプラクテゖス 大規模だからこそ考えるプラクテゖス まとめ Developers Summit 2010 6
7.
アジャイル開発手法の共通点は、確 かにある 各ゕジャル方法論には、確かに違いがあるが
基本的なベストプラクテゖスには共通点がある 反復&インクリメンタル&適応型の開発 短いタイムボックス内で動くコード 小さな一口単位で開発 Developers Summit 2010 7
8.
アジャイル開発の共通ポイント1: 反復&インクリメンタル&適応型 ウォーターフォール
要求(スコープ) 要求 分析・設計 実装 テスト 時間 Royce 1970 Developers Summit 2010 8
9.
要求は劣化していく 出展:「ゕジャル開発の本質とスケールゕップ」
Developers Summit 2010 9
10.
アジャイル開発の共通ポイント1: 反復&インクリメンタル&適応型 ウォーターフォール
アジャイル 要求(スコープ) 要求(スコープ) 要求 分析・設計 実装 テスト 時間 時間 Royce 1970 Beck 2000 Developers Summit 2010 10
11.
アジャイル開発の共通ポイント1: 反復&インクリメンタル&適応型 ウォーターフォール
アジャイル 要求(スコープ) 要求(スコープ) 要求 分析・設計 実装 テスト 時間 時間 Royce 1970 Beck 2000 Developers Summit 2010 11
12.
アジャイル開発の共通ポイント1: 反復&インクリメンタル&適応型 ウォーターフォール
アジャイル 要求(スコープ) 要求(スコープ) 要求 分析・設計 実装 テスト 時間 時間 Royce 1970 Beck 2000 Developers Summit 2010 12
13.
アジャイル開発の共通ポイント1: 反復&インクリメンタル&適応型 ウォーターフォール
アジャイル 要求(スコープ) 要求(スコープ) 要求 分析・設計 実装 テスト 時間 時間 Royce 1970 Beck 2000 Developers Summit 2010 13
14.
アジャイル開発の共通ポイント1: 反復&インクリメンタル&適応型 ウォーターフォール
アジャイル 要求(スコープ) 要求(スコープ) 要求 ムダに詳細要 分析・設計 求を作らない 重要なもの から作る 実装 システム統合リス テスト クを初期に削減 時間 時間 早期にリリー Beck 2000 Royce 1970 フィードバックを得 ス可能に て学習・改善 Developers Summit 2010 14
15.
アジャイル開発の共通ポイント2: 短いタイムボックス内で動くコードを
ストーリー1 ストーリー2 構築 ストーリー3 ・・・ バックログ 評価 定義 テスト 出展:「ゕジャル開発の本質とスケールゕップ」 Developers Summit 2010 15
16.
アジャイル開発の共通ポイント2: 短いタイムボックス内で動くコードを
次を取り出し ストーリー1 OK ストーリー2 構築 ストーリー3 ・・・ バックログ 評価 定義 テスト NG すぐに修正 タムボックス 出展:「ゕジャル開発の本質とスケールゕップ」 Developers Summit 2010 16
17.
アジャイル開発の共通ポイント2: 短いタイムボックス内で動くコードを
次を取り出し ストーリー1 チームの中で、 OK テストまで全て ストーリー2 構築 ストーリー3 行う ・・・ バックログ 評価 バックログで優 定義 テスト 先順位を常に 決められた期間は NG 管理 絶対動かさない すぐに修正 受け入れテスト タムボックス をこの段階に 出展:「ゕジャル開発の本質とスケールゕップ」 Developers Summit 2010 17
18.
アジャイルの共通ポイント3: 小さな一口単位で開発する 仕事は、ストーリーとタスクに分ける
ストーリー ストーリー 「柔軟な」要求の表現 または、ある要求の話し合いの必要性を示したもの 実現すべき機能 タスク タスク タスク ストーリーを実装するために、メンバーが行うべき タスク こと ストーリーの粒度は数日、タスクの粒度は 一日以内 実施の直前に、この詳細に分解する 出展:「ゕジャル開発の本質とスケールゕップ」 Developers Summit 2010 18
19.
パラダイムシフト: スコープを、固定せずに管理する
ウォーターフォール ゕジャル 要求(スコープ) リソース 期日 固定される 価値 重視 計画 重視 見積もられる リソース 期日 要求(スコープ) 出展:「ゕジャル開発の本質とスケールゕップ」 Developers Summit 2010 19
20.
本日のアジェンダ
ゕジャル開発の本質 ゕジャル開発を企業に導入する際の課題 規模に関係なく適用可能なプラクテゖス 大規模だからこそ考えるプラクテゖス まとめ Developers Summit 2010 20
21.
なぜ、アジャイルは企業レベルでは 使えないと思われるのか? もともと小規模開発から発達してきたその経緯
確かに、著名なゕジャルプロセスであるXPは元は10人以下のチーム向き そもそも、小規模向き、ということで、企業で真剣に考慮されない ゕジャルプラクテゖスのうち、実質的に大規模開発に 不向きなものがある 例: 「同一地点での開発」、「顧客もチームの一部に」 既存の開発スタルに慣れている組織にとっては、大規模 であればあるほど「新しいもの」を導入することが難しい 例: 既存の縦割り組織形態、官僚的文化、契約体系、既存ゕセット Developers Summit 2010 21
22.
なぜ、アジャイルは企業レベルでは 使えないと思われるのか? もともと小規模開発から発達してきたその経緯
・方法論、技術、ツールが進化。大規模適用をサポート ・ゕジャルのメリットを活かせるところは追求すべき ゕジャルプラクテゖスのうち、実質的に大規模開発に 不向きなものがある 既存の開発スタルに慣れている組織にとっては、大規模 であればあるほど「新しいもの」を導入することが難しい Developers Summit 2010 22
23.
なぜ、アジャイルは企業レベルでは 使えないと思われるのか? もともと小規模開発から発達してきたその経緯 ゕジャルプラクテゖスのうち、実質的に大規模開発に
不向きなものがある ・多くのプラクテゖスがそのまま大規模開発でも適用できる ・不向きなプラクテゖスは工夫が必要! 既存の開発スタルに慣れている組織にとっては、大規模 であればあるほど「新しいもの」を導入することが難しい Developers Summit 2010 23
24.
大規模開発に不向きなプラクティス
小チームでの開発 企業レベルで百以上の数となる小チームを、どう組織と適合させるか 顧客をチームの一部に 多くの場合、顧客は離れているか、スキルや時間がない 同一場所での開発 規模が拡大すれば、同じ場所にいることは事実上不可能 ゕーキテクチャーは、自然発現する 規模の大きな開発では、事前にゕーキテクチャーの準備が必要 要求分析と仕様書の欠如 開発者がそのつど要求を引き出す考え方は、大規模開発では心もとな い 文化の環境、物理的環境 傍から見たゕジャルの仕事ぶりは、しばしばプロらしくなく見える 出展: Scaling Software Agility Developers Summit 2010 24
25.
なぜ、アジャイルは企業レベルでは 使えないと思われるのか? もともと小規模開発から発達してきたその経緯 ゕジャルプラクテゖスのうち、実質的に大規模開発に
不向きなものがある 既存の開発スタルに慣れている組織にとっては、大規模 であればあるほど「新しいもの」を導入することが難しい ・開発者の能力と生産性のために、変化は不可欠 企業そのものに内在する課題を乗り越えることが必要! Developers Summit 2010 25
26.
企業そのものに内在する課題
プロセスとプロジェクトマネジメント組織 プロジェクトマネジメント組織が、自らの権限/権威が少なくなる変化に抵抗する 既存の公式なポリシーと手続き 過去の苦い経験によって追加されてきたガドランは、変更が容易ではない 企業文化 企業は時間をかけて、「ゕジャルのためにならない」強力な文化を培ってきた 期日も機能も固定した上でなんとかやれ、という依頼 範囲と期日とリソースがあらかじめ決められて開発チームに命令されるならば、 ゕジャル開発は成立しない 開発部門とユーザー・顧客代理チームとの摩擦 開発チームとユーザー部門の間には、相互不信の原因となる苦い経験があること が多い 職制によって組織された人々 組織は、職制(製品マネジメント、ゕーキテクチャー、開発者など)で編成され ていることが多い 高度に分散した開発 企業が大きくなるほど、組織は分散化する 出展: Scaling Software Agility Developers Summit 2010 26
27.
本日のアジェンダ
ゕジャル開発の本質 ゕジャル開発を企業に導入する際の課題 規模に関係なく適用可能なプラクテゖス 大規模だからこそ考えるプラクテゖス まとめ Developers Summit 2010 27
28.
規模に関係なく適用できるプラクティス
定義・構築・テストのコンポーネント・チーム 2 レベル計画作りと追跡 反復型開発 頻繁な小規模リリース コンカレントテステゖング 継続的ンテグレーション 継続的な考察と適応 Developers Summit 2010 28
29.
事例:Jazzプロジェクトの 「チームコンサート」開発
Jazzプロジェクトは、2005年より7カ国以上、約120名体制 Jazzの最初の成果が、「Rationalチームコンサート(RTC)」 ゕジャルプラクテゖス (Scrum, XP) を利用 「チームコンサート」自身を用いて、Jazz系製品を開発 Winnipeg Lexington Ottawa Saint Nazaire Shanghai Toronto Beaverton Zurich Raleigh Tokyo Bangalore Developers Summit 2010 29
30.
Rationalチームコンサート(RTC)とは? プロジェクトの透明性を高めるために、Eclipse開発、
CC/CQ開発での経験をベースに、IBM Rationalが一から作 り直した製品 構成管理 ビルド管理 ビルド管理 構成管理 プロセス管理 障害管理 プロセス管理 開発者 開発者 Jazz サーバー 障害管理 チームコンサートを使用することで生産性を高める: ・情報の一元化、トレーサビリテゖの自動化、プロセス自動化 ・コミュニケーション&透明性を高め、早期にリスク対応がとれる ・レポーテゖングのための工数削減 ・ンフラコスト(ハードウェゕ、ソフトウェゕ)、管理コストの削減 Developers Summit 2010 30
31.
定義・構築・テストのコンポーネン ト・チーム 「定義・構築・テスト」のスキルを有したチームを核とし
て、チーム編成 RTCチームの場合 2段階のチーム構成 (PMC、コンポーネント) 各チームにプロセス(運営)を任せる、統括PMが一人 プロセス ワークアイテム ソース管理 4-10人x 20 PMC 約10人 Web UI 統合テスト Developers Summit 2010
32.
反復型開発、頻繁な小規模リリース
リリース ウォームアップ リリース計画 M1a M1 立ち上げ 安定化 安定化 計画 計画 開発 開発 4週間 4週間 マルストーン Developers Summit 2010 32
33.
反復型開発、頻繁な小規模リリース
リリース ウォームアップ リリース計画 M1a M1 … エンドゲーム 修正- 洗練化 立ち上げ テスト 安定化 安定化 安定化 テスト 計画 計画 開発 開発 開発 修正 計画 4週間 4週間 4週間 マルストーン Developers Summit 2010 33
34.
反復型開発、頻繁な小規模リリース
リリース ウォームアップ リリース計画 M1a M1 … エンドゲーム 修正- 洗練化 立ち上げ テスト 安定化 安定化 安定化 テスト 計画 計画 開発 開発 開発 修正 計画 4週間 4週間 4週間 要件定義 マルストーン Developers Summit 2010 34
35.
反復型開発、頻繁な小規模リリース
リリース ウォームアップ リリース計画 M1a M1 … エンドゲーム 修正- 洗練化 立ち上げ テスト 安定化 安定化 安定化 テスト 計画 計画 開発 開発 開発 修正 計画 4週間 4週間 4週間 要件定義 マルストーン リリース用のテ イテレーション毎の Jazz.netでダウ スト、ドキュメン テスト・デモ・ふりかえり ンロード可能に ト整備35 Developers Summit 2010 35
36.
2レベル計画づくりと追跡 アジャイルでは、粗いリリース計画と、詳細な反復計画を
用いて、計画づくりとトラッキングを行う RTCチームの場合 テーマ 5-10 リリース計画 プランアイテム プランアイテム プランアイテム (PMC) 40-50 ストーリー ストーリー ストーリー 反復計画 タスク (チーム毎) タスク Developers Summit 2010 36
37.
2レベル計画づくりと追跡 リリースバックログ
各自のタスクの状況が一 覧できる スプリントバックログ 見積もりポイント、優先順 位を一元的に管理 Developers Summit 2010
38.
コンカレントテスティング アジャイルでは、「すべてのコードはテストされ
たコード」である RTCチームの場合 反復毎に、各チームレベルで、ユニットテスト 、機能テスト、受け入れテストを行う リリースにむけ、統合テストチームが、並行し て、パフォーマンステスト、信頼性テストを行 う プロセス ワークアイテム ソース管理 4-10人x 20 PMC Web UI 約10人 統合テスト Developers Summit 2010 38
39.
継続的インテグレーション 正常に動くビルドを少なくとも1
日1 回作り出す ソース統合、ビルド自動化、テスト自動化が必要 RTCチームの場合 チームコンサートを用いて一元管理、常に動く安定した プログラムを保持 テストコードを含んだ、個人の作業領域での個人ビルド チーム領域でのビルド 統合領域でのビルド (安定したもの) 出展:「ゕジャル開発の本質とスケールゕップ」 Developers Summit 2010 39
40.
反復ごとの「ふりかえり」の実施 定期的間隔で、チームはより効率を高めるために
どうすべきか考察し、やり方を改善する RTCチームの場合 反復ごとにチーム毎、PMCレベルで実施 ふりかえり(Retrospective)の結果も、 チームコンサートを使って管理 40 Developers Summit 2010 40
41.
本日のアジェンダ
ゕジャル開発の本質 ゕジャル開発を企業に導入する際の課題 規模に関係なく適用可能なプ7ラクテゖス 大規模だからこそ考える7プラクテゖス まとめ Developers Summit 2010 41
42.
大規模だからこそ必要なプラクティス
意図的なゕーキテクチャ リーン要求開発のスケールゕップ:ビジョン、ロードマッ プ、ジャストンタムの詳細化 ゕジャルリリーストレン 高度に分散した開発の管理 顧客とオペレーションへのンパクトの調整 組織を変化させる ビジネスパフォーマンスを計測する Developers Summit 2010 42
43.
意図的なアーキテクチャ ゕーキテクチャは出現するのか?
→どれぐらいのゕーキテクチャをチームが必要とするかは 、何を作っているのか依存する 出展:「ゕジャル開発の本質とスケールゕップ」 Developers Summit 2010 43
44.
意図的なアーキテクチャ RTCチームの場合
製品に対する要件 ソフトウェア コンポーネント Developers Summit 2010 44
45.
意図的なアーキテクチャ RTCチームの場合
製品に対する要件 ソフトウェア コンポーネント 開発チーム(スクラム) 統合テスト・チーム チーム間 スクラム (PMC) 4-10人 x 20チーム Developers Summit 2010 45
46.
リーン要求開発 ゕジャルなチームは、素早いコーデゖングによ
り、形式的な仕様書を避ける とはいえ、大規模開発においては、ビジョンは、 非機能要求などの共通な要求は前倒しで持ってお くべき また、要求の劣化を避けるために、ジャストン タムで要求を詳細化する必要がある 46 Developers Summit 2010 46
47.
リーン要求開発 RTCチームの場合
ビジョン(開発構想書) ロードマップ リリース1 リリース2 リリースv1.0 リリースv2.0 2009年9月 2009年12月 テーマ:快適なバー テーマ:スケーラビ 反復#1 反復#2 反復#3 反復#4 ジョン管理 リティ バージョン管理 分散開発での管理 Emailでの通知 RSSでの通知 プラットフォーム プラットフォーム Windows Linux バックログ ジャストインタイムで ID ストーリー 優先順位 見積もり ストーリーの詳細化 xxxx xxxx Developers Summit 2010 47
48.
高度に分散した開発の管理 大規模開発では、分散開発にならざるをえない
同じ都市や建物内でも、チームはバラバラ 以下の情報の共有が不可欠 優先度、リゕルタムの状況、依存関係、阻害要因 ツールの使用と、より組織的なゕプローチへの必要性が 高まる 電話会議システム、チャット 共通プロジェクトマネジメント、共有要求、ソース コードマネジメント、統合ビルド環境、変更管理、 自動化テストを可能とするツール Developers Summit 2010
49.
高度に分散した開発の管理 RTCチームの場合 一つのチームに属する人も散らばっている
Winnipeg Lexington Ottawa Saint Nazaire Shanghai Toronto Beaverton Zurich Tokyo Raleigh Bangalore プロセス ワークアイテム PMC ソース管理 Web UI Developers Summit 2010
50.
高度に分散した開発の管理 RTCチームの場合 社内の電話会議システム
各チームは、デリーミーテゖング(電話会議) 各自、昨日やったこと、今日やること、課題の共有 PMCは週2回のスクラムミーテゖング ツールによるチーム内情報共有 誰が何をやっているか、誰が次に何をやるかをリゕルタムに把握 常に変化に対応できる体制 RTCを用いて 一元化されたソース管理、作業管理、問題管理 情報を見える化し、情報間のトレーサビリテゖを自動保持 適切なレベルのプロセス管理 Developers Summit 2010 50
51.
アジャイル・リリーストレイン 一般的に、アジャイルチームはより多くの成果を素早く納品可
しかし、大規模では成果納品のコーディネーションが難しい アジャイル・リリーストレインの概念が登場 リリースを、固定され遅らせることのできないスケジュールと 考える 時間通りに次々と発車する電車のように リリース日、テーマ、品質が固定 上記3つが固定であるならば、可変できるのは機能 Developers Summit 2010 51
52.
アジャイル・リリーストレイン
Developers Summit 2010 52
53.
アジャイル・リリーストレイン
リリース ウォームアップ リリース計画 M1a M1 … エンドゲーム 修正- 洗練化 立ち上げ テスト 安定化 安定化 安定化 テスト 計画 計画 開発 開発 開発 修正 計画 複数チーム間で同期を とらねばならないもの 4週間 4週間 4週間 は必須。それ以外は、 マルストーン 優先順位付けしたもの から作る。 53 Developers Summit 2010 53
54.
顧客とオペレーションへの インパクトの調整 小規模で頻繁なリリースは、言うは安く行なうは難し
開発チームがそれを実施できても、企業とすればそれで 終わらない 他システムとの連携 納品プロセス、保守チーム 営業やマーケテゖングなどの利害関係者 リリースの目標に向かって、より多くのコーデゖネーショ ンとコミュニケーションが必要となる Developers Summit 2010 54
55.
顧客とオペレーションへの インパクトの調整 チームコンサート開発チームの場合
Jazz.net で開発の模様を完全に外に公開 ソースコードも、開発タスクの状態も丸見え タムリーな情報公開 ユーザーからのフゖードバックを早期に採り入れる 開発者と、ユーザーの距離を縮める Developers Summit 2010 55
56.
組織を変化させる ボトムゕップゕプローチ
ゕジャル開発を、企業内の「小さなチーム」に適用しても 、それなりの効果がある トップダウンゕプローチ ゕジャルのメリットを最大限に活かすため、全社適用して 組織が抱える課題に取り組む ステップ ①スポンサー、エヴゔンジェリストを確保 ②組織のゕジリテゖに対する適合性を評価 ③パロットプロジェクトを実施 ④組織への展開計画の策定 適切なトレーニング ツール、サポート、コミュニテゖのサポート Developers Summit 2010 56
57.
組織を変化させる RTCチームの場合
IBM Software Group内で、ゕジャル推進チーム「 Agile Transformation」を組織化 情報を集約し、HELPデスクの役割を果たす 定期的に、プラクテゖスの浸透度を測定 PM、開発者向けのAgileトレーニングを準備 ゕジャル開発を支えるツールを提供(RTC) Developers Summit 2010 57
58.
組織を変化させる [非公開] IBMにおけるプラクテゖス浸透度(グラフ)
Developers Summit 2010 58
59.
ビジネスパフォーマンスを計測する 開発チームレベルでは、
動くコードの進捗測定が、生産性の指標として最良 他のさまざまな指標は二義的 しかし、企業には他のレベルでの測定に対するニーズ 全社に渡るビジネスパフォーマンスの測定 例:経営者が複数プロジェクトを横串でみて、 ポートフォリオとして判断するための指標 Developers Summit 2010 59
60.
ビジネスパフォーマンスを計測する
チームコンサートへの入力等を利用して、上位マネージメント のためのダッシュボードを提供 (Rational Insight) 出展: Scaling Software Agility Developers Summit 2010 60
61.
本日のアジェンダ
ゕジャル開発の本質 ゕジャル開発を企業に導入する際の課題 規模に関係なく適用可能なプラクテゖス 大規模だからこそ考えるプラクテゖス まとめ Developers Summit 2010 61
62.
規模に関係なく適用できるプラクティス
定義・構築・テストのコンポーネント・チーム 2 レベル計画作りと追跡 反復型開発 頻繁な小規模リリース コンカレントテステゖング 継続的ンテグレーション 継続的な考察と適応 Developers Summit 2010 62
63.
大規模だからこそ必要なプラクティス
意図的なゕーキテクチャ リーン要求開発のスケールゕップ:ビジョン、ロードマッ プ、ジャストンタムの詳細化 ゕジャルリリーストレン 高度に分散した開発の管理 顧客とオペレーションへのンパクトの調整 組織を変化させる ビジネスパフォーマンスを計測する Developers Summit 2010 63
64.
まとめ ゕジャルは使える――そして、スケール
ゕップ可能です! 本日の公演内容をもっと詳 しく知りたい方のために: http://www.amazon.co.jp/ dp/4798120405/ Developers Summit 2010 64
65.
チームコンサート無料版! アジャイルなチームのための開発環境である
「チームコンサート」のデモブースにも是非 お立ち寄りください! 先着で、無料版Express-CのCDが入手で きます! RTC wiki RTC情報が沢山! Jazz-jp.net Express-Cの質問可能! Developers Summit 2010 65
Download now