いまさらアジャイル巡業 In Tokyo アジャイルモデリング

ULS
Copyright © 2011-2016 UL Systems, Inc. All rights reserved.
Proprietary & Confidential Powered by
いまさらアジャイル巡業 in Tokyo 2016
アジャイルモデリング～モデルと動くソフトウェアの狭間で～

ULS
Proprietary & Confidential Powered by 1
自己紹介
 はじめまして
– 氏名：田上悠樹
– 所属：ウルシステムズ株式会社
– お仕事：エンジニア。エンタープライズ案件（製造業 SCM）の開発をやってます。
– コメント：
『いまさらアジャイル巡業シリーズ』は、2回目です。
『いまさらアジャイル巡業 in 広島』では、
Eric Evans 氏の『ドメイン駆動設計（DDD）』について、お話しました。
本日は、 Scott W. Ambler氏の『アジャイルモデリング』について、お話します。
http://blue-wind.net/photoimage/242

ULS 2
Introduction

ULS
Introduction
 床屋での一幕
– いつもの床屋の場合
– 初めての床屋の場合
お客さん床屋のご主人
いつもの
髪型で
あいよ！
確立された相互理解がある
要求理解
髪型のイメージ
お客さん
（PO）
床屋のご主人
（開発者）
えっ～と、
どう伝えよう
う～ん、よう
分からん
表現しにくい要求 ..
ふわっとした相互理解 ..
1度髪を切ったら、やり直しは次回 ..
髪型のイメージ
要求理解

ULS
Introduction
 床屋での一幕
– 幸い、髪型の見本帳がある。
つまり、
– 言語化しにくい要求は、モデルを介して相互理解を図った方が効率的。
– 髪を切る前にイメージを合わせておくことで、失敗や持ち越しのリスクを下げる。
– ソフトウェアの開発現場も、こうありたいものだ。
お客さん
（PO）
床屋のご主人
（開発者）
こんな
髪型で
ふむふむ、
あいよ！
モデルを介した相互理解
要求理解
髪型の見本帳

ULS 5
モデリング

ULS
 モデリングとは
モデリング
モデリングは、調査対象になっているソフトウェアが持つ顕著な側面を表現することで、意思
決定を容易にし、その内容を利害関係者に対して伝達するための体系的な手法。
― SWEBOK の一文から要約

ULS
モデリングの意義
 モデリング原則
SWEBOKに「モデリング原則」という形でモデリングの意義が示されている。
（以下、かなり要約して紹介。詳しくはSWEBOK参照）
プロジェクト関係者間で、要求や理解を効率的に情報伝達できれば無駄が減る。
結局は、プロジェクトファイナンスとして『お得』だからモデリングをする。
–本質をモデル化せよ
モデリングは、本質的でない情報から身を清めて、特定の側面について表現する。
–大局観を提供せよ
モデリングは、対象となっているソフトウェアに対して俯瞰的なビューを表現する。
–効果的な伝達を図れ
モデリングは、ソフトウェア情報を利害関係者に効果的に伝達する１つの報告手段。

ULS
ITシステムが持つ代表的な側面
 側面の分類
– 代表的な側面として、「振る舞い」「構造」「境界」「制約」が挙げられる。
振る舞い
システムが持つ挙動やフローといった動的側面を、イベントや時系列に沿って描写する。
– プロセス：業務フロー、ユーザーストーリーマッピング、カスタマージャーニーマップ
– 相互作用：コミュニケーション図、シーケンス図
– 状態：状態遷移図、タイミング図
構造
システムが持つ静的な構造側面を描写する。
– データ構造：概念データモデル、論理データモデル、物理データモデル
– 配置構造：配置図、コンポーネント図
– 組織構造：利用部門の組織図、ユーザーロールマップ
制約
判断ルール、計算方式といったシステムが持つロジックを描写する。
– ルール：ビジネスルール、ディシジョンテーブル
境界
システムとユーザ間のタッチポントや、異なるシステム間同士など異種の接続を描写する。
– インターフェイス：ユーザーインターフェイス、外部インターフェイス仕様

ULS
 要求とシステム像のギャップをモデルで埋める
– ふわっとした要求に対して、モデルを介してギャップを埋めて、最終的なシステム像に
漸近的に近づけていく。
要求とモデルのループ
モデル
要求
顧客・PO 開発者
モデルによる会話
モデルによって可視化された
情報を効率的に伝達して、顧
客・PO– 開発者間での相互
理解を深める。
モデルによる表現
モデリングの原則に従い、要求
を本質的かつ大局的に表現して、
顧客が意思決定しやすいモデル
を作成する。
要求の伝達
源泉となる要求を伝える。こ
の時点では、レベル感（ビ
ジョンの話や、細かいビジネ
スルールの話など）は様々。
要求の理解
ふわっとした要求を受け止め、
要求のレベル感や側面を加味
して、表現するのに適したモ
デルを選ぶ。
システム像
要求理解

ULS
疑問の声（1）
 でも、ちょっと待って
でも、モデルだけあってもね～。
イメージの限界があるわけで。。
結局さ、そのモデルは最終的に
どんなシステムや姿になんの？
絵に描いた餅？

ULS
モデルの限界
 そもそもモデルの表現に限界がある
– モデルは物事・現象のある側面を切り取って、理解したり、伝えたり、有意性を発見す
るのには役立つが、一方で、１つのモデルで全てを表現できるわけではない。
所詮、側面的な記述。実感が湧きづらい
 読み手に負荷を強いる
– モデル自体は実体を伴なわないので、読み手はモデルから実体をイメージする思考作業
を義務づけられる。書き手と読み手、読み手同士で思考に齟齬が生じる可能性もある。
イメージ作業は読み手に強く依存
 動かす前に作成するけど、動かしてみないと分からないジレンマ
– 逆説的だが、結局ソフトウェアとして実装してみないとモデルの妥当性は分からない。
最終的にはソフトウェアに依存

ULS
 コミュニケーションツールとしての動くソフトウェア
– アジャイル開発宣言で述べられている『動くソフトウェア』は、顧客・POと開発者間
での最もダイレクトなコミュニケーションツール。
– モデルで伝えきれない事に対しては、動くソフトウェアを使って伝える方が効率的。
（モデルで全てを効率的に伝えきれるという前提に立たない方がよい。）
– 特に、操作性やユーザー体験が重要なソフトウェアであれば、尚更。
「モデル」と「動くソフトウェア」を適所で組み合わせて、
効率的な情報伝達や正確な相互理解へとつなげる。
やっぱり、動くソフトウェアも重要
モデル
動くソフト
ウェア

ULS
モデルか !? 動くソフトウェアか !?
モデル動くソフトウェア
抽象的、概念的、俯瞰的キーワード具体的、実体感、直接的
直接、目で捉えられない全体像や
ルールを伝える面で優れている。
顧客への
伝達性
ソフトウェアの挙動や体験を確実に伝
えられる面で優れている。
簡単なモデルなら参加しやすいが、
専門的なモデルの場合は顧客にも一
定のモデル知識がないと成立しない。
顧客の
参加容易性
モデルに関する事前知識がなくとも、
直接的にソフトウェア挙動を体験でき
て意見交換にも参加しやすい。
相対的に小。
ミニマムだとホワイトボードにサッ
と描いたモデルで十分効果がある。
書き直し/使い捨ても比較的簡単。
作成コスト
相対的に大。
ただし場合によっては、伝達が困難な
複雑なモデルを作成するよりもサッと
作成した方が早い場合もある。
「モデル」だけでは伝え切れないものがあり、
「動くソフトウェア」だけでは表現しきれないものもある。
お互いを補完して協調する手法の1つとして
「アジャイルモデリング」がある。

ULS 14
アジャイルモデリング

ULS
 アジャイルモデリング
– Scott W. Ambler氏が提唱しているモデリング手法。
（以降、AM=Agile Modeling と略す）
– 機敏にモデリングを実施していく上での、5つの価値、18の原則、21のプラクティスか
らなる心得集。RUP のようにプロセスや成果物を全て定義した包括的方法論ではない。
– 過剰にドキュメントやモデルを作成する派閥と、そんなの役に立たないと考える派閥の
間で、AMは程良くモデリングを行うためのやり方を提供。
– 本体のアジャイルプロセス（XP、Scrumなど）に合わせてプラガブルに適用して、要求
開発や設計の領域で本体を補完する関係。（非アジャイル系開発でも部分適用可）
概要
http://www.ambysoft.com/scottAmbler.html
http://www.shoeisha.co.jp/book/detail/9784798102634
アジャイル開発プロジェクト
メインを補完する
プラクティス群
メインの開発プロセス XP, Scrum, DAD …
AM XXツール XX

ULS
AMの価値・原則・プラクティス
AM 5つの価値
フィードバック簡潔さコミュニケーション勇気謙虚さ
AM 18の原則
ソフトウェアが
第一のゴール
変化を受け入れよう複数のモデル素早いフィードバック
利害関係者の投資を
最大限に活かそう
次の備えが第2のゴール身軽な旅簡潔さを心がけよう少しづつ変更する質の高い仕事をしよう見栄えより中身
目的を持って
モデリングしよう
誰しも他人から学べるモデルを知ろう実状に合わせよう
オープンで正直な
コミュニケーション
直感に従って開発しよう道具を知ろう
AM 21のプラクティス
複数のモデルを並行
して作ろう
少しずつモデリング
しよう
コードで確かめよう
取り決めモデルはきち
んと定義しよう
理解するために
中身はシンプルに
作ろう
適切な成果物を使おう他の成果物に移ろう
他の人と一緒に
共同所有モデルを公開しよう
モデルはシンプルに
書こう
テストできるか
考えよう
モデリング標準を
適用しよう
既にある資産を
再利用しよう
利害関係者の
積極的な参加
最も簡単な道具を使おう
パターンは控えめに
使おう
一時的なモデルは
捨てよう
話すためにモデリング
しよう
困ったときだけ
更新しよう

ULS
AMの価値
 AMの価値
– AMの根底にある哲学。
 ピックアップ
AM 5つの価値
フィードバック簡潔さコミュニケーション勇気謙虚さ
– コミュニケーション：
AMが指すコミュニケーションとは、関係者間で効果的に情報を伝達すること。モデルを
作成する理由の１つが、まさにコミュニケーションを良くするため。
– フィードバック：
モデルが正しいかどうかは、フィードバックを通じてのみ確認することができる。
POや利用者からレビューを受けたり、モデルをソフトウェアとして実装して、実際に
使ってみてもらうとよい。

ULS
AMの原則
 AMの原則
– 上位価値に基づき、ソフトウェア開発で何をすべきかの具体的な指針。
AM 18の原則
ソフトウェアが
第一のゴール
変化を受け入れよう複数のモデル素早いフィードバック
利害関係者の投資を
最大限に活かそう
次の備えが第2のゴール身軽な旅簡潔さを心がけよう少しづつ変更する質の高い仕事をしよう見栄えより中身
目的を持って
誰しも他人から学べるモデルを知ろう実状に合わせよう
オープンで正直な
コミュニケーション
直感に従って開発しよう道具を知ろう
–ソフトウェアが第一のゴール：
利害関係者のニーズを効果的に満たす高品質のソフトウェアを開発することが大事。我々
ソフトウェア開発者は、ドキュメント開発者でもモデル開発者でもない。
–複数のモデル：
モデルの種類は広範囲に存在するが、すべての状況に適用可能な単一の成果物というのは
ない。ソフトウェアを効果的に表現するには、複数のモデルを併用する必要がある。

ULS
AMのプラクティス
 AMのプラクティス
– AMの価値・原則から導かれる実際のプロジェクトで適用すべき手法。
AM 21のプラクティス
複数のモデルを並行
して作ろう
少しずつモデリング
しよう
コードで確かめよう
取り決めモデルはきち
んと定義しよう
理解するために
中身はシンプルに
作ろう
適切な成果物を使おう他の成果物に移ろう
他の人と一緒に
共同所有モデルを公開しよう
モデルはシンプルに
書こう
テストできるか
考えよう
モデリング標準を
適用しよう
既にある資産を
再利用しよう
利害関係者の
積極的な参加
最も簡単な道具を使おう
パターンは控えめに
使おう
一時的なモデルは
捨てよう
話すためにモデリング
しよう
困ったときだけ
更新しよう
– コードで確かめよう：
表現したモデルが大丈夫かどうか、対応するコードで実際に確かめる。
– 取り決めモデルはきちんと定義しよう：
異なるグループ間での連携仕様については、双方のグループ間での合意のもと、きっちり
と取り決めモデルを定義して、継続的にモデルを保守していく。

ULS
AM のスイートスポット
「モデル」と「動くソフトウェア」
の良い関係
とにかくドキュメントやモデル
の作成が信条の官僚スーツ族
ソースコード以外は役に立たない
という過激なギーク族
AMのスイート
スポット
持つべつ心得持つべき心得
ドキュメントやモデルだけでは顧客に伝達し
きれない部分をソフトウェアで表現してみる。
情報伝達
目の前のソフトウェアだけでは伝えられない、
目に見えない動作、俯瞰的な要素も共有する。
ドキュメントやモデルを量産して自己満足し
ても駄目。最終的なゴールはソフトウェア。
ゴール意識
ゴールを外さないように、利害関係者の想い
を理解し、モデルを介して共通理解を持つ。
※ 上の二人の設定は、極端かもしれませんが、、、

ULS
疑問の声（2）
そりゃ～、モデルと動くソフト
ウェアの両方のアプローチとった
ほうが充実するよ。
けど、限られた時間で両方を
やるのは大変じゃない？

ULS
モデルの作成対象の方針
 作成対象の方針
AMではモデル作成対象について「これと、これを作れ」という具体的なルールはないが、
以下の方針が挙げられている。
– ちょうど必要な量だけのドキュメントやモデルを作成する
作る/作らないの二元論ではなく、プロジェクトに応じてちょうど必要な量を作成する。
但し、あくまでソフトウェアが第一のゴール。モデルだけでは価値を還元できない。
– 複数のモデルを作成する
１つのモデルで表現できる側面には限りがあるので、複数のモデルを適切に選択して、
相互補完するように表現する。（参考：AMで紹介されているモデル一覧を次頁記載。）

ULS
（参考） AM で紹介されているモデル一覧
UMLでお馴染みのモデルも含め広範囲にモデルとして紹介されている。
# モデル # モデル
1 アクティビティ図 (UML) 17 用語集
2 ビジネスルール定義 18 ネットワーク図
3 変更案 19 組織図
4 クラス図 (UML) 20 物理プロトタイプ
5 CRCカード 21 ロバストネス図
6 コラボレーション図 (UML) 22 シーケンス図 (UML)
7 コンポーネント図 (UML) 23 仕様言語 (OCL)
8 制約定義 24 ステートチャート図 (UML)
9 データ図 25 構造図
10 配置図 (UML) 26 システムユースケース
11 データフロー図 (DFD) 27 技術的要求事項
12 外部インターフェイス仕様 28 利用シナリオ
13
本質ユーザインターフェイス (UI)
プロトタイプ
29 ユースケース図 (UML)
14 本質ユースケース 30 ユーザーインターフェイスフロー図
15 開発項目 31 ユーザーインターフェイスプロトタイプ
16 フローチャート 32 ユーザーストーリー

ULS
疑問の声（3）
ちょうど必要な量と言うけれども、
それはプロジェクトによって異なる。
せめて、目安はないの？

ULS
 そもそも、何が把握できたらプログラムに落とせるのか？
– 要求の全体像（マクロの視点）
プロジェクトの大義（Why）を踏まえた上で、何（What）を、どう（How）作るか。
– 要求の各側面（ミクロの視点）
ソフトウェアを形づくる代表的な４つの側面。
プログラムに落とすための主要な材料
プログラムに落とすための材料
プログラム
振る舞い構造
境界制約
要求階層とモデル
ビジネス要求
業務要求
システム要求
Why: インセプションデッキ
What: 要求モデル
How: 設計モデル

ULS
 プログラムに落としこむのに必要な材料から考えてみた
– ちょうど必要な量＝要求階層ごとに、4つの側面を表現できる量
– 8つのマスにどのモデル群を採用するかを判断する。8つのマスすべてを埋める必要も
ない。ただ、特定のマスだけにモデルが偏るのはバランスがよくない。
– 少ない手数で縦軸の４つ（振る舞い・構造・境界・制約）が埋まると効率的。
– 特に、設計モデルの作成量はチーム内で調整しやすいので、開発者間のあうんの呼吸で
理解が成立するなら削減OK。
ちょうど必要な量の目安
要求モデル
（主な会話相手：顧客・PO・開発者）
設計モデル
（主な会話相手：開発者）
振る舞い
構造
境界
制約
設計モデルは、作成量を調整しやすい
※ 各マスに入れているモデルは一例
ユーザーストーリーマッピングロバストネス図
概念データモデルデータモデル
ユーザーインターフェイスプロトタイプ外部インターフェイス仕様
ビジネスルールディシジョンテーブル

ULS
なんだかんだで、AMとは
「モデル」と「動くソフトウェア」を馴染ませるソフトウェア開発者のためのモデリング技法
アジャイルモデリング
• 伝達面でのお互いの長所・短所を補う
• モデリング作業と実装作業のバランス
モデル
動くソフト
ウェア
効率的な情報伝達
顧客・PO・開発者

ULS 28
Summary

ULS
Summary
 本日お話した内容：
– システム開発の現場では、言語化しにくい要求がたくさん存在する。
– そういった要求に対しては、モデリングというアプローチで要求を可視化して表現した
方が効果的で経済的。
– ただ、残念ながらモデルで全てを表せるわけではない。実際のソフトウェアになってみ
ないと判断しづらいポイントもある。
– そこで、「モデル」と「動くソフトウェア」と上手くバランスさせるモデリング技法
『 AM（Agile Modeling）』の概要を紹介した。
– 最後に、「ちょうど必要な量のモデル」について、各観点の立場（振る舞い・構造・境
界・制約 × 要求・設計）をふまえて考えてみた。
以上、ご清聴ありがとうございました。
ページ中で利用したアイコン素材： http://icooon-mono.com/

いまさらアジャイル巡業 In Tokyo アジャイルモデリング

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (19)

Similaire à いまさらアジャイル巡業 In Tokyo アジャイルモデリング

Similaire à いまさらアジャイル巡業 In Tokyo アジャイルモデリング (20)

Plus de Yuki Tagami

Plus de Yuki Tagami (13)

いまさらアジャイル巡業 In Tokyo アジャイルモデリング