Submit Search
Upload
enterprise agile lean modeling
•
34 likes
•
22,970 views
Kenji Hiranabe
Follow
「エンタープライズアジャイル開発のリーンモデリング」 by 山岸理事 on 5/28, 2014 要求開発アライアンス定例
Read less
Read more
Software
Report
Share
Report
Share
1 of 34
Download now
Download to read offline
Recommended
モデリングもしないでアジャイルとは何事だ
モデリングもしないでアジャイルとは何事だ
Iwao Harada
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗
toshihiro ichitani
Modeling in the Agile Age - JP
Modeling in the Agile Age - JP
Kenji Hiranabe
ドメイン駆動設計 コアドメインを語り合ってみよう
ドメイン駆動設計 コアドメインを語り合ってみよう
増田 亨
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
Recommended
モデリングもしないでアジャイルとは何事だ
モデリングもしないでアジャイルとは何事だ
Iwao Harada
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗
toshihiro ichitani
Modeling in the Agile Age - JP
Modeling in the Agile Age - JP
Kenji Hiranabe
ドメイン駆動設計 コアドメインを語り合ってみよう
ドメイン駆動設計 コアドメインを語り合ってみよう
増田 亨
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
アジャイルにモデリングは必要か
アジャイルにモデリングは必要か
Hiromasa Oka
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
Graat(グラーツ)
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
BIGLOBE Inc.
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
Yusuke Suzuki
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada
どうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCI
Koichiro Sumi
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
Itsuki Kuroda
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
メンバーのスキルアップ、どうしてる? − Java 100本ノックで新加入メンバーを鍛えてみた −
メンバーのスキルアップ、どうしてる? − Java 100本ノックで新加入メンバーを鍛えてみた −
JustSystems Corporation
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道
Arata Fujimura
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
Oxygen Not Includedをやるべき4つの理由
Oxygen Not Includedをやるべき4つの理由
lestrrat
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
React+TypeScriptもいいぞ
React+TypeScriptもいいぞ
Mitsuru Ogawa
koredake modeling
koredake modeling
ChangeVision
More Related Content
What's hot
アジャイルにモデリングは必要か
アジャイルにモデリングは必要か
Hiromasa Oka
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
Graat(グラーツ)
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
BIGLOBE Inc.
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
Yusuke Suzuki
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada
どうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCI
Koichiro Sumi
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
Itsuki Kuroda
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
メンバーのスキルアップ、どうしてる? − Java 100本ノックで新加入メンバーを鍛えてみた −
メンバーのスキルアップ、どうしてる? − Java 100本ノックで新加入メンバーを鍛えてみた −
JustSystems Corporation
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道
Arata Fujimura
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
Oxygen Not Includedをやるべき4つの理由
Oxygen Not Includedをやるべき4つの理由
lestrrat
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
What's hot
(20)
アジャイルにモデリングは必要か
アジャイルにモデリングは必要か
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
イベント・ソーシングを知る
イベント・ソーシングを知る
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 失敗したことと成功したこと
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
どうやらテスト駆動型開発は死んだようです。これからのCI
どうやらテスト駆動型開発は死んだようです。これからのCI
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
メンバーのスキルアップ、どうしてる? − Java 100本ノックで新加入メンバーを鍛えてみた −
メンバーのスキルアップ、どうしてる? − Java 100本ノックで新加入メンバーを鍛えてみた −
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
Oxygen Not Includedをやるべき4つの理由
Oxygen Not Includedをやるべき4つの理由
アジャイル開発とメトリクス
アジャイル開発とメトリクス
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Viewers also liked
React+TypeScriptもいいぞ
React+TypeScriptもいいぞ
Mitsuru Ogawa
koredake modeling
koredake modeling
ChangeVision
koredake modeling accelerates agile
koredake modeling accelerates agile
ChangeVision
Astah Plug-ins 作ろう!試そう!プラグイン!
Astah Plug-ins 作ろう!試そう!プラグイン!
ChangeVision
プログラムの流れを図で表す方法その1:フローチャート/アクティビティ図
プログラムの流れを図で表す方法その1:フローチャート/アクティビティ図
Katsuhiro Morishita
Astah Community スタートガイド
Astah Community スタートガイド
ChangeVision
Viewers also liked
(6)
React+TypeScriptもいいぞ
React+TypeScriptもいいぞ
koredake modeling
koredake modeling
koredake modeling accelerates agile
koredake modeling accelerates agile
Astah Plug-ins 作ろう!試そう!プラグイン!
Astah Plug-ins 作ろう!試そう!プラグイン!
プログラムの流れを図で表す方法その1:フローチャート/アクティビティ図
プログラムの流れを図で表す方法その1:フローチャート/アクティビティ図
Astah Community スタートガイド
Astah Community スタートガイド
Similar to enterprise agile lean modeling
サービス開発における工程
サービス開発における工程
Hidetoshi Mori
Xp2
Xp2
Toru Koido
IT投資のオペレーション・マネジメントの価値
IT投資のオペレーション・マネジメントの価値
Tetsu Kawata
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
Yusuke Suzuki
アジャイルマネジメントとは?
アジャイルマネジメントとは?
Kiro Harada
ぶーすかの取組み
ぶーすかの取組み
boostuposaka
Enterprise DevOps
Enterprise DevOps
智治 長沢
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
Yusuke Suzuki
プロジェクト管理ツール
プロジェクト管理ツール
Atsushi Heito
ドメイン駆動設計と要求開発
ドメイン駆動設計と要求開発
Kent Ishizawa
オープンソースカンファレンスBi勉強会20141018
オープンソースカンファレンスBi勉強会20141018
Hisashi Nakayama
設計品質とアーキテクチャ
設計品質とアーキテクチャ
Toru Koido
Office 365 E5 概要
Office 365 E5 概要
MPN Japan
Xp2 2014版
Xp2 2014版
Toru Koido
yokyo-unv.
yokyo-unv.
hirano
Relationship betweenddd and mvc
Relationship betweenddd and mvc
Takao Tetsuro
エンタープライズ・インフラ構築・運用でもDevOpsを活用しよう
エンタープライズ・インフラ構築・運用でもDevOpsを活用しよう
Hiroshi Tomioka
20050809
20050809
小野 修司
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
Yoshiyuki Ueda
メディカルデザインプロデュース(基本軽)提案書100615
メディカルデザインプロデュース(基本軽)提案書100615
Daisuke Hachimura
Similar to enterprise agile lean modeling
(20)
サービス開発における工程
サービス開発における工程
Xp2
Xp2
IT投資のオペレーション・マネジメントの価値
IT投資のオペレーション・マネジメントの価値
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
アジャイルマネジメントとは?
アジャイルマネジメントとは?
ぶーすかの取組み
ぶーすかの取組み
Enterprise DevOps
Enterprise DevOps
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
プロジェクト管理ツール
プロジェクト管理ツール
ドメイン駆動設計と要求開発
ドメイン駆動設計と要求開発
オープンソースカンファレンスBi勉強会20141018
オープンソースカンファレンスBi勉強会20141018
設計品質とアーキテクチャ
設計品質とアーキテクチャ
Office 365 E5 概要
Office 365 E5 概要
Xp2 2014版
Xp2 2014版
yokyo-unv.
yokyo-unv.
Relationship betweenddd and mvc
Relationship betweenddd and mvc
エンタープライズ・インフラ構築・運用でもDevOpsを活用しよう
エンタープライズ・インフラ構築・運用でもDevOpsを活用しよう
20050809
20050809
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
メディカルデザインプロデュース(基本軽)提案書100615
メディカルデザインプロデュース(基本軽)提案書100615
More from Kenji Hiranabe
effective ba for online communication
effective ba for online communication
Kenji Hiranabe
線形代数の視覚的理解 V1.1-Gストラング勉強会
線形代数の視覚的理解 V1.1-Gストラング勉強会
Kenji Hiranabe
Math in Machine Learning / PCA and SVD with Applications
Math in Machine Learning / PCA and SVD with Applications
Kenji Hiranabe
Scrum-Fest-Sapporo-2021-Keynote-Our-Journey
Scrum-Fest-Sapporo-2021-Keynote-Our-Journey
Kenji Hiranabe
Graphic Notes on Linear Algebra and Data Science
Graphic Notes on Linear Algebra and Data Science
Kenji Hiranabe
Appreciating Your Way to XP
Appreciating Your Way to XP
Kenji Hiranabe
Digital Business and Agile
Digital Business and Agile
Kenji Hiranabe
Graphic Notes on Introduction to Linear Algebra
Graphic Notes on Introduction to Linear Algebra
Kenji Hiranabe
線形代数の視覚的理解のためのノート
線形代数の視覚的理解のためのノート
Kenji Hiranabe
with コロナ時代のアジャイルとコミュニケーション
with コロナ時代のアジャイルとコミュニケーション
Kenji Hiranabe
Agile Ba with Covid at Redmine Japan 2020
Agile Ba with Covid at Redmine Japan 2020
Kenji Hiranabe
ESM Agile Studio DX and COVID
ESM Agile Studio DX and COVID
Kenji Hiranabe
Agile Ba with Covid
Agile Ba with Covid
Kenji Hiranabe
Essence position talk by hiranabe
Essence position talk by hiranabe
Kenji Hiranabe
Agile Scrum at Knowledge Forum 2020
Agile Scrum at Knowledge Forum 2020
Kenji Hiranabe
Ba and digital here now ness
Ba and digital here now ness
Kenji Hiranabe
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age and casual astah models
Kenji Hiranabe
Modeling in the Agile Age
Modeling in the Agile Age
Kenji Hiranabe
Agile in automotive industry
Agile in automotive industry
Kenji Hiranabe
Introduction to Agile - how business and engineer team up
Introduction to Agile - how business and engineer team up
Kenji Hiranabe
More from Kenji Hiranabe
(20)
effective ba for online communication
effective ba for online communication
線形代数の視覚的理解 V1.1-Gストラング勉強会
線形代数の視覚的理解 V1.1-Gストラング勉強会
Math in Machine Learning / PCA and SVD with Applications
Math in Machine Learning / PCA and SVD with Applications
Scrum-Fest-Sapporo-2021-Keynote-Our-Journey
Scrum-Fest-Sapporo-2021-Keynote-Our-Journey
Graphic Notes on Linear Algebra and Data Science
Graphic Notes on Linear Algebra and Data Science
Appreciating Your Way to XP
Appreciating Your Way to XP
Digital Business and Agile
Digital Business and Agile
Graphic Notes on Introduction to Linear Algebra
Graphic Notes on Introduction to Linear Algebra
線形代数の視覚的理解のためのノート
線形代数の視覚的理解のためのノート
with コロナ時代のアジャイルとコミュニケーション
with コロナ時代のアジャイルとコミュニケーション
Agile Ba with Covid at Redmine Japan 2020
Agile Ba with Covid at Redmine Japan 2020
ESM Agile Studio DX and COVID
ESM Agile Studio DX and COVID
Agile Ba with Covid
Agile Ba with Covid
Essence position talk by hiranabe
Essence position talk by hiranabe
Agile Scrum at Knowledge Forum 2020
Agile Scrum at Knowledge Forum 2020
Ba and digital here now ness
Ba and digital here now ness
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age and casual astah models
Modeling in the Agile Age
Modeling in the Agile Age
Agile in automotive industry
Agile in automotive industry
Introduction to Agile - how business and engineer team up
Introduction to Agile - how business and engineer team up
enterprise agile lean modeling
1.
エンタープライズアジャイル時代の リーンモデリング 株式会社 メソドロジック 山岸 耕二
1
2.
関心の変遷 ソフトウエアエンジニアリングのビジネスの中で 2 いかにちゃんと作るか • プログラム言語、アルゴリズム • システムアーキテクチャ、システム構成
• 開発プロセス、開発環境 いかに役に立つものを作るか • ビジネスモデリング • 要求開発 • 業務とITの最適設計 いかにビジネス価値を継続的に高めるか • システム複合体としてのエンタープライズシステ ム・継続的リフォーム • プログラムマネジメント • ビジネスプレーヤーと開発者の協調開発 オージス総研(1989-‐2000) 米国オブジェクト指向調査 シリコンバレー駐在 オブジェクト指向ツール提携 日本ラショナル設立 オブジェクト指向での本格SI ウルシステムズ(2000-‐2004) UMLautフレームワーク構築 Javaによる基幹システム構築 ビジネスモデリング協議会設立 豆蔵(2004-‐2009) 要求開発アライアンス設立 enThology超上流プロセス メソドロジック(2009-‐) 継続的リフォーム エンタープライズアーキテクチャ メガバンクの標準化(モデル、プロセス)
3.
IT戦略とプロジェクトの発生 現在のTo-‐Be IT 現在の 事業戦略 As-‐Is
IT 将来のTo-‐Be IT 将来の 事業戦略 現在 XX年後 現実的目標のIT 現行システム 新規追加 機能的改修 時間軸 プロジェクト プロジェクト プロジェクト 改善 サーバ統合 セキュリティ強 化 クラウド適用 維持 保守切れ対応 OS変更 プロジェクト プロジェクト プロジェクト 破棄 事業戦略 への対応 現行IT人材 コスト削減 継続性確保 コンプライアン ス 育成 採用 パートナ戦略 必要IT人材 例えば3カ年計画 各プロジェクトが上位目的に基づいて企画されているか プログラムマネジメント視点とプロジェクトマネジメント視点 プロジェクト
4.
モデリングとの出会い • 現状よりも一段広いスコープ(結果的には上位の視点) を意識する –
同じスコープ内でやっていると数年で頭打ちになる • 全体をとらえて、今の立ち位置を正しく理解する能力 – モデリング能力(空間認識力) • 全体把握と正確な共通認識 – 空中戦を地上戦に持ち込む • 一般化(抽象化)と具体化を切り分け、問題解決を図る – プロジェクト推進能力(段取り・シナリオを作る能力) • 仮説で作って、段階的(アジャイル的)に詳細化する • プロセスをモデリングする 4 モデリング力とプロジェクト推進力は根本的なスキル
5.
5 ソフトウエアシステム特有の難しさ • プロジェクトは、建築プロジェクトのアナロジーで語られがち・・・
• ソフトウエアシステムは複雑な系 – 対象が見えない – 段取りに決まり手がない – 目標は刻々変化する 対象が見えない 段取りが決まっていない モデリングで可視化 プロセスを定義する 繰返し型で開発する目標が刻々変化する 困難を克服するための特徴的アプローチ ソフトウエア開発上の歴史的なアプローチ
6.
リーン(「これだけ」)モデリングの勧め • こんなに役に立つのに使われていない –
どのぐらい役に立つかわかっていない – 使い方を間違っている – コストパフォーマンスをクリアする「これだけ」モデリング • アジャイルではモデリングは不要なのか – アジャイルにもタイプがある • ジャストアイデアと実装のコラボ – それでも言葉より手っ取り早くて正確に伝えるメモ的モデルは有効 • 複雑な企業システムをアジャイルのベロシティで – ちゃんと地図をもって走らないとあらぬ方向に 6 それぞれの場面に適したレベルの「これだけ」モデリングがある
7.
UMLのダイヤグラム構成 • 13のダイヤグラムで構成(ただし、パッケージ図はクラス図の1種) •
大きくは静的モデル(構造図)と動的モデル(振る舞い図)に分類される 静的モデル 動的モデル スケッチとしてのUML 設計ドキュメントとしてのUML プログラム言語としてのUML
8.
よく使う利用シーンとダイヤグラム 取り扱う ベースとなる 概要 ダイヤグラム ダイヤグラム ビジネスユースケース図 ユースケース図 特定業務領域について対象業務を棚卸し、業務スコープを明らかにする システムユースケース図 システムが提供するサービスをユーザ視点で示し、システムのスコープを明ら かにする 概念クラス図 クラス図 特定業務領域を構成する概念(エンティティ)を抽出し、それらの間の関係を明 らかにする 設計クラス図 オブジェクト指向言語を用いたソフトウエア開発の設計段階でクラス構成とク ラス間の関係を定義する データ設計図 リレーショナルデータベースを利用した永続化を前提にデータモデルを構築す る 業務フロー図 アクティビティ図 業務の処理手順を可視化し、システムとのやりとりを明らかにする 処理フロー図 システムの機能を実現する処理手順、ロジック、アルゴリズムを表現する。関 数やメソッドのプログラム設計を行う。 設計シーケンス図
シーケンス図 利用者とシステム間のやりとり、システム間の連携、システム内部ロジックとし てのモジュール間のやりとりなどを設計する
9.
Bad Smell パターン •
生真面目にやりすぎ – 13種類のダイヤグラム – ほどというものを知らない(抽象度、詳細度や表記法へのこだ わり) – すべてをモデリングする(全部シーケンス図書くとか) – ソースコードと同程度の情報をもたせる • 難しいこと言い過ぎ – 国際語としての英語(スラングやネイティブな表現は通じない) – 抽象度を上げすぎて、具体的なイメージを超えてしまう • 何のためにモデリングをするのかはっきりした目的がない
10.
モデリングの目的をはっきりさせる • 全貌の理解 •
詳細(複雑なもの)の理解 • 伝達 • 記録 • スケッチ • 設計書 • プログラム • 書き捨てる • 中間生成物として使う • 最終成果物として残す • 保守資料としてメンテナンスする 何を使うか どの程度書くか どう扱うか 目的に適う程度にスリムに おのずと程よさが決まる
11.
エンタープライズアジャイルとモデリング 11
12.
スクラムによる開発の進め方 • ソフトウェアに要求される機能とその優先度を 製品バックログとして定める • プロダクト・バックログからスプリントで実装する べき目標( スプリントゴール )を選択する • スプリントゴールをより詳細なタスクに分解した スプリント・バックログを作成し,
タスクの割り当 てを行う • スプリントの間, 毎日決まった場所及び時間で 開発メンバーが参加するデイリースクラムとい うミーティングを開催する • 1 回のスプリントが終了すると, スクラムレ ビューミーティングを開催し, 作成されたソフト ウェアを評価する • 次回のスプリントに備えてプロダクトバックログ の内容と優先度の見直しを行う COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED. 12 スプリント計画 ビジネス要 求 プロダクトバッ クログ設定 スプリント ゴール設定 スプリントバッ クログ設定 スプリント実施 デイリー スクラム スプリントレビュー ミーティング ソフトウエア 評価 製品バックログ 見直し スプリント(約30日) クロージャ ゴール スプリント繰返し
13.
現実的なエンタープライズアジャイル RDn ちゃんと地図は描く たまに地図を見る RD0 保守・運用のための 整備
14.
要求開発とアジャイル開発の究極コラボ 14 スプリント 要求 要求 一定のリズムで継続的にアウトプットを出し続ける工房 非同期バッファ リリース 新たな分業の始まりか スプリント スプリント スプリント スプリント リリース
リリース リリース リリース ・ ・ ・ ・ 個別システムを超えたポートフォリオ マネジメント 外注業者購買担当者設計担当者営業担当者顧客 見積依頼書を作成 する 見積依頼 の送付 見積依頼 の受領 見積依頼の確認 引合案件の登録 社内見積依頼の 作成 設計する 見積条件を検討す る 外注業者の選定を する 見積依頼書を作成 する 見積依頼 の送付 見積依頼 を受領す る 見積を実施する 見積書の 送付 見積書を 受領 見積内容を評価し て候補を絞り込む 見積計算を行う 見積書を作成する 見積書の 送付 見積書の 受領 見積回答の評価 受注フローへ 購入中止 の連絡 購入中止 の連絡を 受ける 失注の登録を行う [新規引合の場合] [再見積の場合] [外注委託加工が必要な場合] [再見積依頼] [発注] [購入中止] 要求開発 プロダクト バックログ プロダクト オーナー
15.
似て非なるRUPとアジャイル 比較項目 イテレーション開発 アジャイル 体制 特に規定はない。開発規模に合わ せて決める。作業ボリュームに合わ せて投入するリソースを調整する。 7±2名程度を1チームとする。基本的 には開発リソースは、開発期間中一 定。プロダクトオーナーやスクラムマ スターのような特殊な役割がある。 イテレーションの期間 比較的長い
(特に規定はないが1ヵ月~3ヵ月ぐ らい) 比較的短い (1~4週間ぐらい) イテレーションの考え方 各イテレーションに意味づけを与え、 それに応じて個々に期間を設定。イ テレーションの期間は一定とは限ら ない。 各イテレーションは期間を固定し、リ ズムを重視。見合うボリュームの作業 を優先順位に従いイテレーションにア サインする。 マネジメントコスト 開発組織が一定以上は、間接的コ ミュニケーションや全体統制のため のマネジメントコストが一定量発生 する 少人数の直接コミュニケーションを基 礎とするため、ドキュメントなどやマネ ジメントのオーバーヘッドを極小化す る 開発環境 一般的な生産性向上のための環境 整備を要する 短期間一定リズムで頻繁にリリース するため、継続的インテグレーション や自動テストなどオーバーヘッドを削 減する環境が望ましい 案件を主体に組み立てるか、人間のパフォーマンスを主体に組 み立てるか (変化を吸収するという目的は同じながら・・)
16.
エンタープライズアジャイルの構造 • プログラムマネジメント(ポートフォリオマネジメント)こそが重要 •
工房とフィーダー間を取り持つのが、プロダクトバックログ – 工房の生産リズムをエンジンにする – 本当の意味で上位目的の共有はできないが相手が大きすぎるの である程度いいか。(Plain Old Agile (POAGILE?)に比べて後 退?) • 全体の構造を把握して細かくちぎる – モデリングなしには成立しない – 疎結合のシステム構成で適正範囲を絞れる • リズムにはいるまでの段取りが必要 – 全体がでかい – 関連システムなど生態系をなしている。 リソース・開発サイクル固定の最適化された開発エンジンとそれにユーザーストーリー をフィードする構造が基本
17.
エンタープライズアジャイルでのお薦めモデリング • スプリント以前 –
要求モデル – 業務をとらえる3種のモデル • サービスモデル、概念モデル、業務フロー – アーキテクチャモデリング • 主要なパターン(設計クラス図とシーケンス図)とサンプルコーディング – ユースケース一覧 • プロダクトバックログへの展開 • スプリント中 – 詳細設計のモデルは省略する • 設計者と実装者が同じ • 詳細レベルはコードの方が表現できる – コミュニケーションのためのメモとしてモデルを多用する • 使い捨て前提 • リリース後、運用準備 – ポリシーによる(紙の形式か情報として残ればいいか) – 主要クラスと主要動作のシーケンス図、特殊なアルゴリズム – ユーザーストーリーの集約 – ビジネスルールの整理だけは怠りなく 17
18.
システム設計におけるモデリング 18
19.
オブジェクトモデルの考え方 • オブジェクトモデル – 役割をもったモノ(オブジェクト)が協調動作することによって特定の処理 (サービス)を実現するととらえるモデル –
銀行口座からの引出しは、役割分担した4人の連係プレーで実現される 窓口 顧客の要求受付、お金の引渡し アシスタント 処理のコントロール 口座管理係 口座管理データベースの更新 出納係 必要金額の出し入れと管理
20.
オブジェクトモデルの表現方法 サービスモデル 静的モデル 動的モデル システムユー スケース図 設計クラス図 設計シーケン ス図 何をするか 何がどうあるか どう動くか システムを構成するクラス群 それらのクラス(オブジェクト)がどのように協調し合うか 利用者と提供するサービス
21.
最低限の設計モデル • 似たようなシーケンス図は書く必要なし –
主要なユースケースを実現する主要なクラス間の役割分 担を確認できればOK。主なメソッドの洗い出し。 – 代表的な10パターン(当然規模による)をまず書いてみる。 パターンとして不足と思ったら、あと、10パターンをあげ てみる。さらに不足なら・・・・そんなには要らないはず • 経験的には – システム全体の動き(外枠・MVC的)を表現するものが数 パターン – ドメイン層の動きやクラスの役割を表現するものが、10 パターンもあれば・・・
22.
要求開発・要件定義におけるモデリング 22
23.
要求獲得のためのダイヤグラム • ビジネスユースケース図(ユースケース図) •
業務フロー図(アクティビティ図) • 概念クラス図(クラス図) ビジネスユー スケース図 概念クラス図 業務フロー図 システムユー スケース図 設計クラス図 要求開発(BA) システム開発 サービスモデル 静的モデル 動的モデル 何をするか 何がどうあるか どう動くか データ設計 図
24.
「これだけ」ビジネスユースケース図の例 サブジェクト ビジネスアクター ビジネスユースケース 関連 汎化関係 包含関係 include
25.
「これだけ」業務フロー図の例 アクション 初期ノード 最終ノード フォーク ジョイン 分岐 マージ
26.
「これだけ」概念クラス図の例
27.
引出しと共通理解のための概念モデル • 業務理解の概念モデルでアナリシスパターンを描かない –
抽象化しすぎるとかえって特徴がわからない • 概念モデルを引きずりすぎない – 使い捨ててもいい – プロセスが重要(引出しのツール) – 無理なトレーサビリティを求めない • 設計では別の概念が入ってきて折衷できないことが多い • 共通に認識している&残像がある でOK
28.
グループ演習 ~概念モデル作成~ • 各チーム(4~5名)で議論して1つの概念クラス図を作 成してください Ø 作成時間 30分
• 代表者1名を決めて、発表してください Ø 1チーム5分程度 ü モデルの概要 ü 特に議論になったところ
29.
概念モデルの題材 • 高校の履修管理業務の概念クラス図を作成しましょう Ø 例えば、次のような情報を網羅してください
ü 各生徒の履修している必須科目と選択科目 ü 各組に所属する生徒 ü 各組の担任 ü 教師と担当している講座 ※ 必要な情報を想像力で補ってモデルを完成させてください
30.
使う記法「これだけ」 • クラス •
クラス間の関係 – 汎化関係 – 関連 • 普通の関連 • 集約(全体と部分) • コンポジション(全体ともろともの部分:かなりオプション) 30
31.
モデリングをやってみて(よくある感想) • モデルを描こうとすることで不足情報を効率よく引き出せた •
それぞれ描いていた業務(この場合「履修管理」)の認識の 違いがよく理解できて、共通認識にまとめることができた • 単なる話し合いでは詰められなかった曖昧なところを明確に できた • 曖昧に使っていた言葉がはっきりと定義できた • 関係する業務を広めに議論してシステム化スコープの輪郭 がはっきりした • システムに着手するまでに業務ではっきりさせておくべきこと が認識できた • システムイメージができあがった • データベース構造がほぼ見えた 31
32.
運用管理の負荷 増大 グループの情報システム、インフラの管理・運営を実施情報システム部 経営情報のリア ルタイム把握 グループの経営戦略立案経営戦略室 業務効率化、精 度向上、迅速化 経理業務に加え、法務、総務機能の実施財務・経理 統制事項の追加内部統制監査の運営内部統制監査室 監査情報の信頼 性向上 監査の実施監査役 監査情報の信頼 性向上 財務諸表が会計原則に準拠しており、企業の財政状態 や経営状態を適正に表示しているか否かについての監 査を実施 監査法人 経営指標の迅速 な把握。経営の 見える化 会社経営の実施経営 想定される影響 (メリット・デメリッ ト) 説明ステークホルダー名 ビジネスユースケース/業務フロー/システムユースケース 発送する 商品在庫を確 認する 注文を受け付 ける 請求書を送付 する 注文をクローズ する 納品を確認する 支払いを確認 する 商品を発注 する 入金を調べ る 在庫センター 営業 経理
システム 入金管理システム 取引顧客 32 注文を登 録する ・・・・・・・・ ・・・・・・・・ ・・・・・・・・・・・・・・・・ ・・・・ ・・・・・・・・ ・・・・・・・・ ・・・・・・・ ・・・・・・・・ ・ ・・・・・・・・ ・・・・・・・・ 機能一覧 ビジネスユースケース 業務フロー ユースケース記述 システムユースケース アジャイルだと • フィーチャー • ユーザストーリー
33.
概念クラス図/設計クラス図/データ設計図 システムスコープに絞り込み 概念クラス図 (分析)クラス図 設計クラス図 永続化対象をテーブル化 実装に必要なクラスの追加 データ設計図
34.
モデルによる業務とシステムの連携 ビジネスモデリング システムモデリング
Download now