はじめに
基幹システム刷新プロジェクトでは、新機能の検討や画面設計に注目が集まりやすい一方、マスタデータの整備は後回しにされがちです。しかし、マスタデータの整備を軽視したプロジェクトは、終盤になって大きなしわ寄せを受けることになります。なぜマスタデータ整備が重要なのか、後回しにするとどうなるのかを整理します。
マスタデータとは何か、なぜ軽視されやすいのか
マスタデータとは、取引先コード、商品コード、部門コード、勘定科目コードといった、システム全体で参照される基礎データのことです。新機能の開発や画面のデザインと違って、マスタデータの整備は地味で、目に見える成果物として実感しにくい作業です。そのため、プロジェクトの優先順位付けの中で後回しにされやすい傾向があります。
しかし、マスタデータは新システムのあらゆる機能の土台になるものであり、ここが整理されていないと、どれだけ優れた機能を作っても正しく動作しません。
後回しにした場合に起きること
マスタデータの整備を後回しにすると、プロジェクトの終盤、特にデータ移行の直前になって、次のような問題が一気に噴出します。
- 重複・表記ゆれの発覚：長年の運用の中で、同じ取引先に対して複数のコードが割り当てられている、表記が統一されていない、といった問題が、移行直前のデータ精査で大量に見つかる
- コード体系の不整合：旧システムのコード体系が、新システムの要件に合わない（桁数が足りない、区分の粒度が異なるなど）ことが判明し、変換ロジックの再設計が必要になる
- 意味不明なコードの存在：現行システムの「ブラックボックス化」を防ぐにはでも触れたとおり、「なぜこのコードが存在するのか」が誰にもわからないまま、使われているのかいないのかも判断できないデータが見つかる
これらの問題は、本来であればプロジェクトの早い段階で発見・対処できたはずのものです。終盤で発覚すると、データ移行のスケジュールそのものを圧迫し、基幹刷新の予算超過はなぜ起きるのかで触れたような追加コストの原因にもなります。
マスタデータ整備を早期に進めるための進め方
マスタデータ整備を後回しにしないためには、要件定義と並行して、次のような進め方をおすすめします。
① プロジェクトの早い段階でマスタデータの棚卸しに着手する
要件定義フェーズの初期から、現行システムで使われているマスタデータの一覧化と、重複・不要データの洗い出しを開始します。これは開発ベンダーに任せきりにするのではなく、実際のデータを一番理解している発注側の業務部門が主体的に関わるべき作業です。
② 新システムのコード体系を早期に確定させる
新システムで採用するコード体系の方針（桁数、区分の粒度、採番ルールなど）を、できるだけ早い段階で確定させます。これが遅れると、移行用の変換ロジックの設計も遅れ、テストフェーズにしわ寄せが及びます。
③ 受け入れテストでデータの正しさを検証する
受け入れテストの設計｜本番後の不具合を減らすためにでも触れているとおり、移行後のマスタデータが正しく変換されているかを、件数だけでなく内容まで含めて検証するテストを計画に組み込んでおく必要があります。
まとめ
マスタデータの整備は地味で後回しにされやすい作業ですが、ここでの問題は必ずプロジェクトの終盤で顕在化し、スケジュールとコストに大きな影響を与えます。要件定義と並行してマスタデータの棚卸しに早期着手し、発注側の業務部門が主体的に関わることが、終盤でのトラブルを防ぐための重要なポイントです。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント