ノーコードで業務アプリ開発、どれが我が社にとって最適ですか?問題

2024年、世の中が「ノーコード、ローコードツール利用の促進」という形で業務アプリ開発に取り組む機運がでてきていることは喜ばしいことです。ところが実現したい業務アプリはそれぞれ難易度が異なるため、どのツールが最適なのかを選択することが難しくなってきました。

当社も加盟している「ノーコード推進協会」で、たまたま同じ問題意識をもった方々で話す機会があり、それなら各社で考える勘所をまとめて伝えてみようというセミナーを企画しました。私もご縁があってお話しさせていただけることになり、嬉しく思います。

https://cdn.peatix.com/event/3845871/cover-xkrZI4KKNgVauhUI6nK61YGcQpOttTkq.png

https://peatix.com/event/3845871/

この中の「第2部 5社によるパネルディスカッション」がどこまで盛り上がるか、を私自身、楽しみにしています。

イベントの前に、こういうことを話そうか...という案をいったんまとめてみました。(当日はまた違う話をしているかも知れませんが。)

つくりたいアプリの「タイプ」を知る

よくあるのは業種や業態別といった視点でアプリを分類することです。しかしここでは、より抽象度をあげて考えます。

ここでは次の3つのタイプをあげてみました。

1. 台帳型
2. 親子型
3. 縦持ち-横持ち型

台帳型

画面上の項目と、データベースの項目が 1:1 になっているものです。顧客や商品といった情報を管理するアプリというとわかりやすいでしょう。

ただし台帳管理されるデータ項目は、別の台帳を参照する、ということがあります。顧客がどの商品を購入した、というのは顧客から商品を参照するという形になります。この参照関係は数珠つなぎになることもありますので、このようなデータの関係性を実現できることがツールに求められます。

親子型

画面上の項目が「見出し部」と「明細部」に分離できるものです。ここで見出し部を「親」、明細部を「子」と呼ぶと、1つの親に対して複数の子が連なる構造になっています。つまり明細部は「行(レコード)」として管理されます。見積書や売上伝票などといった業務データが代表的です。

なお1つの見出し部に対して、異なる種類の子が複数、紐づけられることもあります。例えば「顧客」という親データに紐づく子(明細)として「販売履歴(1顧客が複数の販売履歴を保持する)」「問い合わせ履歴(1顧客のこれまでの問い合わせは複数ある)」という2つの異なる子があることは容易にわかります。

業務系データの多くは、この親子型になっています。そして親の登録・更新画面で、(複数の)子を同時に編集できることが求められます。

このレベルまで実現できるノーコードツールであれば、汎用性が高いといえます。

縦持ち-横持ち型

例えば予算実績管理というアプリを考えてみます。2024年4月のA部門の予算はいくら、実績はいくら、というデータを管理したいのですが、データの形はシンプルで、次のようになります。

年度 部門(コード) 予算 実績

ただ、これをそのまま登録・更新画面にするというのは UI として貧弱です。多くの方は Excel をイメージして、次のような UI を想定するでしょう。

2024年度 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月

ところが今度は、UI をそのままデータとして保持させるとデータの集計が扱いにくいことに気づきます。また、管理したい情報を増やそうとすると前者はシンプルに項目を追加するだけですが、後者はそのたびに大きな見直しが発生します。

ここからわかることは、データの形と、UIの表現は別になる、ということです。専門用語ではないと思いますが、多くの現場では前者を「縦持ち」、後者を「横持ち」と呼ぶようです。私から見ると、データの形は縦持ちがシンプルで良く、しかしUIは横持ちの方が見やすく感じます。

ここからわかることは、縦持ち形式から横持ち形式へ、またはその逆へと相互変換する処理が欲しくなるということです。そのためには変換処理を実現する方法 = プログラム的なものがあるとよいです。ノーコードであっても、このようなニーズに応えるための仕掛けがあるかどうか、がポイントになります。

Excel とはなんだったのか

ここまで読んだ方で、少なくとも Excel でデータ管理していれば、こういうタイプを意識することはなかったと思うかもしれません。Excelは、上であげたタイプをすべて包含する表現力をもっています。ただし、それは「データベース」になっていません。情報を保持するだけの入れ物にすぎません。

業務アプリを Excel でつくることの限界はここにあります。データベースとして管理されていないデータは応用性に乏しいのです。具体的には「再利用性が低い」「コピーされたデータが増大し、どれが正かを特定できない」「権限コントロールしにくく、情報流出の懸念を防げない」などの問題があります。

Excel から業務アプリへ、というのは、単なる情報の入れ物から、組織で使いやすいデータに変えるという意図があります。使い勝手だけをみると Excel の方がよかったというケースが多いかも知れません。それでも脱Excelに着手する目的は UI ではなく、データベース化にあります。

まとめ

ノーコードツールの選定にあたって、私としてはやはり「データベース」を意識してほしいと思います。ここであげた3つのタイプは大雑把ですが、データの形に着目するきっかけになれば幸いです。