ノーコードは形を変えた現代のRPGツクールなのではないか
この記事について。
2030 年 「エンジニアです。コードは書けません。」｜__shinji__｜ note
自分はそもそもビジュアルプログラミングやオーサリングに興味があり、ノーコードは興味の範疇でありつつも、現状のもの、現状の「コード抜きで作れる」ような謳い文句は厳しいと思っています。それを、RPG ツクールを例に説明します。
はじめに、ノーコードを分類する
本記事では、「専用の管理画面で編集し、出力のためにコードを書かない、もしくはコピペ程度」のものをノーコードとして扱います。
その中でさらに種類ごとに分類してみます。このような定義があるわけではなく、自分の主観的で暫定的な分類です。
- タイプ 1: データベースから自動的にフォームを生成
- Google App Sheet
- MS Power Apps
- タイプ 2: 高水準 API のパイプライン
- Zapier
- IFTTT
- 古の Yahoo Pipes
- タイプ 3: 主にランディングページなどのドメイン特化のビジュアルエディタ
- Studio
- Instapage
- Bubble
他、最終出力にエンジニアの手伝いが必要なのでノーコードとは言いづらいですが、管理画面だけ受け持つ CMS Backend も、ある種のノーコードかもしれません。最終的には、プログラマによって組み込まれることを前提としています。
CMS の文脈で、よりノーコードに近いものとして、 wordpress.com も含むかもしれません。
RPG ツクール・ノーコード説
ノーコードツールを触っていて、自分が思い出すのは、RPG ツクールシリーズです。(自分が触ったことがある 2, 3, 4, 2000, MV を念頭に置いています)
シリーズによって違いはありますが、RPG ツクールは、キャラクターの衝突や話しかける、特定マスへ侵入するといった「イベントトリガー」によって、イベントエディタで記述したスクリプトが実行がされます。
このイベントエディタは、 RPG を作るための DSL(ドメイン特化言語)から命令を選択する形式で、高水準な API として、例えば以下のような機能を持ちます。
- マップの切り替え
- メッセージの表示
- カメラ操作
- キャラクターチップの切り替え
- 画像の表示
これだけではなく、プログラマチックな低水準なロジック制御として、次のような機能も持ちます。
- 繰り返し
- 条件分岐
- スイッチによる分岐管理
- コモンイベントの呼び出し
- セーブデータ(セッションごとの永続データ)の操作
コモンイベントは、プログラマの言葉でいうと、スイッチを監視する常駐プログラムで、よく外部化された関数として使われます。
... 察しのいいプログラマはお気づきでしょうが、この時点でチューリング完全です。この記事の特性上、プログラマではない人も読むと思われるので解説しますが、簡単なルールを満たしている命令セットは、潜在的にはなんでも表現可能で、(少なくとも閉じた系の中では)他のプログラミング言語と同等の記述力を持っている、と言える性質です。
RPG ツクールは、標準機能をそのまま使うと、どうしても似たようなゲームになってしまう問題がありました。これは RPG というドメインに特化した結果です。なので、デフォルトの戦闘システムを使わず、マップエディタとイベントエディタで戦闘画面を自作する人たちが現れました。その一つの例として、商業化もされた「ふしぎの城のヘレン」を上げておきます。
先に挙げたノーコードツールも、すべてがチューリング完全といえるかは微妙ですが、似たようなループや条件分岐のコマンドを備えていることが多いです。イベントドリブンに記述するのは zapier や ifttt と同じですし、ドット絵のリソースエディタが付属しているのも、ドメイン特化のビジュアルエディタと言えるでしょう。
ノーコードはプログラミングをしないことではない
テキストによるプログラミングは文字を書いたあとに、それがどう解釈/実行されるか？という処理系のセマンティクスへの理解が必要です。このセマンティクスを覚えることは、ノーコードでも一緒です。
イベントドリブンのエディタにも、RPG ツクールと同じように、真偽値の条件処理や分岐処理がありますし、フォーム生成系のバックエンドにデータベースを持つ環境なら、その表示には配列(またはリスト構造)と繰り返し処理の理解が必要になります。データベースの読み込み・書き込みは、抽象レベルでは変数の理解が必要です。逆に言うと、ノーコード経由だとしても、これらの概念を身に着けた人は、プログラミング言語を書ける素養が既にある、とも言えます。
ランディングページなどのビジュアルエディタは、そもそも論理構造を廃しているかわりにトレンドのデザインに特化しているものが多いです。これは、GUI 環境でビジュアルを編集しながら目に見えない潜在的な状態を記述することに対して、人類にはまだこれといった発明がないからです。Studio は複雑なデータ構造へのバインディングを頑張っていますが、使いこなすにはプログラミングのセマンティクスの理解が必要です。後発のツールもそれ自体はきっと変わらないでしょう。
ビジュアルツールでも、プログラミング的な理解が不要とは言えず、padding や margin のボックスモデル、flex のボックスの整列やレスポンシブレイアウトでの挙動への理解が必要になります。
現時点でノーコードに接するプログラマにとっての一番の地獄は、要件が膨らんで「ノーコードのビジュアルツールで作ったペライチを改造して、動的に動く部分を挟み込むなどして複雑なアプリにして進化したい」といったものです。きれいな出力構造を持っているものは稀で、大抵はサービス側に隠蔽されてるツールによって生成されたものに手を入れるのは、かなり厳しいものがあります。なので、基本的には、よほど要件をコントロールしない限り、本格的なものはゼロから作り直しになることでしょう。
結局、ノーコードで必要とされるのは、テキストプログラミングと同じようなプログラミング的な素養だと言えます。
プログラミング的素養とは、本質的な難しさを分解すること
ここで想定される反論は、「大抵のゴールはそんなプログラミング手続きは必要ないから、ノーコードを扱うのにプログラミング的素養もいらないのではないか」というものだと思います。この問に答える前に、そもそもの断絶があって、プログラミング的な教養がないと、自分が表現したいものの表現の難しさがわからない、という問題と向き合う必要があります。
プログラマとして度々ぶつかる問題は、「私なにか難しいこと言ってます？」という人々とどう向き合うか、というものです。これは大抵、この問題に真正面に取り組むことではなく、本当にやりたいことを問いただして、手段を変えて同じ目的を達することになります。その際、「元々の課題がなぜ難しいか」を共有することが難しいです。例えば、画像認識の精度が上がらないことだったり、GPS の精度が出ない理由だったり、組合せ問題による計算量の爆発だったり、なぜサーバーで出来てクライアントに出来ない処理があるか、またはその逆があるか、という問題です。
この問題は、「やりたいこと」をステップに分解した時に、人類未踏の技術的ジャンプや、Google や Apple の人類最高の叡智が取り組んで実現された結果を簡単に転用できる、という前提があり、その手段が提供されていない時にそれを実現するための困難性を理解したり、または説明するには、やはりプログラミング的素養が必要です。
ノーコードは、現状、使ったツールの制約によって実現できる範囲が決まります。これによって、ツールによって実現できる範囲が最初から決まっていると言えます。
ノーコードでも複雑さが隠蔽されているだけで、表現力自体は既存のプログラミング言語・プログラミング環境と地続きなので、過大な目的に対して「詰む」ことがあります。またはツールが解決したいドメインから外れて、非効率な実装を余儀なくされる可能性があります。ノーコードから入ってしまうと、自分が抱えている問題を解決する命令セットがなく、そもそも何故ないのかを理解できないことも多々発生するでしょう。
プログラマがテキストエディタで汎用プログラミング言語のコードを書くのは、結局はスキルを身に着けた後は、実装面でも学習面でも再利用の面でも、それが一番有利で、かつ速いからです。自分がプログラミングを始めたのは、浪人中の息抜きにウディタでデフォルトの戦闘システムを改造して作って、これならプログラミングを覚えたほうが早い、と思ったからでした。
最近は AppSheet のように AI によって自動生成する系のものも増えてきましたが、結局 AI といってもどのように ML モデルを生成して、どう学習して、自分はその学習段階の、どの側面を切り取ったのか？ という理解は必要です。その挙動を乗りこなすためにもプログラミング的素養が必要です。
ビジュアルプログラミングに未来はあるか
プログラマの使うテキストプログラミング言語は、構文という概念によって、学習面の難を抱えています。括弧の対応や、各種命令は一字一句正確に記述しないと、動きません。曖昧性がないことは、学習後は良いことだと気づくのですが、一定数の初学者を排除します。ビジュアルプログラミングは、専用のツールを介して入力補助が行われるため、その問題は発生しません。
しかし、それに続くセマンティクス理解では「プログラミング抜き」とは言えない理解が必要です。そして、ここまで述べたように、ノーコード、つまりはドメイン特化ビジュアルプログラミング環境(一部の専門用語における DSML) は、プログラミング能力を前提にしても、次の問題を抱えています。
- ドメイン特化による汎用性のなさ
- ビジュアルプログラミングのそもそもの未発達
ビジュアルプログラミング環境の未発達を、ドメイン特化によって弱点を隠している、という言い方もできるかもしれません。
じゃあできないのか？というと、部分的に実現している環境はあります。それは Unity や Unreal Engine のようなゲームエンジン分野です。3D のような複雑なビジュアルは、テキストのみの記述ではプログラマでも理解が難しい分野で、とくにアーティストと協業するためにビジュアルプログラミング環境が発展しました。傾向として、ゲームや Web UI のようなビジュアルに近い部分は、編集頻度の関係からビジュアルエディタに置き換えようという試みが度々行われます。
ブループリント ビジュアル スクリプティング | Unreal Engine Documentation
Web がなぜ ゲームエンジンのようなオーサリング環境が出現しないかというと、ホームページビルダーや DreamWeaver が廃れたのはブラウザ間の際で同じ出力を担保することが技術的に難しいという理由があり、 Adobe Flash の代替が出現しないのは、Web は固定幅ではないリキッドレイアウトが前提にあるからです。
前者の問題は、IE が排除された後の世界ではモダンブラウザの足並みが揃うので解決される見通しがあり、後者はレスポンシブレイアウト技術の発展で多少の解決が見込まれていますが、それをビジュアル環境でプレビューしながら開発するメソッドやツールは、あまり揃っていません。そして、ゲームエンジンでもプログラミング上の変数空間と 3D 空間をつなぐのに識別 ID をつけてプログラミングを行うので、プログラミングを廃してはいません。2D 空間でもコード以外でビジュアルとデータを結びつける記述するのは難しいです。
そして、ゲームエンジンは Web の多くの処理を占めるデータベース処理にはあまり注力せずに済むという背景もあります。最近はオンラインゲームのためのリアルタイム処理は強いですがパフォーマンスよりデータの整合性を優先する Web とはゴールがずれています。
プログラマはノーコードとどう向かい合うべきか
contentful などを使うとわかりますが、管理画面を自作する必要がなく、DB の管理もサービス側におまかせすることができるため、API 経由で使う 管理画面付きの DB SaaS として扱うのがいいでしょう。ノーコードが提供する API 的側面が、プログラマの向き合う部分だと思います。
API がなく出力が決め打ちのサービスは、そもそも連携できる部分がなく、相談された段階で採用を見送ったほうがいいです。また、パフォーマンス上の難がある場合、間にキャッシュを挟むか、それが難しいならそのツールをやめるしかありません。
実装が非公開なオーサリングツールで生成したものに手を入れたい、と言われた場合は、短期的なハックを行いつつ、長期的な作り直しを提案したほうが良いでしょう。よほどよく出来たものではないと、ノーコードからの発展は伸びしろがないです。現状は、その「よほどよく出来たもの」はない、というのが自分の認識です。
最後に
ノーコードで必要になるのはプログラミング的素養で、プログラミング的な考え方を身につけることは、自分のやりたいことを分解するための手段でもあり、プログラミングに限らず有用な手段です。国がプログラミング教育に手を入れるのも、そういう時代を見据えてのことだと理解しており、今後のデジタルトランスフォーメーションでも、その考え方がないと中途半端なものになります。なので、テキストプログラミング/ノーコード問わずプログラミングにふれることは有用なので、どのようなものだとしてもいいので、接してほしい、と思っています。
ただし、現在のノーコードは、ツールごとに独立した知識体系で、短期的、部分的に有効なツールであって、成功したと言えるものは少なく、長期的なノウハウとして学ぶ対象にするものにはなりえません。汎用プログラミング言語と勝負できるビジュアルプログラミングの決定版と、その上に構築されるエコシステムが現状存在しません。その環境がないと、現在主流な OSS エコシステムと接続できず、プログラマにとって役に立たないと判断されます。今現在のプログラマにとっては、ビジュアルエディタは本質的ではなく生産的ではないので、注力すべき領域でない、と思われてもいます。
とはいえ、自分もこれらのツールを完全に否定しているわけではありません。自分の目的と完全に合致した提供されており、その目的から脱しない限りは有効なツールです。ただし、ノーコードすべてが有効だとは言えず、ノーコードプログラマというのは幻想の産物です。ツールごとに知識と目的のロックインが発生します。処理系が公開されているものは少ないので、書いたコードを外に持ち出したりもできません。
自分は最も成功したノーコードは Google Form だと思っています。アンケートフォームを提供して結果を集約するには、過不足ないツールだと思っています。
加熱するノーコード界隈に対しての冷静な分析として、西村賢氏の記事は参考になります。
コーディングを不要にする「ノーコード・スタートアップ」が注目される理由 | Coral Capital
今のままでは無理だが、これが解決されれば OK、と自分が思っている発明を挙げておきます。
- 汎用的なビジュアルプログラミング基盤(Scratch みたいなものではなくプロユースなもの)
- ↑ 上でのビジュアル環境でのデータベースのグラフ構造のビジュアル化手法
- ↑ 上でのビジュアル環境でのパイプラインのビジュアル化手法
- ↑ 上での UI とデータと UI のマッピングのビジュアル化手法
- これらを隠蔽してオートスケールするマネージレスなインフラ基盤(これはパイプライン実装の中身)
結局全てがビジュアルプログラミング環境の決定版の不在、というものに起因しており、そのためロックインが発生する、というのが自分の認識です。
そういえば、ちょっと前にフリーランスの仕事として、RPG ツクールと似たような、スクリプトを GUI で記述するエディタを作ったことがあるのですが、最初はコマンドの羅列を上から実行するだけ かと思っていたものが、実際にはこれらの分岐やループを備えたチューリング完全な表現系が必要ということがわかり、 javascript のコードを生成するツールとして実装し直した経験があります。作りきった感想としては、わかってるなら javascript を生で書いたほうが早い、でした。