「NoCode」という幻想

どうも、エンジニアのgamiです。

数日前に、NoCodeツールのAdaloを使って開発された大学生向けSNS「Union」が資金調達を発表しました。

NoCodeで資金調達まで走ってその後作り直すというのは、まさにNoCodeの正しい使い方という感じする。
"UnionはNocodeツールのAdaloを使用して作成されています。しかし、Nocodeで作成されたアプリは依然として速度、操作性の観点からUI/UXが劣るため今後はFlutterを用い..."https://t.co/kQvk7iEvN6

— gami@デジタル教育系YouTuber兼エンジニア (@jumpei_ikegami) April 3, 2021

このニュースには、NoCodeの素晴らしさと限界が現れていると思いました。

「NoCode」という言葉を真に受けると、「もうプログラムを書いたり、高いお金を払ってエンジニアを雇ったりしなくても、あらゆるアプリケーションが作れる時代になったんだ」という誤解をしがちです。

一方で、Unionのプレスリリースを読むと、「NoCodeツールを使った開発をやめて、エンジニアを採用してプログラムを書きます。そのために資金調達しました」という旨が書いてあるように読めます。

今回のnoteでは、そんなNoCodeの限界について考えます。

「NoCode」という言葉がもつ多様性

そもそも「NoCode」とか「LowCode」といった言葉は、かなりの曖昧さを持った言葉です。

この記事では、NoCodeの定義を次のようにおきます。

本来はプログラムを書いて開発するようなアプリケーションを、プログラムを書かずに実装できるようにすること

そこまで世間のNoCodeに対する認識とズレていないはずです。

一方、この定義をおいてみたところで、NoCodeという言葉の範囲はかなり広いままです。

まず、NoCodeツールによって実装できるアプリケーションには、かなりの多様性があります。社内で使う業務アプリや自動化アプリ、顧客に広く使ってもらうWebサイトやWebアプリやスマホアプリなどなど。アプリケーションを提供する対象も、その提供方法も様々です。

結果として、俗に「NoCodeツール」と呼ばれるようなソフトウェアにもかなりの幅があります。社内業務アプリ開発系だと、Airtable、AppSheet、PowerAppsあたりが有名です。社内業務の自動化では、Zapierが人気です。Webサイトの開発では、ランディングページのデザインに強いSTUDIO、CMS機能の強いWebflow、EC特化のShopifyなどがあります。（Shopifyは単なるサイト構築ツールの域を超えてますが。）また、Webアプリ開発のBubbleやスマホアプリ開発もできるAdaloなど、事業の根幹を担うアプリケーションを柔軟に開発できるプラットフォームも登場しています。（冒頭で紹介したUnionもAdaloで作られたアプリでした。）

ちなみに、NoCodeを大っぴらに謳っていないソフトウェアであってもこの定義によるとNoCodeに当てはまる、というケースがあります。Excelやスプレッドシートを使えば、簡単な勤怠管理アプリなども作れます。極端なことを言えば、僕が今使っているnoteだって、「昔はブログを作るにもコードを書く必要があった」と言い張ればNoCodeと呼べるかもしれません。

そんなわけで、NoCodeという言葉で表現されるものはとても広く、人によってイメージするものが全然違う可能性があります。たとえば、Zapierが好きな人とBubbleが好きな人でNoCodeの話をしても、すれ違いが起きる気がしてなりません。その点には注意が必要です。

今回のnoteでは、状況をある程度限定して、「一定期間使われ続けるそれなりに複雑なアプリケーションをNoCodeツールで開発する」というケースを想定して語ることにします。それが、まさに誤解が生まれやすい状況だからです。

NoCodeツールを使えば誰でも簡単にアプリ開発ができる？

NoCodeという言葉にまつわるマーケティングは、「NoCodeツールを使えば誰でも簡単にどんなアプリケーションでも開発できる」というイメージを広く植え付けることに成功しました。しかしながら、そこには明確な限界があります。

まず、「誰でも簡単に」という誤解について。

開発したいアプリケーションの複雑さが一定を超えると、たとえNoCodeツールを使ってもそれを開発できない人というのが出てきます。これを理解するためには、「プログラミング」という行為に対する解像度を上げる必要があります。

もちろん、NoCodeツールを使うために必要な知識量は、生のプログラミングをするときのそれよりもずっと少ないです。NoCodeツールを使えば、言語選択や環境構築で戸惑ったり、言語の特殊な仕様や罠に詳しくなったり、周辺ライブラリの知識を身に着けたりする必要は無くなるかもしれません。

一方、プログラミングでやるべき行為や必要な知識の一部は、NoCode開発でも依然として必要になります。データベース設計、繰り返し処理や条件分岐の設計、処理やユーザー行動の脳内シミュレーションなどなど。

たとえばNotionのデータベース機能を使いこなせることと、アプリケーション開発のためのデータベース設計ができることには、共通して必要なスキルがあると感じました。

このあたりの問題意識については、次のmizchiさんの記事にも書かれています。

ノーコードは形を変えた現代のRPGツクールなのではないか

ノーコードはプログラミングをしないことではない
テキストによるプログラミングは文字を書いたあとに、それがどう解釈/実行されるか？という処理系のセマンティクスへの理解が必要です。このセマンティクスを覚えることは、ノーコードでも一緒です。
イベントドリブンのエディタにも、RPG ツクールと同じように、真偽値の条件処理や分岐処理がありますし、フォーム生成系のバックエンドにデータベースを持つ環境なら、その表示には配列(またはリスト構造)と繰り返し処理の理解が必要になります。データベースの読み込み・書き込みは、抽象レベルでは変数の理解が必要です。逆に言うと、ノーコード経由だとしても、これらの概念を身に着けた人は、プログラミング言語を書ける素養が既にある、とも言えます。

NHK教育テレビの『テキシコー』は、「所謂プログラムを使わずにプログラミング的思考を育む」ことを目指した挑戦的な番組です。ここで挙げられている5つの思考は、NoCodeツールを使うときにも必要なものと言えるかもしれません。

1. 小さく分けて考える(分解)
2. 手順の組み合わせを考える(組み合わせ)
3. パターンを見つける(一般化)
4. 大事なものだけぬき出して考える(抽象化)
5. 頭の中で手順をたどる(シミュレーション)
（テキシコー - Wikipedia）

もっと踏み込んだことを言えば、個々のNoCodeツールというのは新たな高水準プログラミング言語に近い存在であるともいえます。NoCodeツールを上手に使えるということは、「比較的簡単なプログラミング言語が使える」ということと同義の可能性があるということです。そうだとすると、「世のプログラミング言語と比べてNoCodeツールは誰でも簡単に使いこなせる」というのは「C言語と比べてRubyは誰でも簡単に使いこなせる」というのとあまり変わりません。つまり、実際には「誰でも簡単に」使いこなせるというのは嘘であり、実際には一定の学習コストが必要になったり、人によって向き不向きがあったりするようなものだと理解した方がいいはずです。

NoCodeツールを極めればあらゆるアプリケーションを作れる？

じゃあ仮にNoCodeツールを使いこなせるようになったとして、あらゆるアプリケーションを作れるようになるのでしょうか？もちろん、NoCodeツール群は日々進化しているので、いずれは「そうです」と言える未来が来るかもしれません。しかし少なくとも現時点では、NoCodeツールであらゆるアプリケーションを作れるとまではいえないように見えます。

ここでは、ソフトウェアが持つべき要素に関する解像度を上げる必要があります。たとえばあるアプリケーションをあるNoCodeツールで開発するとき、当面の必要そうな機能はすべてそのNoCodeツールで実現できることがわかったとします。しかし、「当面の必要そうな機能」を実装することだけを考えると、抜け落ちる要素がいくつかあります。そのNoCodeが埋められない余白について、「非機能要件」と「技術的負債」という2つの言葉を題材に考えましょう。

ちなみにこれは脱線ですが、この「作れる/作れない」という分類自体にも実は2段階のレベルがあります。1つは「そもそもそのNoCodeツールを使ってどう頑張っても作れない」というレベルであり、もう1つは「めちゃくちゃ頑張れば作れるがコストが割に合わない」というレベルです。後者の例として、Excelを使ってドラクエ3を再現した人がいました。仮にExcelでドラクエ3が作れるとしても、途方もなく大変でコストが全く割に合わないとしたら、事業的な目線で見ると「Excelでドラクエ3が作れる」とは言えないことになります。今回は、これらを一緒くたに扱います。

非機能要件とNoCode

さて、主にシステム受託開発の世界では、「こんな機能が必要」というシステム要件のことを「機能要件」と呼びます。また、機能についての議論から抜け落ちる要件を「非機能要件」と呼びます。たとえば、顧客が「この機能群があれば大丈夫」と言ったことを真に受けてその機能群だけを実現する最低限の開発をした、という状況を考えます。そのとき、大抵はシステムができてから「操作性が悪い」とか「スピードが遅くて使い物にならない」みたいな話が出てきます。こうした「機能」ではない要素に関する要件を、非機能要件として可視化し合意するわけです。

NoCodeツールベンダーが「こんなアプリも作れます！」と主張するとき、当然フォーカスされるのは機能要件についてです。ユーザーの入力を受け付けられます、タグで絞り込みができます、リアルタイムでチャットのやりとりができます、などなど。

一方で、そこに抜け落ちる非機能要件もたくさんあります。たとえば、冒頭で紹介したUnionのプレスリリースでは、速度や操作性に関する指摘がありました。

また、UnionはNocodeツールのAdalo（https://www.adalo.com）を使用して作成されています。しかし、Nocodeで作成されたアプリは依然として速度、操作性の観点からUI/UXが劣るため今後はFlutterを用い日本だけなく、世界中の大学生に使用してもらえるようなアプリを共に開発できるエンジニアを積極的に採用する目的で、今回資金調達を行いました。

また、アクセシビリティを担保しようとすると、NoCodeツールの限界が見えることがあります。

Notionで構築された某社コーポレートサイトをみんなでスクリーンリーダーで読んでみる会が自然発生してた（あの手の海外サービスはだいたい lang="en" になっちゃってツラいのね）

— ymrl (@ymrl) April 2, 2021

もちろん、NoCodeツール側の進化によってこうした非機能要件に対する高い要求にも答えられるようになるケースはあります。しかし現時点では、「NoCodeツールを捨ててコードを書かないと十分に非機能要件を満たせない」という例が多く見られます。NoCodeツールが汎用的である以上に、現実のソフトウェアに対する要件というのは複雑かつ多様だということです。

技術的負債とNoCode

さらに、NoCodeツールを使って「当面の必要そうな機能」の実現を目指した結果、未来の視点が抜け落ちるということもよくあります。その問題を理解するために役立つのが、「技術的負債」という言葉です。一般に、NoCodeツールは技術的負債を生みやすいといえます。

「技術的負債」の捉え方にも色々とありますが、僕は広木大地さんのQiitaをよく参照します。

"技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita

ここでは技術的負債について、「不可解な開発速度の低下」を説明する言葉であると書かれています。

開発初期においては、今まで積み上げてきたシステムもなく、単純な機能であることが多いので、新機能の実装も比較的簡単に行うことができます。
しばらく開発を進めると、同じような要求をしているつもりでも、「時間がかかる」ようになります。今まで開発してきたシステムが、逆に制約となって考えないといけない範囲が広がるからです。

技術的負債を理解するための喩え話として、最近shindenさんという方から聞いた建築の喩えがわかりやすかったので引用します。

ただ2階建ての建物を作るのと、いずれ50階建ての建物をつくるつもりで2階建ての建物を作るのとでは、土台のつくり方が全然違う

当然、50階建てのビルを支えられる基盤と、2階建ての家屋を支えるだけの基盤では、必要なものが異なってきます。建築の世界では、だいたいは先に作るものが決まっていて、一度立てたらそこまで大きな改修はありません。一方でソフトウェアの世界では、「いったん2階建てで作ったけどユーザーが増えたから50階建てにしよっか」みたいなことがよくあります。そのときに「めっちゃ頑張ればできるけどすごくコストがかかるよ」というのが、技術的負債論でいう「不可解な開発速度の低下」です。

一般に、NoCodeツールはその拡張性に限界があります。建物の例でいえば、素早く2階建ての建物を作ることは得意でもそれを50階建てのビルに作り変えるためにはそのNoCodeツールを捨てた方が早い、という状況が多いです。

このことがよく分かっている人は、「最初に2階建ての建物を作るときだけNoCodeツールを使って、その後で事業が伸びたら作り直そう」とか「最初から大きくなるとわかっているならそもそもNoCodeツールを採用するのをやめよう」という判断をすることになります。

一方で、よく分かっていない人は、「NoCodeツールで2階建ての建物ができたなら、50階建ての建物も作れるはずだ。だからエンジニアは採用しないしNoCodeツール資産も捨てない」という間違った判断をしてしまいがちです。

現時点でノーコードに接するプログラマにとっての一番の地獄は、要件が膨らんで「ノーコードのビジュアルツールで作ったペライチを改造して、動的に動く部分を挟み込むなどして複雑なアプリにして進化したい」といったものです。きれいな出力構造を持っているものは稀で、大抵はサービス側に隠蔽されてるツールによって生成されたものに手を入れるのは、かなり厳しいものがあります。なので、基本的には、よほど要件をコントロールしない限り、本格的なものはゼロから作り直しになることでしょう。
（ノーコードは形を変えた現代のRPGツクールなのではないか - mizdev）

そんなわけで、NoCodeツールは銀の弾丸ではありません。明らかに適材適所で使い分ける必要があり、ときに「NoCode」という言葉は誇大広告じみています。それを理解した上で、正しくNoCodeツールを適用していく態度がとっても重要になります。

本当はNoCodeツールの良い使い所についても書こうと思っていたのですが、自分でも驚くほど記事が長くなってきたので、次回にこの続きを書きます。（よければnoteのフォローやマガジンの購読お願いします！）

（追記：後編も公開しました！）

以下、マガジン購読者の方向けのおわび。

すいません！次回は購入者限定コンテンツも盛々にするので期待しててください。