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

ULSCopyright © 2011-2016 UL Systems, Inc. All rights reserved.

Proprietary & Confidential Powered by

いまさらアジャイル巡業 in Tokyo 2016

アジャイルモデリング～モデルと動くソフトウェアの狭間で～


Proprietary & Confidential Powered by 2

自己紹介

はじめまして

– 氏名：田上悠樹

– 所属：ウルシステムズ株式会社

– お仕事：エンジニア。エンタープライズ案件（製造業 SCM ）の開発をやってます。

– コメント：

『いまさらアジャイル巡業シリーズ』は、 2 回目です。

『いまさらアジャイル巡業 in 広島』では、Eric Evans 氏の『ドメイン駆動設計（ DDD ）』について、お話しました。

本日は、 Scott W. Ambler 氏の『アジャイルモデリング』について、お話します。

http://blue-wind.net/photoimage/242

ULS 3Copyright © 2011-2016 UL Systems, Inc. All rights reserved.


Introduction



Introduction 床屋での一幕

– いつもの床屋の場合

– 初めての床屋の場合

お客さん床屋のご主人

いつもの髪型

で

あいよ！

確立された相互理解がある

要求理解

髪型のイメージ

お客さん（ PO ）

床屋のご主人（開発者）

えっ～と、どう伝えよ

う

う～ん、よう分からん

表現しにくい要求 ..ふわっとした相互理解 ..

1 度髪を切ったら、やり直しは次回 ..

髪型のイメージ

要求理解



Introduction 床屋での一幕

– 幸い、髪型の見本帳がある。

つまり、

– 言語化しにくい要求は、モデルを介して相互理解を図った方が効率的。

– 髪を切る前にイメージを合わせておくことで、失敗や持ち越しのリスクを下げる。

– ソフトウェアの開発現場も、こうありたいものだ。

お客さん（ PO ）

床屋のご主人（開発者）

こんな髪型で

ふむふむ、あいよ！

モデルを介した相互理解

要求理解

髪型の見本帳



モデリング



モデリングとは

モデリング

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

― SWEBOK の一文から要約



モデリングの意義

モデリング原則

SWEBOK に「モデリング原則」という形でモデリングの意義が示されている。（以下、かなり要約して紹介。詳しくは SWEBOK 参照）

プロジェクト関係者間で、要求や理解を効率的に情報伝達できれば無駄が減る。結局は、プロジェクトファイナンスとして『お得』だからモデリングをする。

– 本質をモデル化せよモデリングは、本質的でない情報から身を清めて、特定の側面について表現する。

– 大局観を提供せよモデリングは、対象となっているソフトウェアに対して俯瞰的なビューを表現する。

– 効果的な伝達を図れモデリングは、ソフトウェア情報を利害関係者に効果的に伝達する１つの報告手段。



IT システムが持つ代表的な側面

側面の分類– 代表的な側面として、「振る舞い」「構造」「境界」「制約」が挙げられる。

振る舞い

システムが持つ挙動やフローといった動的側面を、イベントや時系列に沿って描写する。– プロセス：業務フロー、ユーザーストーリーマッピング、カスタマージャーニーマップ– 相互作用：コミュニケーション図、シーケンス図– 状態：状態遷移図、タイミング図

構造

システムが持つ静的な構造側面を描写する。– データ構造：概念データモデル、論理データモデル、物理データモデル– 配置構造：配置図、コンポーネント図– 組織構造：利用部門の組織図、ユーザーロールマップ

制約判断ルール、計算方式といったシステムが持つロジックを描写する。– ルール：ビジネスルール、ディシジョンテーブル

境界システムとユーザ間のタッチポントや、異なるシステム間同士など異種の接続を描写する。– インターフェイス：ユーザーインターフェイス、外部インターフェイス仕様



要求とシステム像のギャップをモデルで埋める– ふわっとした要求に対して、モデルを介してギャップを埋めて、最終的なシステム像に漸近的に近づけていく。

要求とモデルのループ

モデル

要求

顧客・PO 開発者

モデルによる会話

モデルによって可視化された情報を効率的に伝達して、顧客・ PO– 開発者間での相互理解を深める。

モデルによる表現

モデリングの原則に従い、要求を本質的かつ大局的に表現して、顧客が意思決定しやすいモデルを作成する。

要求の伝達

源泉となる要求を伝える。この時点では、レベル感（ビジョンの話や、細かいビジネスルールの話など）は様々。

要求の理解

ふわっとした要求を受け止め、要求のレベル感や側面を加味して、表現するのに適したモデルを選ぶ。

システム像

要求理解



疑問の声（ 1 ）

でも、ちょっと待って

でも、モデルだけあってもね～。

イメージの限界があるわけで。。

結局さ、そのモデルは最終的にどんなシステムや姿になんの？

絵に描いた餅？



モデルの限界

そもそもモデルの表現に限界がある– モデルは物事・現象のある側面を切り取って、理解したり、伝えたり、有意性を発見

するのには役立つが、一方で、１つのモデルで全てを表現できるわけではない。

所詮、側面的な記述。実感が湧きづらい

読み手に負荷を強いる– モデル自体は実体を伴なわないので、読み手はモデルから実体をイメージする思考作

業を義務づけられる。書き手と読み手、読み手同士で思考に齟齬が生じる可能性もある。

イメージ作業は読み手に強く依存

動かす前に作成するけど、動かしてみないと分からないジレンマ– 逆説的だが、結局ソフトウェアとして実装してみないとモデルの妥当性は分からな

い。

最終的にはソフトウェアに依存



コミュニケーションツールとしての動くソフトウェア

– アジャイル開発宣言で述べられている『動くソフトウェア』は、顧客・ PO と開発者間での最もダイレクトなコミュニケーションツール。

– モデルで伝えきれない事に対しては、動くソフトウェアを使って伝える方が効率的。（モデルで全てを効率的に伝えきれるという前提に立たない方がよい。）

– 特に、操作性やユーザー体験が重要なソフトウェアであれば、尚更。

「モデル」と「動くソフトウェア」を適所で組み合わせて、効率的な情報伝達や正確な相互理解へとつなげる。

やっぱり、動くソフトウェアも重要

モデル動くソフトウェア



モデルか !? 動くソフトウェアか !?


抽象的、概念的、俯瞰的キーワード具体的、実体感、直接的

直接、目で捉えられない全体像やルールを伝える面で優れている。

顧客への伝達性

ソフトウェアの挙動や体験を確実に伝えられる面で優れている。

簡単なモデルなら参加しやすいが、専門的なモデルの場合は顧客にも一定のモデル知識がないと成立しない。

顧客の参加容易性

モデルに関する事前知識がなくとも、直接的にソフトウェア挙動を体験でき

て意見交換にも参加しやすい。

相対的に小。ミニマムだとホワイトボードにサッと描いたモデルで十分効果がある。書き直し /使い捨ても比較的簡単。

作成コスト

相対的に大。ただし場合によっては、伝達が困難な複雑なモデルを作成するよりもサッと作成した方が早い場合もある。

「モデル」だけでは伝え切れないものがあり、「動くソフトウェア」だけでは表現しきれないものもあ

る。

お互いを補完して協調する手法の 1 つとして「アジャイルモデリング」がある。



アジャイルモデリング




– Scott W. Ambler 氏が提唱しているモデリング手法。（以降、 AM=Agile Modeling と略す）

– 機敏にモデリングを実施していく上での、 5 つの価値、 18 の原則、 21 のプラクティスからなる心得集。 RUP のようにプロセスや成果物を全て定義した包括的方法論ではない。

– 過剰にドキュメントやモデルを作成する派閥と、そんなの役に立たないと考える派閥の間で、 AM は程良くモデリングを行うためのやり方を提供。

– 本体のアジャイルプロセス（ XP 、 Scrum など）に合わせてプラガブルに適用して、要求開発や設計の領域で本体を補完する関係。（非アジャイル系開発でも部分適用可）

概要

http://www.ambysoft.com/scottAmbler.htmlhttp://www.shoeisha.co.jp/book/detail/9784798102634

アジャイル開発プロジェクト

メインを補完するプラクティス群

メインの開発プロセス XP, Scrum, DAD …

AM XXツール XX



AM の価値・原則・プラクティス

AM 5 つの価値

フィードバック簡潔さコミュニケーション勇気謙虚さ

AM 18 の原則ソフトウェアが第一のゴール変化を受け入れよう複数のモデル素早いフィードバック利害関係者の投資を

最大限に活かそう

次の備えが第 2 のゴール身軽な旅簡潔さを心がけよう少しづつ変更する質の高い仕事をしよう見栄えより中身

目的を持ってモデリングしよう誰しも他人から学べるモデルを知ろう実状に合わせよう

オープンで正直なコミュニケーション

直感に従って開発しよう道具を知ろう

AM 21 のプラクティス

複数のモデルを並行して作ろう

少しずつモデリングしようコードで確かめよう取り決めモデルはき

ちんと定義しよう理解するために

モデリングしよう

中身はシンプルに作ろう適切な成果物を使おう他の成果物に移ろう他の人と一緒に

モデリングしよう共同所有モデルを公開しよう

モデルはシンプルに書こう

テストできるか考えよう

モデリング標準を適用しよう

既にある資産を再利用しよう

利害関係者の積極的な参加

最も簡単な道具を使おうパターンは控えめに使おう

一時的なモデルは捨てよう

話すためにモデリングしよう

困ったときだけ更新しよう



AM の価値

AM の価値– AM の根底にある哲学。

ピックアップ

AM 5 つの価値

フィードバック簡潔さコミュニケーション勇気謙虚さ

– コミュニケーション：AM が指すコミュニケーションとは、関係者間で効果的に情報を伝達すること。モデルを作成する理由の１つが、まさにコミュニケーションを良くするため。

– フィードバック：モデルが正しいかどうかは、フィードバックを通じてのみ確認することができる。PO や利用者からレビューを受けたり、モデルをソフトウェアとして実装して、実際に使ってみてもらうとよい。



AM の原則

AM の原則– 上位価値に基づき、ソフトウェア開発で何をすべきかの具体的な指針。

ピックアップ

AM 18 の原則ソフトウェアが第一のゴール変化を受け入れよう複数のモデル素早いフィードバック利害関係者の投資を

最大限に活かそう

次の備えが第 2 のゴール身軽な旅簡潔さを心がけよう少しづつ変更する質の高い仕事をしよう見栄えより中身

目的を持ってモデリングしよう誰しも他人から学べるモデルを知ろう実状に合わせよう

オープンで正直なコミュニケーション

直感に従って開発しよう道具を知ろう

– ソフトウェアが第一のゴール：

利害関係者のニーズを効果的に満たす高品質のソフトウェアを開発することが大事。我々ソフトウェア開発者は、ドキュメント開発者でもモデル開発者でもない。

– 複数のモデル：モデルの種類は広範囲に存在するが、すべての状況に適用可能な単一の成果物というのはない。ソフトウェアを効果的に表現するには、複数のモデルを併用する必要がある。



AM のプラクティス

AM のプラクティス– AM の価値・原則から導かれる実際のプロジェクトで適用すべき手法。

ピックアップ

AM 21 のプラクティス

複数のモデルを並行して作ろう

少しずつモデリングしようコードで確かめよう取り決めモデルはき

ちんと定義しよう理解するために

モデリングしよう

中身はシンプルに作ろう適切な成果物を使おう他の成果物に移ろう他の人と一緒に

モデリングしよう共同所有モデルを公開しよう

モデルはシンプルに書こう

テストできるか考えよう

モデリング標準を適用しよう

既にある資産を再利用しよう

利害関係者の積極的な参加

最も簡単な道具を使おうパターンは控えめに使おう

一時的なモデルは捨てよう

話すためにモデリングしよう

困ったときだけ更新しよう

– コードで確かめよう：表現したモデルが大丈夫かどうか、対応するコードで実際に確かめる。

– 取り決めモデルはきちんと定義しよう：異なるグループ間での連携仕様については、双方のグループ間での合意のもと、きっちりと取り決めモデルを定義して、継続的にモデルを保守していく。



AM のスイートスポット

「モデル」と「動くソフトウェア」の良い関係

とにかくドキュメントやモデルの作成が信条の官僚スーツ族

ソースコード以外は役に立たないという過激なギーク族

AM のスイートスポット

持つべつ心得持つべき心得

ドキュメントやモデルだけでは顧客に伝達しきれない部分をソフトウェアで表現してみる。

情報伝達目の前のソフトウェアだけでは伝えられない、目に見えない動作、俯瞰的な要素も共有する。

ドキュメントやモデルを量産して自己満足しても駄目。最終的なゴールはソフトウェア。

ゴール意識ゴールを外さないように、利害関係者の想いを理解し、モデルを介して共通理解を持つ。

※ 上の二人の設定は、極端かもしれませんが、、、





そりゃ～、モデルと動くソフトウェアの両方のアプローチとった

ほうが充実するよ。

けど、限られた時間で両方をやるのは大変じゃない？



モデルの作成対象の方針

作成対象の方針AM ではモデル作成対象について「これと、これを作れ」という具体的なルールはないが、以下の方針が挙げられている。

– ちょうど必要な量だけのドキュメントやモデルを作成する

作る /作らないの二元論ではなく、プロジェクトに応じてちょうど必要な量を作成する。但し、あくまでソフトウェアが第一のゴール。モデルだけでは価値を還元できない。

– 複数のモデルを作成する

１つのモデルで表現できる側面には限りがあるので、複数のモデルを適切に選択して、相互補完するように表現する。（参考： AM で紹介されているモデル一覧を次頁記載。）



（参考） 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 ユーザーストーリー





ちょうど必要な量と言うけれども、それはプロジェクトによって異な

る。

せめて、目安はないの？



そもそも、何が把握できたらプログラムに落とせるのか？– 要求の全体像（マクロの視点）プロジェクトの大義（ Why ）を踏まえた上で、何（ What ）を、どう（ How ）作るか。

– 要求の各側面（ミクロの視点）ソフトウェアを形づくる代表的な４つの側面。

プログラムに落とすための主要な材料

プログラムに落とすための材料

プログラム

振る舞い構造

境界制約

要求階層とモデルビジネス要求業務要求

システム要求

Why: インセプションデッキ

What: 要求モデル

How: 設計モデル



プログラムに落としこむのに必要な材料から考えてみた

– ちょうど必要な量＝要求階層ごとに、 4 つの側面を表現できる量

– 8 つのマスにどのモデル群を採用するかを判断する。 8 つのマスすべてを埋める必要もない。ただ、特定のマスだけにモデルが偏るのはバランスがよくない。

– 少ない手数で縦軸の４つ（振る舞い・構造・境界・制約）が埋まると効率的。

– 特に、設計モデルの作成量はチーム内で調整しやすいので、開発者間のあうんの呼吸で理解が成立するなら削減 OK 。

ちょうど必要な量の目安

要求モデル（主な会話相手：顧客・ PO・開発者）

設計モデル（主な会話相手：開発者）

振る舞い

構造

境界

制約

設計モデルは、作成量を調整しやすい

※ 各マスに入れているモデルは一例

ユーザーストーリーマッピングロバストネス図

概念データモデルデータモデル

ユーザーインターフェイスプロトタイプ外部インターフェイス仕様

ビジネスルールディシジョンテーブル



なんだかんだで、 AM とは

「モデル」と「動くソフトウェア」を馴染ませるソフトウェア開発者のためのモデリング技法


• 伝達面でのお互いの長所・短所を補う• モデリング作業と実装作業のバランス


効率的な情報伝達

顧客・ PO・開発者



Summary



Summary 本日お話した内容：

– システム開発の現場では、言語化しにくい要求がたくさん存在する。

– そういった要求に対しては、モデリングというアプローチで要求を可視化して表現した方が効果的で経済的。

– ただ、残念ながらモデルで全てを表せるわけではない。実際のソフトウェアになってみないと判断しづらいポイントもある。

– そこで、「モデル」と「動くソフトウェア」と上手くバランスさせるモデリング技法『 AM （ Agile Modeling ）』の概要を紹介した。

– 最後に、「ちょうど必要な量のモデル」について、各観点の立場（振る舞い・構造・境界・制約 × 要求・設計）をふまえて考えてみた。

以上、ご清聴ありがとうございました。ページ中で利用したアイコン素材：　 http://icooon-mono.com/

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

Software