続・AppSheetを使い倒してみた～ App Makerで開発したアプリをAppSheetに移行する

© Copyright 2020, ESM, Inc.
続・AppSheetを使い倒してみた
～ App Makerで開発したアプリをAppSheetに移行する
2020/2/17
Agile Studio Fukui
岡島幸男
1

なぜAppSheet？
● AppMakerの終了（2021年1月）に伴い、Googleは「AppSheet等に移行してね」と
言っている。
● AppMakerは実務投入済みで、今後も使える場面では使ったろ！モードだったのに
…。
● すでに運用中のAppMakerアプリ、どうやって移行すると良いの？App Makerのた
めに契約したGoogle Cloud SQLはそのまま使えるの？
2

検証方法（やったこと）
「過去に実際にAppMakerで開発したアプリをAppSheetに移行（作り直し）する。
Cloud SQLの構造やデータはそのまま利用すること」
評価観点（定性評価）
● 機能性～ App MakerではできてAppSheetではできないことは何か
● 開発の容易性～非エンジニアでも容易に移行できるのか
● ワクワク感～ App Maker開発では味わえない楽しさはあるか
3

対象アプリ
● 利用者
○ 卸売り
● 利用シナリオ
○ スマートフォンのカメラでバーコードを読み取り、データベースとマッチング。対象があれば、その商
品の詳細を表示する。商品や商品分類などのデータは、別途専用の画面でメンテナンスできる（た
だし、管理者のみデータの登録・変更・削除が可能）。
● 開発期間
○ 仕様確定後はテスト含め 3日程度
● 利用技術
○ App Maker
○ Google Cloud SQL
4

前提知識（このスライドで説明しないこと）
● AppSheet での開発方法・ツールの使い方
○ 公式ドキュメントを読んでみてください
○ AppSheetを使い倒してみた～ GASで1週間かかったアプリはどの程度で開発できるのかを読んでみてください
● App Maker での開発方法
● データベース（Google Cloud SQL）の使い方
5

検証開始
6

大まかな手順
1. AppSheet から接続できるようにCloud SQLを設定する
2. AppSheet にデータソースを作成する
3. AppSheet のテーブルとしてCloud SQLのテーブルを追加する
4. データ型を適切に設定（変更）する
5. テーブル間のリレーションを適切に設定する
6. データメンテナンス画面のUXを調整する
7. アクセス権限を設定する
8. バーコード読み取り画面を実装する
9. 実際にスマートフォンでテストする
7

AppSheet から接続できるようにCloud SQLを設定する
8
https://help.appsheet.com/en/articles/1658319-managing-ip-addresses-and-firewall-information
GCPのCloud SQLコンソールの
「接続」より
※ GASからCloud SQLに接続し
ている人にはおなじみの設定
※公式ドキュメント
公式ドキュメントにあるIPアドレス
を全て登録

AppSheet にデータソースを作成する
9
https://help.appsheet.com/en/articles/3627169-create-a-mysql-database-hosted-in-google-cloud
● Data ＞ Tables ＞ Add New Table ＞ New
Data Source を選択し
● ダイアログから「Cloud Database」を選択
● TypeからMySQLを選択肢、ServerのIPアドレス、
データベース（スキーマ）名、ユーザー、パスワード
を入力
● 「Test Connection」で接続確認後「Authorize
Access｣でデータソースとして登録できる
「インスタンス接続名」ではなくデー
タベース名なことに注意

【補足】データソースは「My account」から管理する
10

AppSheet のテーブルとしてCloud SQLのテーブルを追加する
11
スプレッドシートの場合と同じよう
にテーブル毎に追加する
↓ のように直感的に選択できる
スプレッドシートの場合と同じよう
に即座にViewが作成される

ここまでで実現できたこと
12

データ型を適切に設定（変更）する＃１
13
AppMakerモデルでの型 AppSheetテーブルでの型設定変更の検討
Number
(SQLTYPE＝INT)
Number App Makerモデルのキー項目（オートインクリメンタルなId）の対応
※次ページ参照
Number
(SQLTYPE＝DOUBLE)
Decimal Numberで十分な場合（整数）はNumberに変更する
String LongText Textで十分な場合が多いのでその場合はTextに変更する
Boolean Yes/No
Date DateTime レコードの更新日時を格納したい場合は、専用の
「ChangeTimestamp型」に変更する
App Makerモデルから生成された Cloud SQLのテーブルをAppSheetテーブルとして追加すると、一定のルール
で型が設定される。
AppSheetの型設定を変更してもデータソースである Cloud SQLテーブルが変更されるわけではない

データ型を適切に設定（変更）する＃２
14
https://help.appsheet.com/en/articles/962066-using-data-from-mysql
● AppSheet テーブルのIdのINITIAL VALUE に RANDBETWEEN(10000, 99999) を設定
○ ※ 第1引数の10000は、既存のレコードが十分収まるだけの数を設定する
● Cloud SQLテーブルのAuto Incrementシードを変更
○ これによりAppSheet以外のアプリ（App Makerアプリ）と、AppSheetアプリでは重複しない
範囲でのId値付与が行われることになる
○ 例：ALTER TABLE ProductCategory AUTO_INCREMENT = 100000 ;
Cloud SQLのテーブル定義が変更できない場合の対処
※ 当面 App Makerアプリとの並行稼働が求められる場合など
テーブルを新規で設計できるなら、 Text型のカラムにUNIQUEID関数で値を設定するほうが良い
RANDBETWEENがもし、すでに
存在するのと同じ値を返しても、
AppSheetがチェックしてエラーを
返す

テーブル間のリレーションを適切に設定する
15
https://help.appsheet.com/en/articles/961426-references-between-tables
● 当然ながら、App Makerモデルで作成したリレー
ションは、AppSheetテーブルに引き継がれること
はない
● 以下手順でリレーションを作成すると簡単
○ App Maker でリレーションを作成すると自
動的に付与されるカラム「テーブル名_fk」
（例：Productテーブルの
ProductCategory_fkカラム）の型を
NumberからRefに変更する
○ Source table に参照元テーブルを設定（例
：ProductCategory）
これにより、自動的に
PoductCategoryテーブルに、
「Related Products」バーチャルカ
ラム（List型）が追加される

データメンテナンス画面のUXを調整する＃１
16
● 「LABEL？」がONに設定されているカラムが、選択ダイアログなどに表示されることになる
● 各テーブルの代表的な項目をLABELに適切に設定しておくと良い（例：Productの場合はそ
の製品名）
LABELをIdではなく、Categoryに
変更する（Image型以外のLABEL
は一つしか設定できないので注
意）

データメンテナンス画面のUXを調整する＃２
17
● カラムの「DISPLAY NAME」で画面に表示される値を設定
する
● ちなみにApp Makerもモデルの「Display Name」で同
様のことが設定できる
● カラムの「SHOW?」のON/OFFで画面には表示したくない
項目を隠す
● ランダムに設定されるIdの値に意味はないため、ここ
ではSHOW？をOFFに設定し、非表示にした

データメンテナンス画面のUXを調整する＃３
18
● UX>View＞VIEW OPTIONSでお好みのUXに設定する
「deck」スタイルを選び、Primary
header には Name（製品名）を選
択し、Secondary にはメーカー名
を選択した

アクセス権限を設定する＃１
19
①Users＞Usersタブより、アプリ
を利用させたいユーザーのメール
アドレスを入力する
②私はロボットではありませんを
チェック
（これにより、次ページのステップ
が実行できるようになる）
「メンテナンス画面は管理者だけが追加・変更・削除出来る」
仕様を、AppSheetの権限機構を利用し実現する

アクセス権限を設定する＃２
20
③ここをクリックすることで招待メー
ルを送信する

アクセス権限を設定する＃３
21
④権限を設定する
招待したユーザーは「User」権限とした
参考
https://intercom.help/appsheet/en/articles/2357
273-userrole
※ 権限には「Admin」と「User」の2種類しかな
いので注意
App version：を「Latest」にするとテスト時は便
利

アクセス権限を設定する＃４
22
テーブルごとに権限を設定。
「Adminは読み書きすべて許可
で、それ以外（＝User）は、
READONLY」とした。
USERROLE（）関数はログイン
ユーザーの権限（Admin or User）
を返す ※
https://intercom.help/appsheet/en/articles/2357273-userrole

ここまでで実現できたこと
23

バーコード読み取り画面を実装する＃１
24
https://www.appsheet.com/samples/Scan-a-barcode-to-find-out-all-the-details-of-an-item?appGuidString=87c05a28-539d-40b8-a
b52-2259ec5bb925
スマホなどで動作させるとここを
タップするとカメラが起動する。ス
キャンはリアルタイムで、高速か
つ高精度！
一次元バーコードだけでなくQR
コードもOK
※公式サンプルを参照
● 入力項目のバーコードに実際のスキャン結果を取り込む場合
● Text 型のカラムの「SCAN?」をONに設定するだけ
○ 今回はProductテーブルのBarcodeカラムのSCAN？をONに

バーコード読み取り画面を実装する＃２
25
https://www.appsheet.com/samples/Scan-a-barcode-to-find-out-all-the-details-of-an-item?appGuidString=87c05a28-539d-40b8-a
b52-2259ec5bb925
● 「バーコードを読み取り、データベースと
マッチング。対象があれば、その商品の
詳細を表示する」仕様を実現するために
● スキャン専用のビューを作成し、スキャン
終了後、該当データの詳細画面に遷移さ
せる機能を実現
○ 下記公式サンプルを参考に、専用
のテーブル、ビュー、アクションを作
成（詳細は次ページ以降）

バーコード読み取り画面を実装する＃３
26
● もちろんCloud SQLにテーブルを作成しても良いが、今回は手軽にスプレッドシートにて実現
○ このテーブルはオリジナルのApp Maker版には必要のない便宜的なもの
①このような項目を持つスプレッド
シートを作成し
②scanテーブルとして追加
③barcodeカラムのSCAN?をON
に設定
テーブルの作成

バーコード読み取り画面を実装する＃４
27
View typeとして「form」を選択する
scanテーブルのためのViewとして
ビューの作成

バーコード読み取り画面を実装する＃５
28
https://intercom.help/appsheet/en/articles/1023058-app-column-type-deep-link
LINKTOFILTERDVIEW関数を利
用し「barcodeが一致する
Product_Detail画面へのリンク」を
実現できる
別画面に飛ばしたいので、
「App: got to another view within
this app」を選択
アクションの作成

実際にスマートフォンでテストする
29
● App Store等でAppSheetアプリをインストール
● アプリのMy Appsメニューに自分が開発したアプリが並ぶ
● 起動（ログイン）して動作確認

まとめ
30

「業務デジタル化」においてよく求められる機能と実現方法
31
機能 App Maker での実現方法 AppSheet での実現方法
ロールによるアクセス権限
制御
Role 機構による実現 USERROLE関数等を組み合わせ実現
バーコード読み取り HTML Widget と Quagga.js の組み合わせ
でクライアントサイドで実装
標準機能（Textデータ型を「SCAN可能」に設
定する）
手書き署名 HTML Widget と HTML5 Canvas の組み
合わせでクライアントサイドで実装
標準機能（Signatureデータ型）
CSVエクスポート Serverスクリプト（GAS) にて実装
DriveApp にて
標準機能（「App:export this view to a CSV
file」Action）
チャットに投稿 Serverスクリプト（GAS) にて実装
UrlFetchApp にて Incoming Webhook に
POST
標準機能（｢Webhook｣Workflow）
「アクセス権限制御」「バーコード読み取り」を含め、実際の App Maker案件でよく求められる機能
（※ 個人の経験による。また、 App Maker での実現方法は一例です）

AppSheet ならあっという間にできる
32

AppSheet で手書き署名
33
https://www.appsheet.com/samples/A-work-order-app-in-which-employees-can-request-repairs-and-fixes?appGuidString=7dab4f
ea-19f8-47c6-b760-8fc435fdf639
スマホで試したところ、指で気持
ちよく署名できた
● Signature型のカラムを作るだけ

AppSheet でCSVエクスポート
34
App:export this view to a CSV file を選
択
● Actionから選ぶだけ
● テーブル単位

AppSheet でチャットに投稿
35
Slack 以外のURLでも指定できる。この
例は Google Hangout Chat
● Workflowの
Webhookから設定
● Presetから「Slack
Hook」を選択し
● UrlやBodyを入力

AppSheet でOCR
36
https://www.appsheet.com/samples/How-to-grab-the-text-from-an-image-using-OCR?appGuidString=e6b13b43-6967-4d61-ab72-530c0d000
04b
図形混じりの割と複雑な日本語
入りの画像でも
かなりの精度でテキストを抜き出
してくれる
● ImageとLongTextのカラムを持つテーブルを
作り
● LongTextのINITIAL VALUEに
「OCRTEXT([Imageのカラム名])」を設定する
だけ
● UX（画面）側は特に何もしなくても良い

評価結果
37

結果
38
観点評価
機能性 1アプリのみでの評価ではあるが、App Makerアプリで動作していた機能はAppSheetで全て実現できた。よほど画面
レイアウトや使い勝手にこだわりが無い限りは（次ページ参照）App MakerアプリのAppSheet移行は現実的だと考え
る。
また、Cloud SQLの利用も容易で、（過渡期における）App Makerとの並行運用のために必要となる「既存スキーマに
変更を行わない移行」が実現できる。
AppSheetアプリ（UXや関数）は、Cloud SQLなどのデータベースをそのまま扱うのではなく、AppSheetテーブルが間
に挟まる感じなので、スプレッドシートと同じように手軽に扱えるのもポイントが高い。
開発の容
易さ
バーコード読み取り、手書き署名、OCRなど「業務効率化案件」で必ずといっていいほど必要とされる機能がノーコード
で本当に簡単に実現できるため、今までエンジニアを必要としていた領域でも非エンジニアにて実現ができる（ちなみ
に、今回のアプリ移行検証は、調査やCloud SQL周りの作業含め実質半日程度で完了している）
一方、App Makerからの移行のため、Cloud SQLを利用する場合は、その運用・管理にはある程度の知識は求められ
るが、そもそも、App Maker を利用していたような組織（G Suite for Businessユーザー）であれば大丈夫な気がする。
ワクワク
感
スマートフォンからのユーザー体験は気持ちが良い（バーコード読み取りやOCRの性能が素晴らしい）。また、これだけ
簡単にノーコードで実現できることが多いと、アイディアを形にするまでの壁が恐ろしく低く、ワクワクする。

App Makerにはできて、AppSheetでは実現ができないこと
● 例えば、画面に大きくボタンを配置したシンプルな打刻画面
● 例えば、PCに最適化され、ガチガチにレイアウトされたこだわりの入力画面
39
極論言うとApp Maker は、
・HTML Widget（任意のHTML埋め込み）
・外部JavaScriptライブラリ、CSSの利用
・GASによるサーバサイドコーディング
が出来る時点で、「GASによるWebアプリ開発」で可能なことは全
て実現できると言ってよい
App Makerからのアプリ移行を検討する際は、
・利用者に画面のレイアウトや使い勝手にどの程度こだわりがある
か
にて判断し、そのこだわりがほぐせないならAppSheetではなくGAS
のWebアプリに移行したほうがよい
※ 複雑なサーバーサイドロジックは、別途REST APIとして実装し、
それをAppSheetから呼び出す形で実現できるが、画面はどうしよ
うもない

補足・所感
40
● ネイティブアプリによるユーザー体験が本当に素晴らしい。
○ App Maker のように個別にURLを配布する形でなく、AppSheetアプリで完結した世界に
なっているのが楽
○ とはいえ、完全にベンダーロックインされますが
● Google が「App Maker じゃなくてこっちが欲しい」と思った気持ちが分かった。App Maker で作
ろうと考えたものは大概、はるかに効率よくAppSheetで実現できる。
○ 今後Google Cloudとの統合が進んでいくかと思うが、（今の自己完結した良さを活かして）
いい形でまとまってほしい
● まだ試していない機能（API呼び出しやNFCやchartやMapなどのViewスタイル）も試してみたい
○ APIを絡めたような、単体のアプリではなくシステムの構築となると、エンジニアの出番があ
ると思える

以上
41

続・AppSheetを使い倒してみた～ App Makerで開発したアプリをAppSheetに移行する

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 続・AppSheetを使い倒してみた～ App Makerで開発したアプリをAppSheetに移行する

Similar to 続・AppSheetを使い倒してみた～ App Makerで開発したアプリをAppSheetに移行する (20)

More from Yukio Okajima

More from Yukio Okajima (17)