１．現状と予測
米国の調査会社ガートナー社の調査では、ローコード開発の市場は2021年に1兆円近く予算化されており、2020年から2021年にかけて22.6%増加するとあります。
そして、これはローコード界隈の記事ではよく引用されていますが、ガートナー社の予測では、2024年までにシステム機能のうち65%がローコード開発によるものになるといわれています。
海外はもとより、日本の大手企業も積極的にこれらの技術を取り入れていっています。
「ローコード ノーコード 採用」と検索すれば、多くの事例をみることができます。
とはいえ、日本はまだまだ採用は少ないですが、それも徐々に増えていくと思われます。
若い世代を中心に、ノーコード・ローコードでのシステム開発がみられるようになり、これから起業するときにこれらの技術をベースにする人達も増えると思います。
２．ローコード・ノーコード企業の資金調達状況
実際、市場予測は、投資を促進させるためにも見えます。仮に意図的にそうさせられているにしろ、この市場にお金があつまり、米国を筆頭にこれらの技術を採用することが増えていっているのは確かだと思います。
３．DBの操作、通知などの作り方はパターン化している
Web、スマホ、ローカルアプリで作られる機能の大半は、DB操作や通知の機能が大半です。Webにしても、Yahooジャパンや楽天が創業した1996-97年ぐらいから2021年の間にこれらの開発手法は変われど、実現されている機能はそう変化はしていません。
つまり、ここについてはほぼパターン化しているといってもよいと思いますし、こうしたパターン化があるからこそ、ローコード・ノーコードなどのサービスやツールが生まれているのだと思います。
４．ソフトウェア開発は工数がかかる、学習コストが高いので人材が不足気味
コーディングでの開発、すなわち、スクラッチ、または、プロコード開発においては、少しの機能を実装するだけでも工数がそれなりにかかります。
まして、ゼロからインフラをつくり、アプリの画面、DBをつくり、それのモジュールを連携するコード、そして、その機能を担保するテストコードなどを書いていくと恐ろしく工数がかかります。
ユーザーニーズを汲み取るのも中々難しく、作ったはいいけど求めているものと違うと言われることも多いと思います。また、アジャイル開発で小さく作っていけばそうしたミスマッチも減りはしますが、逆に、開発は長期化してコストは上がります。
もちろん、それを作る学習コストも高いので、人材を集めるのも大変で、人材不足がよく叫ばれています。
こうしてみてもソフトウェア開発は、工数も高いし、人材を集めるのもコストが掛かります。そもそも人材が不足している有様です。
５．ユーザーサイドは予算と工期を縮めたい⇒工数とのギャップ⇒炎上
一方で、ユーザーサイドからすると予算を少なく、工期は短くという思考が働き、往々にして契約時には予算や期間は削減されています。
資産や時間が無尽蔵ではないのでそれは一面仕方のないことだとも思います。
ただ、どうしても工学的にかかる費用はかかり、予算や工期とのギャップがそのうち顕在化し、「炎上」案件へと発展します。
６．アジャイル開発など人の動かし方だけでは制約された状況での開発は難しい
「炎上」防止策として、アジャイル開発により、製造やリリースを細かく区切り、比較的細かい期間での開発をしていくことがあります。
アジャイル開発は本来多くかかる工数にあわせていく開発ともいえます。たとえば、小さく区切って情報を蓄積しながら進めていく過程は当然それなりに時間がかかります。ただ、これは間違っているのではなく未知の課題に対しては当然な方法であり、本来あるべき進め方なのだと思います。つまり、未知の部分が多ければ多いほど開発は工数がかかってしまうものなのです。
一方で、ユーザーはその状況を理解はしながらも低価格で、早く利用したいのにできないという不満を持ちます。その難しい状況を解決してくれるのが「プロ」だろうという意識もあります。
両者のギャップを埋めるためには、少しでも無駄な工数を下げた開発が求められます。工数がかかる手法をとっていたのではこれは解消できません。
７．内部設計視点の機能はローコード・ノーコードに外注する
このようにスクラッチ開発はコストがかかるけれど、ユーザーサイドはそのコストを削減したいというギャップがあります。
これがローコード・ノーコードが求められる背景にあると思います。
ローコード・ノーコードはパターン化した機能を比較的、少ない工数で形にするツール・サービスです。
スクラッチ開発をしていると同じようなことを何度もすることがあると思います。それもまた、工数になるわけですから、できれば同じことは繰り返さず、その工数を削減すべきです。
スクラッチ開発でもコードの再利用などをしていくと生産性は上がっていきます。ローコード・ノーコードのサービスやツールは、外部の専門家にこうした蓄積を委ねるということでもあります。
ソフトウェア開発の設計では、ユーザー視点の外部設計、開発者視点の内部設計がありますが、内部設計については、繰り返しも多いし、どんな分野でも使えるモジュールを作ることができます。つまり、内部設計は、社会全体で共有しやすい部分ともいえます。
この内部設計視点のモジュールはノーコード・ローコードのサービスやツールに委託し、外部設計に関する開発（ビジネスロジック）に集中するほうが工数は削減できます。
８．プロトタイプを早くつくり仕様認識をユーザーと合わせる
ローコード・ノーコードの特徴としては、GUIアプリをすぐに作れる部分もあると思います。スクラッチ開発でも、モックアップをつくり、設計を進めていきます。
ローコード・ノーコードの場合、単なる見た目や画面遷移より、データの更新など機能に近い部分も早く形にすることができます。いわば、プロトタイプを早く作れるといってもいいと思います。
こうしたプロトタイプをベースにユーザーとの仕様認識を合わせていくことで、設計の精度も上がっていくと思います。
９．属人的・人治的になりがちなスクラッチ開発では工数削減、人材不足解消は難しい
スクラッチ開発はライブラリやフレームワークを使ったり、一般化した設計や開発手法で属人化は下げられていってはいます。ですが、日々変わる技術により、どの時点の技術を選択したかによって、情報の非対称性は生まれます。
もちろん、ローコード・ノーコードでもそれは生まれますが、スクラッチ開発の場合、この情報をキャッチアップする時間がかなりかかります。
最近は、異なるライブラリやサービスを連携することが多く、ある人にとっては既知のものでも、別の人に取っては未知のものであることはよくあります。
部分そのものはオレオレでないにしても、構成がオレオレになることもあり、時にそれは引き継ぎに時間がかかることにもなります。
炎上回避のプロジェクト進行方法として、アジャイル開発がよく言及されます。
アジャイル開発は、問題ごとに機動的に動くということがベースにあるため、ある一定水準の能力をもった人の能力が求められています。そのような人材が豊富にいるのであれば、世の中の問題は起きてないかもしれません。
属人的・人治的な側面が強くあるとそのための人材が必要になり、その人材の確保自体が難しいため、問題解決は困難になるのだと思います。
ノーコード・ローコードを利用することで、これら属人的な・人治的なものがなくなるわけではありません。ただ、ツールにより人の関わりを少しでも排していくのがノーコード・ローコード開発の姿です。
開発の手続きがツールのおかげで汎用的になっています。また、マニュアルも用意されているので、教育しやすく学習コストは低く引き継ぎはしやすいです。
アジャイル開発については、ノーコード・ローコード開発でも採用すべきです。むしろ、ノーコード・ローコードだからこそ、形を早く見せてユーザーとの効果的な対話を実現できます。
１０．開発者が率先してDXを実現する
米国をはじめとして海外ではノーコード、ローコードへの投資が増え、それに従って開発現場での採用も増えていっています。
日本では、まだまだ採用は少ないですが、大手企業が旗振り役となり導入が進んでいます。
上述したようなスクラッチ開発の弊害は至るところで聞きますので、合理的な経営者であればノーコード・ローコードの採用を検討するのは当然かと思います。
こうした採用が進む背景には、ただ問題があるからだけでなく、ソフトウェア開発で実現することがパターン化していることも指摘できると思います。パターン化すれば当然、再利用可能なものが作れます。
Webが普及してから考えても20年近くたっているわけですから、こうしたパターンを元に便利なツールができるのは当然なことだと思います。
その一方で、インフラやOS、端末の変化は激しく、最近はいろいろな機能をコラボレーションするのが一般化しています。そのすべてをスクラッチ開発していたのではいくら工数があってもたりませんし、実際は、予算や工期自体が制限されているのです。
適宜、サーバレス、ノーコード・ローコードを使い、内部設計部分は外注し、外部設計・ビジネスロジックに資源を集中していかざるを得ないのだと思います。
ノーコード・ローコードは、単に好事家の遊び道具ではなく、ソフトウェア開発の社会的分業が必要とされるなかにあって、採用されるざるを得ないものな気がします。
まだまだ、ノーコード・ローコードですべてのことが実現できるわけではなく、パターン化された分野以外は、スクラッチ開発が引き続き必要になると思います。
どの分野はノーコード・ローコードで実現できて、どこはスクラッチ開発をしないといけないかの線引ができるように、プログラマーも日頃から幅広くツールを触っておくことがよいと思います。
そのうち、それぞれ分業化して、ノーコード・ローコードしかしらなくてもアプリやシステムが作れてしまうような分野もできると思います。
日本はかなり、ノーコード・ローコードの採用が遅れていますが、ソフトウェア開発者自身のDX(Digital Transformation：デジタル化を採用することによる行動・状態の変化）が急務であると思います。
開発者がDXしないと社会全体はDXしないように思います。
１１．これからのSIerは「システム」ではなく「社内オペレーター」を作り、「顧問化」していく
よくノーコード・ローコードの話をSIerの経営者と話していると、「便利な技術ができるのはわかるけれど、我々はどうすればいいのだろうか」という相談を受けることがあります。
個人的な意見としては、便利なものをつかうことでスクラッチ開発のエンジニアの必要性はある分野では少なくなっていくと思います。
そして、一度ノーコード・ローコードやSaaSで業務システムを組んでしまえば、社内の情報管理部署の人たちで運営できることも増えていくと思います。
SIerは、作ることより、運用設計、導入、マニュアル作成、トレーニングという業務を担うことが増えていくと思います。要は、システムそのものを作るよりは、顧客企業内のオペレーターを教育したり、相談をうける顧問化していくことが増えていくと思います。
また、SaaSは一度いれれば放置していいものでもなく、新しいサービスリリースや機能廃止、メンテナンスなどのアナウンスをうけて対策をとる必要もあります。
こうした運用情報の管理などもSIerの仕事になるかもしれません。
いずれにしろ、SIerは、システムそのものを作ることは減ってくるかもしれないが、顧客企業内のオペレーターを作ったり、ユーザートレニングをしたり、相談をうけたり、運用情報を提供するという業務が増えると思います。
保守契約というよりも、「顧問契約」をしていく企業が増えていくと思います。
１２．プラットフォーム化したSaaSやノーコード・ローコードの利用が増えると、クラウドインフラの資格保有者のニーズが高まる
個人的に、実際、ノーコード・ローコードを導入している大企業の現場をみていると、MS365やGoogle WorkspaceなどのSaaSプラットフォームをベースに、それの上にノーコード・ローコードツール(MS：PowerAppsやPowerAutomate、Googel：Apps Script、AppSheet）でカスタマイズアプリやRPAの仕組みを作るほうが連携コストが少なくてよいなと感じています。
ピンポイントにノーコード・ローコードのサービスを使うよりは、プラットフォームにより基盤を整備して、それらと連携しやすいノーコード・ローコードを作るのがベターなように思います。
要はなんでもゼロからつくらない、あるものをうまく使い、連携するというのがこれからのソフトウェア開発の一つのお作法なのだと思います。「作る」一辺倒ではなく、「使う」ことを最初に考え、「作る」は最後の手段。
ある程度、アプリの連携が取れたプラットフォームをベースにシステムを作ることが、結果的に情報処理の工数を下げていくように感じます。
表計算ソフトを保有するMicrosoftのMS365・Azure、Google Workspace・Cloud Platformが最も有力な候補であると思いますが、企業や個人の資格取得は増えていくと思います。
AWSについては、パターン化しない新規分野、デザインなどがパターン化していないコンシューマー向けの分野において、スクラッチが続いていき、そこでは引き続き多く採用されていくと思います。
ちなみに、Googleのスプレッドシートもオフライン実行できるので、利用内容によってはExcelに劣らないと思います。
１３．量子コンピューティング、光インターコネクトという技術革新がよりAI利用を加速し、アプリ開発はスクラッチでは追いつけなくなる
量子コンピューターもそろそろクラウドを介して実用化される可能性がみえてきました。実際、2021年現在でもある程度のお金を払えば、クラウドを介して量子コンピューターを利用することはできます。数年後にはより低価格で、幅広い人達が利用できるのではと思います。
GoogleやMicrosoftは量子コンピューターの分野では先行していましたが、Amazonも参入し、ビックテックがこの領域を開拓していくと思います。
記事から予想するに2025年あたりから徐々に利用も増えていくのではないかと思います。量子コンピューターにより計算速度が飛躍的に向上し、AIの利用も更に進むのではないかと思います。
さらに、技術的な革新としては、光インターコネクトという技術により、端末内の通信が低電力・高速化することで、バッテリーや機器の小型化が実現し、計算処理の加速化をより進めていくのではと思います。当然、この分野にもビックテックが参入しています。
2025年といえば、今から4年後ぐらいで、そう遠い未来ではありません。しかも、すでにビックテックは投資を始めており、実用化も夢物語ではないように思います。
こうしたハードの革新がAIの利用を更に進めることになり、ソフトウェアに求められる機能は増えていくと思います。技術的にそれが可能になる以上、それは当然のことかと思います。
こうした多様化する機能をスクラッチ開発でしていたのではおそらく追いつきません。こうした背景があるからこそ、ノーコード・ローコードなどの技術は今投資されているのかもしれません。
これらの効率的な生産性を手にすることで、より高度なソフトウェアを短期間で作成することができます。
AIの利用はもとより、ノーコード・ローコードでの開発は、5-10年後には特別なものではなく、ソフトウェア開発者として当たり前のように触れるべきものであるように思います。
１４.スクラッチ開発の今とこれから
コーディングを主体とするスクラッチ開発は今後もなくなることはありません。パターン化していない新規分野、開発者やユーザーが少ない分野では引き続き、スクラッチ開発は続いていくと思います。
また、ノーコード・ローコードのサービスそのものもやはりスクラッチ開発に支えられることが多くなると思います。
ところで、スクラッチ開発と一言でいってもその様相は千差万別だと思います。実際は、現在でも、スクラッチ開発とはいえ、フレームワークやライブラリをつかい「ローコード化」しています。一昔まえのようにアセンブラやC言語を使って開発していた頃に比べれば、格段に「ローコード化」しています。
一方、現在の「ローコード」が意味するところは、単純にコードが少ないというだけでなく、それらを実行させるインフラがすでに用意されていると考えた方がよいと思います。そのインフラ自体は、GUI操作、すなわち、ノーコードで設置し、部分的にその中にコードを埋め込むことが最近いわれる「ローコード」なのだと思います。
ただ、今は過渡的なので、このように線引はできますが、そのうちこの線引すら難しくなり、スクラッチ・ローコードの境はほとんどなくなると思います。
もちろん、本当にアセンブラやCなどをつかってスクラッチでゼロからつくる分野も引き続き存在するでしょうが、多くの分野はノーコードで完結するか、それらをベースとして少しカスタマイズするためにローコードで対応するとなるのだと思います。
これから量子コンピューターが作られてくればまた、スクラッチ開発の領域も増えるかもしれませんが、デジタル開発で培ったノーコードの発想はすぐに、量子コンピューターのプログラムにも導入されていくと思います。
結局は、ツールそのものより、「ノーコード・ローコードという発想」がこれからより強くソフトウェア開発では考えられるようになるのだと思います。実は、形は違えどこれまでもフレームワークやライブラリという形をとってそれは行われてきており、その表層が日々変わってきてるだけなのだと思います。
スクラッチ開発だからといって工数をかけたい訳ではなく、たまたま目的に合致する手法がないからそうしているだけにすぎません。楽をできるのであれば楽をするのが人の常でしょう。
１５．ICTビジネスの下剋上が活発化するかも
これまでみてきたようにノーコード・ローコード開発は工数削減、人材不足に対して有効な手段になると思います。米国を始めとする海外で投資が集中しはじめているのは、こうした理由があるからだと思います。
ノーコード・ローコードを使うことで、内部設計部分の工数は下げられ、ユーザーが触れるプレゼンテーション部分、ビジネスロジックの部分へと工数を集中することができるようになります。
そして、ユーザーにとっては多機能なサービスを享受できるようになるかもしれません。
結局、ビジネスはユーザーに選んでもらわなければ成立しえません。いくら裏側ですごい人材をたくさんつかい、お金をかけたとしても、ユーザーが触れる部分にアピールするものがなければビジネスは消滅してしまいます。
逆に、ユーザーが見えない部分を少人数で、ローコード・ノーコードでつくって簡素になっていたとしても、ユーザーが操作する部分やサービスそのものに価値があれば、ビジネスは成立します。いや、赤字が減るのでよりビジネスは発展するでしょう。
現在、多くのICTサービスを提供している会社があります。その人件費やインフラ費用はかなりかかっています。その資産がやがて「負債」となる会社・分野もあるかもしれません。
後発で、よりユーザーにとって受け入れられやすいサービス・アプリを、ノーコード・ローコードで早く、低予算、少人数でつくる企業もでてくるかもしれません。
これまでもSkypeがLINEやSlackに負けてしまったように、サービスの下剋上は常に起こりますが、ICTビジネスにおいては、ノーコード・ローコードをうまく使うことでこうした下剋上が活発化するのかもしれません。
アイデアや人とのつながり、オンラインだけでは手に入らないものを知っている起業家が、早く・安くアイデアを形にして新しいプレイヤーになる日もそう遠くないのかもしれません。
これからの起業家こそ、ノーコード・ローコード、そして、サーバレスなどを意識して、ユーザーにとって意味があるビジネスプランを早く形にしていくべきなのだと思います。社会的にもそれは歓迎されることだと思います。
１６．SaaSはクラウドプラットフォームの上に存在するようになるかも（下剋上の可能性）
今、会計、タスク管理、ECサイトなど独自のインフラの上で稼働しているSaaSが多くあります。
これらのサービスは便利なのですが、機能ごとに別々の会社とサブスクリプション契約をすると管理やコストの問題が出てきます。
一方、前述したMicrosoftのMS365、GoogleのWorkspaceなどのクラウドプラットフォームをベースとして使い、PowerAutomate/PowerApps、AppsScript/AppSheetで足りない機能を補うということができます。
現在、クラウドプラットフォームのパートナー企業も増えており、これらのプラットフォーム上でシステム、アプリを作ることも多くなってきています。
そうなると、SaaSで存在していたものをクラウドプラットフォーム上で実現して再販してくる企業もでてくると思います。ライセンス・アカウントもクラウドプラットフォームのものを利用し、支払いもクラウドプラットフォームに支払う。
そうなると、SaaSの管理は簡略化し、費用も下がっていく可能性があります。
MS365ではこうしたサードパーティーのアプリのマーケットがすでに存在しますが、請求やライセンスが一括管理できるのであれば、「SaaS on Platform」の形は広まるかもしれません。
ここでもサービスの下剋上が起きるのかもしれません。
１７．ノーコード・ローコードならフリーランスでも仕事を請けやすい分野もあるかもしれない
前述の章で、スクラッチ開発を一人、ないし、少人数ですることをするのは限界があるという記事を掲載しました。
実際、スクラッチ開発を一人で請け負うことは不可能に近いと思います。
ですが、ノーコード・ローコードであれば、かなり工数を削減できますので、対応できる分野も増えるかもしれないです。特に、MS365やGoogleWorkspaceの環境構築や問合せ対応ぐらいなら、一人でも対応できる範囲だと思います。
SIerが顧問化するという話をしましたが、フリーランスもシステム顧問としての道があるのかもしれません。
ただし、ソフトウェア開発をする場合、ノーコード・ローコードとはいえ、要件定義、設計、テストなどは必須になりますので、そこの工数も考えたうえで事業をする必要があります。
顧問ぐらいであれば、そこまで工数はかからないと思います。