組織でAppSheetにおける初回プロジェクト構築手順
組織でAppSheetでアプリを作ると問題が起きるのが「アプリの属人化」と「野良アプリ問題」。また、外部の共同開発者が存在する場合にはデータソースに対するアクセス権問題などが生じます。
その他追加するデータソースによってはまた別の問題が起きかねません。そこで組織に於いてAppSheetアプリを作成する際の初回プロジェクト作成手順の注意点についてまとめました。
目次
今回利用するツール等
今回のテーマに対する問題点は、AppSheetに限らず、Google Apps Scriptでも同様の問題が起きますし、Power Automate Desktopでも同じ問題が起きます。組織が管理していない状況下で作成が開始されて運用が成されるため、とりわけ「担当者が退職や内部異動した場合」が主に問題が発覚するシーンです。
よってスタート段階からこの問題に対して対処しておくことで、何かあっても右往左往せずに済みます。
個人のアカウントではないアカウントで作成する
今回のテーマでは一番重要なのがこの問題。そして多くの組織ではすでに「個人アカウントで開発を始めてしまってる」という問題点です。この問題は後になって発覚する問題であるため、当初はうまく回ってる為気が付きにくい問題でもあります。
個人アカウントで作った場合の弊害
個人のアカウントでプロジェクトを作成した場合、前述の内容のようなシーンに遭遇した場合以下のような問題が発生します。
- データソースのオーナーを別の担当者に移転する作業が必要になる
- Google Apps Scriptを利用してる場合はさらに別の担当者による「初回実行認証」が必要になります。
- また共同開発者がいた場合には対象のデータソース（スプレッドシートや共有ドライブ等）に対するアクセス権の付け替えが必要になります
- カレンダー書き込みなどをしている場合は、書き込み先のカレンダーについて変更が必要になります。
- この作業を作成したアプリ毎に行う必要があります。
- 場合によってはアプリ毎に再デプロイする必要があります。
AppSheet Enterpriseを利用することで組織での管理がしやすくはなるものの、この問題については避けることが出来ません。よって退職者が発生する度に割と面倒な作業手間が現場に発生することになり、管理がおざなりになるキッカケになりかねません。
問題に対する対処法
この大きな問題は「個人アカウントで開発をしてる」ことが全ての発端である為、以下のような環境整備をして体制を整えるのがベストプラクティスということになります。
専用アカウントを用意する
これはGASでも同様のことが言えるのですが、アプリケーションのオーナーや実行権限主に関しては「専用のアカウントを用意してそこで構築する」必要があります。その為、1つ余計にGoogle Workspaceなどのライセンスを消費する事になりますが、これは必須の要素です。
人に紐づいたアカウントではない為、退職や内部異動などの影響を受けることが無い上に通常はこのアカウントを削除したり大きな変更をすることはありませんので安定して運用することが可能です。
ライセンス消費を嫌って、Cloud Identity Freeアカウントで作成すれば良いのでは？と考えがちですが、GASの場合にはこの手法は有効なのですが、AppSheetの場合にはCIFで運用した場合ライセンス形態が「AppSheet Core」ではなく「AppSheet Free」のライセンスとなってしまうので非常に制約と弊害が強いです。
よって、Cloud Identity Freeアカウントでの運用はオススメしません。
GASなどの初回認証
AppSheetのAutomationで利用する機会が多いスタンドアローンのGASコンテナ。AppSheetでは実現できない操作やハンドリングを実現することが可能ですが、これについても前述の専用アカウントのドライブに作成し専用アカウントで認証を実行（Authorize）しておくことが必要です。
AppSheetはオーナーの権限で動作する為、AppSheetについても認証はオーナーで認証してあげる必要があります。コードの編集は第三者でも出来るのですが、実行時にオーナーで認証していない場合、そこでGASの実行がストップしてしまう為、必ずこの作業を行っておきましょう。
基本初回認証をしておけば以降は何度も認証を実行しなければならないといったことは起きません。
図：GASの参照を再設定する
カレンダーソースについて
AppSheetではデータソースとしてカレンダーを利用することが出来ます。このカレンダーについても前述のように「個人のデフォルトカレンダー」を元に構築してしまうケースが多いです。しかし、退職しアカウントが削除されると当然カレンダーも削除されてしまう為、その時点でAppSheetアプリが動作しなくなってしまいます。
またこのカレンダーへのアクセス権限の付与についても個人の管理下となってしまうため、Google Workspaceの管理者が手出しすることが出来ない状態になります。
そこで前述の専用のアカウントにてデフォルトカレンダーではなく「新しいカレンダー」を作成し、そのカレンダーに対して読み書きをするようにデータソースを指定します。管理者の管理下にあるカレンダーである為、カレンダーに対する直接のアクセス権については管理者が管理することが出来ます。
ただし通常はAppSheet経由で読み書きするのでアプリ上では困りませんが、他のユーザに直接カレンダーを見られるようにしたい場合にはそのカレンダーに対するアクセス権限を管理者が行う必要があるため、組織での役割分担に関して情報システム部などに同意を得ておき、作業フローを確立しておくと良いでしょう。
図：専用の独立したカレンダーを用意しよう
日本語テンプレートを利用する
AppSheetは2025年1月時点でも開発画面やユーザの使うアプリのUI画面も標準で日本語化されていません。英語UIであるため、このままでは利用者に抵抗感が出てしまいます。
その為、毎回開発を始めるに当たってスプシをソースに構築・・・と初めてしまうとローカライズを毎回行わなければなりません。これはかなりの手間であり、結構な時間を毎度消費することになります。
そこで以下のエントリーにもあるように日本語化済みテンプレートを元に、専用アカウント上でCopy and Customizeをクリックすることで日本語化済みの空のプロジェクトがコピーされます。ここにデータソースとしてのスプシなどを後から追加することで開発をすることで日本語化の手間を一切省くことが可能です。
AppSheetのSettings→Localizationを開くとすでに様々なメニューの文言が日本語で入れてありますのでボタンやメッセージの殆どが日本語化の状態となっています。
図：Copy and Customizeをクリックする
図：日本語化済みです
共同開発者を共有に追加する
さてここまでで、空の日本語化済みテンプレートによるプロジェクトが専用のアカウント上にコピーされました。共同開発者や利用者などについてはこの段階で追加しておきます。
ここで共有を追加する場合、以下のような形で専用アカウントであるオーナーが追加してあげる必要があります。
- 組織内全員が使うアプリの場合は、Email Address or Domainの部分には自社のドメインを入れます（権限はUse app固定です）
- 編集者などは別にメールアドレスで入れてあげます（AppSheet Enterpriseの場合はグループアドレスが使えます）。権限についてはEdit Difinitionを選択します。
- Advancedでは特にユーザが使うバージョンをStableに限定したり、アプリに対するロールを指定できます（Userなのか？Adminなのか？）。開発者はAdminで良いでしょう。
- 外部の共同開発者についても同様です。ただし、外部ユーザの場合は担当者が変わったりした場合は速やかに共有から外したり変更する必要があります。
以下のエントリーにある社内運用するイロハにもあるようにAppSheet Enterpriseを使っての組織管理もタイミングを見て導入し、ポリシー管理などを合わせて行うとベストでしょう。無秩序な開発やエンドユーザコンピューティングの弊害を避けることが可能です。
図：開発者はEdit Ditinitionで指定
図：組織内全員で共有する
図：Browser Linkは後で使います
図：Advancedで細かく設定可能
データソースを追加する
社内ユーザオンリーや社外ユーザも含めての開発の場合、ちょっと厄介な問題が「データソース」問題。AppSheetアプリ本体だけじゃなくデータソースに対するアクセス権限の管理が別途生じてしまい、場合によってはテナントの外部共有制限に引っ掛かって、アプリは見られるけれどデータソースが開けないといったことが発生します。
またこちらも個人ユーザがオーナーのファイルとしてしまうと退職時等で同様の問題が発生してしまうので、専用のアカウントで用意してあげる必要性があります。
AppSheet DBの場合
AppSheet DBはライセンス形態によって色々制限はあるものの、AppSheetアプリに直結して付属してるデータソースであるため、このようなアクセス権限の問題が生じることがありません。ただし、アプリの所有者が個人で組織の所有にしたい場合、AppSheetのアプリのオーナー権だけじゃなく、AppSheet DB側のオーナー権も別途移動が必要になってしまいます。
故にはじめからアプリを専用アカウントで作成しておく事でこれらの殆どの問題が回避可能です。
データソースがアプリ直結であるため、外部ユーザが開発をする場合でもスプレッドシートの場合と違い、アクセス権や外部共有の制限で振り回されることがありません。
前述の日本語化テンプレートを使った場合、専用アカウントにてデータソースを手動で追加する必要があります（別の人がデータソースを追加してはいけません）。
図：AppSheet DBが最も簡単で管理しやすい
スプレッドシートの場合
概要
実はちょっとやっかいなのが、スプシをデータソースとして追加したい場合です。この場合、Google Workspaceの組織のドライブにおける外部共有の設定の影響を受ける為、一部のユーザや外部ユーザがアプリにアクセス出来てもデータソースが開けないといったことが発生します。
また前述にあるようにAppSheetでPDF生成の際にスプシの場所とPDF生成場所は同じ場所にしておかないとエラーとなる為、この部分についても配慮が必要になってきます。
また、AppSheet DBと異なり普通のスプシであるため、データ構造の設計は自由度が高い反面やりづらいというデメリットがあります。この当たりは総務省が出してるExcelデータの統一ルールをよく読み込んでおくと良いでしょう。
通常のケース
テンプレートからコピーではなく、スプレッドシート上からAppSheetのアプリを作成することが可能です。この場合でも後述のテンプレートからコピーしたケース同様の場所に自動的にフォルダが作成されて、アプリで使ってる画像などの類もそのディレクトリ内に生成されることになります。
ただし利用したスプシがそのディレクトリに勝手に移動することはなく依然としてオーナーのマイドライブ上のもともとあった場所に存在し続ける為、そのスプシが存在するフォルダやスプシ自身だけじゃなく、自動的に生成されたディレクトリに対しても共有権限を追加しないと、別のユーザや外部ユーザは画像類やスプシにアクセス出来ません。
2箇所にファイル類が分散してる状態であるため、ちょっと管理が厄介なだけじゃなくこの状態の場合PDFの生成を装備した際にエラーになります。故にあまり個人的には推奨しにくいのがスプシから直接アプリを作るケースとなります。
テンプレートからコピーしたケース
AppSheetのサイトなどで公開されてるテンプレートにGoogle Spreadsheetをデータソースとして作成されたものはCopy and Customizeをクリックするとアプリだけじゃなく使っていたスプシも同時にコピーされます（PDF生成用の雛形などもコピーされますが、GASのコンテナはコピーされません）。
この場合、スプシデータは自動的に以下のディレクトリに複製されることになります。
|
1 |
/マイドライブ/appsheet/data/アプリの名前 |
アプリのオーナーのマイドライブ以下のディレクトリにファイルが生成されてしまうので、このデータソースに対して他の開発者のアクセス権限を別途付与してあげる必要があります。また外部の共同開発者であっても同様で、この場合Google Workspaceのマイドライブ以下における外部共有の設定がオンでなければ、外部ユーザに対して共有が出来ません。
このスプシだけを外部共有してる共有ドライブに手動で移動しても良いのですが、この場合後述の「PDF生成に対する配慮」で問題が発生する事になります。故に安易に手動で移動してはいけません。
※管理コンソールで対象の組織部門に対して外部共有を禁止にすることでマイドライブの外部共有を禁止に出来ます。共有ドライブだけは単独で外部共有可の組織部門を作成してそこに所属させることで外部ユーザがアクセス可能といった環境を構築出来ます。
図：特定の場所に自動生成される
図：原則外部共有禁止のケース
共有ドライブを使うケース
マイドライブ以下は規制されてるので外部開発者がこのままではアクセスできず開発に支障が出る！！ということで、外部共有が可能になってる「共有ドライブ」上にスプシを作成し、そこからアプリを作ればスプシに対するアクセス権限の問題は回避することは可能です。
この場合対象の共有ドライブに対して外部共有が許可されてる状態であり、外部ユーザもGoogleアカウントがないユーザであればビジター共有として参加しアクセスすることが可能です。よって外部メンバーを参加しての開発の場合には共有ドライブを作成してそこに対してアクセス権限を付与することで、スプシに対してのアクセスも制御される為、管理がしやすくなります（グループアドレスでまとめてアクセス権限も追加できる為、利便性が向上します）。
ただし、この場合であってもPDF生成機能を使った場合のエラーは回避することが出来ません。
データ保存場所を変更する
この時点までで、スプシに対するアクセス権限に関しては「共有ドライブ」を扱うことでだいぶ管理しやすくなりました。しかし依然として残ってる問題点が、アプリで使ってる画像の保存場所やPDF生成時にエラーになるといった問題点は解消されていません。
特にPDF生成機能はスプシがAppSheetで指定されてるデータ保存場所に存在しないとエラーとなるという仕様があるため、PDF生成を使うケースでは非常に困った事になります。このケースに対応するにはAppSheetの設定の「Default app folder」を変更することで対応することが可能です。これに関するドキュメントはこちらになります。
この手法はマイドライブであっても共有ドライブであっても共通の設定方法になります。今回は共有ドライブとして10_営業というドライブを用意し、その直下にスプシを用意してアプリを作成済みとして想定しています。
- AppSheetのアプリの開発画面を開く
- 左サイドバーからSettings→Informationを開く
- App Propertiesの中にあるDefault app folderの欄を見つける（既定で/appsheet/data/アプリ名として値が入ってるハズです）
- ここはそのフォルダまでのパスを入れる必要があるので、今回のケースでは「/[TeamDrive]10_営業」と入れるだけでオッケーです。（共有ドライブ名が先頭に来るのでサブディレクトリ以下ならばそのようにパスを変更します）
- 右上のSAVEボタンをクリックする
これで対象のスプシを使ったデータ類に関しては共有ドライブ上で全て保存される為、外部ユーザ等のアクセス権問題が全てクリアすることが可能になりました。10_営業だけだとマイドライブ直下にフォルダが作成されてしまうので、[TeamDrive]をつけたものを指定すると、共有ドライブにFilesフォルダが自動生成されて、PDFはそこに生成されるようになります。
※実は共有ドライブの場合は、画像に関しては/appsheet/data/アプリ名の場所ではなく、共有ドライブのスプシのある場所に自動的に画像格納用フォルダが生成されて、そこに画像が可能されるようになっています。故に上記の手順はPDFファイル生成時に関して限定となります。
※AutomationのFile folder pathを共有ドライブ上のフォルダに指定しておくという手法でも回避出来ます。
※それまでの/appsheet/data/アプリ名以下に生成されていたデータは移動はしないので手動で移動や登録し直しが必要です。
図：共有ドライブをデータ保存場所として指定する
図：ファイル保管場所が共有ドライブに生成された
