AppGyver（チョット）やってみた#7〜AppGyverっていったいなんなん？

2022年12月2日 05:16

この記事は SAP Advent Calendar 2022 の12月2日分の記事として執筆しています。

今年は巷で話題のノーコードツール（コードを書かなくてもプログラムが作れるツール）を今年は片っ端から学習してみました。今や空港やバス停にまで広告が出ている「Notion」そしてGoogleに買収されて注目の「AppSheet」さらに最も老舗といわれるツール「Bubble」そして今回のテーマであるSAPの「AppGyver」について自力でやってみるなりチュートリアルをこなすなりしてきました。そして今は「Glide」というツールに取り組んでいたりもします。その中でAppGyverというツールの意義と言うか位置づけについて考えてみました。

まずざっくりとした位置づけ

まず数あるノーコードツールのなかでのAppGyverの位置づけを俯瞰してみます。・・・・と入っても今までやってみた５ツールくらいの中での話ですが・・

全体的に左右にはっきりと別れます。

左のグループ（Notion、Appsheet、Glide）はワークフローのアクション（データの更新、削除）や機能のパターン（登録画面、一覧画面）が固定で決められているツール群で、どちらかというと小さな組織で使ったり、簡易的な機能と割り切って使ったり、PoCなど素早く確認したりするようなときに使うようなツールといった感じです。

逆に右のグループ（bubbleとAppGyver）はコードを書くプログラミングのようにボタンなどのオブジェクトを押した後のワークフローも含めてすべて開発者が設定してコントロールする・・・・つまりはコードは書かないけどプログラミング言語とほぼ同等に使うツールで、自由度が高い反面、学習コストがそれなりにかかるタイプのツールです。

一番の特徴は「データベースがない」

これらのツールの中でAppGyverだけが持っていない（もしくは強調していないだけかもしれません）機能があります。

それはデータベースです。

左のグループの簡易ツールはすべてデータベースありきの構造になっています。Notionは独自データベース、AppsheetはGoogleスプレッドシート、そしてGlideは独自データベースやGoogleスプレッドシートやEXCELと一体的に構築します。左側のbubbleでもbubbluデータベースを使うのが通常のようで、用意されたチュートリアルの中でも、そういった流れで紹介されています。

しかしAppGyverについては（私の不勉強の可能性もありますが）データベースの存在はうたわれておらず、チュートリアルでもAPI接続でデータを読んでいます。つまりAppGyverとしてはデータベース一体型のオールインワン型のノーコードツールではなく、何らかの外部データベースやAPIを使う前提のツールなのです。
言ってしまえばC#とかjavaとかそういったプログラム言語と同じ位置づけのツールなのです。（と勝手に推測）

SAPのSide-by-Side拡張戦略との整合性

このデータベースがないという特徴はSAPの戦略にも非常にマッチしています。
SAPは企業のDX推進などによる今後起こりうる様々なカスタマイズについてSAP本体そのものにABAPなどでカスタマイズを加えていく「In App開発」をしていくのではなくSAP Business Technology Platform(BTP)を通してAPI連携による疎結合で作り上げる「Side-by-Side拡張」というアーキテクチャを推進しています。

この方式により本体の変化が周辺のアプリに与える影響を最小化して、今後のバージョンアップをやりやすくするという狙いがあります。

その構築方法のひとつにAppGyverが位置づけられているのです。

そう考えたときにこの「データベース」が用意されていないというのはむしろSide-by-Side拡張の方針にとってアドバンテージになると思われます。ノーコードツールで作る開発者が簡単にデータベースを作ってしまっては、データのガバナンスは全く効かなくなってSAPの拡張ではなくなってしまいます。あくまでデータそのものはSAPなどの基幹システムでしっかりとマネジメントして、その情報を活用するという形で市民開発者へ提供していく・・・・そんな姿を目指しているようですね。

実際にどう使う？

で、このAppGyverどう使うという話です。先程までの話を総括するとSAPのデータをBTPを通してAPIで連携させて、利用するという形になるかと思います。

「市民開発者」という役割をどう位置づけるかによりますが、この場合には基幹システムであるS4/HANAなどのSAP本体からのアプリへの接続はシステム部門（もしくは専門知識をもったパートナー企業）が行って、提供されたデータはAPIが許す範囲で活用してアプリを試行錯誤しながら市民開発者（ここで言うと企画部門の人とか情シスの人）が画面や機能を作り上げていくと言ったイメージではないかと思われます。

ノーコードとはいえAPI接続のところはわかりにくいですし、学習コストもNotionとかに比べるとそれなりにかかりそうなので、ある程度トレーニングが必要かと思われます。いまのところデータベースの項目を指定するところがまだ未完成でコード（式）を書かないといけない感じなので、その形なのかなと感じました。（全くのワタクシの感想）

もはや戦国時代の様相になってきたノーコード開発の世界ですがAppGyverがその特徴あるアプローチでどう発展するのか？そこに期待です。

この記事が気に入ったらサポートをしてみませんか？