ノーコード/ローコード開発ツールのジャンル分けと、Wagbyの立ち位置について

今年は間違いなく「ノーコード/ローコード開発ツールがブレイクした」年、になるでしょう。マイクロソフト社による PowerApps のアピールが本格化したことと、アマゾン社の HoneyCode の登場が決定打です。グーグル社もすでに AppSheet を出しており、これで海外大手企業の製品が出揃いました。

奇しくも日経コンピュータの次回号ではローコード開発の特集記事が予告されていました。メディアの取り扱いも増えていると感じています。

ガートナージャパン片山さんのインタビュー記事は、現在の状況をよく整理しています。ユーザ企業は「パッケージか、手組み開発か」の二択ではなく、「ローコード開発ツールで開発」の選択肢が増えた、と感じているはずです。

www.atmarkit.co.jp

さてブレイクするのは嬉しいのですが、あまりにも選択肢が多いと開発者も混乱してしまいます。そこで大雑把なジャンル分けをしてみました。

誰が開発するのか 意図、目的 ジャンル 注意点
アプリを企画するデザイナー、起業を検討している方 プログラムは書けないが、スマホアプリやWebサービスのアイデアを実現したい。 NoCode イメージをまとめるのに役立つが、本格運用なら作り直しもいとわない。
社内の非エンジニア Excelに代わる、Web上のデータベースを探している。 NoCode 利用規模に応じた課金体系。複数サービス間のデータ連携はかえって複雑になる。
社内のエンジニア、SIer 業務アプリケーション開発の生産性を高めたい。 LowCode ツールの特徴に仕様を合わせる。仕様ありきだと生産性が落ちることも。

一点補足すると、"NoCode" といってもまったくプログラムを書かないわけではありません。ツールによっては業務ロジックを実現するために、何らかの関数やスクリプトを提供することは自然な発想です。また "LowCode" は通常、ツールがカバーしない範囲はカスタマイズが必要ですが、コード生成型か非生成かによってカスタマイズの方法は大きく変わります。実際の選定にあたっては、これらを意識しながら試してみるとよいでしょう。

ユーザのおかれた現状

視点を変えて、あるユーザ企業が抱えるシステム群を考えてみます。以下は架空の例です。

f:id:ynie:20200709093120j:plain
或る企業のシステム群

そもそも NoCode/LowCode の前に、パッケージの導入があるでしょう。最近はWebサービスも多いので、いくつかのサブシステムをWebサービスで実現した例としてみます。

パッケージではカバーできない、自社独自のデータ管理、業務処理が NoCode/LowCode の対象です。非エンジニアが NoCode ツールを、エンジニアが LowCode ツールをそれぞれ選定します。

f:id:ynie:20200709093211j:plain
パッケージ(Webサービス)を含めた構成

ところで、各パッケージが Web サービスのとき、データ連携のためには社内のシステムであってもパブリッククラウドにあった方がよい、ということになります。

f:id:ynie:20200709093248j:plain
パブリッククラウド化の対象

ここまでの図で問題になるのは次の点です。

  • システム全体の運用コストが高止まりする。各Webサービスや、クラウドベースのNoCode、LowCodeツールはおおむね規模による従量制課金。ユーザー数が多いほど月額利用料金が上がる。
  • データ連携の難しさ。それぞれ閉じたサービスは、一つ一つが独立したデータベースであり、マスタデータをもつ。マスタの統合はほぼ不可能なので、サービスごとにマスタをもつ前提で、API連携で整理するしかないが、サービスが増えるごとに複雑度は増していく。

もしかして、よくできた LowCode ツールでアプリケーションを開発し、全体をパブリッククラウドで運用すればいいのでは?という選択肢も検討できるのではないか。かつ、その LowCode ツールがアプリケーション規模で課金しない(ランタイムライセンス不要)なら、コストも十分、抑えられるはずです。

f:id:ynie:20200709093322j:plain
LowCodeツールでつくろうと思えば可能な範囲は広い

すべてを一つの LowCode ツールで開発するわけではなく、他のパッケージ(Webサービス)は残ります。それでも上の図は、自社で管理するデータの領域が広がっているので、ここをマスタデータとすることで管理も容易になります。内製化のメリットは「自社でコントロールできる範囲が広がる」ことです。つまり「生殺与奪の権を他社に握らせない」です。*1

Wagbyがカバーしようとしているのは、最後の図です。そのためにパブリッククラウド対応を進めてきました。分散データベースではなく、中央データベースを維持したままオートスケールやマイクロサービスを実現するアーキテクチャはエンタープライズ向きであり、ニーズがあると考えています。

*1:21巻まで、でましたね。ここから最終巻までが楽しみです。