多くの業務システムの開発プロジェクトで，データモデリングが行われています。しかし，皆さんはデータモデリングの「本当の目的」を理解しているでしょうか？ ひょっとしたら，「よく分からないけれど，成果物としてER図やテーブル仕様書をそろえればいい」くらいに考えていませんか？
この連載では，要件定義の工程におけるデータモデリング，それも，実装を意識せずに業務のデータ構造を表す「概念データモデル」に注目して，現場で役立つ実践的なモデリングの方法を解説していきます。
まずは，下記の事例から見ていきましょう。
ケース1
電子部品販売事業を展開するA社が，基幹システムをリプレースするプロジェクトをスタートさせたのは2年前。同社の情報システム部門は，業務の効率化と保守性の向上を目標に掲げ，業務分析とドキュメント化を進めました。もちろん，新システム導入後の業務について業務フロー図（図1）を作成し，必要な画面を洗い出して（図2），ユーザー部門に確認をとりました。ER図（図3）も作成しています。
 |
| 図1●新システム導入後の業務フロー図の例 |
 |
| 図2●新システム導入後の受注録画面と出荷報告画面の例 [画像のクリックで拡大表示] |
 |
| 図3●新システム導入後のER図の例 [画像のクリックで拡大表示] |
小さな作業上のミスは多少あったものの，要件定義は無事に終わり，実装，単体テスト，結合テストを済ませ，プロジェクトは今年，カットオーバー寸前まで来ていました。ところが，ユーザーを交えた統合テストの段階でトラブルが発生しました。情報システム部門のSEとユーザーの会話をのぞいてみましょう。
ユーザー●簡単な変更をしたいんだけど，相談に乗ってもらえないかな。出荷報告画面に完納区分を追加してほしいんだ（図4）。
 |
| 図4●ユーザーからの出荷報告画面に対する変更要求 |
SE●確か事前に決めた業務ルールでは，商品が全部そろってから出荷ということで，分納は無いはずでしたよね。出荷報告画面に出荷数量の入力も必要ないと伺っていますが。
ユーザー●基本はそうだよ。だけど実は先週，受注した商品の中から一部を先に出荷することがあったんだ。
SE●（当初の話と違うと思いつつ…）今のシステムの仕様では，一つの受注に対して出荷報告は一つなので，2回目の出荷報告ができません。2回目は登録済みの出荷報告を更新するというプログラムの変更でいいですか？
ユーザー●その仕様だと2回に分けて出荷した場合，1回目の出荷の日付が分からなくなるなあ。出荷報告画面で受注番号に枝番を付けて出荷報告するってのはどうかな？
SE●（出荷報告のコード体系が変わると関連プログラムの修正が膨大になると思いつつ…）確かにそうすれば出荷報告はできますが…，完納区分の入力に誤りがあったらどうなります？ 出荷漏れや重複が起きてしまいますね。
ユーザー●なるほど，それはまずいなあ。
SE●分納がある場合は，システムとは別に出荷状況を管理して，すべて出荷されたらまとめて出荷報告を登録することはできないでしょうか？
ユーザー●運用でカバーしろってことかい？ それは無理だよ。それに出荷の日付が分からなくなることに変わりはないし。そうだな，例えば受注情報と出荷情報を突き合わせて不整合をリストアップするようなモジュールを新たに追加できないかな。誰かが定期的にリストをチェックするように調整してみるからさ。
SE●（この段階でまた新しいプログラムを作るのか…）はあ…。
――どうやらこのプロジェクト，このままではとてもカットオーバーできそうにありません。
