Xp祭り2013

Copyright © 2013特定非営利活動法人 UMLモデリング推進協議会 All rights reserved
1
モデリングからはじめる
アジャイルへの第一歩
UMLモデリング推進協議会(UMTP)
アジャイル開発部会
ネットイヤーグループ㈱小倉英一郎
中菱エンジニアリング㈱古川剛啓

2
目次
• UMTP紹介
• なれる！アジャイルなエンジニア
モデリングで始められる！？
（もっと）アジャイルなチームづくり
（ガイドライン紹介）
• 要求導出へのモデリング技術とアジャイル
プラクティスの適用
（ガイドライン紹介）

UMTP/Japanとは
• Consortium for UML based Modeling Technologies Promotion
Japan （会長上野南海雄ｼﾞｬﾊﾟﾝｼｽﾃﾑ（株）監査役）
• 2003年5月19日設立、NPO法人
• 設立発起人：21団体個人:
IBM-japan、HITACHI、FUJITSU、NEC、TOSHIBA、NEXS,NTT Data、Suntory 、Oracle-japan、
Sunmoretec、CATS、Technologic Arts、Toyo Technica、Unisys-japan、Rational Software-japan、
NRI 、Mamezou、Aithent Inc. Japan.、Learning Architecture研究所、Horiuchi（Tokyo
International University）、OGIS-RI
• 会員数：38団体・個人(2013年8月現在)
• 目的（事業）
* モデリング技術の研究活動
* モデリング技術の普及
* 認定事業：技術者認定試験、コンテンツの認定
* アジアを中心とした国際連携
3

活動内容
• UML用語集の策定
Eng/Chn/Jpn
• UML技能認定試験
• 書籍、トレーニングテキストの認定
• モデリング技術の開発
オフショア開発へのUML適用、
組込モデリングカタログの作成、
アジャイル開発とモデリング、etc.
• モデリングフォーラム東京 , 2004 ～
• 各種セミナーの開催：
• 国際連携：セミナー開催、認定試験
0
5000
10000
15000
20000
25000
30000
35000
0
100
200
300
400
500
600
700
800
04/04
04/07
04/10
05/01
05/04
05/07
05/10
06/01
06/04
06/07
06/10
07/01
07/04
07/07
07/10
08/01
08/04
08/07
08/10
09/01
09/04
09/07
09/10
10/01
10/04
10/07
10/10
11/01
11/04
11/07
11/10
12/01
12/04
12/07
12/10
13/01
13/04
受験者数累計
月間受験者数
UMTP認定試験受験者数
4

5
アジャイル開発＋UMLの事例セミナーの様子
2012年3月28日
㈱チェンジビジョン平鍋氏

6
2012年11月29日
楽天㈱藤原氏
2013年2月25日
NECビッグローブ㈱松浦氏
6
アジャイル開発＋UMLの事例セミナーの様子

7
2013年8月27日
合同会社カルチャーワークス本橋氏
他団体（IPA）との交流（セミナー）の様子

なれる！アジャイルなエンジニア
モデリングで始められる！？
（もっと）アジャイルなチームづくり
（ガイドラインの紹介）

UMTP-L3
OCUP Advanced
Scrum Product Owner
Information Security Specialist
Eiichiro Ogura
Technologist

ウォーターフォールと
アジャイル

ウォーターフォール開発
細かく全てを事前に決定していく

手戻り… 最初から

むりやり仕様変更… がっかり品質

アジャイルなソフトウェア開発
イテレーション単位でビジネス価値を届ける

遠いものは粗々でも大丈夫

まだ作ってないものは変えても大丈夫

違いがたくさんある…
• 作る順番
• 何がプロセスを駆動するか
• 成功の定義
• 変更がプロセスに与える影響
など

モデリングで取り扱う概念

粒度
取り扱う事物には大きさがある

複雑さ / 簡潔さ
適宜まとめなおすことで簡潔に取り扱う

静的 / 動的
構造と相互作用を区別する

抽象 / 具象
具体的なものの背後にある抽象性を取り扱う
アルコール
カクテル
容器
グラス
ボトル

抽象 / 具象
具体的なものの背後にある抽象性を取り扱う
【容器】
カクテルグラス
【カクテル】
グラスホッパー
クレームドカカオ
ホワイト
ミント
リキュール
生クリーム

なぜモデリングスキルが重要？

アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

著者
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

彼らが提唱・利用していたもの
• オブジェクトモデリングを全面的に組み込んだ開発プロセス
Steve Mellor / Shlaer-Mellor method
Jon Kern / Coad/Yourdon method
Robert C. Martin / Booch method
• インクリメンタルで変化を受け入れる開発プロセス
Arie van Bennekum / DSDM
Jim Highsmith / ASD
Alistair Cockburn / Crystal Clear
Ken Schwaber & Jeff Sutherland & Mike Beedle/ SCRUM
• パターンを用いたオブジェクトモデリング
Ward Cunningham & Kent Beck / Using Pattern Languages for Object-Oriented Programs
Martin Fowler / Analysis Pattern

アジャイルとモデリングの関係
• アジャイルソフトウェア開発宣言の著者らのベ
ーススキルとして、オブジェクト指向（を用いた
モデリング）やインクリメンタルな開発プロセスが
ある
• アジャイルソフトウェア開発宣言のベースライン
としてオブジェクト指向やモデリングがある
• モデリングを理解することで、アジャイルなソフト
ウェア開発を円滑に進めることができる

パターン

パターン名
フォース解決
コンテキスト問題

後から設計する
設計について知っているので、
改善できることを知っている。
設計に対する知見があること
で、実装中も常に設計を改善
することができる。実装しなが
ら設計を改善することで、コー
ドの一貫性を維持し、モデルを
明快に保つことができる。
設計はほどほどにして、動くコ
ードを作り始めた。
コピペやトランザクションスクリ
プトで実現している機能がたく
さんある。

必要最小限のドキュメント
成果物の中に設計文書が定
義されていないため、作る理
由がない。
ドキュメントを省いて、開発が
難しくなるのであればそれは本
末転倒。プレーンテキストや写
真でよいので、チームにとって
有益なドキュメントやモデルを
作り共有する。
プロセスを採用しており、全員
コードを書いている。
ドキュメントがないせいで、逆に
開発がやりにくい。

ほどほど
全ての情報が事前に手に入る
わけではない。先のことは誰に
も分からない。
分からないものを頭で考え抜
いても、それが正しいか分から
ない。分かるところまではしっ
かりと考えるが、そこから先は
ざっくりとしか見通さない。
ソフトウェアアーキテクチャに関
係する事柄なので、ある程度
しっかりと考えて作りたい。
どこまで作るべきなのか分から
ない。

2段階の開発
作るものが事前に明らかにな
っている部分があり、そこは変
更を前提にする必要がない。
何を作るのかが事前に明らか
であれば、そこはウォーターフ
ォールで作る。出来上がった
成果物を利用し、残りをアジャ
イルで完成させる。
システム全体で使う共通的な
モジュールがあり、その上にビ
ジネスモデルを構築する。
共通モジュールをアジャイル
で作るのはかえって効率が悪
いような気がする…

失敗とは書かない
失敗には区別がなく、すべから
く悪い失敗であると認識される
文化がある。どんなことであれ
、失敗だと表現することが不利
益になる。
Problemに失敗したことは書か
ない。理由や原因だけを書き
、成功か失敗かは文面からは
読み取れないようにする。
KPT(Keep, Problem, Try)を使
って振り返りをしている。
Problem（問題）に失敗したこと
を書きたくない。

今日はここまで
パターンの残りを含めた、ガイドラインの全文は
来年3月に公開予定です。

ご清聴ありがとうございました

40
要求導出へのモデリング技術と
アジャイルプラクティスの適用
（ガイドラインの紹介）

41
自己紹介
ふるかわよしひろ
古川剛啓
中菱エンジニアリング㈱
UMTP L3モデラー
OMG Advanced
認定スクラムマスター
UMTP アジャイル開発部会メンバ
名古屋アジャイル勉強会スタッフ

42
 昨今、ソフトウェア開発に携わる人々の間で
「アジャイル」というキーワードがよく聞かれるように
なっている。
 特にアイデアを素早く形にし、市場に提供すること
がより利益を生むようなサービス業ではこの傾向が
より顕著に表れている。
 組み込みソフトウェア業界では、アジャイル
ソフトウェア開発の需要が低い状況にある。
まえがき

43
 組み込みソフトウェアはUMLと親和性が高い。
クラス図は、ハードウェアとソフトウェアの境界を明確にし、
ハードウェアとソフトウェアの結合を疎にすることが容易
ステートマシン図は、イベント駆動型プログラムの動作を
記述するのに最適等
 UML等を活用したモデル駆動開発は、以下の特徴がある。
ユースケース単位で開発することができる
モデルを繰り返し検討することでより洗練された高品質な
ソフトウェアが製作可能
 この様な背景から、ガイドラインは組み込みソフトウェアの技
術者を対象とした。
まえがき

44
 抽象度の高いモデルと具象度の高いアジャイルプラクティスを組み
合わせることにより、高いレベルで開発者間の意識共有がされると
共に、スプリント毎に妥当性確認がされるスピーディーで確実な開
発を行うことを目指す。
• Scrumでは規定されていないプロダクトバックログアイテムの
発見手法を説明
• プロダクトバックログにユースケース図を使用することを提案
• ユースケース図の説明にアジャイルプラクティスを使用
UMLやアジャイル関連書籍とどこが違うのか
http://www.scrumalliance.org/why-scrum
この辺が対象

45
マインドマップを使って要求を聞き取る
ユーザ要求聞き取り
テンプレート
何を管理したいですか
どんな場面で使用しますか
宿題誰が使用しますか
誰が恩恵を受けますか
動機は何ですか
2012年3月28日セミナー
㈱チェンジビジョン平鍋氏講演資料より
テンプレート化されたマインドマップを足掛かりにユーザの要求を見える化していく

46
マインドマップからユースケース図を作成する
求聞き取り
ート
どんな場面で使用しますか
誰が使用しますか
誰が恩恵を受けますか
動機は何ですか
ユースケース図の
モデル要素
ユースケース（）
アクター（）

ユースケース図(例)
アクター
（人や外部システム）
システムバウンダリ
(開発対象システムと外との境界）ユースケース
（開発対象機能）
47

ユースケース図を作成する際のポイント
（教科書的に）
ユースケースの粒度を揃える
⇒ 見積りの精度向上のため
ユースケース毎にユースケース仕様書を書く
⇒ ユースケースの仕様を明確にする
アクターは「役割」を表す
⇒ 同じ人でも役割によって使用する機能が
異なる
48

ユースケースの粒度が細かくなりすぎる
ユースケース仕様書を書くのに時間が掛かる
ユースケースを捨てられない
システムやアクターはそれ程分析されない
実際にやってみると・・・
http://www.flickr.com/photos/genbug/3424589979/49

ユースケースの規模を相対サイズで見積る
そもそも粒度は揃わない
アジャイルではフィーチャーは相対サイズで
見積るため粒度は気にしていない
50 http://www.flickr.com/photos/adambindslev/4639871328/
ならば、アジャイルプラクティスに倣って
ユースケースの規模を相対サイズで見積ればいい

51
先ずはユーザーストーリーを使う
ユーザーストーリーとは、実現したい
と思っているフィーチャーを簡潔に示
したもので、短い文章として表したも
の
メリット
作成に時間が掛からない
フィーチャーの本質を捉える事ができる
ユースケースの粒度によらない
http://www.flickr.com/photos/psd/8591351239/
ユースケース仕様書は適切なタイミングで必要な量だけ書く

ペルソナを使ってアクターを定義する
http://www.flickr.com/photos/campusparty/4837562909
「役割」だけだと「どんな人」が使うことを想定
しているか曖昧
52
ペルソナによりアクターを詳細に定義し、
想定ユーザを明確にする

53
エレベータピッチを使ってシステムを説明する
http://www.flickr.com/photos/european_parliament/4767798097
ユースケース図に於いて「システム」は単なる「枠」
描かれない場合もある
エレベータピッチ（システムの本質を表す短い
文章）を使いどんなものを作るかを明確に
定義する53

54
ユースケースの優先順位を決める
ユースケースの価値から優先順位
を決める
•ユーザーストーリーマッピング
•狩野モデル
ユースケースの関連を考慮する
•ユースケース図
技術的リスクを考慮する
•開発チームの意見 http://www.flickr.com/photos/mrsj1/4441258474

http://www.flickr.com/photos/49942291@N06/6271934371/
ユーザーが体験するタスクの順番毎
（ワークフロー）にユースケースをマッピング
最小の価値を有する製品（MVP）を構成する
ユースケースから優先順位を決定する
ユーザー
（アクター）
ユーザーストーリーマッピング
55

56
狩野モデル
ユースケースをカテゴリー分けし、優先順位を決定する
① 当たり前、または必須のユースケース
⇒ 製品に欠かせない
② 線形、一元的なユースケース
⇒ あればある程良い
③ 魅力的な、わくわくするユースケース
⇒ 大きな満足をもたらす
以上のカテゴリーを基に価値を考えると・・・
当たり前のユースケースは全て備える
線形のユースケースをできる限り多く備える
①
③ ②
ユースケース量
満
足
度

57
ユースケース間の依存を考慮する
UC_1 UC_2
≪include≫
UC_3
≪extend≫
UC_1は、UC_2を包含する
UC_4は、UC_3を拡張する
従って、優先順位は
UC_2 ＞ UC_1
UC_3 ＞ UC_4 だが
UC_1とUC_4は別の観点での優先順位付けが必要
UC_4

技術的リスクは付きもの
技術的リスクは早期に解消する
技術的リスクを把握しているのは開発チーム
技術リスクを考慮する
58
要求元と開発チームが協力しリスク解消の
優先順位を決定する http://www.flickr.com/photos/purecaffeine/4325390829/

59
1
３５６
２４５
３２高
低
中
高低中
価
値
を
基
に
し
た
順
位
技術的リスクを基にした順位
マスの中の数字は優先度を表す
数字が小さいほど優先度が高い
価値を基にした順位と技術的リスクをマッピングする

60
本日説明したガイドラインは来年３月に
リリース予定です。
最後に

ご清聴ありがとうございました。

Xp祭り2013

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Xp祭り2013

Similar a Xp祭り2013 (20)

Último

Último (11)

Xp祭り2013