完成したアプリをチームで使える形にする
USEREMAIL() / 権限設計 / Security Filter / Share / Deploy
アプリは作って終わりではありません。 誰が使うのか、誰に何を見せるのか、どう公開するのかを整えてはじめて 業務で使えるアプリ になります。 最後に、公開前に押さえておきたい実務ポイントをまとめます。
ステップ7：ユーザー設計と公開までを仕上げる
このページでは、ログインユーザーを判定する USEREMAIL()、 管理者と一般ユーザーの見せ分け、 共有設定の Share、 本番公開の Deploy を順番に確認します。
- USEREMAIL() の意味を理解する
- 管理者 / 一般ユーザーの設計方針を決める
- Share でメンバーを招待できる
- Deploy 前の確認項目を把握する
ステップ7-1：USEREMAIL() で「誰が使っているか」を判定する
USEREMAIL() は、 今ログインしてアプリを使っている人のメールアドレスを返す関数です。 これを使うと、 「誰に何を見せるか」 を判定できるようになります。
よくある使い方
ステップ7-2：管理者と一般ユーザーの見せ分けを考える
実務では「全員にすべてを見せる」よりも、 役割に応じて必要なものだけを見せる 方が、使いやすく安全です。
管理者に見せたいもの
- ・備品一覧の全件
- ・貸出履歴の全件
- ・新規登録や削除の操作
- ・設定系のビューや管理アクション
管理者は全体を管理する立場なので、情報を広く持たせます。 ただし、誰でも管理者にしないことが大切です。
一般ユーザーに見せたいもの
- ・備品一覧
- ・自分の貸出履歴
- ・必要な申請フォーム
- ・使わない管理メニューは非表示
一般ユーザーには、使う画面だけを見せた方が迷いにくくなります。 不要な操作が見えないだけで、運用ミスも減らせます。
表示条件のイメージ
まずはこのようなシンプルな条件から始めると理解しやすいです。
覚えておきたいこと
- ・「見せない」だけでなく「編集させない」も意識する
- ・管理者判定は最初は固定メールでもよいが、あとで管理テーブル化すると運用しやすい
- ・画面が少ないほど一般ユーザーは迷いにくい
ステップ7-3：Security Filterで「見えないようにする」
これまで紹介した「表示制御（Show_Ifなど）」は、 実はデータ自体は端末に届いている状態です。
非表示にしているだけでは、裏ではデータが存在しています。
→ セキュリティとしては不十分です
そこで使うのが Security Filterです。
サーバー側でフィルタをかけ、
そもそもデータを端末に送らない仕組みです。
データの流れの違い
実践例：自分のデータだけ取得する
この設定を行うと、
ログインユーザーのデータだけが端末に送られるようになります。
Security Filter を使うと取得データが減るため、
大規模データではパフォーマンス改善にもつながる一方、
条件を間違えるとデータが見えなくなるので注意してください。
Security Filter はどこで設定する？
Security Filter は、 テーブル単位で設定 します。
Security Filter は「列」ではなく
テーブル単位で設定します。
→ データ取得そのものを制御しているためです。
ステップ7-4：Deploy で本番運用へ進める
アプリが一通りできたら、 最後に Deploy を確認します。 Deploy は、 「試作」から「運用」に進むための最終チェック のようなものです。
いきなり全社展開するよりも、 まずは数人で試し、 使いにくい点を直してから広げる方が定着しやすいです。
Deploy チェックのイメージ
最後に：今回のアプリから広がる改善アイデア
今回作った備品管理アプリで使った考え方は、他の業務にもそのまま応用できます。
AppSheet は表データをもとにアプリを組み立てる。土台の設計が重要。
Type、Scannable、Initial Value、Actions で現場の操作を減らせる。
Views と Column order の調整で、ぐっと使いやすい画面になる。
ユーザー、権限、共有、公開前チェックを整えてからチーム展開する。