ノーコード・ローコードが解決してくれること、解決してくれないこと
メグリでプランニングを担当している篠キチです。
最近だいぶ落ち着いた感じはしてますが、ノーコードとかローコードみたいな言葉がずいぶん流行って、一時期は猫も杓子もノーコードみたいな雰囲気があったように思います。とりあえずノーコードって言っとけみたいな。知らんけど
あまり前面に出してませんが、弊社が開発しているアプリプラットフォームのMGRe(メグリ) も、実は内部的にはノーコード・ローコード化は結構進んでいて、かなり効率的にアプリをリリースできるようになっています。
もちろんアプリの場合はAppleやGoogleの審査があるので、公開してユーザーに届けるところまで自動化はできませんが、ノーコード・ローコードによる効率化がすすんだことで、昔に比べるとアプリを安価に提供できるようになったというのは事実だと思います。
ただ、ノーコードやローコードが解決してくれることというのは限定的で、これによってアプリを作るときにプログラマーだったりプロの手がまったく不要になるかというと、実際はそうでもなかったりします。
今回はアプリ開発の世界でノーコード・ローコードが何を解決してくれて、何を解決してくれないのか、そういったことを書いてみたいと思います。
ノーコード・ローコードは何を解決してくれるのか
まず最も大きい効果は開発の効率化と言っていいんじゃないかと思います。
ノーコードの環境というのは基本的にグラフィカルなUI（いわゆるGUI）を使って直感的に機能などを選んだり設定を決めたりできます。
これは、みなさんがイメージするプログラマの作業のように、文字ベースでキーボードからカチャカチャとコードを打ち込んだり（こういうのをCUI：Character User Interfaceと呼びます。一般的にGUIの反対語）、プログラミング言語を深く学ばなくてもとりあえず触ってみるということができるので、開発そのもののハードルを大きく下げる効果があります。これによって学習コストをおさえるというメリットも生まれます。
こういったノーコード化が進むと作業の効率化はもちろん本職のプログラマ以外に作業を分担することも可能になり、実は我々のような開発側にもメリットは大きかったりします。
もう1つノーコード・ローコードの大きなメリットとして挙げられるのは安定性ではないかと思います
ノーコードやローコードの環境では提供される機能や選択肢が限られているので、ベースのシステムに影響するような変更やカスタマイズはそもそもできないことがほとんどです。
開発側が想定されている変更しか起きないので、生成されるアプリも安定して動きます（そうでなければ元々のシステムが不安定ということなので）。
このメリットは意外と見逃せません。実際にアプリを使うお客様にとって、安定して普通に動くことは当然のことですし、ストレスなく使えるアプリが専門的なプログラマに頼らずに作れるとなれば、夢のような話に思えます。
ノーコード・ローコードは何を解決してくれないのか
ここであらためて、アプリを作るときの流れを整理してみます
いま流行（？）のChatGPTに「スマホアプリの開発の流れ」を聞いてみたところ
1. アイデアの概要を確定する:
2. プランニングと設計:
3. 開発環境のセットアップ:
4. バックエンドの開発:
5. フロントエンドの開発:
6. テストとデバッグ:
7. リリースとデプロイ:
8. メンテナンスと改善:
得られた回答を短く編集しました
という回答が返ってきました。だいたい合ってる。すげえなChatGPT（いまさら）
このうち、3.から6.にかけてはアプリ開発におけるノーコード・ローコード化の恩恵が確実に得られる部分です。
では、このプロセスに入る前にある1. と 2. の工程はどうでしょう。
前項で「ノーコードやローコードの環境では提供される機能や選択肢が限られている」と書きましたが、この機能や選択肢が限られているという制限が1. と2. の工程に大きく影響します。
これはどういうことかと言うと、そもそも作れるものがノーコード・ローコード環境で提供される内容に制限されるので、アイデアや要件を決めたところで、それを実現できるかどうかは提供されるノーコード・ローコード環境に依存していて、できないものはどう足掻いても作ることができません。
カンタンに言うと、望んだものを何でも作れるわけではないということです。
あともう1つ重要なことは、どんなアプリを作るかは自分たちで決めないといけない、ということです。1. と2. の工程はノーコードによって制約を受けることはあっても恩恵を受けられることはありません。
なにを当たり前のことを…と思われるかもしれませんが、ノーコード・ローコードの環境で作ると、自然といいものができあがると思い込んでしまうパターンは意外と多いです。
誰でも簡単にゲームが作れるという、いま思えばノーコードツールの先駆的な事例ともいえる「ツクールシリーズ」という製品が古くからあります。
自然といいものができるならこれで作ったゲームはなんでも面白いはずですが、実際はそうではありません。これと同じです。
ノーコード・ローコードの環境は開発のハードルを下げる手段を提供しているだけで、ノーコード環境がいいアプリや面白いゲームを自然に作ってくれるわけではないのです。
つまり、どんなアプリを作りたいか、何を作らなければいけないのかをちゃんと決めた上で、検討しているノーコード・ローコードの環境でそれが実現できるかどうかをしっかり評価する必要があるということになります。
その結果ノーコード環境で実現できることがわかったなら、これはかなりハッピーな話です。開発期間もコストも抑えられますし、何よりも多くの企業に使われた実績のある安定したサービス上で自社の要望をかなえられるとなれば、これを使わない手はありません
逆に、実現できないとわかったときに取れる選択肢はあまりありません。実際にはこの3つくらいではないでしょうか
別の実現方法を考える（検討していたノーコード環境をあきらめる）
ノーコード環境で実現できる内容に妥協する
ノーコード環境側で実現できるように対応してもらう
自社固有の要件をどう実現するか
先ほど挙げた3つの選択肢ですが、僕が担当者であれば1. を選びます。
2.もよさそうに思えますが、これを選んだ場合は妥協した点が永久に解決しない可能性を覚悟しなければいけなくなります。
なぜかというと、そもそもノーコード環境で提供されている機能は、多くの会社に使われることが想定できるとか、実際に要望が多いから用意されているわけで、用意されてないということはその要望がノーコード環境で提供可能にするには共通化が難しかったり、その会社固有の課題だったりしてそもそもマニアックな要望だったりする可能性が高いからです。
その場合、ノーコード環境を作っている側が、自分たちにとって好都合な機能をたまたま近い将来用意してくれることは望み薄です。
同じ理由で3.も難しくなります。ノーコード環境の開発費用を負担するのはノーコード環境を提供している側ですから、要望がその企業固有の課題であればあるほど、環境を作っている側が対応する理由も動機も薄くなります。
スケジュールや予算の都合でいったんノーコード・ローコードで作る選択をすることもあると思いますが、その妥協ポイントの重要度をきちんと考えておかないと、たいした期間も経ずにアプリを作り直すことになったりして、結果的に高くついてしまったなんてことも起こりえます。
企業にとって重要な要件であれば妥協の選択肢はありません。実現できる方法を選択する一手のみです。
ノーコードとカスタマイズの両立は可能か
そもそもノーコードに限らず、パッケージ型のソフトやSaaS型で提供されているサービスなどは「用意されている機能をそのまま使う」ことが基本になります。
利用する機能を選べたり、見た目を変えたりできるようになっていたとしても、それ自体が既成品の範疇で作り込まれた「機能」の1つに過ぎません。そこに選択肢として出てくるものが「できること」、出てこないものは「できないこと」です。
とはいえ、アプリ開発系のノーコード・ローコードのサービスや、標準機能をいくつも揃えているパッケージ型のソフトでも、追加のカスタマイズ開発を可能としているところは多くあります。弊社のMGReもそうです。
その意味ではノーコードとカスタマイズの両立は可能と言えます。
ただ、カスタマイズを実現するにあたっての制約や、実現方法についてはそれぞれ差があります。
1つの方法としてあるのは、もともと用意しているローコードのサービスやパッケージソフトを、カスタマイズを希望する企業専用に環境を用意してしまい、その環境内で個別要望のカスタマイズ開発を施してしまうというものです（そもそもこの方法が可能であれば、ですが）。
できあがったものは元のサービス・ソフトをベースにしていますが、その企業用に個別開発したアプリと同じような作りになります。
この方法の明確なメリットは、ベースとなるプログラムがあって、それをいじっていく形になるので、0からつくっていくスクラッチ開発と比べると開発期間・コストを大幅に圧縮できる可能性が高い点です。
またベースが安定していれば、それをカスタマイズして開発した成果物もそれなりに安定していることが期待できます。このメリットも意外と見逃せません。
デメリットは一般的に保守・メンテナンスのコストが0から作ったスクラッチ開発に近くなることや、元のサービス・ソフトが改良されたり機能追加があったりしても、独自にカスタマイズした部分の影響範囲がわからないため、利用できるようにするために追加開発が必要になったり、利用自体が不可能だったりということが起きる点です。
スマホアプリ開発の場合でいえば、AppleのiOSとGoogleのAndroidOSのアップデートに対して正常に動くかどうかの検証と、改修が必要になった場合の開発コストがすべてその企業負担になる可能性がでてきます。
このOSアップデートはここ数年は毎年必ず発生しているので、この負担についてきちんと確認・認識しておくことが必要です。
MGReはどうやってカスタマイズを両立させているか
ちょっとここから先はMGReのPRっぽい感じになってしまいますが、ノーコードとカスタマイズを両立させ、多くの企業に選んでいただいている理由がわかりますのでぜひお付き合いいただければと。
MGReの前身となるサービスのEAPでは、前項のように企業ごとに環境を用意して個別にカスタマイズを施すという方式を取っていました。
MGReはその方法を全面的に見直し、多くの企業に使われる機能を共通化しつつ、カスタマイズ開発のニーズが高いシステム連携・データ連携に関しては柔軟性を確保するというハイブリッドな構成に進化しました。
このあたりのことは弊社Webサイトに記事化しています。
この共通化された機能の部分を我々は“コア機能”と呼んでいますが、これがいわゆる「ノーコード」の部分にあたります。設定の自由度は高いですが、この部分をカスタマイズすることは基本的にできません。
ただ、システム連携・データ連携に関してはかなり柔軟性が高く、そのおかげもあってMGReは多くのECシステムやMA・CRMなどと連携実績があります。ここに挙げられていない製品であっても、API等のインタフェースが用意されていれば基本的にはカスタマイズ対応で連携が可能です。
また、ローコードやSaaS型のアプリプラットフォームでは一般的になかなか対応が難しかった各社SDKの組込みについても、企業ごとに必要なものをカスタマイズで追加実装できるようMGReのプラットフォーム自体を改良しています。
この柔軟性の高さがあるおかげで、MGRe製アプリにはクライアント固有のオリジナル機能を個別に追加することも可能になっています（カスタマイズ開発の費用は相応にかかってしまいますが）。
そのためChatGPTのところで書いたような、アプリでやりたいことが決まったときに、それを実現できる手段としてMGReはかなりの確率で要件を満たすことができるようになっています
それを表す象徴的な数値として、お取引のあるお客様の約半数がカスタマイズなどの対応を求めて他社製アプリをMGReでリニューアルしているというデータが出ています。
このようなカスタマイズ対応を実現できるハイブリッドなシステム構成を作ったり、SDK組込に対応できる改良ができるのは、弊社の開発チームの高い技術力や、先を見据えた準備ができる設計力が下支えになっています。
さいごに
という感じで、SaaS型のサービスで意外とノーコード化もされてるのにカスタマイズに強いアプリプラットフォームのMGRe。
それを支えるエンジニアはもちろん、セールスやカスタマーサクセスのスタッフもアプリに詳しい猛者揃いですので、どんなアプリを作ったらいいかわからないという感じの相談から、いまのアプリを入れ替えたいという具体的なご提案依頼まで、アプリに関することならなんでもお問い合わせください。
タイトル画像はぱくたそさんの「こつこつとプログラムの改修を行うエンジニアのフリー素材」を使わせていただきました。
