【 AppSheet 】命名規則でアプリ開発が楽になる!
はじめに
こんにちは。吉積情報(株)アプリケーション開発部のイイズナです。
アプリ開発が楽になるような命名規則の"コツ"をお話しいたします。
主にユーザーよりも開発者目線で、アプリを構築・改修する際に知っておくとよい内容です。
正解は特にはありませんが、Table 名や Column 名、Action 名などどのように管理すればよいかのご参考になればと思います。
他にも AppSheet について詳しい情報を発信中です!
▶吉積情報 AppSheet コラム一覧◀
なぜ命名規則が重要なのか?
AppSheet のアプリを構築する上で地味に重要な要素が「データの命名」です。
これはアプリを作りはじめた頃は比較的問題になりにくいです。
しかし、各部品(ここでは便宜上 Column や View などを部品と呼びます)の命名が適当だと、徐々に多機能なアプリづくりに挑戦していったり、アプリのメンテナンスが必要になった際など、後々困ることがあります。
なぜ困るのか?それは、似たような名称の部品が混在してどれがどこの部品なのか、どの部品がどのような役割なのか、などがわかりにくいからです。
そのため、AppSheet ではTable 名などが五十音順(アルファベット順)に並ぶという特性を活かして、命名規則(接頭辞)をつけておくとエディタ上で見やすくなります。
具体的な命名規則の例
ここからは命名規則を意識して対応しなかった場合の問題点と、その解決方法をご説明します。
ケースその 1 Table の並び順
Table の並び順の見づらさ。
Table の並び替え機能が現時点(2025年1月)では実装されておらず、類似テーブルをまとめておくことができません。
ただし、AppSheet では テーブル名などが五十音順(アルファベット順)に並ぶので、命名規則として接頭辞をつけておくと、見やすくなります。
例えば、日々記録を格納するデータテーブルを探しやすいようにするために、テーブル名の頭に Daily の「D」をつけて「D_入庫商品」や「D_報告」としてまとめておくなどです。
ケースその 2 Table の役割
Table ごとの役割がわかりにくい。
基本的にアプリのテーブル構成は「マスタ」と「それ以外(記録をつけるなど)」のものとで大分されます。
よくある例でいうと、マスタは「商品」Table のように流動性が低く「表」的な役割、それ以外は「入庫商品」Table のように流動性が高く「帳簿」的な役割のものを指します。
マスタテーブルは一度作ってしまえば他のテーブルから参照されるだけ、となることが多くあまりメンテナンスすることがありません(ない方がよい)が、「それ以外」のテーブルは日々使うものなのでアプリ作成やメンテナンス時に修正することが多くなります。
その際、単純なネーミングだとどのテーブルがマスタかそれ以外かで Table の役割がわかりにくいため、命名が大切になります。
上記ケースその 1 とも通ずる内容ですが例えば、「ユーザー」Table をマスタテーブルとする場合は"Master"の「M」を頭につけて「M_ユーザー」とする。
店舗ごとのデータを記録するようなテーブルを用意する場合は、"Shop"の「S」を頭につけて「S_東京店」などとするとわかりやすいですね。
ケースその 3 Column
同じような Column が混在して紛らわしい。
AppSheet では、複数のテーブルにわたってそれぞれ別々のカラムに同じカラム名をつけることも可能です。
例えば、「ユーザー」Table に"ユーザーのメールアドレス"としての「メールアドレス」Column があるとすれば、「受注」Table にも"受注登録担当者を識別するための"「メールアドレス」Column がある、といった具合です。
テーブルごとに各々のカラム設定をしていても機能上は特に問題ありませんが、数式(Formula)などを使い始めるようになると不便に感じます。
カラムを指定する場合の画面を見ると…
上記はそれぞれ別 Table の ”名前” が & で結合されています
画面により AppSheet の機能などによってカラムの所属するテーブルが表示されたりはするものの、紛らわしいですね。
なので、「そのデータの用途なども含めて」カラムに命名したほうがわかりやすくなります。
上の例のように、[名前_姓] とするなどしておくと見やすいです。
また、Columun 名はカラムの詳細設定で「Display Name」として「ユーザーから見えるアプリ画面上の名前」と「開発画面で開発者が見る名前」とを分けてつけることができるので、ユーザー用の名称はアプリの用途に応じてわかりやすい命名がよいですね。
上の例でいうと、開発者用にはユーザー Table にあるメールアドレスを「メールアドレス_ユーザー」とし、ユーザー用には Display Name で「メールアドレス」としてアプリ画面上に表示されるようにする、などの命名が望ましいです。
ケースその 4 View
どの View か区別がつきにくい。
View は同一の Table をソースとして複数の View を作ることができます。
「営業用にはこのビュー」、「事務用にはこのビュー」、などユーザーの属性・役割に応じて ビューを分けてつくり、必要なデータを見やすく表示したい場合などに便利です。
その場合、同一のデータソースを持つビューが複数生まれます(1つの Table に対し View が複数存在する)。
そういったケースで、例えば「受注一覧」Table を元にしたビューを複数作りたい時は、「受注一覧_営業」「受注一覧_事務」など Display name で View 名にそのビューの用途などを明記しておけばわかりやすいでしょう。
Slice(Table データを指定条件のみにフィルタリングする)を用いてビューを作る場合にも同じことが言えますね。
ケースその 5 Action
Action の役割がわかりにくい。
似たような名称を複数のアクションにつけてしまうと、シンプルにわかりにくいです。
特にカスタマイズが複雑化したり自分でアクションをつくるようになると「どのような動きをする Action が存在するか」を把握しておかないと、メンテナンス時にも困ることになります。
「どの Action がどの動きをするかわかりやすく」 を第一に命名し、ユーザー用にはやはり Display Name で別名をつけることをおすすめします。
基本は Display name
ユーザー目線を意識しすぎて開発画面がわかりにくい状態になってしまっては、元も子もありませんね。
これまでの説明をまとめると、いずれの部品も、
- ユーザー用(アプリ画面):Display name
- 開発者用(開発画面):部品に直接つける名称
という使い分けをして命名することが基本となります。
ただし、ユーザー用の名称を設定したこと自体を忘れてメンテナンス時などに混乱することのないよう、そこは注意してくださいね。
おわりに
AppSheet はアプリを作るところまでは簡単ですが、いざ細かくカスタマイズしたりメンテナンスしたり、という場面で混乱しやすい部分もあります。
ポイントを押さえて Table や Column、View などの名称を設定するとよりストレスフリーで開発できるようになるので、アプリ作成開始時から意識してできるとよいですね。
以上、AppSheet 命名規則についての解説でした。
ありがとうございました。また次回の記事でお会いしましょう。
吉積情報(株)では今回のような AppSheet の基本的な使い方や、既に活用が進んで応用的な使い方まで、貴社のご要望に合わせて幅広くトレーニングやサポートサービスを提供しております。
AppSheet や Google Workspace に関する疑問点・不明点を直接エンジニアに質問できる活用サービス他、AppSheet の活用の幅が広がる無料 Webセミナー、AppSheet 受託開発なども承っております。
弊社Webサイトよりお気軽にお問い合わせくださいませ。
サンプルアプリのご案内
AppSheet についての詳しい記事・ご相談などはこちら
※いただいたコメントは全て拝見させていただきますが、全てのご質問にはお答えできないことがございますので、あらかじめご了承くださいませ。
Discussion
実践的な内容ありがとうございます。よろしければAction命名の具体的な例を拝見したいです。
例えば、CSVexportのActionの場合、同じAction名はつけることができないので、CSVexport_テーブル名などとしているのですが、GroupedActionや、他テーブルのActionを呼び出すActionの命名に悩みます😅
コメント、並びにご要望までいただきありがとうございます!
おっしゃるとおり、Actionの命名も悩みどころですよね。
Action nameの頭文字に「0-01_アクション名」など数字をつけて管理していたりしますので、別途記事でご紹介できればと思います。
またご興味あればどうぞよろしくお願いいたします!🙇