モデリング四方山噺～アジャイル開発者に向けて～
2017年 4月13日
Agile Japan 2017
稲見 浩一

はじめに
私は、基幹業務系のデータモデラ―です。
アジャイル開発関連で、モデリングに関して話題になることが少ないと思い、今回の機会を頂きました。
プロダクトバックログから先の開発の話は、他にも多くの方が語っているので、ここではプロダクトバックログ以前のお話です。

2

アジェンダUse Case 3題
企業におけるデータとアプリケーション
「DMBOK」ご紹介
プロダクトバックログの前に要求とドメインの獲得
データモデルへの誤解
モデルは文だ！
モデリングする意味
実行して頂きたいこと

3

Use Case（ADMC2015での講演より）
GAP社の情報システムについて、Allan氏から以下のような発表がありました。
ソフトウェア開発
 ビジネスの現場に開発者が広がり、アジャイルに行われているデータベース レガシーなままでデータ辞書も整備されていない
 どのデータが、どこにどの様に実装されているのか、わからない
 データベースの状況が、アジャイル開発を阻害する要因になっている！
 “Agile or die?”と迫られる

4

（続き）

5

対処
 すべてのデータベースをリバースして解析し、データモデルを作成
 現状ビジネスに合わせた状態にモデルを改良
 リポジトリ化して、データベースを実装し直した

Start

旧RDBMS

現ビジネス状況
旧Physical
Model

Goal
新RDBMS

新Physical
ModelEnterprise
Model＋
glossary

Use Case2（データモデルから出発）
某SIerのロックインから脱出した企業の例
現ビジネス状況

開発を繰り返すTMD（Data Model）

RDBMS

旧システム

リポジトリ

Enterprise Model
1. TMという分析手法を用いて、データモデルを作成
 自社業務を分析し、SIer任せから脱却する
2. モデルを基に、楽々FrameworkⅡにてRDBMSとリポジトリを作成
3. 楽々FrameworkⅡ上でアプリケーションをアジャイルに開発
楽々FrameworkⅡについては、参考資料のページ参照

6

Use Case3（モデルと共に生き残る）ネット販売のシステムを開発した例
アジャイル開発を行なうチームとしてプロジェクトを開始

データモデルを使った分析から始めて、MVCS型のシステムとする

先行してアジャイル開発の小さなプラクティスを実施

外注サイドにて進捗報告に上司が理解を示さず、進め方に関して紛糾

従来型の進め方をするとして、遅れていると思い込み、人員の大量投入予定より大幅に遅れて、コピペの嵐で悪いコードのまま完成とのこと

ベースになるモデルと、正常な構造のDBが残ったので、コツコツ修正する機能追加などの機にコツコツと修正を続けて、真っ当なコードを増やす

現在でも要望通り、月に幾つか新機能を追加できるシステムとして運用中。

7

企業におけるアプリケーションとデータ
歴史を振り返ってみます。
機械化や自動化が目的の時代
データ定義は、アプリと一体コードの中でデータ構造を定義
データ定義

情報活用が経営判断を左右する時代
データ定義が、アプリから独立機能中心

コード

更に、アプリが階層化
データ中心

コード V
コード C

コード M
データ定義

データ定義
ファイルRDBMS

処理が中心
データは使い捨てヒト、モノ、カネに並ぶ財産

RDBMS
多種多様で量も膨大

8

「DMBOK」ご紹介
データマネジメントについても、PMBOKやBABOKなどと同様に、知識体系化されました。
米国を中心として、データ管理の専門家達が作ったコミュニティ（DAMA-I） にて、発行されました。
2010年に英語版が、2011年には日本語版も発行されており、現在第2版の発行準備中です。
「データガバナンス」を中心とした10個の主要な機能から構成されています。
 開発に関しては、「データアーキテクチャ」と「データ開発」が深く関係します ただし、入れ物を作ることだけが問題ではなく、そのデータを定義する組織作りから、実際に入っているデータの品質まで、広い範囲が関係しますDAMA日本支部では、勉強会も開催しています。
DAMAとDMBOKついては、参考資料のページ参照

9

プロダクトバックログの前に要求とドメインモデルの獲得
UMTP Japanが発行している次の資料
アジャイルソフトウエア開発向けUML適用ガイドライン Ver.1.1第3章 モデルとアジャイルプラクティスを有効に使用する
3.2 初期のプロダクトバックログアイテム発見作業にて、「要求とドメインモデルの獲得」は、バックログ作成に先行させて行なうものとしています。

当たり前のことですが、もう少し、このドメインモデルに着目してみましょう。

10

要求とドメインモデルの獲得

11私は次のように進めてきました。
まず、データモデルを作成
 データモデル内で、タイムスタンプのあるデータを時系列に追えるようにすることで、業務フロー図の作成が不要に 用語を辞書として整備する
 分析や説明に必要なら、UMLを併用

並行してユースケースモデルを作成

Data Model＋glossary 図に加え、ユースケース記述を作成
 データモデルのどの部分を利用すれば良いかを書きながら確認する

性能や運用などの要件と合わせて、アーキテクチャを確立し、バックログへと進む。

Usecase Modelデータモデルへの誤解
肝心のデータモデルについて、以下のような誤解が見られるので、解いておきましょう。
誤解１：
正解１：

誤解２：
正解２：

データモデルは、RDBMSの実装のための設計図である設計図にも使えるが、特に業務分析に、非常に効果的である
分析結果は、エンタープライズ情報管理の要として利用できる情報を正規化してから、ER図を書く
P.P.Chen氏が最初にERモデルを発表した
際から、正規化しなくても同じ効果が得られるように作ったと書かれている12

データモデルへの誤解（続き）
誤解３：
正解３：

誤解４：
正解４：

エンドユーザにモデルを書いて見せても理解されない
30分ほど読み方を教えれば、対象の業務の範囲のモデルなら、すぐに読んで貰える
更には、コンサルタントを利用しつつ、エンドユーザがモデルを書いている
試してみたがうまくいかなかった
効果が得られなかった正しい方法でできていなかった
正しい方法の実践者から支援を受けることができていなかった

13

データモデルへの誤解（続き）
誤解５：

データモデルを書いても開発には役に立たない
正解５： 例えば住友電工では、TMというデータモデリング手法を導入した際に、それまでと開発の他の部分を変えずに開発効率を計測した結果、全体で30%の効率化が見られたと発表しており、この成果が後に、楽々Frameworkの開発に繋がりました。
「楽々Framework アジャイル開発」で検索！
某メーカーでの調査では、モデルを読めないSierと、モデルを中心にしたSWATチームでは、開発効率に5~10倍の差が出たと言っていました。
注

SWAT: Skilled With Advanced Tools

14

モデルは文だ！（モデルを読む）
次のようなモデルの部分図があります。
何が書かれていますか？

15モデルは文だ！（書いてあること）
次のように読めるはずです。
従業員は、従業員番号で識別され、氏名、かな氏名と生年月日を持っている。
部署は、部署コードで識別され、部署名を持っている。
従業員は、いずれかの部署に所属することがある。
部署には、何人かの従業員が所属することがある。
従業員は、どの部署にも所属しないことがあり、複数の部署に所属することもある。

16

モデルは文だ！（書いてあること）
次のように読めるはずです。
従業員は、従業員番号で識別され、氏名、かな氏名と生年月日を持っている。
部署は、部署コードで識別され、部署名を持っている。
従業員は、いずれかの部署に所属することがある。
部署には、何人かの従業員が所属することがある。
従業員は、どの部署にも所属しないことがあり、複数の部署に所属することもある。

17

モデルは文だ！（実際のシーン）
実際の出現順は逆です。
①話を聞く②モデルで書く

文章で伝える

モデルを見て、文章として読む③モデルで意味を共有するモデルで表現する

18モデリングする意味何故「モデリングすると良いのか？」と、良く聞かれます。
人は自然言語の文章によって意味を理解します。
 文章は、そのままでは複雑な場合が多いです。
 分解して、個々の言葉の意味や、他の言葉との関係を考えることで、単なる「事実」から、事実となり得る「可能性」を検討できる様になります。
 モデリングによって、それを支援できるのです。

野矢茂樹さんの次の本を読んでくださいウィトゲンシュタイン『論理哲学論考』を読む
そこに答えが載っています。特に次の箇所
P036 2-3 なぜ事態は対象へと解体されねばならないかに注目してください。

19

モデリングする意味（要するに）

20

モデルは「文」である。
業務の世界で使われている文を分解、整理して一定の表記で表したものがモデルです。
文はもともと命題なので、分解して解明すれば、そこに論理を働かせることができます。
文のままより、「色々と扱える文」ということです。

モデルが使えるということは、
聞いたことを分解して、モデルとして表現できる。
モデルを文として読める。
そして、聞いたことと合っているか確かめられる。の３つができるということです。

モデリングする意味（開発に際して）

21

一部のアルゴリズム以外の要件や仕様は、モデルで示せます。
業務を語る文を分解し、エンティティ（クラス）とリレーションシップで表します。
「かつ」は多重度で表し、「もし」や「または」は部分集合（サブセット／サブクラス）で表現できる。
例えば料金計算や、入金時の明細への按分などの一部のアルゴリズムを除き、7割方の業務はER図（クラス図）で表し、その他のアルゴリズムや状態、動作の説明は、他のUMLの図で表現可能です。

オブジェクトをコードのまま理解し合う人とだけ共有するのでなければ、モデルが有った方が、理解しやすいです。

おまけ

22

決して、安易にこうしないでください。
兼務（ある従業員と複数の部署の関係）の可能性を否定してしまっています。
分析時点で兼務が無いからといって、このモデルにしてしまうと、可能性を殺してしまいます。
EMP
EMPNO
DEPTNO
ENAME
JOB
MGR
HIREDATE
SAL
COM

DEPT
(FK)

DEPTNODNAME
LOC

実行して頂きたいこと

23

参加頂いた皆様は、どちらの立場ですか？
 企業内で内製している情報システム部門の方 もし、まだ自社のエンタープライズデータモデルを持ってないなら、データマネジメントの一環としてデータモデルを作成してください プロダクトバックログは、そこから作成してください 受託開発をしているベンダーの方
 委託元の顧客に、データモデルの提示を求めてください プロダクトバックログは、そのデータモデルと、ユースケースを元に始めましょう 品質の良いデータモデルが用意されないようなら、必要な部分だけでも一緒に作るようにしてください どうすれば良いかわからなければ、ご相談ください

参考資料

24

本書は、以下を参考にしています。
DAMA／DMBOK DAMA日本支部 http://www.dama-japan.org/
 書籍「データマネジメント知識体系ガイド 第一版」

TM（旧：T字形ERデータベース設計技法）
 佐藤正美の問わず語り
 データモデリング入門

http://www.sdi-net.co.jp/
https://www.slideshare.net/inamiK/ss-36665472

楽々Framework3
 住友電工情報システム
http://www.sei-info.co.jp/framework/features/point.html/
UMTP Japan http://www.umtp-japan.org/
 アジャイルソフトウエア開発向けUML適用ガイドライン Ver.1.1

「ウィトゲンシュタイン『論理哲学論考』を読む野矢茂樹 著 ちくま書房」の前半
 http://www.chikumashobo.co.jp/product/9784480089816/

「データモデリング入門」
以下のスライドを公開しています。
https://www.slideshare.net/inamiK/ss-36665472
https://www.slideshare.net/inamiK/ss-36898650

知人に２時間程度で、取り敢えずモデルを書き始められるようにして欲しいと言われて作成したものです。
そろそろ、第2版として、もう少し背景などの説明を追加したものを書こうかと思っているところです。

25