【第5回】AppSheet開発を変える！ユースケース図とシーケンス図で処理を俯瞰する

これまでの連載で、AppSheetのテーブル設計やViewの作成方法など、アプリの「部品」を作る技術を学んできました。しかし、複数の機能が絡み合う複雑なアプリを開発しようとすると、「全体の処理の流れが分からない」「誰がどの機能を使うのか整理できない」といった壁にぶつかることはありませんか？

この連載第5回では、これまで開発してきた在庫管理アプリを題材に、システムの全体像を捉える「ユースケース図」と、具体的な処理の流れを時系列で示す「シーケンス図」の作成方法を、手を動かしながら学びます。この記事を読み終える頃には、あなたは単なる「部品作り」から脱却し、アプリ全体の設計を俯瞰し、関係者と円滑にコミュニケーションを取りながら開発を進めるための強力な武器を手に入れているでしょう。

[目次を開く]

本記事でできるようになること第1章：なぜ「図」が必要なのか？～UMLの基本～複雑な要件を整理する共通言語 AppSheet開発におけるUMLの活用メリット第2章：ユースケース図でシステムの全体像を描くユースケース図とは？（アクターとユースケース）演習：在庫管理アプリのユースケース図を作成する第3章：シーケンス図で処理の流れを可視化するシーケンス図とは？（オブジェクトとメッセージ）演習：在庫管理アプリの「出庫処理」をシーケンス図にする第4章：図からAppSheetの実装へつなげるユースケースから必要なViewとActionを洗い出すシーケンス図からAutomationの処理を設計する AppSheet開発で使える作図ツールつまずきと解決集 FAQ まとめ関連記事

本記事でできるようになること

ユースケース図とシーケンス図の基本的な概念と書き方を理解します。
AppSheetで開発するアプリの要件を、UMLを使って視覚的に整理できるようになります。
在庫管理アプリを例に、実際にユースケース図とシーケンス図を作成するスキルを習得します。
作成した図を基に、AppSheetで実装すべきView、Action、Automationを具体的に洗い出す方法を学びます。
チーム開発や顧客への説明において、システムの仕様を明確に伝え、認識齟齬を防ぐためのコミュニケーション能力が向上します。

第1章：なぜ「図」が必要なのか？～UMLの基本～

この章では、システムの設計図ともいえる「UML」の基本的な考え方と、それをAppSheet開発で活用するメリットについて解説します。

複雑な要件を整理する共通言語

UML（Unified Modeling Language: 統一モデリング言語）は、システムの構造や振る舞いを視覚的に表現するための、世界標準の記法です。家を建てるときに設計図が必要なように、複雑なソフトウェアを開発する際にも、その仕様を明確に、かつ誰にでも分かる形で示すための「設計図」が必要になります。

文章だけでシステムの仕様を伝えようとすると、どうしても解釈のズレ（認識齟齬）が生じやすくなります。「AのときはBする」と書いてあっても、そのAやBが具体的に何を指すのか、人によって捉え方が変わってしまうのです。UMLを使うことで、こうした曖昧さを排除し、関係者全員が同じイメージを共有しながら開発を進めることができます。

AppSheet開発におけるUMLの活用メリット

「ノーコードのAppSheetに、わざわざUMLなんて大げさでは？」と思うかもしれません。しかし、AppSheet開発においてもUML、特に今回紹介するユースケース図とシーケンス図は、計り知れないメリットをもたらします。

要件の明確化と合意形成: 顧客やチームメンバーと「誰が（アクター）」「何をしたいのか（ユースケース）」を視覚的に確認することで、開発初期段階での手戻りを防ぎます。
実装の抜け漏れ防止: システムが提供すべき機能をユースケースとして網羅的に洗い出すことで、「この機能を作るのを忘れていた！」という事態を防ぎます。
処理フローの整理: 複雑なデータ更新や通知のロジックをシーケンス図で整理することで、ActionやAutomationの設計が非常にスムーズになります。
ドキュメントとしての価値: 作成した図は、そのままアプリの仕様書や設計書として活用でき、将来のメンテナンスや機能追加の際に役立ちます。

特に、複数のテーブルが連携し、バックグラウンドでAutomationが動作するような複雑なアプリでは、頭の中だけで全体像を把握するのは困難です。図を描くという行為を通じて、自分自身の思考も整理され、より堅牢で質の高いアプリを設計できるようになるのです。

第2章：ユースケース図でシステムの全体像を描く

まずは、システムの全体像を俯瞰するための「ユースケース図」から作成していきましょう。

ユースケース図とは？（アクターとユースケース）

ユースケース図は、「誰が、そのシステムを使って何をするのか」を表現するための図です。以下の2つの主要な要素で構成されます。

アクター (Actor): システムとやり取りをする人間や、外部のシステムのこと。「利用者」や「管理者」などがこれにあたります。
ユースケース (Use Case): アクターがシステムを利用して達成する目的や、システムが提供する機能のこと。「物品を登録する」「在庫を確認する」といった、アクターから見た一連の操作のまとまりです。

ユースケース図を描くことで、そのシステムが「誰に、どのような価値を提供するのか」という根本的な要件を、一目で把握することができます。

演習：在庫管理アプリのユースケース図を作成する

それでは、これまでの連載で定義してきた在庫管理アプリの要件を基に、ユースケース図を作成してみましょう。

1. アクターを洗い出す

まず、この在庫管理システムを利用するのは誰かを考えます。

ユーザー: 日々の業務で物品の在庫確認や出庫・返却を行う一般の従業員。
管理者: ユーザー情報の管理や、物品の種類などのマスタデータをメンテナンスするシステム管理者。

2. ユースケースを洗い出す

次に、各アクターがシステムを使って何を実現したいかを考え、ユースケースとして書き出します。

ユーザーのユースケース
- 物品を登録・編集する
- 在庫情報を確認する
- 物品を出庫・返却する
- 入出庫履歴を確認する
- 現場持ち出しリストを作成・管理する
管理者のユースケース
- ユーザーを管理する
- マスタデータ（物品種類、保管場所など）を管理する

3. 図として描画する

アクターとユースケースを洗い出せたら、それらを線で結んで図にします。Mermaidなどのツールを使うと、テキストベースで簡単に作図できます。

この図を見るだけで、在庫管理アプリが持つべき機能の全体像と、それぞれの機能が誰のためのものなのかが明確になります。開発チーム内での認識合わせはもちろん、顧客に「私たちが作ろうとしているのは、こういうシステムですよ」と説明する際の強力なツールとなります。

第3章：シーケンス図で処理の流れを可視化する

ユースケース図でシステムの「機能」を定義したら、次はそれぞれの機能が「どのように実行されるのか」という具体的な処理の流れを、シーケンス図で明らかにしていきます。

シーケンス図とは？（オブジェクトとメッセージ）

シーケンス図は、オブジェクト（モノやシステム）間のやり取り（メッセージ）を時系列で表現するための図です。縦軸が時間、横軸がオブジェクトを表し、どのオブジェクトからどのオブジェクトへ、どのような順番でメッセージが送られて処理が進んでいくのかを視覚的に示します。

オブジェクト (Object): 処理に関わるモノ。ユースケース図のアクターや、AppSheetアプリ、Googleスプレッドシート（データベース）などが該当します。
メッセージ (Message): オブジェクト間で送受信される情報や命令。「出庫を要求する」「データを書き込む」などがこれにあたります。

AppSheet開発においてシーケンス図を描くことは、特にActionやAutomationといった、目に見えない裏側の処理を設計する際に絶大な効果を発揮します。

演習：在庫管理アプリの「出庫処理」をシーケンス図にする

それでは、ユースケースの一つである「物品を出庫・返却する」の中から、具体的な「出庫処理」のシーケンス図を作成してみましょう。

1. オブジェクトを定義する

出庫処理に関わるオブジェクトを洗い出します。

ユーザー: 操作の起点となるアクター。
AppSheetアプリ: ユーザーが直接操作するインターフェース。
Googleスプレッドシート: データの永続化を行うデータベース。

2. メッセージのやり取りを時系列で記述する

ユーザーが出庫ボタンを押してから処理が完了するまでの流れを、オブジェクト間のメッセージのやり取りとして順番に書き出します。

ユーザーがAppSheetアプリに「物品の出庫」を要求する。
AppSheetアプリはユーザーに「出庫フォーム」を表示する。
ユーザーは出庫情報（どの物品を、いくつ）を入力し、「保存」を要求する。
AppSheetアプリはGoogleスプレッドシートのHISTORYテーブルに、新しいレコード（操作種別：出庫）を追加するようメッセージを送る。
Googleスプレッドシートは書き込みが成功したことをAppSheetアプリに返す。
AppSheetアプリはGoogleスプレッドシートのITEMSテーブルの、該当物品の在庫数量を更新（減算）するようメッセージを送る。
Googleスプレッドシートは更新が成功したことをAppSheetアプリに返す。
AppSheetアプリはユーザーに「出庫完了」を通知する。

3. 図として描画する

この一連の流れを、シーケンス図として描画します。

この図によって、「出庫」という一つの操作の裏側で、どのデータが、どの順番で、どのように更新されるのかが一目瞭然となります。特に、複数のテーブルにまたがるデータ更新（HISTORYテーブルへの追加とITEMSテーブルの更新）が発生する場合、このような図で処理を整理しておくことが、実装時のミスを防ぐ上で非常に重要です。

第4章：図からAppSheetの実装へつなげる

作成したユースケース図とシーケンス図は、眺めるだけでは意味がありません。これらを具体的なAppSheetの機能に落とし込んでこそ、真価が発揮されます。

ユースケースから必要なViewとActionを洗い出す

ユースケース図は、アプリに必要な「画面（View）」と「操作（Action）」を洗い出すための優れたインプットになります。

ユースケース	必要なView	必要なAction
在庫情報を確認する	・在庫一覧 (Deck/Table View) ・在庫詳細 (Detail View)	-
物品を登録・編集する	・在庫登録・編集フォーム (Form View)	-
物品を出庫・返却する	・出庫・返却フォーム (Form View)	・出庫Action ・返却Action
現場持ち出しリストを作成・管理する	・持ち出しリスト一覧 (Table View) ・持ち出しリスト詳細 (Detail View) ・持ち出し明細登録フォーム (Form View)	・リスト新規作成Action ・明細追加Action

このように、各ユースケースを実現するために、どのような画面と、その画面上で実行されるべき操作（ボタン）が必要になるかを整理します。例えば、「物品を出庫・返却する」ユースケースを実現するには、単なるForm Viewだけでなく、在庫詳細画面からワンタップで出庫フォームを呼び出すためのAction（参照アクション）が必要になる、といった具体的な実装計画に落とし込むことができます。

シーケンス図からAutomationの処理を設計する

シーケンス図は、Automation（自動化処理）の設計に直接的に役立ちます。先ほどの「出庫処理」のシーケンス図を見てみましょう。

この図の4番から7番までの流れは、まさにAutomationで実装すべき処理です。

トリガー (Event): HISTORYテーブルに新しいレコードが追加され、かつ[操作種別]が"出庫"であること。
プロセス (Process):
- ステップ1 (Run a data action): ITEMSテーブルの在庫数量を更新するアクションを実行する。具体的には、LOOKUP()関数でHISTORYテーブルの[物品ID]と[数量変更]の値を取得し、ITEMSテーブルの該当レコードの[数量]からその値を減算する。

このように、シーケンス図で定義したオブジェクト間のメッセージのやり取りを、Automationのトリガーとプロセスのステップに置き換えていくことで、複雑なバックグラウンド処理を体系的に、かつ正確に設計することができます。「ボタンを押したら、裏で何かがよしなに動く」という処理を実装する際は、必ずシーケンス図を描いて、データの流れを整理する癖をつけましょう。

AppSheet開発で使える作図ツール

UML図を作成するためのツールをいくつか紹介します。

Mermaid: テキストベースでUML図を描けるツール。今回この記事で作成した図もMermaidを使用しています。manus-render-diagramのようなツールを使えば、テキストから直接画像ファイルを生成できるため、ドキュメント管理が非常に楽になります。
draw.io (diagrams.net): 無料で使える高機能なWebベースの作図ツール。ドラッグ＆ドロップで直感的に図を作成でき、Google Driveなどと連携できる点も便利です。
Miro / FigJam: オンラインホワイトボードツール。チームメンバーとリアルタイムで共同編集しながら、ブレインストーミングを交えて図を作成したい場合に最適です。

つまずきと解決集

図を描くのが面倒で、つい省略してしまう…
- つまずき: 小さなアプリだから大丈夫だろうと高を括り、図を描かずに開発を始めた結果、後から仕様の矛盾に気づき、大幅な手戻りが発生してしまいました。
- 解決策: 「急がば回れ」です。たとえシンプルなアプリであっても、最低限のユースケース図だけでも描く習慣をつけましょう。図を描く時間は、将来の手戻りを防ぐための「投資」です。Mermaidのようなテキストベースのツールを使えば、数分で簡単な図は描けます。
どのくらい詳細に図を描けばいいか分からない
- つまずき: シーケンス図をあまりに細かく描きすぎてしまい、図の作成自体が目的化してしまい、かえって時間がかかってしまいました。
- 解決策: 図は、あくまでコミュニケーションと思考整理のツールです。完璧を目指す必要はありません。シーケンス図であれば、AppSheetのActionやAutomationで実装する単位を意識し、「どのテーブルの、どのデータが、どの順番で更新されるか」という流れが分かれば十分です。
描いた図と実際の実装が乖離してしまう
- つまずき: 開発の途中で仕様変更があったにもかかわらず、設計図であるUML図の更新を怠ったため、図が現状を表していない「死んだドキュメント」になってしまいました。
- 解決策: 図を「生きたドキュメント」として保つためには、仕様変更があった際に、まず図を修正し、その図に基づいて実装を修正するというルールを徹底することが重要です。図と実装を常に同期させる意識を持ちましょう。

FAQ

Q: UMLには他にどんな図がありますか？

A: UMLには、今回紹介した2つの他にも、クラス図（データの構造を定義）、アクティビティ図（業務フローを表現）、ステートマシン図（状態の遷移を表現）など、全部で10種類以上の図があります。まずはユースケース図とシーケンス図をマスターし、必要に応じて他の図も学んでいくのが良いでしょう。

Q: アジャイル開発では、UMLは不要ではないですか？

A: いいえ、アジャイル開発においてもUMLは非常に有効です。詳細な設計書を事前にすべて作るのではなく、スプリントごとに必要な範囲で図を描き、チーム内のコミュニケーションを促進する「スケッチ」として活用されます。

Q: AppSheetのテーブル定義そのものが、ER図の代わりにはなりませんか？

A: AppSheetのDataセクションのテーブル一覧は、確かにER図（テーブル間の関連を示す図）に近い役割を果たします。しかし、テーブル数が多くなると全体像を把握しにくくなるため、draw.ioなどで別途ER図を描いておくと、データ構造の理解が深まります。

Q: ユースケースの粒度は、どのくらいが適切ですか？

A: アクターが「一つの目的を達成するための一連の操作」が一つのユースケースになるのが理想です。例えば、「ログインする」は一つのユースケースですが、「IDを入力する」「パスワードを入力する」はユースケースとしては細かすぎます。

まとめ

今回は、UMLという強力な武器を手に入れ、AppSheet開発をより高い視点から俯瞰する方法を学びました。ユースケース図で全体像を描き、シーケンス図で具体的な処理を設計する。この思考プロセスは、あなたのアプリ開発の質を劇的に向上させるはずです。

これまでの連載で、データ設計からUI/UX、そしてシステムの振る舞いの設計まで、アプリ開発の根幹をなす要素を網羅してきました。いよいよ次回、本連載の最終回となる第6回では、「ActionとAutomationによる業務の自動化」をテーマに、シーケンス図で設計した処理を実際にAppSheet上で実装していきます。ボタン一つで複数の処理を実行するActionや、データの変更をトリガーにメール送信やデータ更新を自動で行うAutomationを使いこなし、手作業を徹底的に排除するテクニックを解説します。お楽しみに！

📄【第1回】AppSheetで在庫表から最短テーブル作成！初級エンジニア向け入門ガイド