NoCodeツールでサービスを作ること

‍

はじめに

‍

最近、一部で話題のNoCode。プログラミングすることなくWEBやアプリの開発ができるとの評判ですが、はたして実際のところはどうなのかについてエンジニア目線で書いてみたいと思います。

‍

（この記事はあくまで「個人で試した範囲内での感想」になりますので、あらかじめその点はご了承いただきますよう、よろしくお願いいたします。）

‍

NoCodeは簡単

‍

これまでNoCodeツールを実際にいくつか試してきましたが、どのサービスでも簡単にアプリやWEBサイトを構築することができました。

‍

中にはデザイン性の優れたテンプレートが用意されているものもあり、それらを使って本格的な見た目のアプリを数十分で構築できてしまうものまであります。

‍

サービス開発の現場で採用できるか

‍

では、実際のサービス開発の現場においてNoCodeツールを活用できるかと言うと、その答えはノーだと思います。

‍

NoCodeにはいくつかの弱点があり、これらの弱点のために本格的なアプリの開発、特に中規模から大規模なアプリの開発には対応できない、もしくは採用されないのではないかと思われるからです。

‍

NoCodeツールの弱点

‍

NoCodeツールの弱点は以下のものがあげられます。

‍

（１）インフラ面での制限が多い。

（２）独自の機能を実装するには、WEBの専門知識が必要となる。

（３）バージョン管理など、大規模開発に向いた仕組みになっていない。

‍

これらは事業としてサービスを展開する上では致命的とも言える弱点だと思います。

特に（１）と（３）はサービス開発を続けていくうえで必要不可欠な要素となってくるため、現時点でNoCodeは選択肢にすら入れられないというのが個人的な評価です。

‍

‍

インフラ面での制限が多い

‍

NoCodeにはWebサーバを増やしたり、構成を変更したりするような機能がありません。

DBの容量についても「プランによる制限」がありますし、サーバのスペックについても同様です。そのため、サービスをスケールさせていくうえで取りうる手段が限られてしまい、実運用で使うのは厳しいと思われます。

‍

また、プロトタイプで動かしていくといった場合でも、その用途は「クライアントに動きを見せる」などの使い方に限られるのではないかと思われます。なぜなら、NoCodeで作ったプロトタイプからAWSなどを使った本格的なサービスに移行すると考えた場合、改めてサーバ台数や構成などを考えたり、バックエンド側のプログラムを作成したりしなくてはいけなくなるからです。

‍

一部ソースコードをエクスポートできるサービスもありますが、出力されたコードの品質次第では書き直す必要があります。また、エクスポート自体ができない場合はUI側も含めて一から作り直しになるリスクさえあります。

‍

もちろん、事前にエンジニアがその面について対策を立てておけばいいのかもしれませんが、その対策を立てる工数を割くのであれば、そもそも最初からNoCodeは採用しないほうがリスクも低く、効率も良いように思います。

‍

独自の機能を実装するにはWEBの専門知識が必要となる

‍

NoCodeでは、テンプレート通りのサービスを構築することが非常に手軽にできます。

‍

その反面、NoCodeの機能を組み合わせてテンプレートとは違ったことをしようとすると、途端にWEBの様々な知識が必要になってきます。条件によって表示を切り替えたい場合には分岐処理の理解が必要になりますし、データを保存したい場合にはデータベース関連の知識が必要になります。

‍

そのほか、NoCodeツール側で欲しい機能が用意されておらず、プラグインも存在しないといったようなケースもあります。こういったケースの場合、プラグインを独自に開発する必要が出てきますが、それにはプログラミングの専門知識が必要になります。また、独自プラグインでも対応できない場合には、機能自体を諦めなくてはならなくなってしまいます。

‍

サービスによっては開発の自由度が高いものもあるのですが、開発手順がどうしてもプログラミングのそれに近くなってしまうために、画面操作による手軽な開発のメリットがなくなるという問題もあります。

‍

これらのことを踏まえると、メリットよりもデメリットの方が目立ってくるため、NoCodeを採用する理由があまりないと個人的には思います。

‍

中規模〜大規模開発に向けた仕組みになっていない。

‍

NoCodeにはGitやSVNのような高度なバージョン管理機能がなく、中規模や大規模の開発ではそれが大きな問題になるかと思います。

バージョン管理が分からない方のために説明すると、

‍

・「バージョン」とは「ソースコードの変更履歴」

・「管理」とは「変更の差分を時系列等で保存すること」

‍

ざっくりと以上のように理解してもらえればと思います。

‍

‍

このバージョン管理の機能があることで以下のことが可能になります。

‍

（１）リリースした機能等に不具合があった場合、すぐに機能追加前の状態に戻すことができる

（２）どの機能がどの段階で追加されたのか、バグがどのようなコードによって修正されたのかを可視化できる

（３）複数人が修正したプログラムを矛盾がないようにまとめることができる

‍

逆にバージョン管理機能がないと、上記のことが実現できず、手元にあるのは常に最新版のソースコードだけになります。

‍

あらかじめバックアップを取っておくことで最新版以外のコードを保持することもできますが、（２）のように修正内容等を正確に確認することはできません。

‍

また、複数人で同じ箇所を変更した場合は一番最後の修正が採用されるため、他の人が行なった修正や機能追加がなかったことになってしまいます。

‍

‍

サービスによってはバージョン管理を備えたものもありますが、バージョン同士の差分を確認することができないなど、限定的な機能しか備わっていません。

‍

これでは、「複数人で開発にあたる上での十分な機能」を備えているとは言えず、中規模以上の開発では採用することができません。

‍

‍

機能系のNoCodeツールは組み合わせ次第

‍

‍

いっぽう、機能の一部をNoCodeで提供しているサービスもあります。

こういったサービスについては実際に試していないので正確なことは書けませんが、調べてみた限りにおいては活用できる可能性があるのではないかと思います。

‍

従来のやり方で開発されたアプリからの送信データを受け取って処理したり、それをきっかけにして他のサービスと連携させたりできるのであれば、サービスの中で一部だけNoCodeにするという選択肢は出てくるかもしれません。

‍

‍

まとめ

‍

以上、NoCodeツールを試してみた感想について簡単にまとめてみました。

ちなみに、コーポレートサイトや個人向けのWEBサイトなどをNoCodeで制作するというのは選択肢としてありだと思います。

‍

というのも、そういったサイトはスケールについて深く考慮する必要がなく、インフラ的な要件もそこまで厳しくないからです。また、基本的な機能や構成がそれぞれで大きく変わることもなく、NoCodeで用意されたテンプレートや部品で作りやすいのではないかと思われるからです。

‍

ITに限らず、ツールや技術はその特性を把握したうえで活用していくのが基本になります。

NoCodeツールについても同様で、それぞれのサービスの特徴を踏まえたうえでケースに応じて活用していくのがいいでしょう。

‍

‍

それでは、この記事がNoCodeの採用を考えている方々の参考に少しでもなれば幸いです。