.png)
以前、App Makerについてのブログを掲載しました。その続編です。
業務上でもApp MakerからAppsheetへの移行についてのご質問についても頂戴しており、ここでApp Makerの仕組みについて短い時間ですが学んでみました。学習と申しましても、まだまだ勉強不足で、YoutubeにUpされているチュートリアル動画（かつ初級編）を見ただけに過ぎませんが。。。
App Makerのアプリ開発のコンセプトと基本的な動作は、Appsheetのそれと大きく異なりました。
まず、アプリの土台となるデータベースとアプリからの接続。（私の理解が異なるようでしたら、ブログをご覧の方、ご指摘・訂正いただけますと助かります。）
①データソースへの接続
第一のポイントとして、アプリビルダーからのデータ接続について。Appsheetは、基本的にGoogle SpreadsheetやExcel, SQL等、複数の異なるデータソースにアクセスし、既存のテーブル・スプレッドシートからアプリの構築を開始することが可能です。と申しますか、それが基本動作です。また、スキーマの修正、例えば、カラムを増やしたいという場合においても、スプレッドシートに行を加え、アップシートのEditorからテーブルを再度読み込ませるだけという単純な作業でスキーマ変更が可能。その後、アプリは対象となるスプレッドシートやSQLに接続し、新たなデータを保管したりと、その名の通り、データソースで有り続けます。
一方、App Makerですが、AppsheetのようにスキーマをSpreadsheetから生成の流れとは真逆。App Makerのプラットフォーム内で、スキーマを生成。Cloud SQL内にデータベースを構築の流れのようです。これだけの作業と一見簡単・便利に思えますが、アプリの土台として利用できるデータベースは、基本、Cloud SQLのみ。例えば、GOOGLE SPREADSHEETをデータベースとしてApp Makerで利用することも技術的には可能なようでしたが、その為にはいわゆるGASを叩かなくてはならない。Appsheetでは、数秒で済む作業がApp Makerでは、ヵ月単位の期間を要することは確か、且つそもそもプログラマーしかこのような作業は実現できないと思います。gasは基本Javascriptですので、JSがわからなければ基本何も出来ない。
Google のプロダクトなのに、なぜ、NativeにGoogleSpreadsheetに接続し、アプリを構築出来ないのか？もちろん、技術力等々さまざまな要素が関係してくると思いますが、この時点で、Googleのその他のサービスとの親和性、という時点でAppsheetは圧倒的に先を行っていると感じます。
あるテーブルはGoogle Sheetから。その他のテーブルは、One Drive上においたエクセル、加えて、MS SQLに接続して、スキーマ確定。といった荒業はApp Makerでは実現できません。（Script無し、という同一の前提条件下の話です。）
この点を理解した際、App MakerはG SUITE サービスの一部で、利用した分だけ課金されるCloud SQLへの接続・利用を誘導しなくては自己矛盾に陥る。従い、Cloud SQLをデータソースの中心と考えて、プラットフォームを構築せざるを得なかった?のではないかと推測が浮かびました。となると本来、ユーザー本位・便利性を最上位に考えるべきところの重要な部分が置き去りにされているように感じます。ユーザー視点から言えば、既存のスプレッドシートや、SQL, なんでもそのまま利用できる方が当然に便利です。「アプリから接続できるのは基本、Cloud SQLのみ。その他のDBにアクセスする場合はGASをご利用下さい。」がApp Maker。
②UIの構築
次に、UIの作り込み。AppsheetではUserが目に触れるUIをViewと一般に呼んでいます。一方、App MakerではPageと呼んでいるようです。Appsheetはデータを読み込むと同時に、アルゴリズムが動き、最適と思われるVIEWを自動生成してくれます。もちろん完璧ではないので、修正が必要であったり、そもそも必要のないVIEWなので自動生成後に削除、という作業が一般的な流れです。一方、App Makerは、View(Page）をゼロから構築しなければならないようです。Drag and Dropのインターフェースで簡単にUIを構築。すばらしいですが、面倒臭がり屋の私としては、この作業もアップシートのように自動化・標準化して欲しい、と思いました。
アプリ開発に要する「時間」だけを見ても、勝敗は明らかですが、App Makerが優れている点として、AppsheetはUIを独自に構築、カスタマイズすることはできない部分。App Makerは、これが出来ることが魅力です。カスタムのCSSも加えることが可能のようです。この点は、Appsheetにはない機能です。但し、Appsheetには、単純なTableViewの他にも、Deck, Card, Chart, Map, Form, Detail , Calendar, Onboard, Dashboard等、標準化された複数のVIEWが準備されています。用途や好みに従い、選択し、UIを構築していくだけです。それぞれのVIEWに組み込まれている様々な「仕組み」もApp Makerには存在しません。App Makerでは、AppsheetでいうところのTable、FormをDrop and dropで構築していく、という作業のようですが、Appsheetで準備されているTable/Formの機能はApp Makerで構築できるものを既に超えています。
また、Viewについても研究を重ね、利便性の高く、且つユーザーフレンドリーなUIをデフォルトとして設定しています。
総合点からしても、データベースの種類、接続方法、スキーマの設定・変更に加えて、UIの分野でもAppsheetが便利との評価。データ接続やUIの構築といったApp MakerでUI構築においてやれていることはすべてAppsheetで対応可能、と結論づけて問題ありません。
GASを叩けるか叩けないか？ AppsheetのOfficial Communityでも何度も質問されているトピックです。
③GASによる機能拡張
Appsheetは完全NO CODEのプラットフォームですので、基本、アップシートのプラットフォーム上でGASを叩く場面は一切ありません。一方、GOOGLE SPREAD SHEETの操作でGASを叩くようなケースはあると思います。バックエンドの対応という理由において。例えば、アップシートで生成されたスプレッドシートのデータを他のSHEETに自動でエクスポートしたり、NULLの行を自動で削除したり等々。これは、Appsheetとは直接の関係のない部分でGASにより機能を拡張している例です。
私も顧客向けにAppsheetでアプリを作成している際、GASを利用しなくてはならないか？という場面に遭遇することもありましたが、信念としてアプリの構築に際してもGASを含めてプログラミングは一切行わない、ことを基本としています。従い、別の方法を考えるわけですが、GASを叩かなくても実現出来てしまう事例がほとんどです。
「Gas 使える、使えない」という視点だけに絞れば、App Makerに軍配と思ってしまいそうですが、基本、App Makerでアップシート上でデフォルト・標準で出来ることに「近づける」ためにはGASが必要なだけで、つまりは、App MakerではGASを利用して機能拡張する部分は、既にAppsheetではNativeに対応しているという事実を忘れてはならないでしょう。
GASを叩いて、機能拡張。この言葉だけで判断しては、間違った結論に至ると思います。
App MakerからAppsheetに移行を、という場面でも、逆に心配はないということの裏返しです。App MakerでゴリゴリにGASを叩いて構築した機能も、AppsheetではNativeに対応可能ということです。
④ロジックの構築
次に、より複雑なアプリを開発する上で必須となるロジックについての考察。アップシートでは、様々準備された関数を複数の場面で多用することで、極めて複雑なロジックもIntuitiveな関数を活用することで実現できます。Google Sheet、Excelでの関数構築に近い便利さです。App MakerのTutorialを通じて確認する限り、関数というよりは、Programmingに近い言語と理解しました。例えば、関数の後ろにドットで次の関数を連結することでロジックを構築。関数を関数で接続という概念はObjectやPropertyといった概念を理解したプログラマでしか理解できないと思います。また、どのObject(関数もObjectに分類します）にどんな関数が利用できるのか？これを学ぶには、新しいプログラミングを学ぶと同じ程度の学習が必要となるかもしれません。App Makerの「関数」ではどのような程度の複雑な内容まで対応できるのかわかりませんが、Appsheetでは従来、バックエンド、SQLなどで、トリガーを叩いたり、VIEWを作ったりといった作業を施さなければ実現できなかったことも、これらの関数を組み合わせることで簡単に実現できてしまいます。現在、私の顧客に利用いただいている大規模アプリはすべてSQL上で動いていますが、SQLといっても何らサーバーサイドにロジックを組みことはなく、Appsheet上で完結してしまっていますので、SQLは単なる箱に過ぎない状態になってしまっています。
小さなことかもしれませんが、例えばドロップダウンに表示させるリストのアイテムを動的に変更したい。App Makerでは簡単にはできそうになく、GASを叩くのでしょうか？Appsheetでは、こんな動作も関数一つで実行可能ですので、アプリを構築し、機能を追加するたびに複雑化してくるこれらのロジックをいかに高速に構築していくか？ あまり焦点があたりにくいポイントかもしれませんが、極めて重要な要素です。
⑤モバイル対応
次にMOBILE Nativeか否か？
最近では、アプリを語る際、MobileとDesktopの垣根が低くなっているように思います。基本、アプリは携帯・Desktopの両方で動かなくてはなりません。App Makerのテストをしたわけではませんので確信的には申し上げら得ませんが、UIの設定方法を見ても、Desktopよりの位置あるものと理解しました。一方、Google検索で、App Maker Mobile と入れてもそれらしい記事・文献がヒットしません。。。。App MakerはそもそもMobile 対応していないのでしょうか？
Appsheetですが、以前は同社のHP上で、「モバイルアプリを作りましょう！」と宣伝していたほどですから、Mobile/Desktopの境目は若干MOBILE寄りにあります。Desktopアプリではよくある、「マウスオーバーするとTooltipsが現れる」こんな動きもありません。今後はわかりませんが、Mobileが基本であったので。但し、Desktopで使える機能も沢山追加されたために、最近ではMOBILE APPとは宣伝せずにHP上でもAppとだけ表示しているようです。
App MakerからAppsheetへの移行に関する考察において
・外部サービスとの連携は
・レポート作成機能
・位置情報把握
・写真撮影機能
・
・
・
等々、現代のアプリにおいて必須となる各種基本機能についてのポイントも必要とされると思いますが、ほとんどのところ、App MakerではScriptを叩くと出来る、叩いても出来ないものと定義すると、既にこれらはAppsheetではNativeに対応可能ということなので、これ以上の深い検証は不必要と思います。
上記の評価を踏まえて、極めてラフにアップシートとApp Makerの比較を可視化しますと、
個人的な結論、意見です、もちろん。
今後、具体的にAPP MAKERで作成されたアプリをAppsheetにコンバートするプロジェクトにも参画する予定があり、新しい発見がありましたらブログなどを通じシェアできればと思います。