JDMC会員による「リレーコラム」。
メンバーの皆さんそれぞれの経験・知見・想いをリレー形式でつなげていきます。今回、バトンを受け取ったのは、株式会社データ総研の芳賀恒太さんです。
JDMCの皆さま、こんにちは。株式会社データ総研の芳賀恒太と申します。
当社は、データマネジメントを専門としたコンサルティングファームです。概念データモデリングの技術を核として、企業のデータ統合やデータ基盤整備、組織づくりなどを支援しています。
私は2019年にデータ総研に入社し、コンサルタントとしてお客様のシステムの概念データモデルの設計や、お客様が描いたモデルのレビュー、データマネジメント導入の支援を担当しています。今回のコラムでは、その中で印象に残った出来事と、そこから得た気づきをお話ししたいと思います。
当初は、概念データモデルで「業務ルール」を表現する必要性がわからなかった
当社の新入社員は、入社直後から徹底的に、概念データモデリングの教育を受けます。その後も、概念データモデリングの案件があれば優先的に若手をアサインし、早い段階での技術習得を目指します。なぜなら当社では、概念データモデリングとそれを通じて得られる視点が、データマネジメントを推進していくための重要な基礎になると考えているからです。
それらの教育や実際の案件の中で、上司や先輩から繰り返し言われる言葉に「概念データモデルは、業務の写像である」というものがあります。そして、その言葉通り、社内で概念データモデルのレビューを行うときには「業務ルールが概念データモデルに表れているか」が非常に重要視されます。
概念データモデルをあまり描かない方に向けて補足しますと、概念データモデルでは、リレーションシップや、主キー／非キー属性の設定などで、業務ルールを表現することができます。以下に簡単な例を挙げます。
＜業務ルールがリレーションシップに表現される例＞
- 「1件の受注を分割して、複数回の出荷が発生することがある（帳票の発生という視点で考えると、注文書1つづりに対し、対応する納品書が複数つづり発生しうる）」場合は、受注エンティティと出荷エンティティが、「1:多」のリレーションシップで結ばれる。
- 一方、「受注が分割されたり、まとめられたりすることがなく、受注1件に対しては出荷1件のみ発生する。（注文書1つづりに対し、対応する納品書は1つづり）」場合は、受注エンティティと出荷エンティティが「1:1」のリレーションシップで結ばれる。
さて、新人の頃に上記のようなことを言われた自分は、次のように思いました。「動くソフトウェアを作るためだけなら、そこまで業務ルールを意識してモデルを描く必要がないのではないか？」
むしろ、業務ルールを意識して描かないほうが良い場面もあるのではないかと思っていました。例えば、「受注：出荷」が仮に「1:1」だったとしても、「1:多」としてしまった方が、将来的に分割出荷が発生した場合も、むしろ対応しやすいように思えます。エンティティのナチュラルキーの特定などせず、最初から全てサロゲートキーでデータモデルを描いてしまった方が、業務が変わって主キーの要素が変更になってしまったときにも楽に思えます。
実際、物理実装においては、ある程度変更に耐えられるような柔軟なテーブル設計を行うことが多いかと思います。どのみち物理側で柔軟な構造にするのであれば、概念側で業務ルールを詰める必要はなさそうに思えてきます。「過度に柔軟なつくりにしようとすると、開発や保守の工数が大きくなる」と言われたこともありましたが、「業務が変更になったときの改修コストとどっちが大きいのかは、その時によるだろう」と、そのときは思っていました。
しかし、ある出来事をきっかけに、概念データモデルで業務ルールを表現することの意義に気づけたのです。
業務ルールに合わないオペレーションが「できてしまう」のは、よくないこと
あるとき、とある製造業のお客様の支援をさせていただきました。そのお客様では過去に、現場の業務についてあまり調査しないまま、ERPパッケージを導入したという背景がありました。その結果、さまざまな点で現場からの不満が出てしまっており、再度システムをリプレースしようとしているところでした。
販売管理領域の概念データモデルを描いている時に伺った業務ルールは、以下のような内容でした。
- 受注1件に対し、出荷1件が対応する。
- もし欠品があるなどの理由で、分割して出荷する必要が出てきた場合、注文主に連絡して受注（注文主から見ると発注）を取り消してもらい、発注し直してもらう。
このルールは、注文主との事前の取り決めのもとに設定されており、本来は動かせないはずでした。
しかし、実データを調査したところ、ルールに反して、受注:出荷が「1:多」になっているケースが見つかりました。パッケージを導入する前に運用していたシステムは、そもそもシステム側で機能が制限されていたため、このような事態は起こりませんでした。一方、新しく導入したERPパッケージでは分割出荷ができるようになっていたため、今回の事態を防ぐことができなかったのです。
「機能が制限されていることも、価値の一つである」というのは、その時の自分にとっては目からウロコでした。またそう考えると、概念データモデルの段階から業務ルールを無視してやみくもに柔軟性を指向するのも、よくないことだと思えてきました。
概念データモデルは「人間系も含めた」システム全体を見据えたもの
これから導入しようとするソフトウェアが、業務ルールに合わないオペレーションを許容してしまう場合（かつ、業務ルールを変えることが難しかった場合）、導入企業としてはどうすべきでしょうか。いっそのこと導入するソフトウェアを変更したり、簡単な設定で機能制限を付与したりできればよいのですが、実際には、そううまくいくケースばかりではありません。
その場合は、ソフトウェアの機能以外の部分で、業務ルールが守られるための工夫を考える必要が出てきます。工夫の内容は対象業務によりますが、例えば、「改めて業務ルールを明文化し、従業員に教育する」「オペレーションが正しく行われているかのチェックを、一連の業務の中に組み込む」などの対応策が考えられます。そうなれば、ソフトウェアの導入と並行して、「どのようなスケジュールで教育を行うか」「オペレーションのチェックは誰が行うか」などの、対応策の実現に向けた具体的な検討も進めなくてはいけません。
概念データモデルで業務ルールを表現する目的は、「『人間系も含めた』システム全体で、どのような状態を目指したいのか示すことであると、今の私は考えています。導入するソフトウェアが自社の業務ルールに反したオペレーションを許容してしまうこと、逆に、対象業務の一部がソフトウェアの機能だけで実現できないこと、これらはどちらも十分に起こり得ます。これはパッケージでも、スクラッチ開発でも同じです。その場合は、人間系も含めさまざまな仕組みを組み合せて解決方法を探らなくてはなりません。組み合せた結果どうなりたいのか、その指針として概念データモデルはあるべきだと、私は考えます。
仮に、過去の自分に似た考えの人に出会って、「動くソフトウェアを作るためだけなら、そこまで業務ルールを意識してモデルを描く必要がないのではないか？」と聞かれたらどう答えるのが良いでしょうか。現時点の自分なら、「そもそも概念データモデルは、『ソフトウェアを作る』ためだけに作るものではありません。概念データモデルは、人間系もソフトウェアも含めたシステム全体で実現したい姿を表すためのものです。そのためには、業務ルールも意識する必要があります。」と回答するかなと思っています。
今回は、つたない文章ながら、概念データモデルに関する気付きを共有させていただきました。もし何かご意見やこの分野に関心のある方がいらっしゃれば、ぜひJDMCの分科会等でお声がけください。意見交換できるのを楽しみにしています。
芳賀 恒太（はが こうた）
株式会社データ総研
コンサルタント
新卒で広告代理店に入社し、ウェブ解析の業務を経験。その後2019年にデータ総研に入社し、データマネジメントに関するコンサルティング業務に従事。現在までに金融業、製造業、物流業におけるMDM・DWH構築、製造業、不動産業における基幹システム再構築の上流工程を支援している。
コンサルティング業務に従事するかたわら、データ総研の企業ブログ（https://jp.drinet.co.jp/blog）で、ユーザー企業の担当者向けにデータマネジメントやデータモデリングに関する情報発信を行っている。