業務整理法としてのデータモデリング

「ユーザ企業の情報システム部門に所属する技術者が、自分達でデータモデルを作成しない、できない」という企業が増えているように感じます。

理由はいくつか考えられます。

• 要件定義からシステム構築・テスト・保守まで外部委託するためにデータモデリングも自分達の仕事でなくなってしまった。
• グループ会社の情報システム全部に守備範囲が広がり、忙しすぎて手がまわらない。
• データベース設計はベンダーの仕事だから我々は実施する役割ではない。
• パッケージの導入比率が増え、その影響でデータモデルを作成する機会が少なくなった。

システム開発の中で使われるデータモデルは、業務要件を検討する際の「業務データモデル」と、ソフトウェアがハンドリングするデータの構造を表す「ソフトウェアデータモデル」に大別されます。
（注）「業務データモデル」「ソフトウェアデータモデル」はここでの造語ですのでご容赦ください。概念とか論理という言葉を使うと、人によって解釈が異なるためあえて、造語を使うことにしました。今回は主に業務データモデルについてお話しています。

ところで、先日、ザックマン氏が講演したときに、こんなことを言っていました。
クラウドの時代がきて、システムづくりは社内で実施するよりも外部の方が、より早く、安くできるようになった。それにもかかわらずアメリカ企業が多くの技術者を社内に抱えておく理由はなぜか。「こう作ってほしいと思っていても、出来上がったものが期待どおりにできていないことがどれほどあることか・・・・」ユーザ要求をまとめ、発注先に正しく伝え、納品物を評価するために社内技術者は必要となる。どれほど効率的に、安価にシステムづくりができるようになったとしても、この役割はなくならないだろう。

私も同じ意見です。業務要件をまとめる機能は、社内に残す必要があるのです。そして、業務要件を把握あるいは検討する際に、業務データモデルを使うことが効率よく・品質も高いので、社内でその技術者を育成する必要があるのです。

業務データモデルが業務整理法としてパワフルなことを図ではなくテキストでお伝えするのは難しいのですが、チャレンジしてみます。

受注伝票を素材としてデータモデリングする際の質問事項を列挙し、業務理解がどれほど進むのか例示してみます。

Q1：受注伝票にある注文主コード、出荷先コード、請求先コードは同じコード体系ですか？また、これらのコード体系の正式な名称は？
A1：はい同じコード体系です。正式には顧客コードと呼ばれています。おそらく、注文主と請求先が同じ場合は、同じ顧客コードが採番されているはずです。
【業務理解のポイント】注文主、出荷先、請求先が顧客として認識され、１つのエンティティとして統合されていることがわかります。

Q2：注文主や出荷先をサブタイプとしてエンティティの箱を書いたときこれらの間に関係線を引けますか？
A2：注文主と出荷先の間に１:Ｎの関係があるので関係線を引けます。ただし、例外的に出荷先を注文時に指定されることがあります。このときは、出荷先コードではなく出荷先住所を入力します。
【業務理解のポイント】１つの注文主に対して、Ｎ個の標準出荷場所が決められていることがわかります。また、例外的な対応の際には、出荷場所をリソースエンティティとして登録管理するのではなく注文データの一部として捌いていることがわかります。

Q3：注文明細行に同じ商品コードが２行出力されることがありますか？
A3：あります。
【業務理解のポイント】さらにどういう場合か深堀りすることにより、次のようなことがわかります。

• 同じ商品コードでも梱包デザインが違うものがある。
• 有料の受注明細行と無料の受注明細行（サンプル支給など）を分けている。

ここまで書き進めてきたのですが、やはり１万字ぐらい書くスペースがないと、業務データモデルのパワフルなところは伝えられないかもしれません。すみません。

まとめ
業務データモデルを作成する際のＱ＆Ａが、深く広く業務を知ることにつながっています。
そして、これらを図として表現することが、モデリング担当者の頭の整理に役立っているのです。
業務データモデリングは、業務整理を効率化する強力な手段だと思います。