近代化プロジェクトのためのデータ品質評価フレームワーク

データ品質への投資を正当化する標準的な根拠は、運用リスクにあります。組織の84%がデータ品質の低さから測定可能な混乱を経験しており、4分の1以上が直接的な結果として年間500万ドル以上の損失を被っています。標準的な対応策は、継続的な閾値に対して正確性、完全性、一貫性、適時性、妥当性、一意性を測定するデータ品質管理プログラムと、運用システムを流れるデータが定義された基準を満たしているかどうかを追跡する指標ダッシュボードです。

この標準フレームワークは、近代化プロジェクト向けに設計されたものではありません。COBOLを基盤とするメインフレームからクラウドネイティブプラットフォームへのデータ移行は、継続的な運用品質の問題ではありません。これは、移行前の特定の要件、移行時の特定のリスク、および移行後の特定の検証ニーズを伴う変革イベントであり、標準のデータ品質ディメンションでは部分的にしか対応できません。近代化プロジェクトに適したデータ品質スコアリングフレームワークは、運用監視に適したフレームワークとは、次の3つの点で根本的に異なります。すなわち、現在の運用への適合性ではなく移行への適合性を評価する必要があり、運用エラー率ではなく移行リスクを評価する必要があり、変換されたデータがソースデータと同等に動作するかどうかを確認する移行検証プロセスの証拠を生成する必要があります。

標準的なデータ品質フレームワークが近代化に不十分な理由

DAMA（データ管理知識体系）フレームワークの6つの側面、すなわち正確性、完全性、一貫性、適時性、妥当性、および一意性は、運用要件に対するデータ品質を測定する指標です。正確性95%、完全性98%、一貫性99%のレコードは、ほとんどのシステムにおいて運用品質の基準を満たします。ただし、移行に適しているかどうか、また移行先のシステムで正しい結果が得られるかどうかは保証されません。

不十分な点は、寸法そのものにあるのではなく、それらが何を測定しているのか、そして近代化プロジェクトの特定の目的において何を見落としているのかにある。

移行適合性と運用適合性は同じではありません。有効なCOMP-3パック10進数フィールドを持つVSAMレコードは、COBOLでは正しく動作しますが、ターゲットフィールドがDECIMALではなくFLOATとして定義されている場合、ターゲットデータベースへの移行時に正しく動作しない可能性があります。これは、元のフィールドを読み取るCOBOLプログラムがCOMP-3表現から正しい結果を計算するため、運用品質チェックを通過しますが、浮動小数点演算を使用するターゲットシステムでは丸め誤差が発生するという精度エラーです。運用品質スコアは高いですが、移行適合性スコアは低くなります。

ソースシステムの暗黙的なデータ契約は、外部の品質ツールからは見えません。COBOLプログラムは、手続き型コード、IF文の範囲チェック、EVALUATEブロックの書式検証、COMPUTE文の計算ルールなどを通じてデータ品質を強制します。これらの品質ルールはソースコード内に存在し、データ自体には存在しません。データを生成するプログラムを分析せずにデータをプロファイリングする外部のデータ品質ツールは、これらの暗黙的な制約を認識できないため、ターゲットシステムが同等の制約を強制しているかどうかを判断することができません。

AI対応は、運用面や移行面の適合性に加えて、第三の次元をもたらします。ガートナーは、AI対応データに裏付けられていないAIプロジェクトの60%が2026年までに放棄されると予測しています。「AI対応データ」は、運用上の定義における「クリーンデータ」とは異なります。AIモデルは、財務システムの「収益」には払い戻しが含まれないが、CRMの「収益」には含​​まれていることを知らず、両方を同じ指標として扱い、その矛盾を基盤として構築します。AIやアナリティクスの変革の一環である近代化プロジェクトでは、移行されたデータが下流のAIやアナリティクスワークロードで信頼できる結果を生み出すかどうかという、第三の基準に基づいてデータ品質を評価する必要があります。

近代化に特化したデータ品質の側面

近代化プロジェクト向けのデータ品質評価フレームワークは、標準的な6つの側面を拡張し、移行に特化した5つの評価項目を追加するものです。

標準的な6つの側面（移行の文脈に適用）

精度データが、それが記述する現実世界のエンティティまたはイベントをどの程度正確に表現しているかを示す度合い。移行のコンテキストでは、ソースシステムの表現とターゲットシステムの表現の両方に対して正確性を評価する必要があります。 PIC S9(11)V99 COMP-3 COBOLでは、DECIMAL(13,2)はパック10進数形式で暗黙的に小数点以下2桁までの値を表します。ターゲットデータベースにDECIMAL(13,2)として格納された同じ値は、同じ値を表します。バイナリ浮動小数点数で正確に表現できない値の場合、FLOAT(8)として格納された同じ値は、ほぼ正しい値ですが、完全に一致する値ではありません。

完全性とは、必要なデータがすべて揃っている度合いのことです。COBOLプログラムでは、SQLのNULLセマンティクスにそのまま変換されないNULLと機能的に同等のものとして、フィラーフィールド、パディングバイト、番兵値（すべて空白、すべてゼロ、高値）が頻繁に使用されます。移行のための完全性評価では、物理的には存在するものの、意味のあるデータが存在しないことを示すこれらの機能的なNULL値を特定し、それらがターゲットシステムのNULL処理にどのようにマッピングされるかを判断する必要があります。

一貫性とは、データセット間またはデータセット内におけるデータの矛盾の度合いを指します。メインフレームデータの場合、プログラム間の一貫性は特に重要です。同じビジネスエンティティ（顧客、アカウント、ポリシーなど）が、異なるプログラムによって管理される複数のVSAMファイルやDB2テーブルに表現される可能性があるためです。各プログラムは、エンティティの現在の状態に関する独自の記録を保持しています。一貫性スコアリングでは、これらの表現が一致しているかどうか、または移行によって一貫性のあるターゲットデータセットを作成する前に解決しなければならない不一致を特定する必要があります。

適時性とは、データが許容可能な時間枠内で現状をどの程度反映しているかを示す指標です。バッチ処理されるメインフレームデータの場合、適時性はバッチサイクルによって決まります。月次バッチでは、過去1か月以内の最新データが生成されます。一方、移行システムでは、ソースシステムが想定していなかった分析ワークロードのためにほぼリアルタイムのデータが必要となる場合があり、移行だけでは解消できない適時性のギャップが生じます。

妥当性データが定義されたフォーマットと型の制約にどの程度準拠しているか。 COBOL の 88 レベルの条件名は、データ型システムでは捉えられない意味的妥当性制約を作成します。フィールドは次のように定義されます。 PIC 9(2) COBOLプログラムでは、値が01～12（月）または01～31（日）の場合にのみ有効となり、有効性はレベル88の条件によって強制されます。フィールドをプロファイリングする外部データ品質ツールは、2桁の数値フィールドとして認識するため、コンテキスト内で値00、13～99を無効にする意味的な制約は認識しません。

一意性とは、データエンティティが一度だけ表現される度合いのことです。COBOLデータの一意性を理解するには、VSAM KSDSファイルがファイルレベルで主キーの一意性を強制するものの、同じ論理エンティティが異なるプログラムによって管理される複数のVSAMファイルに異なるキーで出現する可能性があることを理解する必要があります。CUSTMSTR.VSAMのCUSTOMER-RECORDとACTHLD.VSAMのACCOUNT-HOLDERが同じ実在の人物を表しているかどうかを判断するファイル間エンティティ解決は、どちらかのファイルを個別に調べても評価できない一意性の問題です。

移住特有の5つの側面

構造的整合性とは、データの物理的なレイアウトがプログラムが想定するスキーマ定義とどの程度一致しているかを示すものです。COBOLデータはPIC句の仕様に従って格納されます。プログラムが正しく解釈するためには、ディスク上またはVSAMレコード内の物理バイトがこれらの仕様に準拠している必要があります。構造的整合性の障害、つまりCOMP-3フィールドにパック10進数として無効なビットパターンが含まれているレコードや、数値フィールドに非数値文字が含まれているレコードは、レガシーデータによく存在し、無効な値を使用しないプログラムからは見えません。変換ツールがこれらのフィールドを読み取ろうとすると、移行エラーが発生します。

スキーマバリアントのカバレッジとは、データ品質スコアリングがソーススキーマ内のすべての REDEFINES バリアントをどの程度考慮しているかを示すものです。VSAM ファイル構造分析の文脈で説明したように、VSAM レコードには、REDEFINES 句によって定義された複数の重複するレイアウトが存在する場合があります。基本レコードレイアウトをプロファイリングする標準的なデータ品質評価では、各レコードにどのバリアントが適用されるかを決定する識別子フィールドの値や、適切な条件下での各バリアントのフィールド値の妥当性など、REDEFINES バリアントの品質特性が見落とされてしまいます。

プログラム間の一貫性とは、同じビジネスエンティティの重複する表現を保持する複数のプログラム間で、データ値がどの程度一貫しているかを示す指標です。この側面は、同じエンティティが複数のプログラムによって共有データセットを通じて管理されるメインフレーム環境に特有のものです。ビジネスルールが変更された際に一方のプログラムが更新され、もう一方のプログラムは更新されなかったために、2つのプログラム間で異なる実装がなされたビジネスルールは、単一プログラムのデータ品質評価では検出できないプログラム間の不整合を引き起こします。

精度を考慮した品質とは、数値データが対象システムで同等の精度で表現できる度合いを指します。この指標は、COBOLプログラムでよく使用され、精度を考慮した対象型マッピングを必要とするCOMP-3、COMP、COMP-5フィールドに特化しています。すべての数値フィールドを特定し、その値が対象フィールド型の範囲と精度内に収まっているかどうかを評価する品質評価は、移行固有の品質チェックであり、標準的なプロファイリングツールでは実行されません。

移行準備スコアは、各データエンティティがそのまま移行できる状態にあるか、移行前の修正が必要か、または同等の動作を実現するために移行先側での変換が必要かを総合的に評価したものです。移行準備スコアは、前述の各次元を組み合わせた結果です。正確性、完全性、一貫性、妥当性、一意性、構造的整合性、スキーマバリアントの網羅性、プログラム間の一貫性、および精度を考慮した品質において高いスコアを獲得したレコードは、移行準備完了です。これらの次元のいずれかに不合格となったレコードは、廃棄、クリーンアップ、変換、除外、または文書化されたリスクを伴う差分の受け入れが必要です。

複合品質スコアの計算

近代化プロジェクトの複合データ品質スコアは、各次元スコアの加重平均であり、その重みは、特定の移行状況における各次元の相対的な重要性を反映しています。

次元	標準重量	財務データの調整	分析目標の調整
精度	25%	30%（精度が重要）	20%
完全	20%	15%	25%（AIには完全な機能が必要）
一貫性	15%	20％（規制）	20%
妥当性	15%	15%	10%
独自性	10%	10%	15%（AI向け重複排除）
適時性	5%	5%	10％（モデルの鮮度）
構造的完全性	5%	2%	0%（変換後）
スキーマバリアントの網羅率	3%	2%	0%
プログラム間の一貫性	1%	1%	0%
精度を意識した品質	1%	1%	0%

各項目は0～100点で採点され、総合スコアは加重合計値となります。この総合スコアに基づいて、移行準備状況の分類が決定されます。

複合スコア	移行準備	推奨される処置
90-100	レディ	標準検証を使用して移行する
75-89	監視準備完了	移行後の検証を強化して移行する
60-74	条件付きの	移行前に特定の次元の障害を修正する
40-59	準備ができていない	移行前の大幅な是正措置が必要
40以下	重大な品質問題	根本原因分析と修復が完了するまで移行しないでください。

実践的な測定：評価ワークフロー

近代化プロジェクトにおけるデータ品質スコアリング評価は、運用品質監視とは異なる特定のワークフローに従います。

ステップ 1: スキーマの発見とドキュメント化。データをスコアリングする前に、そのデータを定義するスキーマを把握しておく必要があります。メインフレーム データの場合、これは各データセットにアクセスするすべての COBOL プログラムから FD エントリ、COPY メンバー、および SELECT 句を解析することを意味します。スキーマ発見フェーズでは、データ型、長さ、COMP 仕様を含む完全なフィールド インベントリ、すべての REDEFINES 階層とその識別子条件、88 レベルの条件名とその意味制約、および PROCEDURE DIVISION ロジックに組み込まれたプログラム レベルのデータ品質ルールが生成されます。

ステップ 2: 発見されたスキーマに対するデータ プロファイリング。想定または文書化されたスキーマではなく、ステップ 1 で発見されたスキーマに対して各データセットをプロファイリングします。プロファイリング対象: null 相当頻度 (NULL セマンティクスが意図されているフィールドのスペース、ゼロ、高値)、88 レベルの制約に対する値範囲分布、構造的整合性 (有効な COMP-3 ビット パターン、有効な COMP-5 表現)、フィールド間の一貫性 (日付フィールドで、日付の値が指定された月の最大値を超えている)、レコード間の一貫性 (共有属性で一致するはずなのに一致しない関連レコード)。

ステップ3：プログラム間の整合性評価。複数のプログラムまたはデータセットにまたがって表現されている各ビジネスエンティティについて、表現間の整合性を評価します。これには、依存関係マッピングによって重複する表現を保持しているプログラムを特定すること、各エンティティの各表現に対応するレコードを抽出すること、整合性が保たれるべき値を比較すること、および不一致とその頻度と深刻度を文書化することが必要です。

ステップ4：精度影響分析。COMP -3フィールドとバイナリ数値フィールドごとに、ターゲットフィールドタイプのマッピングによる精度への影響を計算します。具体的には、ソースデータ内でターゲットフィールドタイプに正確に表現できない値を特定し、タイプ変換によって生じる丸め誤差を定量化し、下流のユースケース（規制報告と内部分析では許容範囲が異なる）を考慮して、丸め誤差が許容範囲内かどうかを判断します。

ステップ5：ディメンションスコアリングと複合スコアの計算。ディメンションスコアを適用し、データタイプと移行対象のコンテキストに応じて重み付けを行います。各データセットおよびポートフォリオ全体について、複合スコアと移行準備状況の分類を作成します。

ステップ6：修復計画。移行準備のしきい値を下回るスコアのデータセットについては、以下の項目を特定する修復計画を作成します。品質チェックで失敗した特定のデータ要素、影響を受けるレコード数、失敗を修正するビジネスルールまたは変換、および修復が完了したことを確認する検証チェック。

データ品質測定のためのSQLパターン

実用的な品質評価には、実行可能な測定が必要です。以下のSQLパターンは、レガシーシステムからステージング環境に抽出されたデータに対して、最も一般的なモダナイゼーション固有の品質チェックを実装します。

SQL

-- 1. Completeness: detect functional nulls (spaces/zeros as NULL equivalents)
SELECT
    COUNT(*)                                          AS total_records,
    SUM(CASE WHEN TRIM(CUSTOMER_NAME) = ''
             THEN 1 ELSE 0 END)                       AS functional_null_name,
    SUM(CASE WHEN ACCOUNT_BALANCE = 0
             AND ACCOUNT_STATUS NOT IN ('ACTIVE','CLOSED')
             THEN 1 ELSE 0 END)                       AS suspicious_zero_balance,
    ROUND(100.0 * SUM(CASE WHEN TRIM(CUSTOMER_NAME) = ''
                           THEN 1 ELSE 0 END)
              / COUNT(*), 2)                          AS functional_null_pct
FROM staging_customer_master;

-- 2. Validity: check 88-level equivalent constraints (month range)
SELECT
    COUNT(*)                                          AS total_records,
    SUM(CASE WHEN TRANSACTION_MONTH NOT BETWEEN 1 AND 12
             THEN 1 ELSE 0 END)                       AS invalid_month_count,
    SUM(CASE WHEN TRANSACTION_DAY NOT BETWEEN 1 AND 31
             THEN 1 ELSE 0 END)                       AS invalid_day_count,
    SUM(CASE WHEN TRANSACTION_YEAR < 1900
              OR TRANSACTION_YEAR > 2100
             THEN 1 ELSE 0 END)                       AS invalid_year_count
FROM staging_transaction_header;

-- 3. Precision impact: identify values that lose precision in FLOAT conversion
SELECT
    RECORD_KEY,
    ORIGINAL_AMOUNT,
    CAST(CAST(ORIGINAL_AMOUNT AS FLOAT) AS DECIMAL(13,2)) AS float_roundtrip,
    ABS(ORIGINAL_AMOUNT -
        CAST(CAST(ORIGINAL_AMOUNT AS FLOAT) AS DECIMAL(13,2)))
                                                      AS precision_loss
FROM staging_financial_amounts
WHERE ABS(ORIGINAL_AMOUNT -
          CAST(CAST(ORIGINAL_AMOUNT AS FLOAT)
               AS DECIMAL(13,2))) > 0.005
ORDER BY precision_loss DESC;

-- 4. Cross-program consistency: compare entity representations across programs
SELECT
    a.CUSTOMER_ID,
    a.CUSTOMER_NAME        AS name_in_custmstr,
    b.ACCOUNT_HOLDER_NAME  AS name_in_acthld,
    a.CUSTOMER_ADDRESS     AS addr_in_custmstr,
    b.MAILING_ADDRESS      AS addr_in_acthld,
    CASE WHEN a.CUSTOMER_NAME <> b.ACCOUNT_HOLDER_NAME
         THEN 'NAME_MISMATCH' ELSE 'OK' END           AS name_consistency,
    CASE WHEN TRIM(a.CUSTOMER_ADDRESS) <> TRIM(b.MAILING_ADDRESS)
         THEN 'ADDRESS_MISMATCH' ELSE 'OK' END        AS addr_consistency
FROM staging_customer_master a
JOIN staging_account_holder b
    ON a.CUSTOMER_ID = b.CUSTOMER_ID
WHERE a.CUSTOMER_NAME <> b.ACCOUNT_HOLDER_NAME
   OR TRIM(a.CUSTOMER_ADDRESS) <> TRIM(b.MAILING_ADDRESS)
ORDER BY a.CUSTOMER_ID;

-- 5. Uniqueness: identify duplicates on logical keys
SELECT
    CUSTOMER_ID,
    COUNT(*)   AS occurrence_count,
    MIN(RECORD_TIMESTAMP) AS first_occurrence,
    MAX(RECORD_TIMESTAMP) AS last_occurrence
FROM staging_customer_master
GROUP BY CUSTOMER_ID
HAVING COUNT(*) > 1
ORDER BY occurrence_count DESC;

移住波に対する品質ゲートフレームワーク

近代化プログラムは通常、アプリケーションとデータセットのグループをまとめて移行する「波状移行」方式で進められます。データ品質スコアリングフレームワークは、この波状移行の構成を決定する上で重要な役割を果たします。

移行ウェーブの適格基準：データセットは、その総合品質スコアがウェーブの最小しきい値を超えている場合にのみ、移行ウェーブの適格性を有します。ティア1（ミッションクリティカル）アプリケーションの場合、最小しきい値は85です。ティア2の場合は75です。これにより、ミッションクリティカルなアプリケーションが、十分な品質基準を満たしていないデータに基づいて移行することを防ぎます。

移行実行前の品質ゲート：移行実行が開始される前に、最終的な品質スキャンによって、データの品質スコアが初期評価以降低下していないことを確認します。ソースシステムが稼働を続け、評価時に特定された品質基準を満たさない新しいレコードを蓄積し続けると、初期評価から移行実行までの間にデータ品質が低下する可能性があります。

移行後の同等性検証：各ウェーブの移行後、品質フレームワークは比較基準を提供します。ソースデータで計算されたすべての次元スコアは、移行後のデータで再計算され、ソーススコアとターゲットスコアの差が移行品質レポートとなります。ソースよりも精度、完全性、またはプログラム間の一貫性が低いターゲットデータセットを生成した移行は、品質劣化を引き起こしたため、次のウェーブに進む前に調査する必要があります。

認定条件 SMART TS XL 近代化のためのデータ品質スコアリングをサポート

移行固有の品質特性、スキーマバリアントの網羅性、プログラム間の一貫性、精度を考慮した品質、および構造的整合性はすべて、標準的なデータ品質ツールにはない、ソースアプリケーションコードに関する高度な理解に依存します。これらの特性を理解するには、データを生成するプログラムが有効なものとして定義しているもの、COMP-3 であり精度を考慮したターゲットマッピングを必要とするフィールド、および同じビジネスエンティティの重複表現を保持しているプログラムを把握する必要があります。

SMART TS XLさん 静的コード分析 スキーマ検出レイヤーを提供します。COBOLポートフォリオ全体にわたるすべてのFDエントリ、COPYメンバー、およびSELECT句を解析し、完全なスキーマインベントリ、すべてのフィールド定義、すべてのREDEFINES階層、すべての88レベル制約、すべてのCOMP-3精度仕様を生成します。このインベントリは、移行固有の品質ディメンションに必要な基盤であり、データ自体からは導き出すことができません。

アプリケーション依存関係マッピングにより、プログラム間の整合性評価が可能になります。どのプログラムがどのデータを保持しているか、どのプログラムがどのVSAMデータセットに書き込んでいるか、どのデータセットに同じビジネスエンティティの重複表現が含まれているかを示すマップを作成することで、依存関係マップはプログラム間の整合性スコアリングが必要なペアとグループを特定します。このマップがないと、評価者はどのプログラムとデータセットが同じエンティティを表しているかを知ることができないため、プログラム間の整合性を評価することはできません。

影響分析機能により、品質ゲートフレームワークを大規模に運用することが可能になります。特定のデータセットで品質問題が発見された場合、影響分析によってそのデータセットに依存するすべてのアプリケーション、プログラム、およびビジネスプロセスが特定され、品質問題が下流に及ぼす影響の範囲が決定され、影響を受ける依存プログラムの数に基づいて修復の優先順位が付けられます。

エンタープライズ検索機能により、移行プログラム全体を通して品質インベントリを照会できます。特定のVSAMファイルを読み取るすべてのプログラム（プログラム間の整合性評価の範囲を定めるため）、COMP-3として定義されているすべてのフィールド（精度を考慮した品質インベントリを構築するため）、88レベルのすべての条件名（外部ツールでは確認できない意味的妥当性制約を列挙するため）を検索できます。この検索機能は、初期品質評価と、評価から移行実行までの間に品質が低下しないことを保証する継続的な監視の両方をサポートします。

組織が実施する場合 レガシーの近代化 プログラム、 SMART TS XLの分析は、運用監視用に設計されたデータ品質フレームワークと、近代化プロジェクトが正しい結果を生み出すかどうかを判断する移行固有の品質要件との間のギャップを埋めるものです。標準的なデータ品質の次元は必要不可欠ですが、移行固有の拡張機能によって、それらは十分なものとなります。

結論：移行のための品質は、運用のための品質ではない

2026年のデータ品質環境は、運用データ管理向けに設計されたフレームワーク、ツール、および指標が豊富に存在します。DAMAの各側面は確立され、広く導入されています。Great Expectations、Monte Carlo、Collibra、dbtといったツールも大幅に成熟しました。品質ルールを定義し、データをプロファイリングし、閾値に基づいて監視するという標準的なアプローチは、設計された運用目的において十分に機能します。

近代化プロジェクトには、従来とは異なるアプローチが求められます。運用上の適合性ではなく、移行の適合性を評価する品質スコアリングが必要です。データそのものだけでなく、データを生成するソースコードの理解も必要です。精度を考慮した数値フィールド分析、REDEFINESバリアントカバレッジ、およびプログラム間の整合性評価といった、運用システムでは必要とされない側面を、運用品質フレームワークでは網羅的に扱う必要があります。

適切な移行結果を生み出す組織は、移行という特定の目的のためにデータ品質評価フレームワークを構築し、その後運用監視に拡張する組織です。移行のためのデータ品質は、運用データ品質管理のサブセットではありません。それは独自の分野であり、独自の次元、独自の閾値、独自の検証要件を持ち、そのように扱うことが、近代化プログラムが技術的な約束を果たすための鍵となります。