手軽に台帳の作れるノーコードシステム「NocoBase」

アプリケーションのレビューと説明の第二弾です。

CassetteOSに入れるいい感じのノーコードがないかなと考えていて選択して、自分でも使ってみました。

NocoBaseについては、前弊社でもレビューしたりいじったりしています。

スケーラビリティ優先のオープンソースのノーコード開発プラットフォーム「NocoBase」

オープンソースノーコード「NocoBase」が日本語対応されました

こちらも併せてご覧ください。

バックオフィスとLCNC

CassetteOSではまずはバックオフィスにあると便利そうなソフトウェアを揃えたいと思っています。

その中でやっぱりお手軽にアプリっぽいものが作れる何かがあったら嬉しいかなと思って、以前紹介したLCNC(ローコードノーコードのことをこう表記するらしい)の中から簡単に使えそうなものを選定することを思いました。

こういったことを考えた時に必要とされるシーンを考えると、がっつりしたアプリを作ると言うよりは、「ちょっと便利なアプリっぽいもの」が出来たらそれで十分かなと思います。がっつりしたものは、ちゃんと作られたアプリがいくらでもあるだろうと思いますし、なければ

餅は餅屋

と割り切って作ってもらうのが間違いがないと考えています。下手に素人が工夫して大システムを作ってしまうと、後々面倒なことが起きてしまいますから。

逆に、ちょっとした表計算でやりたいことであれば、下手に何か持って来るよりはExcelを使えば十分だと思います。 Excel便利ですよね。その便利さを越えるツールはなかなかないと思います。

この用途でのExcelの良さと言えば、

割と誰でも使える
ファイル単位でハンドリングできる
雑な使い方に耐える

じゃないかなと思います。ある意味、これこそがビジネスに求められるLCNCの姿だと言えなくもありません。もちろん欠点とか足りない点もありますが、それらを補ったシステムがこれらの「良さ」のトレードオフとできるかと言えば、なかなか難しい… と言うのが、LCNCの選択の難しさではないかと思います。

そこで今回LCNCを選択するにあたって、以下の要件を考えました。

ExcelやAccessに機能では対抗しない
アプリ開発をゴールとしない
雑な使い方に耐える
機能豊富よりも簡単でわかりやすいこと
必要十分な日本語対応があること

です。

AirTable系使うくらいならExcelの方が楽

ExcelやAccessに対抗しないとなると、この延長とされる「AirTable系」のものは残念ながら軒並アウトです。具体的には、 NocoDB, Grist, Baserow は軒並ダメです。

いずれも悪くはないものですし、「わかっている人」にとっては使いでもあって良いのですが、「お手軽にごにょごにょ」という感じにはちょっと遠いようです。

個々の具体的なレビューを書くと長くなってしまうので割愛しますが、本家AirTableも含めてこれらAirTable互換品は他のものも同じで、「しょせんDBに皮かぶせたもの」に過ぎません。ですから、DB設計や運用にある難しさ面倒さから逃れられません。

Excelも本来「正しく」使えばそんな感じのものだったはずですが、Excelを使う時にそんな「正しさ」はあまり意味を持ってない… ってことはわかってると思います。「表も描ける方眼紙」あるいは「だいたい表だけど時々変なものが混ざってる」というのが、普通のExcel表の姿でしょう。そして、それは結構手軽で便利です。

この便利さをAirTable系のアプリは全く継承していないので、難しさと覚悟(潔さ)が求められてしまい、手軽に使うには難しいところです。

これらAirTable系のExcelに対する強みは、「表が大きくなっても大丈夫」というところなのですが、CassetteOSがターゲットとする層がそこまで大きなテーブルを使うことが頻繁にあるかと言えば、それも考えにくいところです。そして、大きなテーブルを使わないのであれば、全てがインメモリとゆーか「イン・シート」で完結するExcelの方が扱いやすくて便利です。

わかって使う分にはどれも良いものではあるので、将来はこれらもアプリストアに置きたいと思いますが、「まず」というところではちょっとね、という感じです。

アプリ開発系はハードルが高い

過去にレビューした Budibase, appsmith, ToolJet あたりは、「アプリを手軽に開発するもの」として作られたものです。これらは悪くはないのですし私は個人的に好きなのですが、「お手軽ごにょごにょ」という観点ではハードルが高いです。

今回この調査のためにあらためて私がBudibaseを使ってみたのですが、

機能が用意され過ぎててどれを使えばいいか混乱
初めて起動してから使い始めるまでが遠い
いろんなものが細か過ぎてよくわからない
そもそもメニューもヘルプもドキュメントも日本語化されてない

ということで、採用を断念しました。このうち「日本語化」に関してはBudibase固有の問題とも言えますが、どれも大差ないとも言えます。

またBudibaseは結構便利に使えたということもあって、「日本語がないなら作ればいい」「NocoBaseの日本語化も旧弊社でやった」というのがあるもので、「じゃあBudibaseの日本語化もやればいいじゃん」と思ったのですが、そもそもBudibaseは国際化について1ミリも考慮されてなくて、まずはそこから始めないと手がつけられません。

この他の項目は全ての共通です。どれも機能が豊富過ぎて、逆にハードルが上がっています。確かにプログラムを書く必要はありませんが、その分機能が「用意」されています。ですから下手すると「想定されているアプリの種類だけ機能がある」状態です。

それとは別の話として、これらは「アプリ」を作ります。そのためのものですからね。これが「ごにょごにょっとお手軽アプリ」のレベルであれば良いのですが、どれもがっつりしっかりアプリ開発です。ちょっとハードルが高いです。

推しは？

そういったことで、「CassetteOSに最初から用意されているLCNC」という観点で選ぼうとすると、世の中のLCNCは「ほぼ全部ダメ」になってしまいます。多分これはOSSに限らず、現代のLCNCの限界じゃないかと思います。これを克服するには、AIアシストのLCNCということになるのでしょう。

その中でギリギリ採用してもいいかなというのが、今回紹介するNocoBaseです。

NocoBaseについて

NocoBaseについての紹介は、旧弊社の

スケーラビリティ優先のオープンソースのノーコード開発プラットフォーム「NocoBase」

に書いています。日付けを見るとちょうど3年くらい前ですね。

基本的にはあの頃と大きな変化はありません。ただ、あの時「まだ開発中です」だった機能が実現されていたり、AIがついたりという順当な進化をしています。

特徴

今時のそこそこ歴史を積んだシステムなので、機能は豊富にありますし、プラグインも随分と増えました。ただ、そういった量や質というところを越えた部分での特徴を挙げてみると、

AirTable系とアプリ開発系の中間の使い勝手
そこそこ使える便利ツールが「ごにょごにょ」くらいの手間で作れる
無駄に機能が見えて来ない(いい感じで整理されている)
日本語(多国語)対応がちゃんとされている

以下、もうちょっと詳しく説明します。

AirTable系とアプリ開発系の中間の使い勝手

NocoBaseはテーブルを定義して使うのが基本です。また、NocoBaseにはExcelのように直接テーブルの中を操作できるようにはなっていません。この点ではちょっととっつきが悪いです。

他方、テーブルを定義してしまえば、ほぼ自動的にデータ入力フォームができてしまいます。この辺はある意味Access的です。

ただ、普通のRDBのそれとは違い、割と安易にカラムの追加削除ができます。直接編集はできませんが、この辺はExcel的とも言えます。

「がっつり開発」もかなり出来るようになりましたが、そこまでやらなくても、「雑なフォームを作って入力編集」という操作は簡単に作れます。

そんなわけで、割と手軽に使えます。

そこそこ使える便利ツールが「ごにょごにょ」くらいの手間で作れる

これは非常に大きいですね。

前節でも書いたように、テーブルを定義するとフォームがほぼ自動的に作れる「元」ができます。どこを入力可能にするかとゆートグルを操作するだけで、とりあえず使えるフォームが生成されます。

フォームのコンポーネントはテーブルのフィールドの型と紐付いています。ですから、テーブルのフィールドを適切に定義してあれば、フォームは自動的です。と言うよりも「フィールドの型」に見えているものは、実は入力フォームのコンポーネントだとも言えます。

Railsのscaffoldで作れる程度のものがこれだけで出来てしまいますし、使えるコンポーネントは豊富ですから、「scaffold程度」とは言っても結構使えるものになります。

もちろん「scaffold程度」を越えたものも作れます。

無駄に機能が見えて来ない

前節で、型、フィールド、コンポーネントがいい感じにまとまっていることを書きました。システム設計、特にデータの使い回しの観点からすると「ん？」という感じがしますが、お陰で余分なものを見る必要がありません。

内部スキーマの定義でも、

{
  name: 'price',
  type: 'float',
  interface: 'number',
  uiSchema: {
    title: 'Price',
    'x-component': 'InputNumber',
    'x-validator': 'float'
  }
}

という感じになっていて、「フィールドの型」と「そのフィールドで使うコンポーネントに期待されていること」が一致しています。汎用性は下がりますが間違いはありませんし、「こうするしかない」となれば迷いがありません。この辺、全体をひっくり返すと機能豊富ですが、迷う余地がない程度に拘束されていますから、「多機能」であることが直接目に触れません。「余分なもの」が見えないわけです。

これは当然ながら学習コストも下げます。余分なことを把握する必要がありませんし、迷うほど選択肢もありません。データドリブンな開発という観点からは離れてしまいますが、「雑にごにょごにょやって、使えるアプリっぽいものを作る」ということをゴールとした時には、実にうまいやり方だと言えます。 Budibaseが「既存のデータをうまく使う」というゴールで作られているため、コンポーネントの選択肢が膨大に出て来てしまうという悩みの対極にあると思います。

日本語対応がちゃんとされている

これは弊社社長が頑張って… ということもあるのですが、元々中国製のものですから、国際化は最初からちゃんとしていたというポジションの良さがあります。

そして、フィールド名については「名前」と「表示名」が別々に存在していて、名前にはalpha numericなものを、表示名には任意の文字列(多分utf-8)がというように別々に用意されています。二重にあって面倒臭いという面もありますが、「いいとこ取り」というようでもあって、うまく機能していると思います。「なぜかコードシーケンスが特殊な意味になってしまって使えない」というような謎動作も起きません(Windowsのファイル名でしばしばありますね)。

サンプル

今回2種類のテーブル(アプリ)を作りました。

StableDiffusionのモデルとプロンプトと生成画像の管理
気になるアプリケーションのリスト

の2つです。どちらも「ごにょごにょ」っと作ったもですし、項目足りないなと思ったら適当に追加したりしているものです。雑に作ったものですが、結構便利に機能しています。

StableDiffusionのモデルとプロンプトと生成画像の管理

表題通りです。

最近ちょっと思うところあってStable Diffusionで色々画像生成していたのですが、その学習過程でのモデルやプロンプト、生成された画像を記録しようと思って作ったものです。

NSFWなサムネは消してありますｗ

これだけ見ると、「ジェネリックAccess」という感じに見えます。

生成された画像は、「生成画像」と書かれたところにある「+ Upload」というエリアにDnDします。

フィールドの定義はこんな感じです。

見てのとおりという感じですね。これを定義しておいて、

UIエディタを起動して、「Configure field」をクリックすると、

フォームで使うべきフィールドの選択が出て来るので、使いたいもののトグルをオンにします。

これだけで雑にフォームが生成されますが、縦にずらずらと並ぶだけなので、もうちょっとマシにしようと思うとマウスでごにょごにょと並べ変えたり編集したりできます。この辺は何となくやってるとわかるという感じです。

この程度のものであれば、手間もかかりませんし、Excel使うよりも便利なので、そこそこ使える便利ツールが「ごにょごにょ」くらいの手間で作れるという感覚ですね。

気になるアプリケーションのリスト

Twitter等で流れて来たり、どこかの情報から流れて来たりした面白そうなアプリのブックマークのようなものです。これは後で自分で見て使うと言うよりは、RAGの元ネタにすることを目的として作っています。

入力フォームとしてはこんな感じです。

「分類」はドロップダウンになっていたりします。

フィールドの定義は、

こんな感じで、ドロップダウンのところは「Single select」となっていますね。この中身は、

こんな感じになっています。後からラベルを追加したり表示順序を変更したりできます。

いずれの例も、テーブルを定義してしまえば、ほぼ自動的にフォームを作ってくれるのがわかると思います。色々複雑で高度なこともできるシステムですが、最初の一歩は「ごにょごにょ」で作れるのは便利です。

作った「アプリ」には可搬性があまりなくてそのシステムの中でしか動きませんが、アプリとしてはサーバ上で動いていますから、ローカルで使う上での問題にはなりません。また、下手に分離して扱えない分、単一のメニューに全てがおさまりますから、アプリの入口がどこにあるかを悩むことがありません。

他方、認証がありながら「自分だけのアプリ」が作れないという不便さもありますが、本当に自分だけのアプリが欲しければExcelでやればいいと割り切るのが良いんじゃないかと思います。私も最初は欠点だと思っていたのですが、そういった割り切りをするのがLCNCを複雑なものにしたり運用を面倒にしたりしない元なんだろうなと納得しています。

何よりも台帳的なものが簡単に作れるというのは非常に良いです。そして、「それより先」も頑張れば作れるようになっています。でも、その機能は無理に使わなくても使えます。

NocoBaseは名前の通り、大別するとAirTable系になると思うのですが、テーブルを直接見せるのではなくて「台帳(フォーム)」を見せます。そのためテーブルがそのまま見えてしまうExcelにあるような「ちょっとだけ違う行がある」ようなことが避けられます(あるはできなくてイラッとしない)し、データベースの本来の使い方ができます。

手放しで「サイコー」というほどではありませんが、色々な意味でバランスが取れているいいシステムだと思います。