重複レコード統合のUX：残す値と関連データを確認する

レコードの統合画面では、確定する前に統合後の内容を予測できることが大切です。どの値が残るのか、関連する業務データはどうなるのか、元に戻せるのかを示します。名前が似ていることは調査のきっかけになりますが、同じ人や組織の情報だという証拠にはなりません。

この記事では、業務担当者が仕入先の重複レコードを統合する画面を設計します。データテーブルの部品設計では、この作業に入る前の行や選択部品を扱います。ここで考えるのは二件を選んだ後の判断、つまり「統合後のレコードに、どのデータを残すか」です。

同一性の確認、値の選択、関連データの扱いを分ける

購買システムに、Northstar Studioという仕入先のレコードが二つあるとします。SUP-104には以前の請求先メールアドレスと三件の発注があり、SUP-218には新しい請求先メールアドレスと二件の発注があります。そのうち一件の発注は両方に関連付いています。会社名が一致すれば確認候補になりますが、登記上の住所が違うなら、別々の会社かもしれません。

画面が答えるべき問いは三つです。この二件は一つにまとめるべきか。食い違う項目のどちらの値を残すか。発注、メモ、ファイル、参照はどうなるか。「新しい方を残す」という一つの初期設定にまとめると、この三つの判断が見えなくなります。

名前の横に変わらないレコードIDを置き、誤った一致に気付ける情報を添えます。確認済みのドメイン、取引先番号、既知の事業所住所は、アバターをもう一つ見せるより役立つ場合があります。重要な情報は出典と最終確認日時も示します。昨日変わったのがタグだけなら、「昨日更新」という表示だけで連絡先の正しさは判断できません。

統合せずに離れる方法も残します。重複候補の確認では、「別の仕入先です」と「後で確認」は異なる結果です。前者は同一という推定を否定し、後者は判断を保留します。どちらを選んでも、説明なくレコードを削除したり、未確認の別の候補を消したりしないようにします。

初期選択の理由を示し、確認済みと取り違えさせない

初期選択は手間を減らしますが、理由を説明できることが前提です。購買システムと接続しているレコードを優先しながら、請求先の連絡先はもう一方から選ぶこともあります。優先する情報源を明記し、選択した各値を結果の列に示します。左から右への矢印だけで、どちらのデータが残るかを説明しないでください。

実際の製品でもルールは異なります。HubSpotの統合ガイド（英語）は、残すプロパティ値の確認、関連付けの統合、統合を取り消せないことを説明しています。Attioの説明（英語）では、値が競合すると右側のレコードを優先し、結果に新しいレコードIDが付く方式です。「主レコード」という言葉がどこでも同じ意味だと想定せず、自分たちの製品のルールを示す必要があります。

特に、優先する値の情報源と、統合後のレコードの識別は分けます。SUP-104の名前とメールアドレスを残しても、結果のIDがSUP-104になるとは限りません。新しいIDを発行するなら、その結果を伝えます。既存のリンクが統合先へ移動する仕様は、開発側が確認できた場合にだけ説明します。

項目ごとに違いと、選んだ結果を比較する

パソコンで項目数が適度なら、情報源A、情報源B、選択結果の三列が比較しやすくなります。項目名は各行の近くに残します。違いは色に加えて文字やアイコンで示し、選択した値を、選べるだけの候補と区別します。

選んだ値の横に情報源のIDを残し、元レコードを開き直さなくても、結果をたどれるようにします。

項目が多い場合は「違いだけ表示」を用意しつつ、「すべての項目を表示」も残します。一致する値が正しいとは限らず、承認前に全体を見る必要もあります。未解決の競合があれば、「支払条件と請求先メールを選んでください」のように操作の近くで具体的に伝えます。理由のない無効ボタンでは、先へ進む方法が分かりません。

空欄をすべて同じ意味にしないでください。「記録なし」「意図的に削除済み」「閲覧権限なし」では扱いが異なります。閲覧できない値を単なる空欄として見せ、自由に上書きできると思わせないようにします。保護された項目のため安全に統合できないなら、値自体を明かさずに、誰が確認できるかを説明します。

関連付けは、件数を足す前に中身を確認する

二件の統合は、比較表の項目以外にも影響します。発注は内部IDで仕入先を参照しているかもしれません。同名のファイルでも内容が違う場合があります。メモの作成者と日時は、元のメモと対応したまま残す必要があります。

この例の発注は五件ではなく、異なる四件です。両方に存在する発注を含め、実際の関連項目か、展開して確認できる要約を示します。重複を除く関連付け、制限のある情報、別に処理するものがあるなら、「すべてのデータを保持します」という一括の説明では不十分です。

例外は、判断に必要な場所で説明します。外部連携のため統合できないなら、他の12項目を選ばせる前に知らせます。移せない添付ファイルがあれば、名前と解決方法を示します。処理全体を止める条件と、利用者が納得して除外できる任意の項目を分けます。

通知の受信設定、アクセス権、確認済みの本人情報などは、製品で承認したルールに従います。日時が新しい、または空でないという理由だけで、どちらかを正式な情報源と決めないようにします。

結果を確認して確定し、実際の処理結果を伝える

確定前の説明には、直前の選択を反映します。「二つの仕入先レコードを一つに統合します」と示し、選んだ請求先メール、発注の結果、元に戻せない影響を続けます。比較画面ですでに分かるなら、一般的な「よろしいですか」というダイアログを重ねても、判断材料は増えません。結果を見直せる位置で最終操作を行えるようにします。

最終ボタンは「仕入先レコードを統合」のように操作を名付けます。「キャンセル」や「一覧へ戻る」も曖昧にしません。値、関連付け、その後の影響を実際に戻せる場合にだけ、「元に戻す」を提供します。監査イベントが記録されていても、それ自体が復元の仕組みになるわけではありません。

送信後も、処理中と完了を分けます。「統合を受け付けました」を「統合しました」と同じ見せ方にしないでください。バックグラウンドで続くなら、状態を確認できる固定の場所と、そこへ戻る方法を示します。応答が遅いだけで、もう一度統合を依頼しないようにします。

通信が途切れると、結果が不明になる場合があります。この場合は「何も変わりませんでした」と断定せず、処理状況を確認する方法を提供します。検証で失敗したと確定している場合は別です。止めた項目や関連付けを具体的に示し、利用者の選択を保って修正できるようにします。

同時編集にも備えます。比較画面を開いている間に、別の担当者が請求先メールを変えたとします。確定前にプレビューの元データと現在のレコードを比較し、違いがあれば、その項目と影響をもう一度確認してもらいます。古いプレビューのまま黙って適用すると、丁寧に比べた意味がなくなります。

完了後は結果のレコードを開くかリンクし、元の二件がどうなったかと、読みやすい変更履歴を残します。監査ログの設計ガイドでは、実行者、操作、対象レコード、結果を、詳細の読み込みエラーと混同せず示す方法を扱っています。

小さな画面とキーボードでも比較できるようにする

スマートフォンに三列を押し込むと、長い値を比べにくくなります。各項目を、項目名、SUP-104の値、SUP-218の値、選択結果の順で縦にまとめます。短いレコードIDを各選択肢で繰り返し、画面外へ流れたヘッダーを覚えておかなくても判断できるようにします。

一つの値を残す場合は、それに合う選択部品を使い、ラベルに項目と情報源を含めます。色の付いたセルを押せるだけでは不十分です。複数の値を合わせられる行なら、一つ選ぶ行とはルールが異なると明示します。

フォーカスを見える状態で保ち、プレビューの変更後も維持します。選択のたびに結果の列へフォーカスを飛ばさず、更新を通知します。送信時に未解決の競合が見つかったら、該当操作へ移動できるエラー一覧を提供します。支援技術での動作は実装で試します。デザインファイルに仕様を書くだけでは、その動作が成立したとは判断できません。

Pixsoで、統合前の判断を試せる形にする

Pixsoのデザインファイルに、二つの仕入先レコードと統合後のプレビューを置きます。支払条件の違いと共通の発注を含め、例と同じ値を使います。比較する一行を再利用できる部品にし、他の項目へインスタンスとして使うと、間隔と選択の見せ方をそろえられます。

最初の比較、請求先メールの選択変更、未解決の競合、処理中、結果不明、他の担当者による元データの変更、統合完了の七つのフレームを用意します。必要なクリック経路をプロトタイプでつなぎます。レビューで利用者の判断をたどれるようにし、データの照合と実際の統合処理はアプリケーション側で実装します。

同僚には「SUP-218の確認済み請求先メールを残し、現在の担当者を保ち、発注が何件残るか確認してください」と具体的に依頼します。何を探し、最終ボタンを押す前に結果を説明できるかを観察します。説明できなければ、警告を増やす前に、比較方法や結果の言い方を直します。

開発へ渡すときは、値の優先ルールを該当行の近くに、処理中、失敗、同時変更の動作を該当フレームの横に置きます。実際に可能な復旧操作と、関連レコードの更新ルールも含めます。

Pixsoでレコードの比較画面を設計する