アプリ開発のフローチャートは、画面の順番と内部処理を一枚に詰め込むほど読みにくくなります。
利用者が移動する「画面遷移」、業務担当者をまたぐ「業務フロー」、条件分岐を追う「処理フロー」、複数システムの呼出し順序を追う「シーケンス図」を分けることが出発点です。
四種類の図を同じ用語と識別子でつなぐと、企画、設計、実装、テストの認識差を減らせます。
外注先へ図の作成から相談する場合は、アプリ開発の相談先を目的別に整理したガイドで依頼範囲を確認できます。
| 確認したいこと | 使う図 |
|---|---|
| どの画面へ移るか | 画面遷移図 |
| 誰が次の作業を持つか | 業務フロー |
| どの条件で処理が分かれるか | 処理フロー |
| APIや外部サービスがどの順に応答するか | シーケンス図 |
機能を決める前の検証段階なら、先にアプリ開発のMVPで最小機能を決める方法で対象経路を一つに絞ってください。
まず図の目的を四種類に分ける
| 図の種類 | 主語 | 表すもの | 書かないもの |
|---|---|---|---|
| 画面遷移図 | 利用者 | 画面、操作、戻り先 | DB内部の細かな更新 |
| 業務フロー | 利用者と担当者 | 受け渡し、待ち、承認 | ボタン配置 |
| 処理フロー | システム | 判定、更新、失敗処理 | 装飾や余白 |
| シーケンス図 | 複数システム | API呼出しの順序 | 画面全体の構成 |
画面遷移図は、利用者がどこからどこへ移るかを確認する図です。
AndroidのNavigationガイドは、遷移先をノード、接続をグラフとして管理し、戻る操作やディープリンクも扱う構成を示しています。
ログイン画面からホーム画面へ進む矢印には「認証成功」のような操作条件を書き、APIの再試行回数は別の処理フローへ置きます。
業務フローは、問い合わせを利用者、受付担当、審査担当の誰が持っているかを可視化します。
OMGのBPMN紹介は、業務担当者と実装担当者が共有できる標準化された業務プロセス表記を目的としています。
担当者ごとのレーンを設けると、アプリ外の電話確認や手作業も消さずに表せます。
処理フローは、一つの入力がどの条件で成功、保留、失敗になるかを実装者とテスト担当が追う図です。
外部決済や通知サービスをまたぐ場合は、呼出し順序を独立したシーケンス図にすると責任範囲が明確になります。
記号と命名を最小限に統一する
フローチャートの記号を増やす前に、五つの意味だけをチームで固定します。
| 記号 | 意味 | ラベル例 | 確認事項 |
|---|---|---|---|
| 角丸 | 開始、終了 | 注文開始 | 終了条件があるか |
| 長方形 | 処理 | 注文を保存 | 誰が何を変えるか |
| ひし形 | 判定 | 在庫があるか | YesとNoが両方あるか |
| 矢印 | 流れ | 認証成功 | 条件や操作が読めるか |
| レーン | 担当 | 利用者、店舗、決済会社 | 受け渡しが見えるか |
Mermaidのフローチャート構文は、ノード、矢印、サブグラフをテキストで定義できます。
図をリポジトリへ置く場合は、画像だけでなくテキスト定義も保存すると変更差分をレビューできます。
画面には SCR-010、処理には PROC-020、外部APIには EXT-030 のような識別子を付けます。
名称が変わっても要件、テスト、障害記録から同じ対象を追えることが目的です。
画面遷移と業務フローを五段階で作る
最初から清書せず、正常経路を一本通してから例外を足します。
- 開始条件と完了条件を一つずつ書く
- 利用者が触る画面だけを時系列に並べる
- 各矢印へ操作か判定条件を付ける
- 担当者と外部サービスの受け渡しを追加する
- 戻る、中断、重複送信、通信失敗の経路を追記する
Androidのナビゲーショングラフ設計は、各画面を遷移先として持ち、その接続をデータ構造で管理する考え方を説明しています。
図と実装で同じ経路名を使うと、存在しない遷移や戻り先の欠落を見つけやすくなります。
注文アプリの例で三つの図をつなぐ
注文処理を例にすると、画面遷移は「商品一覧から完了画面まで」、業務フローは「利用者から店舗への受け渡し」、処理フローは「在庫確保と決済」を表します。
| 識別子 | 画面または処理 | 入力 | 成功時 | 失敗時 |
|---|---|---|---|---|
| SCR-010 | 商品一覧 | 商品選択 | SCR-020へ | 空状態を表示 |
| SCR-020 | 注文確認 | 注文ボタン | PROC-010へ | 入力箇所を表示 |
| PROC-010 | 在庫確保 | 商品IDと数量 | PROC-020へ | SCR-020へ在庫不足を返す |
| PROC-020 | 決済 | 金額と決済手段 | SCR-030へ | 再試行か取消を選ばせる |
| SCR-030 | 注文完了 | 注文番号 | 履歴へ | 状態照会を案内 |
この一覧から画面遷移図には SCR だけを置き、処理フローには PROC と失敗時の復帰先を置きます。
二重決済を避けるため、注文ボタンの再押下と決済応答が不明な場合を別の例外経路として記録します。
六画面の図からテスト本数を見積もる計算例
ここでの数字は工数相場ではなく、漏れを数えるための例です。
六画面に通常の遷移が七本、例外の遷移が五本あるなら、少なくとも十二本の矢印を一度ずつ通るテストが必要です。
| テスト単位 | 本数 | 一件の確認時間 | 合計 |
|---|---|---|---|
| 通常遷移 | 7本 | 8分 | 56分 |
| 例外遷移 | 5本 | 12分 | 60分 |
| 戻る操作 | 3本 | 6分 | 18分 |
| 合計 | 15本 | – | 134分 |
一つのテストで複数の矢印を通る場合でも、矢印ごとの通過記録を残します。
画面数だけでテストを数えると、通信失敗から復帰する経路や二回押したときの経路が消えやすいためです。
フローチャートを更新できる設計資料にする
完成した図には、作成者だけでなく更新条件を付けます。
画面追加、API応答の追加、担当者の変更、エラー処理の変更が起きたときは、関連する識別子を検索して同じ変更単位で直します。
PlantUMLのアクティビティ図は、条件分岐、反復、並列処理、レーンをテキストで表せます。
MermaidかPlantUMLのどちらか一つへ統一し、生成画像と定義ファイルの版がずれないよう自動生成すると保守しやすくなります。
アプリ開発のフローチャートでよくある質問
画面遷移図とフローチャートは同じですか？
同じではなく、画面遷移図はフロー図のうち利用者の画面移動へ焦点を絞ったものです。
AndroidのNavigationガイドでは、画面に相当する遷移先とその接続をグラフとして扱います。
業務担当者の受け渡しや内部判定まで一枚へ混ぜず、識別子で別図とつないでください。
業務フローにはアプリ外の作業も書きますか？
電話、紙、目視確認、他部署への連絡も、サービス完了に必要なら書きます。
OMGのBPMNは、業務利用者から実装担当者まで理解できるプロセス表記を目標としており、システム内だけに限定していません。
アプリ外の待ち時間を消すと、通知条件や期限切れ処理を設計できなくなります。
フローチャートはどのツールで作ればよいですか？
共同編集だけなら図形ツールでも作れますが、長期運用ではテキスト定義を履歴管理できるMermaidやPlantUMLが便利です。
Mermaid公式構文はノードと接続をテキストで記述できるため、コード変更と同じレビュー手順へ載せられます。
採用前に日本語ラベル、分岐、レーン、PDF出力を小さな図で試してください。
図を描く目的は実装とテストの漏れを減らすこと
きれいな一枚を作るより、目的の違う図を同じ識別子でつなぐ方が実務で役立ちます。
- 画面遷移図の主語は利用者で、業務フローの主語は利用者と担当者です。
- 最小の共通記号は、開始、処理、判定、矢印、レーンの五種類です。
- 例外経路には、中断、通信失敗、重複操作、戻る操作が含まれます。
- テスト対象は画面数だけでなく、条件付きの矢印ごとに数えます。
- テキストで定義した図は、要件やコードと同じ変更履歴へ置けます。
図を正式な要件やテスト条件へ展開するときは、アプリ開発の設計書に必要な項目も併せて整理してください。
