ローコード・ノーコード開発（Glide）
いつもと違った開発の関する投稿です。
■実際にローコード・ノコード開発をした感想
あるクイズアプリを作成することになり、Glideで開発をしてみました。
結果、、、普通の開発よりも難易度が高かったです。
データを参照・入力や編集するだけのアプリ（つまりデータに向けたUI作りなら、非常に簡単に作れます。テーブルを作ったら、それに見合う画面（しかもキレイ！）がほぼ自動的に作成されます。
が、クイズはテーブルを１画面づつ参照してその問題などを書き換えるものではないです。いろいろ苦労した点から、「ローコード・ノーコード開発」と進めるうえで大切に思ったことを書いてみます。
■ローコード・ノーコード開発で必要なもの
１．データ構造とテーブル間リレーションを理解・構築できるスキル
テーブル（データ）をどう持つか、その画面をどう作るかがポイントだと思いました。「ローコード・ノーコード」だからこそ、ＰＧ（処理）でテーブル（データ）と画面の関係を自由に構築できません。
テーブル（データ）に関するスキルは必須な気がしました。今は、ＲＤＢの知識がよいと思いますが、データ構造とテーブル間の繋がりを構築できるスキルがないと厳しいなと思います。
２．自部門の処理をデータの観点でシンプルに設計する＝業務フロー化
今はデータを基幹システム（社内で共有するデータを格納して、各部に流して処理させるシステムという意味）にデータをためる（入力・編集）、参照して活用することが基本です。その活用アプリの開発を容易にすることが、ローコード・ノーコード開発ツールの存在意義なのかなと思います。クイズのように、データを使って、加工して処理させるものは、非常に難しかったのも納得です。
ということは、、自分たちの作業（処理）をどう効率良くできるかで考えるとドツボにはまって使えないとの評価になるかもしれません。従来、会社の情報部門はユーザー部門にヒアリングして効率よく作業できるシステムを目指してきましたが、もう時代は違うような気がします。
自部門の処理をデータの観点でシンプルに設計できる＝業務フロー化できる、これが一番大事なスキルかもしれません。
３．実現できる・出来ないではなく、実現する・しないの判断基準を設ける
Glideは、Googleシートと連携でき、部品（テーブルの参照式やデータ計算式、UI部品）が多く、画面（UI）がきれいにできるので素敵なツールです。
でも、作りこみすぎるとＰＧよりも複雑になり、Glideの知識が相当ある人にしか引継ぎできないものができてしまいます。全社でそのツールを全面的に活用していく方針があるならスキルを持った人材を育成できるので良いと思います。そうでない場合は、今後のメンテや拡張性を考えて、シンプルに作ることも必要です。
何より、実現できる・出来ないではなく、実現する・しないの判断基準を設けることがとても大事だと思います。
ツール選定が難しいと言われるのは、上記原因かもしれません。
４．最後に
デジタル化はデータを中心にして考えることが多いです。
精度が高く、有用なデータをいかに効率良く貯めていけるか、そしてデータをどう効率良く共有して活用していくかです。
この「ローコード・ノーコード開発」は、業務に精通したユーザーの方が部門でアプリを開発するためのツールではありますが、部内だけではなく、会社全体を流れるデータについて意識することが肝になる気がしました。
■開発過程をちょっと公開【参考レベル】
まず、普通のアプリ開発のように考えました。
画面イメージから、必要なデータをＲＤＢ形式で定義して作り始めました。
まず、レベル選択画面で次へ行っても、問題Tからデータを取得して、Q１→Ｑ２→Ｑ３画面を表示できない・・・
そして、Q１、Ｑ２、Ｑ３画面の選択結果を結果Ｔに保存できない・・・
画面とテーブルは１対１で自動生成されるため、
・自由にテーブルから画面が作れない
・自由に画面遷移できない
・自由にテーブルを指定して書き込めない
ということのようです。
次に、画面とテーブルを１対１で作成する、テーブル同士をリレーションシップで関連づけるサンプルを見つけ、作りなおしてみました。
画面遷移をしてクイズに答えてもらうまでは上手く実現でした。
画面開発は部品がいっぱいあり、クセはありますが、スムーズに作れます。リレーションシップで次の画面に行くところはサンプルで勉強しましたが、仕組みはシンプルにつながったデータを参照していくだけなので、分かりやすいです。
ただ、クイズの選択結果はQ1テーブル、Q2テーブル・・に格納されます。そうですよね。Q1テーブルを表示して、そのテーブルに書き込む、それが原則です。
上記だと、１人しか結果が保存できません(^^;
（頑張ればできるようになると思いますが、ここでは記載しません）
次に、複数人でクイズができるサンプルを見つけて、やっと完成！
それは、クイズ画面＝結果テーブルの１対１の関係で作る方法でした。
基本は、クイズ画面＝結果テーブルの１対１の関係です。
ただ、クイズ問題は別テーブルで管理して、結果テーブルで参照させることにより、今後のメンテ（クイズ更新）には対応できます。
でも、「ローコード・ノーコード」で処理が自由に作れないので、Googleシートを連携させたり、下記のようにデータ参照やリレーションシップ、式を多用して実現しないといけないです。
if( re1=="〇” ){・・・とかがないーー！！
JavaやC#が組める人間としては、PGの方が簡単に思えて仕方ありません。
うーむ、正直、下記テーブル構造を説明して引継ぐことは考えたくないなと思う自分がいます（^^;
最後のもう一つ、サンプルなどを探して解読して理解する、プロトをとりあえず作るスキルもないとダメかなと思いました。
最後までお読みいただき、ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？