[プログラム技術者の関心事①]
ノーコーディング技術の支援範囲と実装自由度はどのレベルなのか？
ノーコーディング技術を見つめるソフトウェア技術者たちの2つの懸念
プログラム技術分野に携わる人々が、ノーコーディング技術に初めて触れると、反射的に2つの懸念と心配をするようになる。 まず、コーディングが必要なくなったら、
① 自分の仕事と職業的地位はどうなるの？
そして
② 本当にコーディング作業なしで多様で複雑な実務用アプリを組めるということ?
自己の生業活動や社会的地位に直観した仕事で、第一のテーマにもっと敏感にならざるを得ないだろう。 そのため、ノーコーディング技術の現象をきちんと把握する前に、自分のコーディング作業の経験を基準に、予断したり拒否する態度を示す場合が少なくない。
しかし、この新しい技術、ノーコーディングを拒否するのか、あるいは受け入れて私も積極的に参加するのかどうかは、その実体をしっかりと知った上で決めても遅くない。 いや、もしかするとその実体を正しく知り、受け入れるとすれば、すでにこの分野で既得権を持っている技術者である自分にとって非常に有利な立場を先取りすることができるはずであり、もし防御したり拒否したりすれば、さらに論理的かつ体系的に対応することもできるだろう。 そこでまずは、その実体を正確に把握することが必要である。
以前のコーディング基準で見ると、ノーコーディングは制約の多い技術
コーディング作業に長年の経験がある技術者であるほど、ノーコーディング技術で今自分がC、Java、Pythonなどプログラム言語で実装するような複雑な機能や多様なUI/UXを実装することは不可能であるという先入観を持つことが多い。こうした疑問点を解消できず、ある程度ノーコードソリューションを検討してみても、いざ実際にプロジェクトを遂行する段階では、適用をあきらめるケースも少なくない。
このような先入観を持つようになったのは、既存のコーディング技術体系と経験を基準に判断するからである。 コーディングという技術が誕生してから、60年以上、人はややこしく複雑なコーディング作業を少しでも簡単かつ迅速に行う方法を模索することに集中してきた。 その結果、非常に多様かつ効率的な言語が出現し、統合された開発環境の提供やビジュアルなツールを採用するなど、発展してきたことは否めない。
しかし、今まで発展してきた方向は、コードという体系とコーディングという作業方式を前提に、既に実装しておいた産出物を再使用する方式に偏ってきたといえる。 そこで、Subroutine、Function、Class、Library、Framework、Moduleなどの形でプログラム言語や開発ツールを供給するベンダ社が基本的に使用するインフラを提供したり、自分に必要なオブジェクトを独自に制作しておき、必要なときにAPIの形で呼び出して再使用する方式で、時間とコストを節約してきたといえる。
このように再使用するために実現したオブジェクト(機能)は一様にCPU、Memory、保存装置、通信装置、運営体制などを作動させ、制御する方法と手続きを体系化して再使用する機能として作り出す方式を採択してきた。 もちろん、このようなアプローチは、繰り返される類似のコーディング作業を減らすのに、確かな効果があったのも事実である。
それにもかかわらずそのようなオブジェクトを活用して具現化する最終アプリは、そんなハードウェア装置内部の構造も異なり、処理することの概念や処理手続きが全く異なる、物事を表現し、人々の日常的行為を盛り込まなければならない。
それで、そのような世の中の事物や人間行為に近いように一つのオブジェクトに多様な機能を包括して作ると、実際に適用可能な対象が少なくなって実用的価値がなくなる。 結局再使用性を高めるために、ごく小さな単位の独立した要素機能をオブジェクトの形で作り出さなければならなかった。 その意味は、アプリで処理すること(作業)や、最終で作り出すアプリの機能構成よりは、ハードウェア動作メカニズムや機械的機能を制御する観点でオブジェクトを具現化してきたという意味である。 そのため、目的と用途が異なるプログラムを作るたびに新しいオブジェクトを作り出さなければならず、そのオブジェクト(API)の種類はすでに数え切れないほど多くなっており、それ自体が多くの努力を投資して学ばなければならない新しい対象となったのである。
今まで人類が発展させてきたコードという技術体系とコーディングとは、生産方式が生まれつき抱えている問題であるといえる。そのような構造的問題を解決せずに、ノーコーディング技術を実装するならば、当然適用できる対象や実装可能な機能に多くの制約があり、ユーザの立場からして非常に重要なUI/UX表現の自由度も大きく低下せざるを得なくなる。
適用する対象と実装可能な機能上に制約がなく、UI/UXの表現の自由度も高いノーコーディング技術を実現するためには、従来とは異なる新しい戦略やアプローチを選択しなければならない。 真の意味で、ノーコーディング技術を実現するためにはCPU、Memory、保存装置、通信装置などハードウェア装置の機能や動作手順などではなく、発想の転換を通じて作り出す最終アプリ製品の構成と機能の研究に集中する必要がある。
具現化対象の制約がなく自由度の高いノーコーディング新技術の出現
実務現場の様々な業務を処理するアプリ制作に特化したノーコードソリューションを作り出すために、次のような仮定をしてみる。
まず、産業現場で実際に広く使われている様々なアプリ製品の適用対象と機能構成を調査する作業から始める。そのように調査された機能と構成要素を体系的に分類し、項目別にまとめてアプリを制作するのに必要な部品をすべて導き出す。 そして、それぞれの部品の用途や処理機能及び動作方式等を科学的に研究し、汎用化及び標準化設計を行う。 また、UI/UXも実務現場で実際に使われている実態と操作する方式などを調査し、典型的な表現形式と作動方式のスタイルを作り、オプションを選択できるように設計する。
そして、設計された各部品の機能とUI/UXのスタイルを、いかなる状況にも適用可能にし、各部品間で処理手順と処理情報を共有するように設計し、万能共用部品形態で作り出す。 この過程を経て作られたすべてのオブジェクトを一つにまとめ、プラットフォーム形態で一括して事前に提供する。
また、アプリを制作したい人のために、先に提供されたそれぞれのオブジェクト(万能共用部品)を象徴するアイコンを活用して、自分が作るアプリ機能を構成し、動作する手順や UI/UX表現方式まで定義できるGUI方式のデザインツールを作って提供する。
そのGUI方式のデザインツールを活用すれば、今や人は自分が作るアプリに対する要求提起作業を、手軽なデザイン作業の結果物に置き換えることができる。 コーディング作業の一行なく純粋なGUI方式でデザインされた結果物には、アプリを作る際に必要な4大核心要素(①UI/UXの構成、②データ、③イベント、④プロセス)がすべて含まれることになる。
その結果物を分析して、アプリを実行するのに必要なデータベーステーブルを設計し、プログラム画面とUI/UX機能を具現化し、各イベント別に動作するプログラムも作成し、処理された情報をDBサーバーに保存、修正、削除などのデータ管理プログラムまですべて自動的に作成する人工知能(AI)製作エンジンを作る。
今まさに、ノーコーディング技術に関心を持ち始めている方であれば、これらの仮定がやや荒唐無稽な話のように思われるかもしれないが、既にそのような革新的なR&D戦略とアプローチを採用しているソリューション製品が発売されており、既に多くの人々が実務に適用している。
そのようなアプローチを採用したノーコードソリューションであれば、当然適用する対象と実装可能な機能に制約もなく、UI/UX表現でも自由度が非常に高くならざるを得なくなるだろう。 もちろんそのようなソリューションは、最初からアプリケーション製作のために考案されたものであり、システムプログラムや組込みプログラム開発のように、他の用途で使われることはふさわしくないだろう。
しかし、アプリケーションプログラムを製作する場合であれば、C、Java などの一般プログラミング言語のように実装する機能や、UI/UX の表現にも何ら制約がなく、実用的なアプリ製品を最も早く経済的に作ることができる。
私が選択するかどうかは関係なく、ノーコーディングはすでに時代的な流れ
従って、ノーコーディング技術？ソフトウェア技術分野に携わる者であれば、検討もしっかり行う前に、何らかの制約が多いだろう。 あるいは単純なプログラムモジュールしか作れないだろう。 何か間が抜けているだろう。 そのような先入観は、もはや果敢に捨てて傍観者や観察者といった立場から一日も早く抜け出し、本格的に最新情報を探し出し、合理的な技術を見出して学習しなければならない状況になったといえる。
近年の緊迫した経営環境の変化と社会的距離を置く政策の影響で、ソフト技術者やソフト事業者よりも先に、需要者である企業や機関からノーコーディング技術情報を習得し、一足先に採用し始めているためである。 そして、一部のソフトウェア事業者は、新しいノーコーディング技術の可能性をいち早く見抜いて採用することで、従来開発費の1/10~1/20水準超低価格でアプリ開発事業を開始したことで、問い合わせや注文が殺到していることが知られている。
かつては、あるITソリューション一つを選択する場合に、技術的な互換性、拡張性、発展性などについて多くの時間と費用をかけて検討し、また検討する過程を経て決定していた。 他のすべての購買品とは異なり、ITソリューションを購入する際には、経済性が技術的要素よりもそれほど重要な変数にはならなかった。 しかし、ここ数十年でIT分野の技術も飛躍的に発展し、大衆化·標準化され、15年以上続いたモバイル化現象により、全ての人がITとソフトウェアを日常的に体験する状況になり、今や市場の状況は様変わりしている。
特にノーコード開発プラットフォームとノーコッド技術まで一般化し、ソースコードの再使用や互換性、拡張性といったコーディング技術時代の基準は、もはや重要な判断の基準にはならず、他の多くの購買品と同様にソフトウェアソリューションの導入検討基準も、今や経済性と効率性が最も重要な選択の尺度となっているのである。
水が常に上から下に流れるように、ノーコーディング技術の導入可否はこのように費用や収益などのようなお金の問題である。 したがって、どの技術者や専門家がその技術を好むか否かに関わらず、この時代の大勢はすでにノーコーディング技術になったのである。 既にITソリューション市場を支配している非常に有力なグローバルベンダ社であっても、このような流れを遮ることはできず、どの技術者集団であってもそのような変化に逆らうことはできない状況である。
今日のように世の中のすべてが開放されて透明になり、すべての情報がリアルタイムで共有されている状況では、そのような情報とトレンドは瞬時に特定産業と市場の地形を変えてしまったり、特定の企業や個人の成功と失敗を分ける分水嶺にもなっている。
従ってソフトウェア技術分野に携わる者であれば、一日も早くノーコーディング技術を真剣に検討し、その技術と機会を積極的に活用する方策を模索することをお勧めするところである。
ノーコード技術ジャーナルは下記のような順序で記述されています。
最も良い方法は順番に読むことを推奨します。
1. [ノーコード技術] なぜ、今...「ノーコードプラットフォーム」ブームが起こっているのか？
2. [ノーコード技術] ソフトウェア産業従事者への深層情報提供が目的
3. [ノーコード技術] ノーコード技術とコーディングの根本的な違いは何か？
4. [ノーコード技術]ノーコードソリューションとローコードソリューションはどのように異なるのか？
5. ノーコード体制を実現するには、何を直すべきか？
6. ノーコードソリューションが、本当にCやJavaの代わりになるのか？
7. ノーコードソリューションの基本的要件は何か？
8. 「ノーコード開発プラットフォーム」が第4次産業革命のエンジンである理由
9. エンタープライズ・ノーコード・プラットフォームの選択基準
10. ノーコード開発プラットフォームは、実務用プログラムの制作に制約のない技術選択が必須