ノーコード・ローコード：AppSheetがもたらす開発手法と業務スタイルの変化

Advent Calendar 2024

こんにちは、GASエンジニア の 佐伯 です。

この記事はEnigmo Advent Calendar 2024の 21 日目の記事です。 この記事ではGoogle製のアプリ開発ツールである、AppSheet について紹介します。

軽く自己紹介になりますが、普段はGAS（Google Apps Script）やBigQueryなどを用いて業務用ツールの開発を行っています。最近はGASとの親和性も高いAppSheetに挑戦しているので、その中で気づいたことをまとめます！

概要

AppSheetの利用を検討している方向けに、AppSheetの基本的な特徴やメリットをまとめる。また、より高度に使いこなしたい場合の拡張性や、筆者が感じる向いている用途、デメリット（弱点）、Microsoft製品との比較についても記載している。

特徴とメリット

データに関する設定を重視した開発ツール

  • 大前提とされるべきAppSheetの特徴として、データ重視の開発ツールである点がある。
  • これはどういう意味かというと、例えば、ある業務に関連した複数のリレーショナルなテーブルがあるとする。これらに対して、各テーブルの主キーやデータ型を定義し、またテーブル間の参照関係を設定すると、それらのテーブルの利用の仕方は、おおよそ決まってくる（予想がつく）。
  • 「予想がつくなら、自動で作ればいいやん」というのが、Google社がAppSheetに込めた主要な思想かな、、と考えている。
  • それゆえ、それらのテーブルに対する CRUD（ = Create 生成、Read 読み取り、Update 更新、Delete 削除）操作を行うUIを、ほぼ自動で作成するのが AppSheetのメイン機能となっている。
  • それ以外にも多くの便利なサブ機能があるが、これらはメイン機能に付随し、補完する形で提供される。

UIの作成が非常に早い

  • データソースの設定がなされた時点で、主要なUIは、ほぼ自動で作成される。
  • UIの表示形式も、テーブルやカード、タイル形式だけでなく、ダッシュボード、カレンダー、マップ、フォームなどなど、ある程度のバリエーションが用意されている。
  • データ型に応じた入力補助のUIなども、自動で適用される。選択肢タイプであればドロップダウンが表示されるし、日付型であればカレンダーが表示される。当然、データ型に違反するような入力はできない。
  • あとは、表示順や、並び替えといった、実際に利用するユーザー目線での利便性を向上させれば完了である。
  • ここまで読んで、メイン機能それだけ？！と言われそうであるが、AppSheetを利用することで、UIとデータソースをほぼ完全に分離することができるため、これによるメリットはやはり大きい。
  • 例えば、GASでスプレッドシートをベースにツールを組む場合、UI作成の手間を回避するためにスプレッドシートをUIとして用いることが多いが、この場合、どうしてもユーザーがデータソースを直接編集する形になりがちであり、誤操作やツールの破壊が生じるリスクは大きい。
  • また、本来であれば正規化して複数のテーブルに分離されるべきデータ構造であっても、やはりユーザーの一覧性向上の観点から、一つのシートにまとめて表示させる場合も多く、冗長でもあるし、データの保全性という点でも、よろしくない。
  • AppSheetを利用することで、UIを独立させ、データソースを理想的なリレーショナルDBの構成で、堅牢に安全性高く維持することができる。しかもUIはほぼ自動でできるのだから、活用しない手はない。
  • ちなみに自動で作成されたUIを利用せずに、手動でイチから設定していくことも可能である。

データソースの選択肢が幅広い

名称 説明
AppSheetデータベース 専用のリレーショナルデータベース。
Googleフォーム Googleフォーム入力値をテーブルに使える。
Googleドライブ フォルダーやファイルを指定し、そのコンテンツを解析して半自動でテーブルを作成する。
Microsoft OneDrive または SharePoint にあるエクセルを使える。
Airtable
Cloud Database GCP,AWS,Azureなど、クラウド上にあるデータベース。通常のSQL形式はもちろん、BigQueryも含む。
On-premises Database オンプレデータベース。DreamFactory connection を使って接続する。
  • 特にGoogleドライブは、請求書などの書面からも自動的にデータを再現するとのことであり、使ったことはないが、おもしろそうである。

サブ機能によって処理内容の自由度を上げられる

基本的なCRUD操作以上の処理フローを構築する手段として、AppSheetでは様々なサブ機能が提供されている。

サブ機能 内容
入出力補完 UI上でユーザーが様々なCRUD操作を行う際に、いろいろなバリデーションや加工、警告といった機能を付与できる。
Action ユーザーが実際にCRUD操作を行う際に、実行するであろう画面遷移や処理内容を、ボタン１クリックにまとめて、UI上に配置する機能である。
Automation テーブルに加えられたCRUD操作や、スケジュール設定をトリガーにして、定められた処理を実行する機能である。処理内容の選択肢としては、大きく次の２種がある。
①メール、通知、SMS、Chatなどの通知系
②webhookやGASを実行する外部連携系
Chat app アプリと連動させて、Google Chatにメッセージを送るような使い方ができる。普段から Google Chatを使っているならば、便利と思われる。
  • Action はアプリ内での画面遷移や、他のテーブルへ影響を伝播させるための機能で、処理内容は選択式となるため制約もあるが、比較的簡単な操作で処理フローを構築できる。
  • Automationは、ユーザー操作や時間タイマーをトリガーとする自動化処理を構築するための機能で、先ほどのActionによる内部的な処理はもちろん、web APIなどを通じた外部サービスとの連携や、GASとの連携を図ることができる。GASはGCPとも密接に連携可能であり、この点は、AppSheetの限界を大きく広げてくれる。
  • ただしweb APIについては、AppSheetから直接認証通過できるのは、APIキー方式などの単純なものに限られ、OAuth2といった主流の方式は（今のところ）直接接続はできない。ただしこの点も、GASに処理を任せてしまえば、そちらでOAuth2通過はできるので、あまり問題にはならない。
  • GASをどれだけ使いこなすかが、AppSheetの限界を決めそうであるが、GASとAppSheetを連携させる場合においても細かい注意点はあるので、こちらは別途まとめる予定。

SQLライクの専用関数を利用して、複雑な処理フローも構築できる。

  • 少し複雑な処理フローを構築する場合でも、AppSheetには専用の関数が利用されており、これらを用いることで、かなり複雑なデータ操作も作成できる。
  • これらの関数の使い心地としては、基本的にはスプレッドシート関数に似ていて、テーブルデータを操作する部分についてはSQLの記法も混じっている感覚となる。関数の数は少ないが、よく考えられており、組み合わせ次第で多彩な使い方が可能。

モバイルからの利用をメインで想定しているようだが、パソコンでも問題なく使えるし、便利。

  • AppSheetのエディター画面では、モバイル形式のプレビュー画面がデフォルトで表示されるが、パソコンのブラウザでのプレビューも表示できるし、実際、問題なく利用できる。
  • ただ、基本的にモバイルを想定しているため、パソコン（ブラウザ）で利用すると、画面がちょっとシンプルすぎる印象ではある。ただこの点も、デスクトップモードの改善が進んでおり、かなり利便性を向上させやすい状態になっている。

実質無料

  • 驚くべきことに、無料のGmailユーザーであっても、AppSheetは利用できる。いくつか機能に制限があり、アプリを共有できるのも最大10名までではあるが、それで事足りる場合も多い。
  • ましてや workspaceを利用している組織であれば、使わない手はない。プラン関係なく、Business系プランには AppSheetの Coreプランが付属している。
  • AppSheet有料プランの料金体系は極めて複雑であり、合理的なのだろうとは思うが、ユーザーの理解を拒絶しているといっても差し支えないレベルである。
  • 詳細を無視してざっくり言ってしまうと、「（有料レベルの機能を利用している、または10個以上のGoogleアカウントで利用しているアプリの場合、）そのユーザー数分の AppSheet有料プラン契約が必要」というイメージである。
  • workspaceを利用している組織であれば、そのユーザー数分の AppSheet有料プランは含まれているわけだから、例えば30人の組織であれば、あるアプリを最大30ユーザーで利用できる。しかも、これは組織内のアカウントに限られず、組織外の無料Gmailユーザーを含んでいてもよい。そのアプリの合計ユーザー数が30を超えなければよい、のである。
  • さらに無料、有料を問わずアプリ数の制限はなく、また全アプリの合計ユーザー数分の有料プランが必要なわけでもない。あくまで個々のアプリでユーザー数が判定されるのみで、先ほどの例で行くと、組織内でアプリA、アプリB、アプリC の 3つのアプリを運営しているとしても、それぞれのアプリで30ユーザーまで設定できる。

抜群の拡張性

ここまで AppSheetの主要な特徴に絞って記載してきたが、それ以外にも注目に値する特徴は多い。

  • バーコード、QRコードの読み取りが可能
    商品や資材といった物理的なアイテムを取り扱う業態の場合、これは非常に強力なメリットとなる。コードを読み取ってアプリに値を直接入力したり、コードを読み取ってそのアイテムに該当するデータを瞬時に検索したりすることができる。
  • データだけでなく、画像を始めとした各種ファイルの取り扱いが可能
    画像やファイルを、データに紐付けて保管できる。アプリ内で端末からアップロードすると、Googleドライブ内に作られた専用フォルダに自動で保管される。
  • CSVを介したデータ操作が可能
    他ツールとの連携や一括更新の際に便利。現状のテーブルをそのままCSVで出力し、修正の上で、アップロードして反映させることも可能
  • アプリごとにAPIを利用できる
    これもエンジニアにとっては嬉しいところ。他のシステムやツールから、API を介して直接データ操作することができる。
  • GAS（GCP）連携
    先にも述べた通りで、スタンドアロン型のGASと連携できる。GASはGCPや外部システムとの連携が可能であり、これはつまり、ほぼ何でもありであることを意味する。

デメリット

AppSheetにはデメリット、または使いにくそうな面ももちろんある。以下は、これまでの使用経験の中で感じた主要なデメリットであり、今後の改善に期待している。

  • UI作成の自由度は低い。特に要素配置やメッセージ表示の観点で不自由を感じることが多い。
  • 環境移行の手間が比較的多い。アプリAからBへ丸っと移行はできるが、その際にGitのような移行前後の差分確認ができない。来歴管理については、開発画面で編集保存するたびにバージョンが自動更新されるようになっており、過去のバージョンにロールバックさせる機能が備わっている。
  • スプレッドシートのように他ユーザーの利用状況を確認できない。
  • スプレッドシートのようにアプリ画面で関数や条件付き書式の設定ができない。（開発エディターからは可能）
  • 他ユーザーによる操作の反映がリアルタイムに行われない場合がある。その際は画面再読み込みが必要。

向いている用途

SQL形式のデータ構造に基づく、業務用アプリケーションの作成に向いている。

NoSQLや複雑なデータ構造が必要なアプリケーションや、顧客向けアプリのようなオシャレで複雑なUIデザインが必要な用途には、向いていない。

また業務アプリケーションであっても、複数人で同時にテーブルの同一行を編集するような用途では、衝突により更新が拒否される場面が多くなる可能性があり、工夫が必要である。

今後期待している点

一番は、UIの柔軟性の向上である。表示のデザインや操作性には特に文句はないのだが、項目やボタンの配置の自由度がもっと上がれば、非常に使いやすい画面になると思っている。

またユーザーからの指摘で「なるほど」と思ったのは、スプレッドシートのように「誰がどこで作業しているかを表示してほしい」という意見であった。業務に関する操作を行うのが目的である以上、他メンバーの状況が一目瞭然にわかるということは、進捗の把握や連携の向上といった点で、得られるものは大きいと思う。

Microsoft製サービスとの比較

仕事と言えばエクセル（？）、エクセルといえば Microsoftということで、長く独壇場を維持していた Microsoftも負けてはいない。グループウェアのビッグ２といえば、Google Workspace と Microsoft 365 であり、Microsoft 365 には AppSheet と類似する Power Apps が含まれている。

Power Apps もノーコード・ローコードツールであり、SharePoint に作成したテーブルなどをベースに、Poser Automate の処理フローと連携して作成する業務アプリケーション作成ツールである。

Google AppSheet と比較した際の一番の特徴は、UI制作の自由度の高さである。項目の配置はもちろん、その大きさや配置など、極めて柔軟であり、自由である。VBAのユーザーフォーム（UI)作成の操作感とよく似ていると思う。

ただ自由度が高いということは、それだけ手間がかかるということであり、実際、同じような画面を作る工数は、AppSheet と比べると Power Apps のほうが大きくなると感じている。

Google AppSheetのようにスッパリ割り切るのがよいか、それとも、Microsoft Power Appsで納得いくまでこだわれる方がよいか、、このあたりはまさに悩みどころかもしれない。

終わりに

近年のノーコード・ローコードツールの発達は目覚ましく、AppSheetがその代表例の一つであることは間違いない。いろいろとツールを調べたり使ってみたりする中で思うようになったのは「拡張性の高いノーコード・ローコードツールを、エンジニアが使うことが重要」という点だ。

プログラミングスキルに乏しい状態でノーコード・ローコードツールを使っても、さほど便利なアプリは作れない。あくまで標準的に準備されている環境の中だけで構築することになるからである。

しかし、エンジニアが拡張性に優れたノーコード・ローコードツールを使うことで、

  • （生産性の低くなりがちな）UIや簡単な処理フローの構築をツールに頼って高速化しつつ、
  • ツール内では対応しきれないような複雑な処理フローについては、連動可能なプログラミング環境内で実装することで、その業務特有の複雑なプロセスにも対応できる。

という、両者のいいとこどりが可能となる。

また、操作性がよいゆえに、ノーコード・ローコードツールの開発者は、かつてのVBAのように今後ジリジリと増えていくと思われる。こういったツールでは開発手法がより規格化されやすいので、同じ機能を実装した場合の開発者による差も生じにくい。

それゆえ、できるだけこういったツールを用いることで、開発／保守業務の属人化を極小化し、ひいては業務の継続性・安定性を高めることになると考えている。

明日の記事の担当は RDチーム の 廣島 さんです。お楽しみに。

株式会社エニグモ すべての求人一覧 hrmos.co