マスタデータの変更管理：変更申請・承認・履歴記録の設計

マスタデータ（顧客マスタ・商品マスタ・取引先マスタ等）は一度整備してもその後の変更管理が適切でないと、再び品質が劣化します。「誰がいつ何を変えたかわからない」「担当者の判断でマスタを変更している」「変更が承認なしに通っている」——こうした状況は変更管理の仕組みが整っていないことが原因です。整備済みマスタを入力チェックや棚卸しで維持する仕組みについては「整備したマスタデータがすぐ崩れてしまう」——維持するための入力チェック・承認フロー・棚卸しの設計で解説しています。本記事は変更が発生した際の「申請→承認→履歴記録」のフロー設計に特化しています。

変更管理の3要素：申請・承認・履歴

• 申請（Request）：マスタデータの追加・変更・廃止を希望する担当者が、定められたフォーム・手順で申請します。申請には「変更内容」「変更理由」「変更が必要な業務上の根拠」を含めます
• 承認（Approval）：申請を受けたデータオーナーまたは指定の承認者が、変更内容の業務的妥当性を確認して承認・却下します。変更の影響範囲（他のシステムやデータへの影響）の確認も承認ステップで行います
• 履歴記録（Audit Trail）：承認された変更が実施された後、「誰が・いつ・何を・なぜ変えたか」を変更履歴ログとして記録します。変更の根拠（申請内容・承認者）も履歴に紐付けます

変更申請フォームの設計

変更申請フォームは「必要な情報を確実に集める」と「申請のハードルを下げる（使いやすい）」のバランスが重要です。複雑すぎると担当者が申請を省略するようになります。

承認権限の設計

変更の種類・影響範囲によって承認権限を分けることで、軽微な変更は迅速に処理し、重大な変更は適切な権限者が確認できます。

• 軽微な変更（既存レコードの連絡先・住所更新等）：データスチュワードの確認のみで反映可。1〜2日以内に処理します
• 通常の変更（新規レコードの追加・分類・コードの変更）：データオーナーの承認が必要。3〜5営業日が目安です
• 重大な変更（コード体系の変更・廃番処理・複数システムに影響する変更）：データオーナー＋関連部門（IT・経理等）の合意が必要。実施前に影響調査を行います

変更履歴の記録方式

変更履歴は、DB側の監査ログと申請・ワークフロー側の履歴を組み合わせて管理する方法が代表的です。

• DBの監査ログによる変更記録：DBMSの機能（トリガー等）を利用して、INSERT・UPDATE・DELETEなどの変更を自動的に記録します。変更前後の値や変更日時、変更者など、必要な監査項目を設計して記録します。変更者の特定については、アプリケーションからDBへの接続方式やユーザー識別情報の渡し方など、システム構成を踏まえた設計が必要です
• 申請管理ツールでの履歴管理：kintone・ServiceNow・Jiraなどのワークフローツールに申請・承認の履歴を蓄積することで、「なぜ変わったか（申請理由・承認者）」も含む完全な履歴が残せます

変更管理ツールの選択：どのシステムで管理するか

マスタデータの変更管理を支える仕組みとして、専用ツールの導入を検討する組織もありますが、まずは手軽な代替から始めることをお勧めします。Excelの申請シート＋メール承認でも変更管理の基本は機能します。業務が複雑化・申請件数が増えてきたら、Microsoftの場合はPower Automate（承認ワークフロー）+SharePointリスト（変更履歴）の組み合わせが低コストで導入できます。Salesforceを使っている場合は標準の承認プロセス（Approval Processes）やカスタムオブジェクトを活用できます。

変更管理の仕組みは「使われなければ意味がない」ため、導入するツールは現場担当者が日常的に使えるシンプルさを優先します。複雑すぎる申請フォームや多段階の承認フローは、担当者に「変更管理を省略して直接変えてしまおう」という行動を招きます。まず最低限の3項目（変更内容・理由・影響範囲）で申請フォームを設計し、定着してから項目を追加する方が現実的です。

変更管理と品質監査への応用

変更管理の記録は、内部監査・外部監査・セキュリティ審査への対応で活用できます。「誰がいつどのマスタデータを変更したか」のログは、不正変更の検知・インシデント調査・コンプライアンス対応や監査対応（個人情報を扱う業務や財務関連データの管理など）において重要な証跡になります。変更管理ログの保存期間・アクセス権限の設計は、変更管理フローと合わせて整備することをお勧めします。

さらに、変更管理の記録を定期的に集計・分析することで、マスタデータ品質の改善につながるインサイトが得られます。「どのマスタドメインの変更申請が多いか」「どの変更理由が繰り返し発生しているか」を分析することで、変更が多発している根本原因（入力設計の問題・マスタの設計思想の問題）を特定し、予防的な品質改善に繋げられます。

緊急変更への対応：承認フローの例外設計

マスタデータの変更管理フローを設計する際に忘れがちなのが「緊急時の例外対応」の設計です。通常の変更申請→承認フローが完了するまでに2〜3営業日かかる場合、業務上すぐに変更が必要な緊急事態（取引先の急な名称変更・誤登録の即時修正）では、フローを待てないケースが発生します。緊急変更の場合は「緊急承認→即時変更→事後記録」という例外フローを設計します。チャット等で緊急承認を行う場合も、承認者・承認日時・承認内容が後から確認できるよう記録を残し、所定の期間内に正式な申請・履歴へ反映することが重要です。内部統制の観点では「事前承認」が原則であるため、緊急変更はあくまで例外であることを明確にし、その件数をモニタリングすることで例外の濫用を防ぎます。

緊急変更の例外を記録なく認めてしまうと、「緊急」を理由に申請を省略する習慣が広がり、変更管理フローが形骸化するリスクがあります。例外変更は必ず事後申請で記録を残し、緊急変更の件数を月次でモニタリングすることで、本当に例外が必要なケースと、ルールを回避するための「緊急名目」の利用を区別できます。緊急変更が多い場合は、通常フローの承認時間を短縮する改善が必要なサインでもあります。

変更管理の定着化チェック：運用レビューのポイント

変更管理フローを設計して運用を開始したら、3〜6か月後に定着化の状況をレビューすることをお勧めします。確認すべきポイントは「申請件数が月ごとに安定しているか」「承認なしの直接変更が発生していないか」「申請から承認までの所要日数が長すぎないか」の3点です。申請件数が少なすぎる場合は、フローを省略した直接変更が起きている可能性があります。承認所要日数が長すぎる場合は、承認者の変更・承認ステップの見直しが必要です。

変更管理を段階的に導入する：最小構成からの始め方

変更管理の仕組みを一度に完全整備しようとすると、現場の負担が大きくなり形骸化するリスクがあります。まずは「最小構成」から始めて、定着後に拡張する段階的アプローチが現実的です。第1段階は申請フォームの標準化（Excel）と承認メール通知のみ。第2段階は申請件数が増え、Excelやメールだけでは申請状況・承認状況・変更履歴の管理が難しくなってきたら、kintoneなどのワークフローツールへの移行を検討します。第3段階はERPや基幹システムと連携した自動承認フローと変更履歴の自動記録を整備する——この順で進めることで、現場の抵抗を最小化しながら変更管理を定着させられます。なお、kintoneやSharePoint等のツールを使う場合、申請者が「変更前の値」を手入力する手間を省くため、変更対象レコードを選択した時点で変更前の値を自動表示・参照できる設計にすると、入力負担が減り申請の省略を防げます。

重要なのは「誰でも申請できる状態を作ること」です。申請フォームが複雑すぎたり、申請先が不明確だったりすると、担当者は申請を省略して直接マスタを変更してしまいます。申請ハードルを下げるための工夫として、申請フォームへのショートカットをチーム共有フォルダに置く・申請方法をチャット（SlackやTeams）でいつでも質問できる窓口を設ける・申請承認の状況を申請者が確認できるようにすることが有効です。

まとめ

マスタデータの変更管理は「申請・承認・履歴記録」の3要素を設計することで、「誰がいつ何を変えたかわからない」問題を解消できます。変更の重大度に応じた承認権限の設計と、申請フォームのシンプルさのバランスが定着化の鍵です。まず最小構成（Excelフォーム＋メール承認）から始め、申請件数の増加に応じてツールを拡張する段階的な導入が、現場定着への近道です。マスタデータ変更管理の仕組み構築についてはBFT Insightにご相談ください。