ローコードもそうですが、ノーコードの盛り上がりも加速してきました。
ところで両者は「似て非なるもの」なのか、それとも「ローコード = ノーコード + プログラミングスキル」なのか。このブログを書いている2021年2月現在では、まだ混沌としています。今回は私の独断で、両者を分けるポイントを考察します。
「コード」の意味を深掘りする
ノーコードはコードを書かないというイメージが先行しますが、ローコードもビジュアルプログラミングを前面に出すことでノーコードのように振る舞うこともできます。そうすると一見、両者の違いはわからなくなります。
しかし現場ではユーザ自身が、両者を明確に使い分けているように感じています。
例えばノーコードツールは主に次のようなユーザ層を獲得しています。
- プログラムを書かずにスマートフォンの UI Design を行う。
- Google スプレッドシートなどのクラウド上にある「データ」をスマートフォンから操作するための定型アプリをつくる。
- 既存の Web サービスの API を連携した「業務処理」を行う。
最後の API 連携を補足します。多くの企業でクラウド型のサービス導入が進んだ結果、顧客データはCRMサービスにあり、社員データはHRサービスで管理され、経理データは経理サービスにあり、自社のECサイトは別にもっている、という状況になりました。それぞれのサービスは独立しています。これらのサービスを連携させるために RPA が注目されましたが、昨今のクラウドサービスは API を提供するようになってきました。RPA 利用より、API 連携の方が一層、安定していることはいうまでもありません。この API 連携に特化したノーコードツールも有効です。業務フローはビジュアルプログラミングで表現しやすい領域です。
さて興味深いことに、ノーコードを支持するユーザ層は、ローコードとは距離をとっているように感じます。そこには見えない壁があって、その壁を超えるのは自らの役割ではない、という制約を自らに課しているようなのです。
私は最初、その壁は「コード」だと考えていました。しかしノーコードツールといっても、実際にはプログラミングという工程を英単語を並べて書く代わりに、ブロックを並べるかの表現上の違いでしかなく、その本質である「論理的に手順を整理する」ことは変わりません。
そこで気づいたことがあります。両者を隔てる壁は、データモデリングではないかと。
誰もが避けようとするデータモデリング
多くのノーコードツールは、データモデリングが不要です。
まず UI Design はデータモデリングなしで可能です。（もちろん実際に動作するアプリケーションにするためにはデータ構造を意識する必要があります。そこを除いて UI Design だけを行おうとしている、という意味です。）
クラウドにあるデータ… Google スプレッドシートや、外部のサービスが管理している自社データ… は API を通してデータ操作するため、データがどういう構造になっているかを意識しなくてもよいです。A という形式のデータから必要な項目を取得し、それを B という形式のデータに変換して次のサービスに渡すのが連携です。データモデリングをしないとは、サービス提供者から与えらたデータモデルをそのまま使うだけということです。
そして多くのローコードツールは、データモデリングありき、です。
どういうデータを、どういう構造で管理したいのか。データモデラーにとっては、データモデルをみることで、そのシステムができること（業務フロー）とユーザの操作（UI Design）、そしてシステムの限界までもが明らかになります。システムの核になるのがデータモデルであるため、ゼロからシステム開発をしようとすると、データモデリングを避けることはできません。
しかし振り返ると日本のシステム開発史は2000年代に入って、いかにデータモデリングを回避するか、という呪縛にとらわれてきたようにみえます。
パッケージ型ERPは「業界のあるべきデータモデルを内包していた」ために、その採用によって自らデータモデリングを行わずに済むと思われました。Excelベースの業務がこれだけ普及しているのも、統合されたデータモデルを意識せず、自分の業務だけに必要なデータだけで済むため、わかりやすいのです。もちろんその代償として、他者とのデータ連携が面倒で、似たようなデータが重複・分散されていきます。RPA の普及も、業務フローだけを把握しておけば大丈夫というメッセージが込められていました。クラウド型業務システムの普及も、パッケージ型ERPと同じくデータモデリング不要です。API が提供された分、より連携しやすくなったという効果はあるでしょう。
なにもかも、いかにしてデータモデリングをやらずに済ませるか、ということにつながっています。ノーコードもその延長線上にあるのではないか、というのが私の直感です。
データモデリングは難易度が高いが、必要不可欠なテーマ
先日、私も参加しているIT勉強宴会で興味深い記事を教えていただきました。
この調査結果からいえるのは、"どの国もデータモデリングには苦労している" ことでしょう。しかしデータモデルの必要性を感じている組織が多いというのは、羨ましいことです。
一般のニュース報道で多くの人が聞くようになったデジタル・トランスフォーメーション (DX) について、識者がいろいろとわかりやすい説明を行なっていますが、これも私の独断でいえば
"データモデリングから逃げなかった企業だけが、DX のスタートラインに立つことができる。"
です。DX を支える基盤 - 核となる部分- はデータモデルであり、組織が自社で把握しているデータモデルの範囲内でしか DX の取り組みは行えません。言い換えると組織ぐるみで取り組む DX とは、すべてのステークホルダーが利用可能なデータモデルを把握することが出発点になります。
多くのローコードツールは、データモデリングありき、です。それがローコードツールを難しくみせているのかも知れませんが、難しいのはツールではなく、データモデリングの方です。
そしてローコードツールはデータモデリングを核としたシステム開発を支援するという立ち位置で良い、と考えています。その核の周辺に API 連携や、センスの良い UI があります。もちろんローコードツールはこれらの領域もカバーすることが求められていますが、データモデリング抜きでの実現はありえません。データモデリングを核と据えるのがローコードで、データモデリングなしで手早く実現を試みるのがノーコード、というのが現時点での私の解釈です。
最後に、当社も所属しているローコード開発コミュニティのリファレンスモデル分科会で興味深いイベントが行わることを紹介します。「新型コロナワクチン接種管理」を題材にした、本格的なデータモデルを各ローコードツールで取り扱ってみるというものです。私もWagbyで参加予定です。オンラインイベントなので、興味のある方は聴講してみてください。データモデリングに取り組もうという技術者層の一助になることを願っています。
