完全性とは
完全性は、データが実際に存在するかどうかを測定します。フィールドは意味のあるデータを含むときに完全といえます。null、空欄、または「N/A」「TBD」のようなプレースホルダで埋められているときは不完全といえます。
完全性はデータ品質の次元の中で最も基本的なものです。データがなければ、検証、重複排除、分析の対象が存在しません。
完全性率 =(データのあるレコード / 全レコード)× 100
Contactレコード1,000件のうち850件にEmail値があれば、Emailの完全性率は85%です。この指標は(入力率とも呼ばれ)、どのフィールドにおいても看板となる数字です。
完全性が重要な理由
レポート
不完全なデータは分析を歪めます。Accountレコードの40%に業種の値がなければ、業種でグループ化したレポートは部分的な真実しか示せません。ダッシュボードは信頼できなくなります。経営層の意思決定が全体像の一部に基づくことになります。
自動化
Salesforceの自動化はフィールドの値に依存します。メールを送信するワークフローは、Emailが空欄だと失敗します。Account Ownerを更新するプロセスは、ルックアップがnullだと失敗します。欠損値の一つひとつが自動化失敗の潜在要因です。
AIとAgentforce
AIモデルはデータから学習します。フィールドが空欄なら、学習する材料がありません。AgentforceはSalesforceのデータを使って応答を生成し、アクションを取ります。欠損データは不完全なコンテキストとなり、AIの出力の有用性を下げます。
| システム | 完全性の影響 |
|---|---|
| レポート | 部分的なデータが偏った指標を生む |
| ワークフロー | 欠損値がプロセス失敗を招く |
| 重複ルール | 不完全なレコードはマッチングが難しい |
| Agentforce | コンテキストのギャップがAIの精度を下げる |
DQSによる完全性の測定方法
DQSは、次の診断的な問いを軸として10の完全性指標を算出します。「データはどこで欠けているのか、なぜ欠けているのか、存在するデータは本当に有用なのか」
これらの指標は診断ファネルのようなものです。各ステップは前のステップの上に積み上がります。
ステップ1:どの程度完全か
完全性率は看板となる指標です。非空・非nullの値を持つレコードの割合を計算します。ダッシュボードに掲載する数字がこれです。
Accountオブジェクトでスキャンを実行します。Industryフィールドの完全性率は62%と表示されます。つまりAccountの38%に業種値がないということです。業種でフィルタするセグメンテーションレポート、テリトリールール、マーケティングキャンペーンはすべて不完全なデータで動いていることになります。
他の完全性指標はすべて、この数字が100%でない理由を説明するために存在します。
ステップ2:規模はどの程度か
率は深刻度を示し、件数は作業量を示します。入力済み件数が規模の問いに答えます。実際に値を持つレコードが何件あるかを示します。カバレッジレポートや、総レコード数に対するギャップの規模把握に使います。総数と入力済み件数の差が、クレンジングのバックログです。
**例:**データスチュワードはクレンジングキャンペーンを構築する必要があります。Contact 50,000件でPhoneの入力済み件数が35,800件なら、14,200件のレコードにエンリッチメントが必要だとわかり、データベンダーへの費用見積もりと現実的なタイムラインを設定できます。
ステップ3:なぜ不完全なのか
3つの指標が不完全さの原因を分解します。それぞれ異なる根本原因を示します。
null件数とnull率は、フィールドがデータベース上で真のnullを持つレコード、すなわち一度も値が入ったことがないレコードを測定します。Salesforceでは、nullと空文字列は異なる状態です。一度も触れられていないフィールドはnullです。明示的にクリアされたフィールドは空文字列です。この区別により、データが一度も取得されなかったのか、意図的に削除されたのかがわかります。
**例:**データ移行後、AccountのFaxフィールドはnull率45%を示します。ファクスのデータは、取得後に後でクリアされたのではなく、レガシーシステムから移行されませんでした(null=一度も存在しなかった)。高いnull率は、ユーザーの行動ではなくソースシステムを指し示します。
プレースホルダ件数とプレースホルダ率は、「N/A」「TBD」「Unknown」などの既知のプレースホルダ値や、ユーザー定義のカスタム値を含むレコードを測定します。これらの値はデータのように見えますが、実際の情報を持ちません。
**例:**グローバルなAccountデータはIndustryの完全性率が94%と表示されます。数字の上では良好に見えます。しかしプレースホルダ率を見ると、これらの「入力済み」値の18%が実際は「N/A」「Other」「Unknown」であることがわかります。真の完全性は76%に近い値です。ダッシュボードの緑を赤に変える指標です。
ステップ4:「完全な」データは有用か
最初の3ステップは何が欠けているかを特定します。ステップ4はより難しい問いを投げかけます。そこにあるデータは持つ価値があるのか。
Incompleted件数は最も広い欠損データの指標です。null、空欄、そしてプレースホルダ値という、あらゆる形の不完全さを組み合わせます。プレースホルダ検出が有効な場合、Incompleted件数は常にnull件数単独以上になります。空白のみおよびプレースホルダの入力も捕捉するためです。
**例:**OpportunityのDescriptionフィールドはnull件数500件ですが、Incompleted件数は1,800件です。その差は何か。1,300件のレコードには「TBD」「N/A」「---」のような説明が入っています。これらのレコードは技術的には入力されていますが、実質的に役立ちません。この指標がなければ、修正対象は1,800件ではなく500件だと考えてしまうでしょう。
Rich Text Ratioは、文字数のしきい値を超える実質的なコンテンツを含むテキストフィールドレコードの割合を測定します。意味のある文章を含むフィールドと、数語しかないフィールドを区別します。Descriptionフィールドは、「Good customer」であっても3段落のアカウントプランであっても「入力済み」です。AI対応においては、存在以上にコンテンツの深さが重要です。
**例:**あなたの会社はCaseの説明を要約するAIツールを評価しています。CaseのDescriptionフィールドをスキャンします。完全性率88%、しかしRich Text Ratioはわずか31%です。Caseの説明のうち、AIが機能するのに十分な中身があるのは31%だけです。残りは「call back」「see email」「issue reported」といった入力です。このAIプロジェクトは、価値を届ける前にデータエンリッチメントの段階が必要です。
Text Field Utilizationは、テキストフィールドの利用可能な文字数のうち、どれだけが使われているかを測定します。32,000文字の容量を持つLong Text Areaで、平均入力が45文字であれば、利用率は非常に低いです。
Average Utilizationは、すべてのレコードにわたってフィールド長の使用割合の平均を示します。Text Field Utilizationと組み合わせることで、テキストフィールドが適切なサイズかどうかの全体像が見えてきます。
**例:**組織評価の中で、Text Field UtilizationはNotes__c(Long Text Area、131,072文字)の平均利用率が3.2%で、ほとんどの入力が200文字未満であることを明らかにします。一方でShort_Description__c(Text、255文字)は利用率94%で、頻繁に切り詰め問題が発生しています。スキーマのサイズ見直しが必要です。Long Text Areaは過剰で、Textフィールドは小さすぎます。
**注:**Text Field UtilizationとAverage UtilizationはStringフィールドとTextAreaフィールドにのみ適用されます。測定対象となる文字数容量が定義されているのはこれらのフィールドタイプだけだからです。
率と件数がペアである理由
ほとんどの指標は率(パーセンテージ)と件数(絶対数)の両方で提供されます。これは意図的なものです。
- 率はダッシュボード、経営層向けレポート、トレンド追跡のためのものです。「今四半期で完全性が72%から89%に改善した」
- 件数はプロジェクト計画、作業量見積もり、クレンジング範囲設定のためのものです。「修正すべきレコードが14,200件ある」
進捗の伝達には率を使いましょう。作業計画には件数を使いましょう。
指標リファレンス
基礎指標
次の5つの指標は、完全性分析の基盤を成します。ほぼすべてのフィールドタイプで機能します。
| 指標 | タイプ | 適用対象 |
|---|---|---|
| 完全性率 | パーセンテージ | すべてのフィールドタイプ |
| 入力済み件数 | 件数 | すべてのフィールドタイプ |
| Incompleted件数 | 件数 | すべてのフィールドタイプ |
| null率 | パーセンテージ | すべてのフィールドタイプ |
| null件数 | 件数 | すべてのフィールドタイプ |
コンテキスト指標
次の5つの指標は「そこにあるか」を超えて「意味があるか」を問います。Contextual Completeness分析モードが必要です。
| 指標 | タイプ | 適用対象 |
|---|---|---|
| プレースホルダ率 | パーセンテージ | テキストフィールドのみ |
| プレースホルダ件数 | 件数 | テキストフィールドのみ |
| Rich Text Ratio | パーセンテージ | テキストフィールドのみ |
| Text Field Utilization | パーセンテージ | StringとTextAreaのみ |
| Average Utilization | パーセンテージ | StringとTextAreaのみ |
フィールドタイプのカバレッジ
DQSはすべての標準Salesforceフィールドタイプで完全性チェックをサポートします。
| カバレッジグループ | フィールドタイプ | 利用可能な指標 |
|---|---|---|
| 全タイプ(20) | String、TextArea、LongTextArea、Html、EncryptedText、Picklist、Multipicklist、Email、Phone、URL、Reference(Lookup)、Date、DateTime、Double、Integer、Currency、Percent、Boolean、Combobox、Id | 完全性率、入力済み/Incompleted件数、null率/件数 |
| テキストフィールド(8) | Text、TextArea、LongTextArea、Html、EncryptedText、Email、Phone、URL | 上記+プレースホルダ率/件数、Rich Text Ratio |
| StringとTextArea(2) | String、TextArea | 上記+Text Field Utilization、Average Utilization |
2つの分析モード
DQSには2つの完全性分析モードがあります。
Basic Completenessは「フィールドは入力されているか」という問いに答えます。5つの基礎指標を生成し、データ衛生チェックや簡単な監査に必要な要素をカバーします。
Contextual Completenessはさらに深く掘り下げます。プレースホルダ検出、リッチテキスト分析、フィールド利用率を含む10指標すべてを生成します。存在するデータと有用なデータを区別する必要がある場合にこのモードを使います。
| ビジネスニーズ | 推奨モード |
|---|---|
| 簡易衛生チェックまたはベースライン監査 | Basic Completeness |
| データ移行評価 | Contextual(プレースホルダ検出でレガシーシステム由来の偽データを検出) |
| AI対応度評価 | Contextual(Rich Text Ratioと利用率指標でコンテンツの深さを評価) |
| 継続的データガバナンス | Basicから始め、深い分析の準備ができたらContextualへ |
完全性の設定
DQSは完全性に対して4つの設定入力を提供します。それぞれグローバルレベル(すべてのフィールドに適用)で設定し、個別フィールドレベルでオーバーライドできます。
| 設定 | 制御内容 |
|---|---|
| Blank As Incomplete | 有効にすると、DQSは空文字列と空白のみの値を不完全として扱います。デフォルト:有効。 |
| Placeholders As Incomplete | 有効にすると、DQSはプレースホルダ値(「N/A」「TBD」など)を不完全として扱います。デフォルト:無効。 |
| Placeholder Values | DQSがプレースホルダとして扱う文字列のリスト。組織のデータ入力パターンに基づいて定義します(例:N/A, TBD, Unknown, --, 000-000-0000)。 |
| Case-Sensitive Placeholders | プレースホルダマッチングが大文字小文字を区別するかを制御します。有効にすると「tbd」と「TBD」は異なる値として扱われます。デフォルト:大文字小文字を区別。 |
**ヒント:**まずは一般的なプレースホルダ(「N/A」「TBD」「Unknown」「—」)から始め、スキャン結果で見つかった組織固有の値を追加しましょう。
よくある完全性の問題
任意フィールドが一度も入力されない
フィールドが任意の場合、ユーザーはスキップします。時間とともに、Company DescriptionやLinkedIn URLなどの有用なフィールドはほぼゼロの完全性率になります。
**対処法:**重要なフィールドを必須にするか、レコード編集時にプロンプトを作成します。
ギャップのある一括インポート
データ移行やリストインポートでは、特定のフィールドの値が欠けていることがよくあります。購入した連絡先リストにはAccountの関連付けがありません。レガシーシステムからのエクスポートには標準化された業種値がありません。
**対処法:**ロード前にインポートを監査します。DQSでベースラインを確立し、インポート後の改善を追跡します。
プレースホルダの濫用
ユーザーは入力規則を通すために「N/A」や「TBD」を入力します。フィールドは完全に見えますが、実際には使える情報がありません。標準レポートはこれらを入力済みとして数えます。
**対処法:**プレースホルダ検出を有効にし、プレースホルダ値リストを定義します。定期的なデータメンテナンス時にプレースホルダ値を見直し更新します。
空白のパディング
一部のインテグレーションや手動入力では、フィールドに空白のみが残ります。Salesforceはこれらを「入力済み」として数えますが、有用な情報は含まれていません。
**対処法:**空欄検出を有効にし、空白のみの値を検出します。
ベストプラクティス
ビジネスインパクトで優先順位をつける
すべてのフィールドに高い完全性が必要なわけではありません。自動化を動かすフィールド、経営ダッシュボードに表示されるフィールド、AIやAgentforceに供給されるフィールド、コンプライアンス要件を支えるフィールドに焦点を当てましょう。
トレンドを時系列で追跡する
単一の完全性スコアはスナップショットです。複数のスキャンにわたってスコアを追跡し、劣化を早期に検出し、改善施策を測定し、問題のあるデータソースを特定しましょう。
根本原因に対処する
低い完全性はプロセスの問題を示します。ユーザーがフィールドをスキップしているのか、インポートにデータが欠けているのか、インテグレーションが無言で失敗しているのかを調査しましょう。症状ではなく原因を修正します。
診断ファネルを使う
完全性率で止まらないでください。ファネルを進みましょう。規模を確認し(入力済み件数)、原因を特定し(null対プレースホルダ)、コンテンツ品質を評価(Rich Text Ratio、利用率)します。各ステップは異なる種類の問題を明らかにし、異なる修正を要求します。
次のステップ
完全性の測定と改善方法を理解しました。次の次元について学び続けましょう。