Submit Search
Upload
アジャイルにモデリングは必要か
•
64 likes
•
11,702 views
Hiromasa Oka
Follow
2015/7/23開催のUMTPアジャイル開発事例セミナー「現場に学ぶ実践アジャイルモデリング」株式会社ゼンアーキテクツ 岡 大勝による講演資料です。【更新2版:一部図形を修正】
Read less
Read more
Software
Report
Share
Report
Share
1 of 58
Download now
Download to read offline
Recommended
ドメイン駆動設計の考え方、ドメイン駆動設計を理解する三つのキーワード、エヴァンス本のススメ、レガシーに立ち向かう、マイクロサービスとドメイン駆動設計
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
2013/11/9 DevLove甲子園発表資料 チーム創 4階裏
モデリングもしないでアジャイルとは何事だ
モデリングもしないでアジャイルとは何事だ
Iwao Harada
第2シーズンに向けて、設計コースの内容と進め方について、説明会の資料
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
ドメイン駆動設計の要点は3つ。ビジネスルール・値オブジェクト・型
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
要件定義・仕様化・実装の継ぎ目をなくす開発手法。 ビジネスロジックを軸に組み立てる。 値の種類(型)に注目してモジュール化する
ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善
増田 亨
エヴァンス本を読んだことがない人、ネット上の情報を聞きかじったことがある程度の人、そんな人たちを対象に、ドメイン駆動設計について、わかりやすく説明してみました。
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
Recommended
ドメイン駆動設計の考え方、ドメイン駆動設計を理解する三つのキーワード、エヴァンス本のススメ、レガシーに立ち向かう、マイクロサービスとドメイン駆動設計
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
2013/11/9 DevLove甲子園発表資料 チーム創 4階裏
モデリングもしないでアジャイルとは何事だ
モデリングもしないでアジャイルとは何事だ
Iwao Harada
第2シーズンに向けて、設計コースの内容と進め方について、説明会の資料
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
ドメイン駆動設計の要点は3つ。ビジネスルール・値オブジェクト・型
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
要件定義・仕様化・実装の継ぎ目をなくす開発手法。 ビジネスロジックを軸に組み立てる。 値の種類(型)に注目してモジュール化する
ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善
増田 亨
エヴァンス本を読んだことがない人、ネット上の情報を聞きかじったことがある程度の人、そんな人たちを対象に、ドメイン駆動設計について、わかりやすく説明してみました。
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
ドメイン駆動設計の実践力に転機が訪れる時。 チームがオブジェクト指向を体で覚えた時。 チームがインクリメンタルな設計を体で覚えた時。 チームでオブジェクト指向とインクリメンタルな設計を体で覚えるための指針。 QCon Tokyo 2016
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイント
増田 亨
ドメイン駆動設計でなぜ作るのか? ドメイン駆動設計の考え方 ドメイン駆動設計を実践するための6つの問い 事例研究 ドメイン駆動設計を現場に導入する 体験的に学ぶ エヴァンス本をちゃんと読む
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
更新日時を排除していくことでそこそこのモデルを書けるようになる手法です。
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
オブジェクト指向では、モデリング(分析)、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
ドメイン駆動設計 Domain-Driven Design ( DDD ) 準備 / スタートアップ / ブラッシュアップ / チャレンジ / 参考書籍 /
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
アジャイル札幌 ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
1995年まで:イノベータとアーリーアダプターの時代; 1995-2005 : オブジェクト指向ブームと混乱の始まり; 2005-2015 : さらなる混乱と収束の兆し; 2015- ; 現在の状況とこれからの20年
オブジェクト指向プログラミングの現在・過去・未来
オブジェクト指向プログラミングの現在・過去・未来
増田 亨
ブログでもいろいろ解説しています。 http://little-hands.hatenablog.com/entry/top ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。 --- 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界付けられたコンテキスト ・境界付けられたコンテキストをどう実装に落としこむか 今回のスライドでは、概念の方の説明をしたいと思います。
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
ドメイン駆動設計で、モデリングをどうやっているか、それをどう実装に結びつけているかの事例紹介。 RDRA+ICONXをベースに、より機敏なやり方への挑戦。実践的なオブジェクト指向設計。
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
2022-03-05 YAPC::Japan::Online 2022
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
「ドメイン駆動設計」の第4部の概要と理解の手がかり。現場での実践経験から。
3週連続DDDその3 ドメイン駆動設計 戦略的設計
3週連続DDDその3 ドメイン駆動設計 戦略的設計
増田 亨
第1回 しょぼべん ( http://connpass.com/event/10849/ ) で話しした、イミュータブルデータモデル(世代編)です。
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 発売記念に、本書の1,2章の内容を中心にDDDの概要について解説する勉強会です。
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
関西Javaエンジニアの会'13 7月度 発表資料 http://kanjava.connpass.com/event/2740/
ドメイン駆動設計入門
ドメイン駆動設計入門
Takuya Kitamura
ソフトウェア設計の課題 ソフトウエア設計の品質 学習と成長 設計の初歩を学ぶ 中級者への道 上級者の挑戦
ソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考える
増田 亨
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン(規律)の存在」や「General Electric(GE)やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
astah* communityを初めてご利用になる方を対象とした基本操作ガイドです。画面構成や基本概念、簡単な操作を紹介しています。
Astah Community スタートガイド
Astah Community スタートガイド
ChangeVision
「こ・れ・だ・け」モデリングのススメ。 メソドロジックの山岸さんによる、「こ・れ・だ・け」モデリングのイントロダクション。企業情報システム開発において、モデリングのパワーを活かしながらアジャイルに開発を進める、軽量モデリングのススメ。Part 1 では、「やり過ぎモデリング」や、「やらな過ぎモデリング」に対して、コスト効果のある「ほどよいモデリング」として「これだけモデリング」を提案。UMLの13図から4図を選んで、その利用シーンとともに解説する。 本人解説ビデオはこちら。 http://youtu.be/-9MH2dVPb-E
koredake modeling
koredake modeling
ChangeVision
More Related Content
What's hot
ドメイン駆動設計の実践力に転機が訪れる時。 チームがオブジェクト指向を体で覚えた時。 チームがインクリメンタルな設計を体で覚えた時。 チームでオブジェクト指向とインクリメンタルな設計を体で覚えるための指針。 QCon Tokyo 2016
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイント
増田 亨
ドメイン駆動設計でなぜ作るのか? ドメイン駆動設計の考え方 ドメイン駆動設計を実践するための6つの問い 事例研究 ドメイン駆動設計を現場に導入する 体験的に学ぶ エヴァンス本をちゃんと読む
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
更新日時を排除していくことでそこそこのモデルを書けるようになる手法です。
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
オブジェクト指向では、モデリング(分析)、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
ドメイン駆動設計 Domain-Driven Design ( DDD ) 準備 / スタートアップ / ブラッシュアップ / チャレンジ / 参考書籍 /
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
アジャイル札幌 ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
1995年まで:イノベータとアーリーアダプターの時代; 1995-2005 : オブジェクト指向ブームと混乱の始まり; 2005-2015 : さらなる混乱と収束の兆し; 2015- ; 現在の状況とこれからの20年
オブジェクト指向プログラミングの現在・過去・未来
オブジェクト指向プログラミングの現在・過去・未来
増田 亨
ブログでもいろいろ解説しています。 http://little-hands.hatenablog.com/entry/top ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。 --- 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界付けられたコンテキスト ・境界付けられたコンテキストをどう実装に落としこむか 今回のスライドでは、概念の方の説明をしたいと思います。
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
ドメイン駆動設計で、モデリングをどうやっているか、それをどう実装に結びつけているかの事例紹介。 RDRA+ICONXをベースに、より機敏なやり方への挑戦。実践的なオブジェクト指向設計。
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
2022-03-05 YAPC::Japan::Online 2022
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
「ドメイン駆動設計」の第4部の概要と理解の手がかり。現場での実践経験から。
3週連続DDDその3 ドメイン駆動設計 戦略的設計
3週連続DDDその3 ドメイン駆動設計 戦略的設計
増田 亨
第1回 しょぼべん ( http://connpass.com/event/10849/ ) で話しした、イミュータブルデータモデル(世代編)です。
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 発売記念に、本書の1,2章の内容を中心にDDDの概要について解説する勉強会です。
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
関西Javaエンジニアの会'13 7月度 発表資料 http://kanjava.connpass.com/event/2740/
ドメイン駆動設計入門
ドメイン駆動設計入門
Takuya Kitamura
ソフトウェア設計の課題 ソフトウエア設計の品質 学習と成長 設計の初歩を学ぶ 中級者への道 上級者の挑戦
ソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考える
増田 亨
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン(規律)の存在」や「General Electric(GE)やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
What's hot
(20)
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
オブジェクト指向プログラミングの現在・過去・未来
オブジェクト指向プログラミングの現在・過去・未来
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
3週連続DDDその3 ドメイン駆動設計 戦略的設計
3週連続DDDその3 ドメイン駆動設計 戦略的設計
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Tackling Complexity
Tackling Complexity
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
ドメイン駆動設計入門
ドメイン駆動設計入門
ソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考える
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Viewers also liked
astah* communityを初めてご利用になる方を対象とした基本操作ガイドです。画面構成や基本概念、簡単な操作を紹介しています。
Astah Community スタートガイド
Astah Community スタートガイド
ChangeVision
「こ・れ・だ・け」モデリングのススメ。 メソドロジックの山岸さんによる、「こ・れ・だ・け」モデリングのイントロダクション。企業情報システム開発において、モデリングのパワーを活かしながらアジャイルに開発を進める、軽量モデリングのススメ。Part 1 では、「やり過ぎモデリング」や、「やらな過ぎモデリング」に対して、コスト効果のある「ほどよいモデリング」として「これだけモデリング」を提案。UMLの13図から4図を選んで、その利用シーンとともに解説する。 本人解説ビデオはこちら。 http://youtu.be/-9MH2dVPb-E
koredake modeling
koredake modeling
ChangeVision
astah製品のサンプルプラグインを紹介します。community、UML、professionalの各エディションで利用できるプラグインを集めました。
Astah Plug-ins 作ろう!試そう!プラグイン!
Astah Plug-ins 作ろう!試そう!プラグイン!
ChangeVision
「こ・れ・だ・け」モデリングはアジャイルをさらに加速する。 メソドロジックの山岸さんによる、これだけモデリングの解説。企業情報システム開発において、モデリングのパワーを活かしながらアジャイルに開発を進める、軽量モデリングのススメ。Part 2 ではエンタープライズアジャイル開発の中でどのように「これだけモデリング」を活かして行くのかについて解説する。スプリントの中だけでなく、準備としてすばやく業務を把握する場面でモデリングは特に有効であり、アジャイルをさらに加速することができる。 あくまで「業務理解」が目的であり、抽象化しすぎたり、設計モデルへのトレーサビリティを意識しすぎることがないように。モデリングを参加者の「共通の残像づくり」という割り切りが面白い。 本人解説ビデオはこちら。 http://youtu.be/bnJdXiYsgV0
koredake modeling accelerates agile
koredake modeling accelerates agile
ChangeVision
フローチャートって何なのって、こんなのです。プログラムの説明が少しでも円滑になれば幸いです。
プログラムの流れを図で表す方法その1:フローチャート/アクティビティ図
プログラムの流れを図で表す方法その1:フローチャート/アクティビティ図
Katsuhiro Morishita
アジャイル時代のモデリング
Modeling in the Agile Age - JP
Modeling in the Agile Age - JP
Kenji Hiranabe
「エンタープライズアジャイル開発のリーンモデリング」 by 山岸理事 on 5/28, 2014 要求開発アライアンス定例
enterprise agile lean modeling
enterprise agile lean modeling
Kenji Hiranabe
Viewers also liked
(7)
Astah Community スタートガイド
Astah Community スタートガイド
koredake modeling
koredake modeling
Astah Plug-ins 作ろう!試そう!プラグイン!
Astah Plug-ins 作ろう!試そう!プラグイン!
koredake modeling accelerates agile
koredake modeling accelerates agile
プログラムの流れを図で表す方法その1:フローチャート/アクティビティ図
プログラムの流れを図で表す方法その1:フローチャート/アクティビティ図
Modeling in the Agile Age - JP
Modeling in the Agile Age - JP
enterprise agile lean modeling
enterprise agile lean modeling
Similar to アジャイルにモデリングは必要か
企業内でアジャイルを始めようとすると様々な障壁が見えてきます。その壁を越え、企業活動との融和を目指すためのアジャイルチームの立ち上げ方を、ゼンアーキテクツのNAISEI Build-up programでの活動を例に挙げて解説します。 【DevLove甲子園2015東日本大会MVP受賞講演】
「俺の背中について来い」アジャイルチームを一気に立ち上げる方法
「俺の背中について来い」アジャイルチームを一気に立ち上げる方法
Hiromasa Oka
Intalio japan special cloud workshop
Intalio japan special cloud workshop
Daisuke Sugai
企業システム開発のアジャイル内製化を推進していく中で、実は開発チームよりも既存の事業活動に障壁が現れます。本資料では、例えばPMOや品質管理部門といった予測型を前提とした管理統制スキームを適用している組織にアジャイル内製チームを立ち上げる際に考慮すべき3つの観点について事例を交えて解説します。 【2015/12/9に開催されたエンタープライズアジャイル勉強会での講演資料です】 ※ 2015/12/12 関連スライドとして下記講演へのリンクを加筆 「俺の背中について来い」アジャイルチームを一気に立ち上げる方法 http://www.slideshare.net/hiromasaoka/ss-56106141 ※ 講演時のタイトルは「事業計画に適応するアジャイル内製プロジェクトの運営」でしたが、配付資料では講演内容に即した名称に変更致しました。
エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと
エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと
Hiromasa Oka
アジャイル時代のモデリングと astah* のサクサク活用
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age and casual astah models
Kenji Hiranabe
2015/6/22にアイ・ラーニング様にて開催された「悩める管理職のためのエンタープライズ・アジャイル導入セミナー」の講演資料です。
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
MaruLaboの浅海ゼミでの講座のスライドです。 https://www.marulabo.net/docs/asami19/ 作業分野「設計」の最初の作業としてアーキテクチャ設計を説明します。 アーキテクチャ設計におけるコンポーネントを軸にした論理モデルと物理モデルの関係を軸に、 アーキテクチャ中心、原理、パターン、DevOpsについて取り上げます。
設計/アーキテクチャ設計 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第19回】
設計/アーキテクチャ設計 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第19回】
Tomoharu ASAMI
JST未来社会 未来社会創造事業 機械学習を用いたシステムの高品質化・実用化を加速する”Engineerable AI”(eAI)プロセスパターンチーム による機械学習応用システムのアーキテクチャ・デザインパターンの整理
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
HironoriTAKEUCHI1
講師:日本仮想化技術 玉置 日時:2015/7/15 タイトル:オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで 概要: - オープンクラウド基盤とは - オープンクラウド基盤のユースケース - オープンクラウド基盤についての関心領域
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
Nobuyuki Tamaoki
講師:日本仮想化技術 玉置 日時:2015/7/15 タイトル:オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで 概要: - オープンクラウド基盤とは - オープンクラウド基盤のユースケース - オープンクラウド基盤についての関心領域
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
VirtualTech Japan Inc.
BPStudy#62 匠Business Place 萩本順三さんの発表資料
モデリングの神髄
モデリングの神髄
bpstudy
Open棟梁について - OSSコンソーシアム https://www.osscons.jp/dotNetDevelopmentInfrastructure/OpenTouryo/
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
Daisuke Nishino
ーーーーーーーーーーーーーーーーーーーーーーー schoo WEB-campusは「WEBに誕生した、学校の新しいカタチ」。 WEB生放送の授業を無料で配信しています。 ▼こちらから授業に参加すると、先生への質問や、ユーザーとのチャット、資料の拡大表示等が可能です。 https://schoo.jp/class/261/room ーーーーーーーーーーーーーーーーーーーーーーー
いま、UXについて世界の最先端で起こっていることを学ぶ 先生:長谷川 敦士/井登 友一
いま、UXについて世界の最先端で起こっていることを学ぶ 先生:長谷川 敦士/井登 友一
schoowebcampus
オープンソースカンファレンス2018 Hiroshima > セミナー講演「広島近辺のSIerでアプリ開発しているエンジニア向け、弊部会とOSSの紹介」のセッション・スライド OSC 2018 広島 参加報告 - OSSコンソーシアム(9/27投稿予定) https://www.osscons.jp/jo2allmgh-537/#_537
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
Daisuke Nishino
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
Developers Summit
第15回ピク活IT勉強会(2014/3/26)の資料です。
第15回ピク活IT勉強会 ピクト図解入門(01 ピクト図解入門 20140328_公開用)
第15回ピク活IT勉強会 ピクト図解入門(01 ピクト図解入門 20140328_公開用)
Hidehiko Akasaka
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
Toshiyuki Konparu
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料
Tae Yoshida
MaruLaboの浅海ゼミでの講座のスライドです。 https://www.marulabo.net/docs/asami34/ 今回からクラウド・アプリケーションのアプリケーション・アーキテクチャの概要と オブジェクト指向分析設計との連携方法について整理していきます。 今回は全体像について説明しました。 次回以降にドメイン層、アプリケーション層、プレゼンテーション層について詳細に見ていきます。
アプリケーション・アーキテクチャ 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第34回】
アプリケーション・アーキテクチャ 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第34回】
Tomoharu ASAMI
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」
Cybozucommunity
10/30に実施されたSmart Storeのセミナーの資料です。 日本マイクロソフト株式会社 クラウドソリューションアーキテクト 内藤稔
Ms retail update ra 20191030
Ms retail update ra 20191030
Microsoft Azure Japan
Similar to アジャイルにモデリングは必要か
(20)
「俺の背中について来い」アジャイルチームを一気に立ち上げる方法
「俺の背中について来い」アジャイルチームを一気に立ち上げる方法
Intalio japan special cloud workshop
Intalio japan special cloud workshop
エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと
エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age and casual astah models
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
設計/アーキテクチャ設計 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第19回】
設計/アーキテクチャ設計 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第19回】
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
モデリングの神髄
モデリングの神髄
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
『これからの.NETアプリケーション開発』セミナー .NET用アプリケーション フレームワーク Open 棟梁 概説
いま、UXについて世界の最先端で起こっていることを学ぶ 先生:長谷川 敦士/井登 友一
いま、UXについて世界の最先端で起こっていることを学ぶ 先生:長谷川 敦士/井登 友一
OSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
【17-C-4】「Axure RPによる画面プロトタイプを活用した要件定義の改善:野村総合研究所、NTTデータの事例紹介」松永充弘氏
第15回ピク活IT勉強会 ピクト図解入門(01 ピクト図解入門 20140328_公開用)
第15回ピク活IT勉強会 ピクト図解入門(01 ピクト図解入門 20140328_公開用)
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
JAWS-UG三都物語_企業でのAWS導入のエントリーポイント
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料
アプリケーション・アーキテクチャ 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第34回】
アプリケーション・アーキテクチャ 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第34回】
基調講演「データのグループウェア化」
基調講演「データのグループウェア化」
Ms retail update ra 20191030
Ms retail update ra 20191030
More from Hiromasa Oka
2021/9/9 に開催された ZOZOテクノロジーズMeetup 「ZOZOTOWNアーキテクトナイト」でお話しした講演資料です。 ■ connpass イベントページ https://zozotech-inc.connpass.com/event/221751/ ■ イベント動画 【後日追加】
ZOZOTOWNのアーキテクトという役割を紹介します
ZOZOTOWNのアーキテクトという役割を紹介します
Hiromasa Oka
2021/1/13 開催の SoftBank DeepTech での講演資料です。 https://sb-deeptech.connpass.com/event/195540/
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
Hiromasa Oka
2019/11/28 に開催した NoOps Meetup Tokyo #9 のオープニングスライドです。
NoOps Meetup Tokyo #9 Opening
NoOps Meetup Tokyo #9 Opening
Hiromasa Oka
2019/10/9 に開催したマイナビセミナー「クラウドネイティブトランスフォーメーションのススメ」の資料です。 開催概要:https://news.mynavi.jp/itsearch/seminar/335
クラウドネイティブトランスフォーメーションのススメ
クラウドネイティブトランスフォーメーションのススメ
Hiromasa Oka
2019/9/17 に開催した NoOps Meetup Tokyo #8 のオープニングスライドです。
NoOps Meetup Tokyo #8 1st Anniversary - Opening
NoOps Meetup Tokyo #8 1st Anniversary - Opening
Hiromasa Oka
2019/7/29 に開催した NoOps Meetup Tokyo #7 のオープニングスライドです。
NoOps Meetup Tokyo #7 Opening
NoOps Meetup Tokyo #7 Opening
Hiromasa Oka
2019/7/23 に開催されたCloud Native Days Tokyo 2019 の登壇資料です。Microsoft真壁さんとの共同登壇です。
ZOZOTOWN の Cloud Native Journey
ZOZOTOWN の Cloud Native Journey
Hiromasa Oka
2019/6/23 DevLoveX Day2の「もう「効率化」なんてゴミ箱に捨ててしまおう ~情報時代の価値観と行動原則、そして「正しさ」とは何か」の講演スライドです。
もう「効率化」なんてゴミ箱に捨ててしまおう
もう「効率化」なんてゴミ箱に捨ててしまおう
Hiromasa Oka
2019/5/2-30に開催された Microsoft de:code 2017 DAY2 SP07 実践NoOps ~NoOpsで本当に働き方は変わるのか?~ のセッションスライドです。
de:code 2019 SP07 実践NoOps
de:code 2019 SP07 実践NoOps
Hiromasa Oka
2019/6/4 に開催した NoOps Meetup Tokyo #6 のオープニングスライドです。
NoOps Meetup Tokyo #6 Opening
NoOps Meetup Tokyo #6 Opening
Hiromasa Oka
2019/3/26 に開催した NoOps Meetup Tokyo #5 のオープニングスライドです。
NoOps Meetup Tokyo #5 Opening
NoOps Meetup Tokyo #5 Opening
Hiromasa Oka
2019/2/5 に開催した NoOps Meetup Tokyo #4 のオープニングスライドです。
NoOps Meetup Tokyo #4 Opening
NoOps Meetup Tokyo #4 Opening
Hiromasa Oka
2018/12/7 に開催した NoOps Meetup Tokyo #3 のオープニングスライドです。
NoOps Meetup Tokyo #3 Opening
NoOps Meetup Tokyo #3 Opening
Hiromasa Oka
JAPAN CONTAINER DAYS V18.12 (セッション 2E5)の講演資料です。 https://containerdays.jp/
NoOpsが目指す未来とコンテナ技術
NoOpsが目指す未来とコンテナ技術
Hiromasa Oka
2018/10/26 に開催した NoOps Meetup Tokyo #2 のオープニングスライドです。
NoOps Meetup Tokyo #2 Opening
NoOps Meetup Tokyo #2 Opening
Hiromasa Oka
2018/9/28 デブサミ関西 B-7 セッション資料です。
勝てる「開発プロセス」のつくり方
勝てる「開発プロセス」のつくり方
Hiromasa Oka
2018/9/12開催の NoOps Meetup Tokyo #1 でのセッション資料です。
15分で分かる NoOps
15分で分かる NoOps
Hiromasa Oka
2018/9/12 に開催した NoOps Meetup Tokyo #1 のオープニングスライドです。 コミュニティの目的、活動方針などについてお話しました。
NoOps Meetup Tokyo #1 Opening
NoOps Meetup Tokyo #1 Opening
Hiromasa Oka
2018年6月16日開催の DevLove #201 越境ジャーニーでの講演資料です。
新世代の価値観へ越境せよ
新世代の価値観へ越境せよ
Hiromasa Oka
2018年6月8日に京都でお話した資料です。
NoOps で変わる 人とシステムの関わりかた
NoOps で変わる 人とシステムの関わりかた
Hiromasa Oka
More from Hiromasa Oka
(20)
ZOZOTOWNのアーキテクトという役割を紹介します
ZOZOTOWNのアーキテクトという役割を紹介します
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
NoOps Meetup Tokyo #9 Opening
NoOps Meetup Tokyo #9 Opening
クラウドネイティブトランスフォーメーションのススメ
クラウドネイティブトランスフォーメーションのススメ
NoOps Meetup Tokyo #8 1st Anniversary - Opening
NoOps Meetup Tokyo #8 1st Anniversary - Opening
NoOps Meetup Tokyo #7 Opening
NoOps Meetup Tokyo #7 Opening
ZOZOTOWN の Cloud Native Journey
ZOZOTOWN の Cloud Native Journey
もう「効率化」なんてゴミ箱に捨ててしまおう
もう「効率化」なんてゴミ箱に捨ててしまおう
de:code 2019 SP07 実践NoOps
de:code 2019 SP07 実践NoOps
NoOps Meetup Tokyo #6 Opening
NoOps Meetup Tokyo #6 Opening
NoOps Meetup Tokyo #5 Opening
NoOps Meetup Tokyo #5 Opening
NoOps Meetup Tokyo #4 Opening
NoOps Meetup Tokyo #4 Opening
NoOps Meetup Tokyo #3 Opening
NoOps Meetup Tokyo #3 Opening
NoOpsが目指す未来とコンテナ技術
NoOpsが目指す未来とコンテナ技術
NoOps Meetup Tokyo #2 Opening
NoOps Meetup Tokyo #2 Opening
勝てる「開発プロセス」のつくり方
勝てる「開発プロセス」のつくり方
15分で分かる NoOps
15分で分かる NoOps
NoOps Meetup Tokyo #1 Opening
NoOps Meetup Tokyo #1 Opening
新世代の価値観へ越境せよ
新世代の価値観へ越境せよ
NoOps で変わる 人とシステムの関わりかた
NoOps で変わる 人とシステムの関わりかた
アジャイルにモデリングは必要か
1.
アジャイルにモデリングは必要か 2015/7/23 株式会社ゼンアーキテクツ 岡 大勝 Is “Modeling”
required in Agile? UMTPアジャイル開発事例セミナー 現場に学ぶ実践アジャイルモデリング
2.
⾃自⼰己紹介 • 第⼀一勧銀情報システム(現:みずほ情報総研) • VOS3
COBOL&MS-‐Cプログラマ • ⽇日本ディジタルイクイップメント(⽇日本DEC) • 主に⽣生保・損保・銀⾏行行向けの資産運⽤用システムに携わる。 • Alpha NT, SQL Server, DECnet • ⽇日本ヒューレット・パッカード C&I-‐Financial • ⾦金金融機関向けのシステムアーキテクチャ設計、開発プロセス設計、 運⽤用プロセス設計を⾏行行う。 • HP-‐UX, J2EE, WebLogic, Oracle Database, OO • ⽇日本ラショナルソフトウェア • 開発プロセス(RUP)およびオブジェクト指向分析設計⼿手法の導⼊入 コンサルティング。 • RUP, Rose, ClearCase, Functional Tester • ゼンアーキテクツ • 2003年年よりIT設計事務所として活動。お客さまのIT投資の最適化を ⽬目指し、アーキテクチャ中⼼心のプロセス改善を推進。 著作/翻訳 • 「要求」の基本原則(技術評論論社)2009 • 本当に使える開発プロセス(⽇日経BP社)2012 • ディシプリンド・アジャイル・デリバリー(翔泳社)2013 岡 ⼤大勝 株式会社ゼンアーキテクツ CEO/チーフアーキテクト プロフィール @okahiromasa
3.
© 2015 ZEN
ARCHITECTS Co.,Ltd. UMLは、いまどうなのか? •共通⾔言語として使えて当たり前。 •「読めない」「書けない」では話にならない。 •SWEBOKv3の5つのKAで“前提” • 要求・設計・実装・プロセス・モデルと⼿手法 3 http://www.computer.org/web/swebok
4.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 1. アジャイルでの「モデル」を 整理理する 2. アジャイルプロジェクトで モデルを活⽤用する
5.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルにモデリングは必要か? •現実には、いつも、どんなアジャイルプロジェク トでも⾏行行われている。 • UMLだけがモデルではない • 「モデル」と「⽂文書」は異異なる • 精緻で正確でビジュアルに描かれたものだけが モデルではない • 意識識していない活動を含む アジャイルに限らず、知的⽣生産活動には モデリングは⽋欠かせない
6.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルは組織活動を変⾰革した 予測型 (計画駆動) 適応型 (変化駆動/アジャイル) ジャストイン タイム Just-In-Time 成果物駆動 Document Driven ■ 計画管理理/要求管理理 ■ 開発⼯工程 詳しくは「企業システムにアジャイルは必要か」スライドを参照 http://www.slideshare.net/hiromasaoka/agile-‐is-‐really-‐need-‐to-‐enterprise-‐system-‐49711192
7.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 計画できることは、計画して実施する • 「正しい」ことが分かっている • よほど⼤大きな問題が発⽣生しない限り“うまくいく” • 事業者は「必要な時期」に「必要なもの」が⼿手に⼊入れば良良い。 • 定型反復復業務 • 確⽴立立された⼿手順 予測型 (計画駆動) Lv.1 確実な未来 Lv.2 選択的未来 PMBOK 5th
8.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 計画できないことは、確認しながら進む • 何が「正しい」のか判断できない • 正しいものが変化する • 機能 • 技術 • ビジネス、マーケット • 変化への継続的な対応 • 「要求の変化」と「優先順位の変化」 • 要求の変化=反復復型による継続的フィードバック • 優先順位の変化=バックログによる動的要求管理理 反復型 Lv.3 一定の幅 適応型 (変化駆動/アジャイル) PMBOK 5th
9.
© 2015 ZEN
ARCHITECTS Co.,Ltd. ジャストインタイム(JIT) • 作業の管理理を、テスト結果によって⾏行行う • 中間成果物は「それが必要な場合に」作成する 9 要求 分析 実装 テスト 要求 分析 実装 テスト 要求 分析 テスト 設計 実装設計 設計 チェック ポイント 要求 分析 設計 実装 テスト チェック ポイント チェック ポイント チェック ポイント チェック ポイント チェック ポイント タスクそのものを「必要に応じて」実施 チェック ポイント チェック ポイント 成果物駆動 ジャストインタイム データ 設計 テストデータ 作成
10.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 反復 Iterative ジャストイン タイム Just-In-Time 適応型 Adaptive Lifecycle アジャイルの⾻骨格 アジャイルは、成果物や文書に影響されない つまり「何でもいい」
11.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 反復 Iterative ジャストイン タイム Just-In-Time 適応型 Adaptive Lifecycle 価値駆動 バックログ管理 コードの 共同所有 リファクタリング 自動回帰テスト Living Document 安定した アーキテクチャ 継続的統合/ デリバリー アーキテクチャ スパイク ペアプログラミング BDD カンバン イテレーショ ン計画 マルチファンクショナル エンジニア(多能工) リスク駆動 タイムボックス ベロシティ ふりかえり Pull Request インセプション 日次ミーティング 100%専任バーンダウン チャート 自己組織的 チーム リスクリスト アジャイルは、成果物に依存しないよう うまく設計されている ビジョンドキュメント イテレーション デモ ※ゼンアーキテクツがお客さまの現場で実践している主要なプラクティスを表したものです
12.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 「成果物」の意味が変わった 成果物駆動 ジャストインタイム 「次⼯工程の⼊入⼒力力」 → 「必要に応じて作るもの」 要求モデル 分析モデル 設計モデル 実装モデル コード コード 要求 ドキュメント 成果物を作成する活動(=ドキュメンテー ション)は、成果物駆動型の主たる構造 コード不不要の世界を⽬目指していた • MDA/MDD • Executable UML ジャストインタイムでは「ドキュメ ントはコードを補うもの」 「Collective Code Ownership = コードの共同所有」が根源的価値 • 開発⾔言語の抽象度度の⾼高まり • DSL
13.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 何が起こったか •「⽂文書化」の⽬目的が変わった 成果物駆動 • 「ドキュメントの連続性」でプロジェクトを構築 • 検討し残しや書き残しのないように、すべきことを 「ドキュメント記載項⽬目」で表現する JIT • 「動作するコードの積み重ね」でプロジェクトを構築 • 事前に明らかにすべきことは確認する。 必要に応じて、適切切な⽅方法で伝える。
14.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 「アジャイルモデリング」 • Agile Modeling • 2002年年:英語版 • 2003年年:⽇日本語版 • スコット.W.アンブラー 著 • 他の著作 • Enterprise Unified Process • データベースリファクタリング • ディシプリンド・アジャイル・デリバリー • モデリングを“アジャイル”のコンテキス トに適⽤用するためのガイドブック。 • 「ソフトウェア開発プロジェクトで適⽤用でき る、効果的で⼿手軽にソフトウェアをモデリン グするための価値、原則、およびプラクティ スを集めたもの」「アジャイルなモデルは完 璧である必要はない」 14 http://www.ogis-‐ri.co.jp/otc/swec/process/am-‐res/am/
15.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 「メモ書き」と「清書」の分離離 •成果物駆動では、メモ書きは捨てるもの • ⼤大事なことは「正式なドキュメント」として記載 •JITでは、「メモ書き」の⽐比率率率が⾼高まる • 本当にメモ書きを捨てていいのか? • ⼤大事なことは、どこに書くのか? メモ書き 清書
16.
© 2015 ZEN
ARCHITECTS Co.,Ltd. モデルとは何か 「問題の1つ以上の側⾯面、その問題に対して考えられる 解決策を抽象的に記述したもの。図や⽂文章で⽰示される」 • 視覚的モデル • フローチャート, 状態マシン, ER図, DFD, OMT, Booch法, UML(ユースケース図, クラス図, アクティビティ図,..), BPMN, Value Stream Map, Lean Canvas, ユーザーストーリーマッ プ, 任意のアーキテクチャ図 • 任意のモデル • 要求⼀一覧, 機能⼀一覧, 業務ルール, 計算ロジック, ユーザース トーリー, CRCカード,インタフェース仕様, ポンチ絵, サンプ ルコード, 任意のメモ書き 「アジャイルモデリング」での定義
17.
© 2015 ZEN
ARCHITECTS Co.,Ltd. モデル(一時モデル) モデルと⽂文書とモデリングの関係 文書(保管用モデル) 清書 下書き モデリングモデリング
18.
© 2015 ZEN
ARCHITECTS Co.,Ltd. モデリングという活動 1. ありのままを表現する (これを“分析”と呼ぶ) 2. 作りたいもの(なりたい姿)を表現する (これを“設計”と呼ぶ) 分析 設計
19.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 分析と設計 文書 モデル 分析モデル 設計モデル 分析 設計
20.
© 2015 ZEN
ARCHITECTS Co.,Ltd. モデリングは多⾯面的である • 例例えば要求モデリング • プロダクトバックログに積まれたユーザーストーリー (ストーリー⼀一覧)だけで、要求が適切切に表現できるだ ろうか。 • 複数の軸で視覚的に分類して俯瞰したい • ユーザーストーリーマッピング • アクターを軸にグルーピングして俯瞰したい • ユースケース図で全体を把握 • 業務にマッピングして俯瞰したい • ビジネスプロセスマッピング • 全ての要求の優先順位を知りたい • プロダクトバックログ 自然に、複数のモデルを併用しているはず
21.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 【AM】なぜドキュメントを作成するのか 1. プロジェクトの利利害関係者が要求しているため 2. 取り決めモデルを定義するため • インターフェイスを含むシステム間の相互作⽤用 3. 外部グループとのコミュニケーションをサポートするため • 書いたことは誤解されやすいが、補助的なメカニズムとしては優れている • 「話すためにモデリングしよう」 4. 何かについてじっくり考えるため • 「理理解するためにモデリングしよう」 【アジャイルモデリング 14.1 より引⽤用】 “モデリングは後続⼯工程のために⾏行行うものではない”
22.
© 2015 ZEN
ARCHITECTS Co.,Ltd. ⽤用語を整理理する ü⽂文書(Document) • ⻑⾧長期間維持できる⽅方法で情報を伝える⽬目的を持つ。 üモデル(Model) • 問題の1つ以上の側⾯面、その問題に対して考えられる解決策を抽象的 に記述したもの。図や⽂文章で⽰示される。 üドキュメント(Documentation) • 他の⼈人のためにシステムについて記述した永続情報。⽂文書とコードの コメント両⽅方を含む。 üコード(Source Code) • コンピュータシステムに対する⼀一連の命令令と、命令令について記述した コメント。 ü成果物(Artifact) • 納品物または⽣生産した製品。 【アジャイルモデリングでの定義】
23.
© 2015 ZEN
ARCHITECTS Co.,Ltd. UMLモデルの位置づけ 文書 (保管用モデル) モデル (一時モデル) UMLモデル ER モデル BPMN 業務 フロー 要求 一覧 メモ書き、一時的 公開、永続的
24.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルなモデルのライフサイクル 思いつき 思いつきを モデル化する 一時モデル 残す 保管用モデル バージョン 管理する 更新する更新する 一時的なものにする 廃棄する 捨てる 廃棄する アジャイルモデリング 図14.2より
25.
© 2015 ZEN
ARCHITECTS Co.,Ltd. モデル、⽂文書、コード、ドキュメント モデル Model 文書 Document コード Code ドキュメント Documentation なる可能性がある。 または一部に含まれる (※清書) である 含む 記述する 可能性がある (※コメント) 記述する アジャイルモデリング 図14.1より
26.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 1. アジャイルでの「モデル」を 整理理する 2. アジャイルプロジェクトで モデルを活⽤用する
27.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルプロジェクトの⼀一⽣生 2つの期間 •「安定するまで」 •「安定してから」 よく耳にするのは「安定してから」の話 Image source by Wikipedia
28.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルは「安定するまで」が難しい
29.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイル プロジェクト イニシエーション 29 • いきなり書けと⾔言われても • どんな技術を使うのか • いつ、何ができるのか • 誰が、何をすればいいのか • だれが決めるのか・・・ Agile Project Initiation で 安定させる
30.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルの⽴立立ち上げを安定させる • アジャイル プロジェクト イニシエーション • Agile Project Initiation • 安定したアジャイルライフサイクルへの助⾛走 ØIteration Zero • XP ØSprint 0 • Scrum Ø⽅方向付けフェーズ • ディシプリンド・アジャイル・デリバリー 見積りのベースライン づくり 安定した継続的活動 の確立
31.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 何を安定させるのか アジャイルプロジェクトを安定させるための3つの観点 1. 要求を安定させる • たくさんの“やりたいこと”を、観点を合わせ、優先順位順に並べ、スコー プの⽬目星をつける • プロダクトバックログ:安定した⼊入⼒力力 2. アーキテクチャを安定させる • チームの試⾏行行錯誤を最⼩小化し、誰もが安定して開発(ジャストインタイ ム)が進められるよう、技術の組み合わせや書き⽅方のパターンを共有する • アーキテクチャドキュメント:安定した開発活動 3. 計画を安定させる • 個々の要求の実現コストが予測できる(⾒見見積基礎値)ようになってくると、 リリース時の要求実現状況のぶれ幅が⼩小さくなる • リリース計画:安定した計画と実績 31
32.
© 2015 ZEN
ARCHITECTS Co.,Ltd. ディシプリンド・アジャイル・デリバリー(DAD) 32 引⽤用:ディシプリンド・アジャイル・デリバリー(2013/翔泳社)
33.
© 2015 ZEN
ARCHITECTS Co.,Ltd. DADでのAPI(Agile Project Initiation)の位置 =アジャイルプロジェクトの⽴立立ち上げ 33 引⽤用:ディシプリンド・アジャイル・デリバリー(2013/翔泳社) アジャイル プロジェクト イニシエーション:API
34.
© 2015 ZEN
ARCHITECTS Co.,Ltd. APIで⾏行行うべき3種類の活動 34 引⽤用:ディシプリンド・アジャイル・デリバリー(2013/翔泳社) 初期の要求モデリング 初期のリリース計画 初期のアーキテクチャモデリング
35.
© 2015 ZEN
ARCHITECTS Co.,Ltd. DAD⽅方向付けフェーズのモデリング • 初期の要求モデリング • IRM:Initial Requirement Modeling • 初期のアーキテクチャモデリング • IAM:Initial Architecture Modeling • 初期のリリース計画(IRP) • IRP:Initial Release Planning • →またの機会に紹介します • ⽬目的は「Scrumを安定して運⽤用する」 • 安定したプロダクトバックログ運⽤用 • 安定したスプリント計画 • 安定した実装 • 安定したリリース • 安定した⾒見見積り アーキテクチャ ストー リー ストー リー ストー リー プロダクトバックログ 実装
36.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルプロジェクト⽴立立ち上げ後の モデリング活動の推移 36 I1 I2 C1 C2 C3 C4 Inception (Agile Project Initiation) Construction (Stabled Agile Project) 要求モデリング アーキテクチャモデリング 注)本チャートはゼンアーキテクツ実施の事例例による推測です モデリング活動 多い 少ない
37.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルプロジェクト⽴立立ち上げ後の モデリング活動の推移 37 I1 I2 C1 C2 C3 C4 Inception (Agile Project Initiation : API) Construction (Stabled Agile Project) 要求モデリング アーキテクチャモデリング 注)本チャートはゼンアーキテクツ実施の事例例による推測です コーディング アジャイルではリソース総量量は変わらない。 APIで”コーディングを最⼤大化できる環境をつくる”
38.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アジャイルプロジェクト⽴立立ち上げ後の モデリング活動の推移 38 I1 I2 C1 C2 C3 C4 Inception (Agile Project Initiation) Construction (Stabled Agile Project) ビジョン ドキュメント 採⽤用技術選定 要求モデリング アーキテクチャモデリング ユーザー ストーリー テクニカル ストーリー 業務フロー UIプロトタイプ アーキテクチャ 設計 ATAMユーティ リティツリー 主要技術の PoC 主要な API設計 E2E 実装サンプル 次反復復⽤用 API設計 新たな実装 技術のPoC 新APIの 実装サンプル UIをアーキテク チャに適合 ユーザー ストーリー 実装⽅方式確認 初期の データモデル データモデルの 拡張 外部接続の PoC 外部接続の 実装サンプル テスト アーキテクチャ設計 プロジェクト ライフサイクル ・プロダクトバックログ ・Living Document ・ソースコードリポジトリ ユーザー ストーリー 実装⽅方式確認 注)本チャートはゼンアーキテクツ実施の事例例による推測です ・プロダクトバックログ運⽤用開始 ・アーキテクチャドキュメント初版リリース ・基本的なユーザーストーリー(US)を実装可能 ・基本的なUSが動作 ・補助的なユーザーストーリーを実装可能 ・補助的なUSも動作 ・別の補助的なユーザーストーリーを実装可能
39.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 初期の要求モデリング To-‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装方 式 初期のアーキ テクチャ アーキテクチャ ドキュメント 主要なストーリーを実装 (US、TS) 実現したい業務を ストーリーとして切り出して登録 受け入れられた 実装済ストーリーを、To-‐Beにフィードバック SP 実装実績から 見積基礎値を設定 方式、パターン サンプルコード 2W 優先順位の高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識別しやすい) ソース 管理 ビルド・デプロイ・テスト プロダクトバックログ 見積基礎値の フィードバック ドキュメントの追記・更新 Living Document イテレーション計画 IRM:初期の要求モデリング 自動回帰テスト 受入テスト リリース判定 Ops リリース 本番運用 インシデント管理 修正依頼 ユーザ 運用担当者
40.
© 2015 ZEN
ARCHITECTS Co.,Ltd. IRMで利利⽤用可能なモデル(DADより) • ビジネスプロセス図 • データフロー図 • ビジネスルール • 制約事項 • コンテキスト図 • ドメインモデル • エピック • 機能⼀一覧 • フローチャート • マインドマップ • ⾮非機能要求(NFR) • ペルソナ • 要求事項 • UIフロー図 • UIプロトタイプ • UI仕様書 • UMLアクティビティ図 • UMLユースケース図 • ユースケース仕様書 • 利利⽤用シナリオ • 状態遷移図 • ユーザーストーリー • バリューストリームマップ 23種類のモデルを“適切切に組み合わせて”活⽤用し、 初期の要求モデルを構築する
41.
© 2015 ZEN
ARCHITECTS Co.,Ltd. IRMで利利⽤用可能なモデル(DADより) • ビジネスプロセス図 • データフロー図 • ビジネスルール • 制約事項 • コンテキスト図 • ドメインモデル • エピック • 機能⼀一覧 • フローチャート • マインドマップ • ⾮非機能要求(NFR) • ペルソナ • 要求事項 • UIフロー図 • UIプロトタイプ • UI仕様書 • UMLアクティビティ図 • UMLユースケース図 • ユースケース仕様書 • 利利⽤用シナリオ • 状態遷移図 • ユーザーストーリー • バリューストリームマップ ユーザーストーリーマップ NEW でも23種類にはこだわらない。 ⽬目の前の要求を適切切に扱うために、”適切切な道具”でモデリングする。 ATAMユーティリティツリー
42.
© 2015 ZEN
ARCHITECTS Co.,Ltd. DAD新刊での ユーザーストーリーマップ活⽤用例例 42 DAD新刊:Introduction to Disciplined Agile Delivery ユーザーストーリーマップ NEW
43.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 【事例例】企業システム刷新時のIRM •新技術による次世代製造管理理システムの開発 43 プロダクトバックログ • 既存システム • 新システムへの 要求事項 インプット • UMLユースケース図 • ユースケースシナリオ (一部の主要UC) • UIプロトタイプ(一部) • ビジネスルール IRM • ユーザーストーリー (ユースケース名) 規模が大きく(数百機能)、既存システムが存在するため、UMLユースケース図で アクター観点で全体像の整理。粒度調整のため一部をシナリオ化。 ユースケース名をストーリーとしてプロダクトバックログに登録し、イテレーション内 で必要に応じて(JITで)詳細化する。
44.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 初期のアーキテクチャ モデリング To-‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装方 式 初期のアーキ テクチャ アーキテクチャ ドキュメント 主要なストーリーを実装 (US、TS) 実現したい業務を ストーリーとして切り出して登録 受け入れられた 実装済ストーリーを、To-‐Beにフィードバック SP 実装実績から 見積基礎値を設定 方式、パターン サンプルコード 2W 優先順位の高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識別しやすい) ソース 管理 ビルド・デプロイ・テスト プロダクトバックログ 見積基礎値の フィードバック ドキュメントの追記・更新 Living Document イテレーション計画 IAM:初期のアーキテクチャモデリング 自動回帰テスト 受入テスト リリース判定 Ops リリース 本番運用 インシデント管理 修正依頼 ユーザ 運用担当者
45.
© 2015 ZEN
ARCHITECTS Co.,Ltd. IAMが早期安定化のカギ • 適切切なアーキテクチャ • 偶発的アーキテクチャ→ 創発的アーキテクチャ • 適切切なストーリー実装 • INVESTなストーリーをそのままシンプルに実装できる • 抽象度度の⾼高いドメインレベルAPI • ちょうど良良いバランスを「作る」 ストーリー実装 アーキテクチャ ストーリー実装 アーキテクチャ ガチガチ、 柔軟性なし 実装コストが⾼高すぎる、 メンテ困難 バランス
46.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 適切切なアーキテクチャをつくる 1. アーキテクチャ要求を識識別・収集 • 品質特性シナリオ(主たる機能+⾮非機能) • 品質モデル(ISO/IEC25010等)での網羅羅性検証 2. アーキテクチャ設計 • 利利⽤用可能かつ適切切な技術を組み合わせる • ⾃自⼰己検証(モデル、実装) 3. 客観的な妥当性検証 • 第三者によるアーキテクチャの妥当性検証(実現性、リスク、コ スト、選定技術が適切切性、ストーリーの実装しやすさ) • ATAM(Architecture Trade-‐‑‒Off Analysis)によるトレードオフ分 析等を活⽤用する アーキテクチャを後から⼤大きく改修するのは困難 アジャイルでも変わらない
47.
© 2015 ZEN
ARCHITECTS Co.,Ltd. Architecture Description • 4+1 View • 静的ビューをシナリオで「振る舞わせる」= ⾃自⼰己検証モデル
48.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アーキテクチャで ストーリーの実装を安定させる • 複雑さの隠蔽 • パターンの提供 • 新規性の最⼩小化 • ドメインの⾔言葉葉で実装したい(OOAD/DDD) • ”ユーザーストーリーがそのまま実装できるアーキテクチャ” • シンプルなコード • 結果「コードの共同所有」を促進 テクノロジ抽象化レイヤ ドメイン抽象化レイヤ プリミティブ技術 US US
49.
© 2015 ZEN
ARCHITECTS Co.,Ltd. アーキテクチャをどうやって伝えるのか • 「アーキテクチャ設計書」と「アーキテクチャ説明書」 • アーキテクチャ設計書(Architecture Description)は、内部の構造、 振る舞い、根拠、保守の観点を⽰示す「設計書」 • アーキテクチャドキュメント(Architecture Document)は、アーキテ クチャ(API)の使い⽅方やサンプルを⽰示す「説明書」 • 「しっかり書く」 or 「徐々に積み上げていく」 • 「安定」までの戦略略次第。最⻑⾧長6〜~8週。 • 傾向として • アーキテクチャドキュメントと「ストーリー増加に応じて徐々に」 • アーキテクチャ設計書は「主要なテクニカルストーリーが通ることを 確認できるところまで」 • “Living Document” • Wikiプラットフォーム • 「必要に応じて、必要なことを、伝える」
50.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 【事例例】ソフトウェア製品開発でのIAM •新分野でのソフトウェア製品の初期開発 50 • 新システムへの要 求事項 (機能・非機能が 混在) インプット • アーキテクチャスタック図 • 論理クラス図(全体構造) • ATAMユーティリティツリー • 品質特性シナリオ • アプローチ分析シート • 論理クラス図 • 物理クラス図 • 物理シーケンス図 • サンプル実装(実現性、性能 評価用) IAM(4反復) 新分野における未知の製品開発。 要求事項の優先度と非機能のトレードオフを明確化するため、ATAMユーティリティツリーを 活用。妥当性の客観的評価のためアプローチ分析シートを用いて机上・実証両面で検証。 性能・保守性・拡張性・ストーリー実装性でバランスのとれたアーキテクチャを構築。 初期の アーキテクチャ アーキテクチャ ドキュメント API定義
51.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 「安定してから」のモデリング • JITモデリング • 最⼩小で良良い • 「コードの共同所有」と、 それを⽀支えるアーキテクチャの安定 • “新しいこと”を扱うときに、軽く書く • 新しいテーブル • 新しい処理理⽅方式 • 新しいモジュール • 新しいタイプの要求 Image source by Wikipedia
52.
© 2015 ZEN
ARCHITECTS Co.,Ltd. スクラムの基本的な進め⽅方 52
53.
© 2015 ZEN
ARCHITECTS Co.,Ltd. ⾦金金融機関中規模チームでのDAD適⽤用例例 • ツール • JIRA • Confluence • Bitbucket • Jenkins • SWAT • アーキテクチャ • SPA/HTML5/knockout.js • MSA/PHP/Laravel/MySQL • RHEL • プロセス • Disciplined Agile Delivery 53 http://www.smartekworks.com/ http://www.atlassian.com/ ツール Tools プロセス Process アーキ テクチャ Architecture
54.
© 2015 ZEN
ARCHITECTS Co.,Ltd. PO (Product Owner) システム部 Web企画部 デザイナー AO (Architecture Owner) アーキテクチャ 担当デベロッパー UI担当デベロッパー プロダクト バックログ ドキュメント スプリント/タスク (計画・実績) ソース リポジトリ お客様 テスト 環境 TL (Team Leader) <Scrum Master> プロジェクト リリース 体制
55.
© 2015 ZEN
ARCHITECTS Co.,Ltd. PO プロダクト バックログ <JIRA> DADの開発保守サイクル 課題 要望 制約 追加/ステータス変更/ 属性変更 スプリント 1 スプリント 2 スプリント 3 スプリント 4 スケジュール <JIRA> マイルストーン設定 仕様 優先度 タスク化して スプリントに割り当て 作業量 見積もり 将来 像 実装 コスト 適用 技術 実装方式・規約・ ルール等 <Confluence> アーキテクチャドキュメント サンプル コード サンプル コード 実装方式 (パターン)の 割り当て 協働 協働 協働 AO メンバーの 適性・熟練度 の把握 リポジトリ <Bitbucket> デザイナー TL 協働 サンプル コード デザイン実装方式の調整 デザイン案 HTML Web企画部 デザイン案 コミット アーキテクチャ担当Dev UI担当Dev コミット 自動テスト 作成 参照 把握 2W 2W 2W 2W ・バックログ作成、優先順位設定 ・マイルストーン設定 ・協働時の検討・判断 ・タスク設定、アサイン ・実装方式の検討と定義 ・作業量見積もり ・実装方式の習熟 ・成果物作成 ・テストの定義と実施 ・テクニカルバックログ ・PoC・サンプル作成
56.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 【AM】アジャイル ドキュメンテーション戦略略 ü動かない仕様よりも実⾏行行可能な仕様を選ぶ üドキュメントを要求として扱う üドキュメントは情報を整理理する場であり、 思索索にふける場ではない ü簡潔さを保つ üドキュメントは、あなたの置かれた状況に合わせて⼗十分なもの を作ればよい ü情報を捕まえる「よりよいやり⽅方」を懸命になって探しなさい üドキュメントを書く正当な理理由を検討しなさい üプロジェクトの利利害関係者がそれを求めた üAPIを定義する ü外部のグループとコミュニケーションを円滑滑にする
57.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 【AM】現実に「UMLをどう使うか」 1. UMLをモデリングの中核として使う(もちろん全てではない) 2. 表記法の重要な部分だけを採⽤用する (全て使おうとしない。重要な20%から取りかかる) 3. すべての開発者にUMLの教育を⾏行行う (コミュニケーションのための当たり前の道具) 【アジャイルモデリング 15.5 より引⽤用】 UML推進者が注意すべきこと 「〜~にUMLをどう適⽤用するか」ではなく「ここで〜~をモデリング (分析や設計)を活⽤用するにはどうすればいいか」と考えた⽅方が良良い。 つまり「アジャイルにUMLをどう適⽤用するか」ではなく 「アジャイルでどうモデリングを活⽤用するか (そのうちのどこで UMLが適切切なのか)」と考えていきたい。
58.
© 2015 ZEN
ARCHITECTS Co.,Ltd. 58 zenarchitects.co.jp facebook.com/zenarchitects
Download now