店舗の編集履歴に「料金修正」と書かれていたとしよう。料金が変わったことは分かるが、どのゲームがいくらからいくらになったかは調べなければならない。共同編集が増えるにつれ、この確認を作成者の短い説明だけに任せるのは難しくなった。3月には編集前後を比較し、実際の変更内容を履歴に含める方式へ変えた。

編集説明と実際の変更内容

編集説明は理由を伝えるのに役立つ。しかし「情報更新」のように短ければ料金と台数の両方が変わったか分からず、説明がなければ結果のデータから差を探す必要がある。作成者がどれだけ詳しく書くかによって、確認できる情報量が変わっていた。

以前のチケット表示は「設置ゲーム領域の編集」という区分と作成者の説明を並べていた。個別の変更はデータを見直す必要があった。英語の注記を添えた韓国語の原キャプチャ。

履歴を読むのは運営者だけではない。同じ店舗の最近の状態を調べる利用者も、変わった項目を知る必要がある。説明の言語や長さが違っても前後の値は同じなので、それを補う比較資料をサービス側で作ることにした。

フィールド比較と項目の追加および削除

比較の単位は、名前や住所のように意味が定まったフィールドと、設置ゲームのような複数の項目である。基本情報、営業時間、ゲームはすでに分かれ、店舗が現在の値を参照する構造になっていた。変更前後の状態を読めるため、その比較に利用できる。

flowchart TD
    accTitle: 編集説明だけで確認する際の不足
    accDescr: 短い編集説明だけでは、どの項目の変更前後の値が異なるかを別に探す必要がある。
    A[短い編集説明] --> B[変更領域は推測できる]
    B --> C[実データを再確認]
    C --> D[変更項目と値を探す]

例えばゲームの台数を2台から3台に直せば、そのゲームと前後の台数が残る。フィールドでは変わった値を、複数項目の領域では追加、変更、削除を分けて記録する。説明に台数変更が抜けていても、データ上の差は確認できる。

flowchart LR
    accTitle: 変更前後の状態から差分を作る
    accDescr: 変更前後のデータを比較し、フィールド変更と項目の追加・変更・削除を構造化した履歴にする。
    P[変更前のデータ] --> C[フィールドと項目を比較]
    N[変更後のデータ] --> C
    C --> F[フィールドの変更前後の値]
    C --> I[項目の追加・変更・削除]
    F --> H[一件の変更履歴]
    I --> H

変更履歴の多言語表示

サーバーは編集を反映する際、対象領域の以前と次の状態を結び付ける。名前や住所はフィールド単位、ゲームのまとまりは項目単位で比較する。変わらない値まで新しい変更として並べず、差がある部分を履歴にする方式だ。

変更前後のデータの差を、追加・変更・削除にまとめた履歴画面。 英語の原キャプチャ。

画面は領域と項目を分けて前後の値を表示する。比較結果をデータとして保存し、説明文を画面言語に合わせれば、韓国語、英語、日本語で同じ編集を読める。自由記述を翻訳したり、その文から変更事実を抽出したりする必要はない。

flowchart TD
    accTitle: 同じ変更を複数の言語で表現
    accDescr: サーバーが作った同じ変更データを画面の言語ごとに説明するが、変更前後の値は変わらない。
    D[構造化した変更データ] --> K[韓国語の説明]
    D --> E[英語の説明]
    D --> J[日本語の説明]
    K --> V[変更前後の値を確認]
    E --> V
    J --> V

変更確認と以前の状態への復元

短い説明でも、実際の差と並べて確認できるようになった。複数ゲームを一度に直した場合も、追加、変更、削除を分けて見られる。誤りが見つかれば、以前の状態を読んでどこを戻すか判断できる。

ただし、比較だけで料金や住所の正しさは証明できない。現地資料との照合は必要で、自由な文章の意味をすべて要約することもできない。データ構造が変われば比較と表示も直す必要がある。差を探す手間を減らすことで、値の妥当性を確認する作業に集中しやすくなる。

関連記録：Musecatの開発過程