パッケージシステムでは、多くの業種とその業務プロセスに対応できる、柔軟な標準機能が用意されています。そのためパッケージ導入プロジェクトでは、新規業務をこうした標準機能でどこまで対応できるか、Fit＆Gap分析を行います。
たいていのプロジェクトでは、この分析時にプロセスモデル図を作成し、
・どのプロセスにどのパッケージ標準機能が対応するのか
・パッケージ標準機能が対応できない業務は、アドオンを導入するのか、追加開発するのか
を明らかにしていきます。
データ構造もFit&Gap分析が必要
一方、パッケージは機能だけではなく、データを格納する標準データ構造（テーブルなど）も用意しています。
機能をプロセスモデル図でFit＆Gap分析するのと同じように、新規に管理すべきデータと標準データ構造をデータモデルで図化して分析すれば、より漏れ無く無駄の無いパッケージ導入ができるはずです。
ただ実際のパッケージ導入プロジェクトの多くで、プロセスモデル図は作られてもデータモデルはあまり作られないようです。
それで問題が起きなければいいのですが、そういったプロジェクトではテーブルやI/F設計の手戻りが発生したり、データの移行設計が見直されたりすることが多いように思えます。
データモデルに工数をかける価値
なぜパッケージ導入プロジェクトで、データモデルは作られないのでしょうか。
まず、パッケージ導入が短期間のシステム構築を目的としているため、データモデル作成の工数を懸念されるのかもしれません。既存システムからパッケージの移行設計をしなくてはいけないのに、データモデルまで作るのは負荷が高い、などなど。
ただ移行範囲全体を表すデータモデルが一枚あると、詳細な移行設計前に移行元と移行先の関係を確認でき、対象データの漏れや重複の確認ができます。移行設計の手戻りは移行作業の負荷とテストの精度にも影響を与えるので、早い段階で移行検討できるのは価値が高いでしょう。
モデリングコミュニティとしてのDAMA
データモデルが作られないのは、パッケージ導入の現場にデータモデルを読み書きできる人材が少ないこともあるでしょう。データモデラーはどうしても手組みシステム開発の現場にアサインされがちです。
またプロセスモデル図がプロセス間の関係を順に追って読めるのに対して、データモデルは記法による表現の違いが大きく、読むのにもある程度の学習が必要です。
もしこのエントリーを機にデータモデルを学びたいという方がいらっしゃったら、書籍を読んだりセミナーに参加したりするのに加えて、DAMA日本支部に入会されることをオススメします。実はDAMAには、メインフレームのシステム開発時代からデータモデルと格闘してきた、データモデラーの“猛者”たちが集っているからです。
特に、第10分科会「データモデリングの実践的検討会」では具体的なデータモデルをベースにノウハウの共有を行っていますから、パッケージ導入時のコツについて聞くことができるかもしれません。