大部分のアプリ作成者は、作成したいアプリについて構想を持っていて、以下の 2 点について考えています。
- AppSheet を使用してこのアプリを作成できるか。
- AppSheet を使用してどのようにこのアプリを作成すればよいか。
AppSheet を使用して、思い描いているアプリを作成できる可能性があります。
サンプルのユースケース
この記事では、以下のサンプルのユースケースについて順を追って見ていきます。
「私は建設会社を経営しています。建設現場で行われていることを追跡するための一連のアプリを作成しています。スプレッドシート（データソースは Google スプレッドシートです）に、特定の作業（この場合は水まわりのコーティング）に関連する全データを入力しました。
データ列では、コーティングが必要な各場所を指定しています。たとえば、列 A はビル A、列 B はマンション 301、列 C はビル B となっています。
このテーブルには既存のデータを入力しました。目標は、作業監督者が作業完了を確認したら、チェック欄にチェックを入れられるアプリを作成することです。その後は、各従業員が毎日塗布するコーティング剤の合計分量のほか、すべての建設現場で塗布される分量を追跡できるようにしたいと思っています。
これを AppSheet で作成するにはどうしたらよいでしょうか。」
ステップの概要
以下の 6 ステップに沿ってアプリを作成します。
ステップ 1: エンティティを定義する
AppSheet アプリでは、とにかくデータが重要です。エンティティとそのプロパティの観点でデータについて考えます。
各データをエンティティに分類する必要があります。エンティティとは、現実世界における物事の集合です。この例では、関連する 4 つのエンティティとして、Employee（従業員）、Job（作業）、Location（場所）、Customer（顧客）が挙げられています。
各エンティティは一連の標準プロパティを持ちます。たとえば、各 Customer は Name（名前）、Address（住所）、Phone Number（電話番号）、Email Address（メールアドレス）を持ちます。エンティティのすべてのインスタンスは、同じ型のプロパティを持ちます。ただし、プロパティの値は異なります。
プロパティ値が異なることで、エンティティのインスタンスを一意に識別できます。たとえば、Employee は、ID number（身分証明書番号）プロパティを持つと考えられます。
エンティティは、互いに関連付けることができます。この例では、各 Job は 1 つの Building（建物）における 1 人の Customer に対するものであり、それが 1 人の Customer に割り当てられています。Job エンティティは、Customer エンティティ、Building エンティティ、Employee エンティティを参照します。
ステップ 2: スプレッドシートを作成する
AppSheet は、Google スプレッドシート、Microsoft Excel、Smartsheet に対応しています。データを AppSheet に接続するには、これらのプラットフォームのうち一つを使用する必要があります。
定義した各エンティティ（Job、Employee、Building）には、AppSheet に接続するスプレッドシート内で独自のワークシートを割り当てる必要があります。
この 1 枚のワークシートでは、エンティティの各プロパティを列見出しにします。下の例では、エンティティの各プロパティに対応する列を Customer シートに作成しています。
![[Customer] テーブルにはエンティティに対応する列がある](http://lh3.googleusercontent.com/xuEpF3Hcyfv0c8LflrvcAst2jlmgu2sm33-gHoXp2e6tuDb91jeS8bSb7ipz-tp0Ow=w895)
スプレッドシートの作成方法の詳細については、データ: 基本情報をご覧ください。
ステップ 3: スプレッドシートを接続する
作成するアプリにデータを実際に入力するには、[Data] 
デフォルトでは新しいエディタが有効になっていますが、いつでも以前のエディタに戻すことができます。
以前のナビゲーションをお使いの場合
ステップ 4: ユーザー エクスペリエンスを定義する
UX とは、アプリのユーザー エクスペリエンスをいいます。UX の定義は、アプリユーザーに何が、どのように表示されるか（つまりユーザー インターフェース）を説明するものです。
ビューはデータを可視化するさまざまな手段です。AppSheet エディタでは、カレンダー、スライド、テーブル、ギャラリー、詳細、マップ、グラフ、ダッシュボード、フォームのビューを使用できます。UX ウィンドウの該当のテーブルをクリックすると、ビューのタイプを選択できます。
ビューを配置し起動する場所
プライマリ ビューとメニュービューの 2 か所のビューがあります。
- プライマリ ビューは、アプリの下のバーからアクセスでき、頻繁に使用されるものです。
- メニュービューは、アプリの左上のメニューからアクセスできます。このビューは、まれにしか使用されません。
詳細は、アプリでビューを起動する場所を構成するをご覧ください。
フォームビューを使用してデータを収集する
フォームビューは、ユーザーからデータを収集するために使用されます。アプリの既存のビューでは、編集アクション ボタンが表示されています。このボタンをタップすると、新しい Job レコードを作成できます。
アプリのロゴのカスタマイズ、カラーテーマの選択、形式のルールの定義などを行えます。
詳しくは、UX: 基本情報をご覧ください。
ステップ 5: アプリの動作を改善する
アプリはデータを表示し、ユーザーによるデータの探索、収集、追加、バックエンドのスプレッドシートとの同期を可能にします。このプロセスのすべての局面でデフォルトの動作が準備されていますが、アプリ作成者はこれらの動作を変更、改善できます。
アプリの動作は、以下の 4 つの手法で改善できます。
静的構成
静的構成は、最もわかりやすい手法です。「静的」という言葉は、この構成がアプリの全ユーザーとアプリの全データに対して変化しないことを表しています。各テーブルの各列には、複数の静的構成のオプションがあります。たとえば、列を読み取り専用にするか、またはユーザーによる編集を許可するか、ということです。同様に、各 UX ビューにも、複数の静的構成のオプションがあります。例として、ギャラリー ビューの画像サイズやテーブルビューの並べ替え順が挙げられます。
また、アプリのオフラインでの動作や、アプリとバックエンドのスプレッドシートの間でデータを同期する頻度を制御するさまざまな静的構成のオプションもあります。これらのオプションは、ユーザーに認識されるアプリのパフォーマンスに大きな影響を及ぼすことがあります。
動的構成
他の 3 つの手法は一段と効果的ですが、複雑なところもあります。3 つの手法では、動作が選択されるときに実行または評価可能な方法で、アプリのある側面の動作をアプリ作成者が定義する必要があります。当然ながら、そのような動的動作は、静的構成よりもはるかに効果的です。異なるユーザー、同じテーブルの異なる行、または同じ列の異なる値に対して、個別の、適切な動作を指定できます。
このような判断のたびに、アプリを制御するためにシステムが動的に評価できる形式で、アプリ作成者が動作を定義する必要があります。AppSheet では、こういった動的動作の基本構成要素は、式（すなわち数式）です。
式について
構文と動作において、AppSheet の式は、スプレッドシートの数式とほぼ同じです。
式は通常、特定のテーブルの行を対象として定義されます。たとえば、[Status] = "Complete" という式を使用すると、テーブルの行をフィルタ処理して、Status（ステータス）列が "Complete"（完了）となっている行のみを保持できます。
式は、条件の自然な組み合わせ（AND([Status] = "Complete", [Quantity] > 5) など）、数式、テキスト操作、より複雑なさまざまな計算を定義できます。
式自体が行動を引き起こすわけではない点に注意してください。式とは単に、実行される値を生成する計算を定義するものです。式がどこで使用されるか（後述します）によって、その計算値により、アプリの動作が変わります。
アプリの定義における多くの構成では、静的値ではなく式が受け入れられています。たとえば、式の結果に応じて特定の行にある列の表示と非表示を切り替えることができます。同様に、特定の列の値を表示するのに使用される色は、条件付き形式ルールを使用して変更できます。このルールにおける条件は式です。
式の重要な用途として、以下の 2 種類の仮想データの計算が挙げられます。
- 仮想列: スプレッドシートのデータソースでは実際に実体化されることがなく、代わりに式を使用して動的に計算される列。ほとんどの実用事例において、仮想列は通常の列同様に動作します。
- 仮想テーブル（またはスライス）: 一部の行と一部の列だけを持つテーブルの仮想サブセット。式によってフィルタが定義されます。ほとんどの実用事例において、仮想テーブルは通常のテーブル同様に動作します。
アクション
アクションは、アプリのエンドユーザーにとって意味のある論理的ステップを表す単一の操作です。アプリのデフォルトの動作はすべて、システムが作成したアクション（UX ナビゲーション、フォームの編集、新しい行の追加、電話の発信）の結果です。実際、システムで作成されたこれらすべてのアクションは、制御、変更、オーバーライド可能です。
定義が簡単なアクションは、アプリ内の異なる状態（UX ビュー）、または外部アプリ（スマートフォン アプリやメッセージ アプリなど）にユーザーを遷移させるアプリのナビゲーション アクションです。
データ変更アクションにより、多様な要件に柔軟に対応できます。アプリのセマンティクスを反映した独自のアクションを作成できます。たとえば、Job を Complete にするアクションを定義できます。このアクションによって内部的にジョブレコードの 2 種類のプロパティの値が設定され、顧客に送信するメールを開くことができます。
ただし、AppSheet のアクションはコード プログラムではありません。アクションには、アプリのデータやプレゼンテーションの状態に対して行いたい変更を説明するための単純な宣言式が必要です。個々のアクションを単一のレコードまたはレコード群に対する複合アクションにまとめることで、非常に便利な動作を定義できます。
通常、アクションは、エンドユーザーと UI との明示的なやり取り（つまりボタンのタップ）の結果としてアプリで実行されます。アプリの UI は、エンドユーザーの操作イベントを待ち、そのイベントとイベントに関連付けられたデータ行にバインドされたアクションを実行することで、それぞれのイベントに反応するものととらえるのが最適と考えられます。
詳細は、アクション: 基本をご覧ください。
自動化
アプリの動作の中で最も複雑であるものの最も力を発揮するのが自動化です。自動化を行うと、アプリの動作をエンドユーザーが明示的にトリガーする必要がありません。その代わりに、スケジュールに従って、または特定のイベント（データ変更など）の発生時に実行するアクションを指定できます。たとえば、エンドユーザーに情報を通知するプッシュ通知を実行するなどのエンドユーザーとのやり取りを自動化することもできます。自動化ロジックは、複雑な一連のアクティビティをトリガーできます。
AppSheet では、このような自動化は bot を使用して定義されます。bot は、以下の 2 種類の環境で実行できます。
-
デバイス上で実行されるアプリ内 -- このような bot に共通するシナリオとして、デバイス上の定期的なスケジュールでなんらかのデータ取得ロジックを実行すること（たとえば、GPS の位置情報を定期的に記録するなど）が挙げられます。
-
AppSheet クラウド サービス内 -- このロジックは、スケジュールどおりに（定期的なレポート作成に最適）、または新しいレコードまたは更新されたレコードがバックエンドのスプレッドシートに送信されたときに実行されます。この形式の自動化は、すでにサポートされています。ここに掲載のアプリの例では、Job レコードの更新を確認し、Job が完了した場合、その Job の概要をマネージャーにメールで送信するのが当然の流れです。
詳細は、AppSheet Automation: 基本事項をご覧ください。
ステップ 6: アプリのセキュリティを確認する
アプリを作成した当初は、作成者しかそのアプリを使用しません。しかしながら、なるべく早く、数人のテストユーザーとアプリを共有して、意見をもらうのが当然の流れです。これは、アプリエディタで簡単に行えます。共有: 基本情報をご覧ください。この段階では、アプリのセキュリティについて考慮することが重要です。
AppSheet は、さまざまな粒度でアクセスを制御できる豊富なセキュリティ機能を備えています。
詳細は、セキュリティ: 基本情報をご覧ください。
アプリレベルでのアクセス制御
最も重要な決断は、誰にアプリへのアクセスを許可するかです。「アプリへのアクセスを制限するのか」という簡単な質問を考えてみます。
アプリを社内環境で使用する場合、またはアプリでユーザーがデータを更新できる場合、この答えはほとんど常に「はい」となります。「いいえ」となるのは、広く一般に利用されるアプリを作成する場合だけです。
この例では、アプリは建設会社での使用のために作成されているので、アクセスをその会社の従業員のみに制限する必要があります。AppSheet では、アクセスを制限にはアプリを使用するユーザーにログインを要求します。
また、アクセスが許可されたユーザーとそのメールアドレスのリストも提供します。
UX レベルでのアクセス制御
個々の UX ビューは、あるユーザーにはアクセス可能に、別のユーザーには非表示にできます。これは、現在のユーザーの ID を使用して動的な判定を行う式によって実現できます。
データレベルでのアクセス制御
アプリ内の各テーブルでは、追加、削除、更新の権限が指定されます。この判定は、式を使用して動的に行うことができます。また、この式は、現在のユーザーの ID を使用して作成でき、豊富な権限制御機能を実現できます。
また、ユーザーによって閲覧可能なデータのサブセットを変えることも、よく必要とされます。このような行レベルのセキュリティは、データの各行に適用されるセキュリティ フィルタ式を使用して実現できます。
動作レベルでのアクセス制御
個々のアクションと自動化 bot を、現在のユーザーの ID を使用する式でカスタマイズすることもできます。その結果、アプリの動作をパーソナライズし、さまざまな動作へのアクセスを完全にデータに基づく形で制御できるようになります。
反復型のアプリ設計
アプリの実装を始める前に、アプリを完全に設計する人はいません。むしろ、設計は反復的なプロセスです。AppSheet は、このプロセスを 2 つの方法で支援します。つまり、ユーザーは、常にアプリを動作させながら、段階的な変更を加えてすぐにユーザーにデプロイできます。アプリ作成者は、数日の間にアプリに何百回もの変更を加えるのが普通です。おそらく皆様もそうでしょう。アプリの設計をお楽しみください。