この記事は、以下の動画と連動しています。
[Weekly kintone talk 2023 week 04] kintoneは誰でもは使えないって話
kintoneをはじめとしたローコードツールはシステム開発に対する深い知識がなくても簡単にシステムを作ることができます。
しかし、本当に知識は不要でしょうか？
kintoneはあくまでも道具に過ぎません。いい包丁を手に入れたからといってすぐにおいしい料理が作れるかというとそんなことはありません。いい道具があると便利ですが、それを使いこなすための知識と経験が必要です。
それはkintoneでも同じです。
データ設計
kintoneは画面上で項目をドラッグ＆ドロップするだけで業務で使えるシステムを作ることができます。それは便利である反面、深く考えずに適当に項目を置いていってもなんとなくシステムができてしまうことを意味します。
kintoneで作るものはあくまでもデータベースです。そしてデータベースには設計が必要です。
正しい設計がなされていないデータベースは将来破綻します。kintoneのように業務の行いながらどんどん変更していくことを前提としている仕組みの場合はなおさらです。
正規化
RDBMSには正規化と呼ばれる設計での考慮事項があります。kintoneで直接的に使うことはあまりありませんが、kintoneでも重要な概念なのでぜひ勉強してみていただくことをオススメします。
kintoneでのデータ設計のダメケース
このコラムでデータ設計のやり方を細かくお伝えすることは難しいのですが、kintoneで典型的にやりがちなデータ設計上の間違いをいくつかご紹介します。
主キーがない
データには主キーが必要です。主キーとは「あるデータを一意に特定できる項目」です。RDBMSであれば複合キーという機能をつかって複数の項目をまとめて主キーとすることもできますが、kintoneではそれができないため、単一の項目で主キーを作成する必要があります。
kintoneにはレコード番号というkintoneが自動的に採番してくれる連番があり、レコードを一意に特定できます。ただし、これを主キーとして使うことはオススメできません。なぜなら、レコード番号は一度採番されると同じ番号は二度と作れないためです。
これがどう問題になるかというと、たとえばレコード番号3番のレコードを誤って消してしまったとします。データの内容は再現できるので、再度レコードを入れ直したとしてもレコード番号3だけは復活させることができません。
もし、このレコード番号を使ってルックアップや関連レコードを作成していると、そこでつながりが切れてしまいます。
kintoneにはレコード番号以外に自動的に採番する仕組みがないため、手動で入れるか、それ以外の番号を採番するにはプラグインや弊社のgusuku Customineを利用していただく必要があります。しかし、それをやる価値は十分にあります。
kintoneの活用が進むとkintoneだけでなく、kintoneのデータを外部のシステムやサービスと連携させてもっと広く使いたくなります。そのときに主キーがないとまともに連携させることができなくなってしまいます。
テーブルを多用しすぎる
kintoneには便利なテーブルという機能があります。これはRDBMS的に言うと子テーブルを自動的に作成して親のデータと同時に編集できるような仕組みです。これによって1つのデータの中に可変行数のデータを持たせることができます。
注文に対する注文明細のような使い方が典型的に使い方になります。 ただ、テーブルを多様しすぎると困ったことが起きます。
まず、kintoneのテーブルにはテーブルの各行を指し示す安定したキーがありません。上の主キーの話と同じようにテーブルの各行に自分でキーを設定していかないといけません。
また、キーを設定してもその行を簡単に取得する方法がありません。テーブル全体を取得して絞り込む必要があります。
テーブルはkintone基本機能の集計やグラフの対象にできないなど制約も多いため使うのは「テーブルじゃないと困る」ときに限ることをオススメします。
それ以外はできるだけ別アプリにして関連レコードを使ってください。
汎用項目
文字列一行や文字列複数行はなんでも入るので便利です。ただ、データベースは各項目の意味が統一されていてはじめて意味があります。
あるときは数値、あるときは備考のような汎用的な使い方をされる項目は持つべきでありません。
「備考」や「その他」のような項目を作りたくなったら要注意です。まったく作ってはダメとは言いませんがこういう項目は集計や連携の対象にできないことを理解して作るようにしてください。
1対1アプリ
アプリAのレコードとアプリBのレコードが1対1で関連づいていて、Aで更新したらBも更新、Bを更新したらAも更新のように同期したいというご相談をよく受けます。
同期はトラブルが発生しやすく、またデータ構造的にも意味がありません。
この場合、アプリを1つにすることを考えてください。「色々理由があって分けた」と言いたくなるかもしれませんが、1つにしようとしてください。
ただし、1対1でも分けることに合理性があるケースもあります。それは、更新が1方向になるケースです。
たとえば、営業部門が案件管理アプリを使ってして、受注すると開発部門に渡すというような場合。営業部門と開発部門では基本情報は同じでも管理したいデータや項目の見方が違います。
そのような場合、営業部門が受注した時点で、営業の案件に対となるデータを開発部門用のアプリに作成することがあります。ただし、この場合開発部門でデータを更新しても営業部門の案件管理アプリには反映しません。1方向にしておくことが大切です。
まとめ
少しではありますがよくない例を挙げました。データ設計は非常に奥の深い世界で、一朝一夕にマスターできるものではありません。しかし、データ設計を勉強して意識してkintoneアプリを作成すると、将来の変更に強いアプリを作成できますので、これまで意識していなかった方はぜひ勉強してみてください。