To portray the business processes using data model notation.

1. 付録７
データモデルとプロセスフロー
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 128

2. 1995年3月のできごと
今から長い『枕』を記述します。
阪神・淡路大震災のあった年、小生は外資系アパレル企業の情報システム部に所属していた。当時、佐藤正美氏に師事し、データモデリング
を勉強中であった。あれは、3月20日の朝。出勤すると携帯電話の着信音が鳴った。何かと思いディスプレイを見ると、親友からの電話だと
わかり応答した。「おい、大丈夫か？」「え?!」「地下鉄恵比寿の駅で大変なことが起こっているぞ！ 体は大丈夫か？」「俺は、地下鉄つ
かってないから大丈夫だが、いったい何があったんだ？・・・」地下鉄サリン事件を知ったのはこのときだった。
同僚が日比谷線を利用していて「今日は霞ヶ関の駅に止まらず通過したんだ。時刻表から遅れていたものだから、急行運転に切り替えたのか
と思ったよ！地下鉄でも急行運転することあるんだな！ ん？・・・冗談だよ、何か異常があったとおもったよ！」
営業部の女性社員が被害にあった。サリンの影響で瞳孔が収縮し、暗いと訴えていたと後で知った。
グルによる魂の救済、積極的に死をもたらすことで意識を神の次元へと移し変える・・・このような教義を真剣に受け止め、従った若者がい
て、それを指示した教祖がいた。地下鉄サリン事件、その前をさかのぼれば松本サリン事件。常軌を逸したカルトの教義に端を発する悲劇を
今も私たちは目にするのである。
当時、子供たちは幼く、サリンがどんなものかもわかっていなかったようで、帰宅した小生に何を聞くでもなし、父親の心配をするでもな
かった。その日、こんな家族の対応に、これだけ数がいるのに俺のことなど誰も気にもしないのか！と、正直がっかりもした。しかし、後に
なって事実が露見するにつれ、組織的で計画的な大事件の構図が報道で徐々知られるようになり、罪もなく関わりもない命が一方的に奪われ
たのだとわかると、子供たちにはこのままわからないほうがよかったのだと思えてきた。
今も後遺症に苦しむ人々、遺族の皆様の心痛ははかるに余りある。
この未曾有の事件を引き起こしたカルト教団は、後に山梨県内で大規模な捕り物が勃発し、司直の手によって教祖をはじめとする多くの幹部
に極刑判決が言い渡されたれ、刑が確定した。周知の通りである。そして、この事件を契機に『テロ』と言う詞が定着し、駅からはゴミ箱が
撤去された。
話し変わって、時は元禄16年、春まだ浅い2月4日。亡君の敵、吉良上野介を討ち伊予松山藩松平家にお預けとなった大石主税良金は16歳。こ
の日、将として松平家お預け10名の先として切腹した。この切腹を命じる前、ときの将軍綱吉は、上野寛永寺輪王寺門主公弁法親王に意見を
求め赤穂義士の助命を模索したが、若い者が後の人生で道をはずれ、この名誉が泥にまみれぬよう腹を切らせよと諭されたと言う。先んじて
名誉の死を与えることこそ武門の誉れ！と。
人生を完全に遂げることの意味を考えさせられる。他人が決めた道理によって、他人により齎された死を受容れることが、私たちにとってど
んな意味を持つのだろうか。このような死はあまりにも不合理であり、見方によっては安直だ。これが日常というこのなのか。・・・あるい
は異常と言えるのか・・・
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 129

3. 今度こそデータと業務プロセスとの関係?!
1. 業務プロセスを中心に、業務の手順やその過程を分析してシステム開
発に取り組む手法をプロセス中心アプローチ（POA：冗談交じりにポアとい
う人もいる）という
2. DOA（データ中心アプローチ）に携わる一部の人たちにPOAを対極と
見做す向きがある
既に、エンティティ･ロールで解説したとおり、データモデルによる業務プロセ
スのモデル化の可能性を提示した
3. DOAは業務プロセスをどの程度分析することが可能なのか？
4. データモデルで業務プロセスを分析することに利点があるのか？
5. そもそも、エンティティ･ロールはPOAではないかと言う意見･批判
6. 業務の事実から『あるべき姿』を導き出すとは
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 130
3, 4 について、論じてみよう
あとは論点が異なるのでこの場で論じない

4. POAの特徴
1. 業務のモデリングを実施する
2. 業務プロセスに見合ったデータ構造を設計する
3. 特定業務を短期間に設計・実装することを目指す
4. よって、業務プロセス実現のための機能を重視した要
求定義・設計プロセスを経る
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 131

5. プロセスフローモデルとは？
一言に『業務モデル』といっても様々な種類がある
1. 業務プロセスと称しながらデータフローを描くモデル
2. NOMA方式のプロセスフローモデル
3. BPMNのプロセスフローモデル
4. BPECによる業務階層図…
5. UML ユースケース
6. UML アクティビティ･ダイアグラム
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 132

6. プロセス中心と業務モデル
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 133
3, 4 について論じてみよう
DOAは業務プロセスをどの程度分析することが可能なのか？
一般的にERモデルは、エンティティの関連をリレーションとして表現する。ER
モデル上では線にあたる。エンティティ間の結線はキー（KEY）に由来する
KEYはエンティティの中にあり、一意制約キー（Unique Key）と参照キー
（Reference key）に分かれる
任意のエンティティに配置された同名のKEYをリレーションで結線する
KEYによりエンティティとリレーションシップは成立する
それでは、エンティティ、リレーションシップ双方の成立に拘る
KEYの束縛から解放されたなら、ERモデルはどうなるのだろう
か？

7. DOAによるは業務プロセスの分析可能範囲
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 134
カードキー社員
社員コード. 氏名
生年月日
住所
メールアドレス
製造番号
R R
社員・カードキー･対照表
社員コード(R)
製造番号(R)
有効化年月日
有効/無効区分
無効化年月日
TS
有効なものは１個の社員コードにカードキー1枚
カージナリティが n:m になる
理由は、社員が複数枚カード
キーを手にすることが考えら
れるため。
業務の事実の存在を示すコード体系（個体指示子：Identifier）と
個々のデータを識別するKEYは、夫々が異なる目的を持つ。よって
同じ視点で論じられない
但し、コード体系を主軸にデータモデルを作図 / 推敲する場合でも、
その実は『KEYの束縛』に似た制約に煩わされる
その束縛とは、ズバリ『一意性』！
一方、業務プロセスの分析では、一意性に注視することは先ずない

8. T字形ERモデルで分析できる業務プロセス
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 135
データモデルの分析主題はキーによるエンティティとリレーショッ
プの生成、その結果のデータ構造の提示にある
もし、KEYではなく『業務の事実』のエビデンスであるコード体系
を分析対象にしたら、業務プロセスをどこまで分析できるのか？
コード体系自体の分析でわかること
複合コード
ばらす / 掛け合わせる
同一コード体系内の種類
実業務視点 / 分析業務視点
コード体系と共に発生するデータの分析でわかること
まとめる / 引き継ぐ
共に生まれる / 後から生まれる

9. T字形ERモデルの各要素とプロセスの対応
コード体系自体の分析でわかるプロ
セスに関すること
複合コード
ばらす
掛け合わせる
同一コード体系内の種類
実業務視点
分析業務視点
コード体系と共に発生するデータの
分析でわかること
まとめる / 引き継ぐ
共に生まれる / 後から生まれる
何かを確認する / 種類にした
がって結果が現れる
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 136
最小単位の『事実』を見つける最小単位の『事実』を見つける
リソースの場合、対照表に該当リソースの場合、対照表に該当
スーパーセット･サブセットに該当スーパーセット･サブセットに該当
区分･種別 / データ再利用・並べ替え区分･種別 / データ再利用・並べ替え
イベント/ 対照表 / 対応表に該当イベント/ 対照表 / 対応表に該当
エンティティ / VEに該当エンティティ / VEに該当
エンティティ･ロールエンティティ･ロール

10. データモデルで業務プロセスを分析すること
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 137
3, 4 に論じてみよう
データモデルで業務プロセスを分析することに利点があるのか？
プロセスフローモデルによる業務プロセスの分析では、その対象を概略⇔詳細
に層別するケースが多い
また、ダイアグラムの作成過程で、プロセスを度々追加 / 削除する柔軟性があ
る
プロセスフローモデルは、プロセスの動性をコマ撮りしたスナップショット
業務フローの軸とは、業務に携わる人？ 組織が担う役割？ 写像したモデル
の分析目標は？
データモデルで表現できないものをプロセスフローは表現している
と仮定すると、データモデルにとって業務プロセスフローは必要な
パートナーだと考えられないか？
では、データモデルでは表現できないものとはなにか？

11. プロセスフローの特徴
1. システム開発者の目は、業務の『関係者』と『手順』に着目し、『業務
や作業』を『機能』として捉える
機能は、設計が必要。よって基本的な設計を施した後、機能を部品化することは
可能（楽々Framework3が実現）
T字形ERモデルのリレーションシップは『手順』を示している場合もある
しかし、リレーションシップはそもそも『キーの束縛』の影響下にあり、手順を
表現するものではない
2. また、分析対象となる業務を『概略⇔詳細』に層別するケースが多い
データモデルでは、概念モデル⇔論理モデル⇔物理モデルを描き分けることはあ
るが、業務階層の層別を示したものではない
3. データモデルは機能遷移/ 分岐を表現することに向いていない
機能遷移 / 分岐がわかっていればデータモデル上のエンティティ等を指し示すこ
とはできるが、データモデルに描き込むことは困難
4. 前述の『業務や作業』の階層をデータモデルの表記法を使って表現する
ことは可能である（以下、参照のこと）
ハンドノート 業務階層図における『役割と種類』
ハンドノート 業務階層とAP機能の関係
付録１David C. Hay の モデル 業務階層図の構造
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 138

12. データモデルと業務プロセスフローの関係
1. 業務の事実を捉えるのに、データモデルとプロセスフ
ローモデルは相互を保管しあう関係
2. データモデルでは、次の事柄をダイアグラム上に表現
することが難しい
データモデルで表現が難しいのは、業務の手順、業務
の層別（概略⇔詳細）、そして 機能遷移 / 分岐 である
また、『主管組織』『担当者』『タイミング（ランダ
ム / 日に一度 / 月に一度など）』をアトリビュートリス
トに記載することはできるが、ダイアグラム上に表記
することがない
2015 Copyright, All rights reserved. SYSTEMS DESIG Co.,Ltd 139