保存したテーブルビューのUI設計：共有・権限・古い条件への対応

保存したテーブルビューは、開く前から三つのことが分かるように設計します。どの条件で行を絞るのか、その条件を誰が変更できるのか、表示されるデータへの権限は誰にあるのか。ビューはデータの複製ではなく、絞り込み・並べ替え・表示列を記憶した設定です。その設定が変更されたり壊れたりしたとき、黙って別の一覧を見せてはいけません。

ここでは、購買チームが注文一覧から「要確認」の作業用ビューを作り、翌日また開き、同僚へ共有するまでを追います。単なるテーブルの見た目ではなく、保存した条件と一時的な変更の境界を決めるためのガイドです。表そのものの列構成や状態を作るなら、先にPixso のデータテーブル設計ガイドで基本構造を確認できます。

名前を付ける前に、何が保存されるか決める

注文一覧には、状態、担当者、依頼日、金額、顧客の列があります。購買担当の麻衣は「要確認」「担当者は自分」「過去７日間」で絞り込み、新しい依頼を先に並べ、使わない列を隠しました。「ビューを保存」を加える前に、この三つ――絞り込み、並べ替え、列の表示――をすべて記憶するのか決めます。絞り込みだけを保存するなら操作時に伝えなければ、麻衣は翌日も同じ並びと列構成で開くと思うでしょう。

注文自体は一つのデータ集合に残ります。保存するのは今日表示された行のコピーではなく、行を表示するための条件です。翌日、新たに条件に合う注文が追加されれば、同じビューに現れます。「自分の確認待ち」のように仕事を表す名前を使い、固定の件数を約束する名前は避けます。現在のビュー名の近くに「要確認・自分の担当・過去７日」と短く示せば、すべてのフィルターを開かなくても何を見ているか分かります。

「自分の担当」は共有すると特に注意が必要です。「自分」とは作成者の麻衣でしょうか。それとも今ビューを開いている人でしょうか。チームの各人に自分の確認待ちを見せたいなら、閲覧者ごとに条件を評価し、その意味を明示します。麻衣の担当分を同僚へ引き継ぐなら、共有前に動的な「自分」を「麻衣」に置き換えます。同じリンクの意味が閲覧者によって黙って変わると、件数の違いを調べにくくなります。

一時変更と保存済みの設定を分ける

麻衣が「過去７日」を「過去30日」に変えると、表示行はすぐ更新されるかもしれません。しかし、保存済みビューの定義まで変わったとは限りません。画面では「保存済みの設定を表示中」と「未保存の変更を試している」を区別します。後者には「未保存の変更」と示し、既存ビューを更新する、新しいビューとして保存する、変更を破棄する、という選択肢を用意します。フィルターを一つ操作しただけで、個人の試行がチーム全員の設定変更になってはいけません。

操作名は結果に合わせます。「共有ビューを更新」は同僚が次に開く内容を変え、「個人ビューとして保存」は共有版を残します。共有ビューの編集権限がない人でも、一時的に絞り込みを試せる設計は考えられます。製品の権限規則が許すなら、自分用のコピーを保存する道も示します。編集権限がないからと操作をすべて隠すと、別の切り口で仕事をしたい人にはビューが使えないように見えます。

権限の細部は製品ごとに異なります。Microsoft の個人ビューに関する説明では列、並び順、絞り込みを含むモデルを扱い、共有や編集は権限に従います。Airtable のビューの説明では共同編集、個人用、ロックされた設定を区別します。設計上の問いを整理する参考にはなりますが、別製品の権限規則を自分たちのデータモデルへそのまま移してはいけません。

ビューの共有とデータへのアクセスを混同しない

ビューの選択メニューには、製品の実際の規則に沿って「個人用」「チーム用」、または所有者名を表示します。チーム用なら設定を編集できる人も分かるようにします。麻衣が「確認待ちの注文」を同僚の蓮へ共有するときは、確定前に相手と付与する権限を見せます。URL をコピーできたことは、蓮がそのビューを開ける証拠にはなりません。

重要なのは、ビューの定義を共有しても、元の注文データへのアクセス権を自動的に付けないことです。蓮はビュー名を見られても、条件に合う注文の一部しか閲覧できないかもしれません。結果が０件のときも、「該当する注文がない」と「該当する注文への権限がない」を分けて伝えます。アクセス権のない顧客名や件数を、共有前のプレビューで漏らしてはいけません。

既定のビューも範囲を明示します。個人の既定値は麻衣だけの開始位置を変え、チームの既定値は全員に影響します。操作を別の場所に置くか、名前で適用範囲を示します。共有ビューをロックできる場合は、同僚がその場限りの絞り込みを試せるのかも説明します。共有設定を固定することと、注文の行を固定することは別です。

削除された項目や古いリンクから復帰できるようにする

ビューは項目の変更後も残ります。管理者が「要確認」を「承認待ち」へ置き換えたり、依頼日の項目を削除したりすると、保存済みの条件が無効になることがあります。その条件を黙って捨てると、麻衣の想定よりはるかに多くの注文が表示されかねません。逆に黙って０件を返すと、仕事のキューが空になったように見えます。ビュー名は残したまま「状態『要確認』は存在しません」と問題の条件を示し、代替条件を適用前に確認できる修正経路を用意します。

表示名を変えただけの場合と、元の選択肢そのものを削除した場合も分けます。安定した項目 ID が残っていれば、ラベルだけ更新して条件の意味を保てることがあります。項目や選択肢が本当に削除されたなら、利用者が新しい条件を選ぶ必要があります。壊れた条件を含むビューを部分的に開くのか、安全側で止めるのか、所有者の修正を求めるのかは、権限と業務への影響を見て決めます。

共有リンクが古い場合にも専用の状態が必要です。チームビューが削除されたなら、説明なく無関係な既定ビューへ飛ばさず、利用できない理由と、許可された注文一覧への道を示します。役割の変更で麻衣のアクセス権がなくなったなら、壊れたフィルターではなく権限の問題として伝えます。

状態の変化を短い仕様として確認する

きれいな選択メニュー一つでは足りません。利用者が一覧に抱く予想を変える場面を、同じ注文例で並べてみます。

チームビューの保存も、レコード編集と同じように競合します。麻衣が試している間に蓮が共有条件を変更したら、二つの定義を見せ、権限のある人に共有版を更新するか個人版として残すか選んでもらいます。蓮の変更を上書きした後で「保存しました」とだけ知らせても、チームが必要とする判断は隠れたままです。

Pixso でビューを選ぶ場面を試作する

Pixso の一つの注文表を使い、三つの画面を作ります。麻衣の保存済み「自分の確認待ち」、未保存の過去30日版、無効になった状態条件を含むチームビューです。注文、ラベル、件数を画面間でそろえると、レビューする人は無関係な画面を比べずに変化を追えます。ビュー選択を適用範囲のラベルと条件の短い説明を持つコンポーネントにし、「更新」「別名保存」「破棄」「条件を確認」から各結果へプロトタイプをつなぎます。

説明を加えずにレビュー参加者へ聞きます。30日版はすでにチームへ保存されていますか。蓮がリンクを開いたとき「自分の担当」は誰の注文ですか。「要確認」が削除されたら次に何をしますか。答えられなければ、色を磨く前に名称と状態表示を直します。Pixso のプロトタイプは、この判断の流れを確認する場所であり、注文を保存したり、その閲覧権限を実際に制御したりするものではありません。

開発者へは、ビューのどの設定を保存するか、変更の版をどう扱うか、ビューの定義と注文データにそれぞれどんな権限を適用するか、動的な「自分」をどう評価するか、壊れた条件をどう処理するかを短く渡します。Pixso でビューの動きを設計する。

次に開いたときも、結果を予測できるようにする

役立つ保存ビューは、仕事へ戻るための確かな入口です。麻衣は何が保存され、何が一時的に変わり、誰が共有条件を直せるのか、昨日と件数が違う理由は何かを理解できる必要があります。最初の「保存」だけでなく次に開く場面まで設計してこそ、ビューは意外な一覧の上に付いた名前ではなく、チームが信頼して使える道具になります。