AppSheetで問い合わせ管理を作るとき、すべての情報を1枚の表へ詰め込むと、対応メモが増えたときに管理しにくくなります。また、担当者の役割まで相談データへ直接書くと、権限の変更も複雑になります。
今回の社内相談デモでは、GoogleスプレッドシートをRequests、Updates、Usersの3つに分けました。この記事では、3つに分けた理由と、一意のID、Refを使って関係を作る考え方を解説します。
この記事でわかること
- 相談、対応メモ、利用者を別の表にする理由
- 行番号や件名をキーにしない理由
- AppSheetのRefで相談と履歴を結ぶ方法
- Is a part ofを今回は使わなかった理由
3つの表は役割が異なる
最初に、保存する情報を業務上の役割で分けます。
| 表 | 1行が表すもの | 主な列 |
|---|---|---|
| Requests | 1件の相談 | RequestID、Title、RequesterEmail、DueDate、Status、Resolution |
| Updates | 1件の追加メモ | UpdateID、RequestID、AuthorEmail、PostedAt、Note |
| Users | 1人の利用者 | Email、DisplayName、Role、Active |
Requestsには、相談本体と現在の対応状況を保存します。Updatesには、相談受付後の追加連絡や対応メモを保存します。Usersは、利用者が管理担当者か一般利用者か、有効か無効かを判断するために使います。
対応メモをRequestsのMemo1、Memo2、Memo3のような列で持たせると、メモ数の上限が列数で決まります。誰がいつ書いたかも扱いにくくなります。Updatesを別表にすると、一つの相談に必要な数だけ行を追加できます。
変更しないIDをキーにする
RequestsのキーにはRequestID、UpdatesのキーにはUpdateIDを使いました。新規登録時のInitial valueには UNIQUEID() を設定しています。
件名をキーにすると、同じ件名を登録できません。件名を直したときに、対応メモとの関係が分かりにくくなる問題もあります。スプレッドシートの行番号も、並べ替えや行追加の影響を受けるため、業務上のIDには向きません。
利用者からはIDを隠し、画面上は件名をLabelとして表示します。利用者に見せる名前と、データを識別する値を分ける考え方です。
UpdatesからRequestsをRefで参照する
UpdatesのRequestIDは、型をRef、参照先をRequestsに設定しました。Ref列には参照先行のキー値が保存されます。
Google公式ヘルプでは、Refを使うとテーブル間の関係を表し、関連行の情報取得や画面間の移動ができると説明されています。Refを設定すると、参照される側には逆参照の仮想列も作成されます。
今回のRequestsには、次の逆参照が生成されました。
REF_ROWS("Updates", "RequestID")表示名を「対応履歴（依頼者にも公開）」へ変更し、相談詳細から関連するメモを一覧表示しました。
Is a part ofをオフにした理由
RefにはIs a part ofという設定があります。有効にすると、子行を親フォームの一部として扱い、親行の削除に子行の削除を連動させる構成が可能です。
今回のUpdatesではオフにしました。相談登録フォーム内でメモまで同時作成する必要がなく、親相談の削除に伴う履歴の連動削除も初版の要件に含めなかったためです。相談とメモは関係していますが、メモは登録後に詳細画面から追加します。
Is a part ofは便利な設定ですが、常にオンにするものではありません。親子を一体として入力・削除したいかを決めてから選びます。
Usersを別表にする理由
UsersにはEmail、DisplayName、Role、Activeを保存しました。Roleには管理者か一般利用者か、Activeには現在利用を許可するかを記録します。
相談行ごとに役割を書くと、同じ人の役割を複数行で直す必要があります。Usersを分けると、利用者単位で役割と有効状態を管理できます。
ただし、Usersを別表にしただけでは安全になりません。一般利用者がUsersを編集できれば、自分のRoleを変更できてしまいます。今回のアプリではUsersをREAD_ONLYにし、アプリから役割を変更できないようにしています。
日本語の画面名と英数字の内部名を分ける
シートの列名にはRequestID、DueDate、Resolutionのような英数字を使い、AppSheetのDisplay nameには「相談ID」「対応期限」「対応結果」のような日本語を設定しました。
内部の式では英数字の列名を使い、画面では利用者に分かりやすい言葉を表示できます。列名を後から大きく変えると式や参照先の確認が必要になるため、最初に内部名を決めておくと管理しやすくなります。
試作で確認したこと
初期データ12件と、アプリから追加した2件の相談で、相談詳細に対応メモが表示されることを確認しました。アプリから追加したメモには親のRequestIDが保存され、投稿者と投稿日時も自動設定されました。
今回の確認は架空データによるものです。大量データでの性能や、親相談を削除した場合の運用は検証していません。
まとめ
問い合わせ管理では、相談本体、繰り返し追加される履歴、利用者の役割を分けると、それぞれの責任が明確になります。
一意のIDをキーにし、UpdatesからRequestsへRefを設定すると、相談詳細から関連メモを確認できます。表を増やすこと自体を目的にせず、「1行が何を表すか」を一つに絞るのが設計の出発点です。
