はじめに
実務でシーケンス図を描いてみたものの、「線が渋滞して何がしたい図か分からなくなった…」「条件分岐がマトリョーシカ状態になって混乱した…」という経験はありませんか？
この記事では、初心者が設計時に迷いがちなポイントを振り返り、図を劇的にスッキリ＆正確に見せるための実践的なTipsを解説画像とともに紹介します。
1. ライフラインと実行仕様の基本を覚えよう
初心者が最初につまずきがちなのが、ライフラインの終端と、処理中を表す「実行仕様（アクティベーションバー／縦棒）」の長さです。
ライフラインの終端（消滅エラー ×）
-
× 惜しい例: データベースやテーブルの処理の最後に、バツ印（
×）を置いて終了させてしまう。 -
👉 解説:
×は一時的に生成され、メモリから破棄されるオブジェクト（ポップアップ画面や一時的な計算クラスなど）に使うものです。データベースや永続テーブルは用が済んでもシステムから消滅しないため、バツ印は置かずに点線のまま下へ伸ばしておくのが正解です。
実行仕様（縦棒）の長さ
- × 惜しい例: 複数の処理や別のタイミングで発生するメッセージを、1本の長い縦棒でまとめて受け止めてしまう。
- 👉 解説: メッセージ（矢印）が届いた瞬間にバーが始まり、戻り値を返したらバーが終わるように、処理ごとに独立した短いバーを小分けに配置しましょう。「今、どのオブジェクトが動いているのか」が直感的に伝わるようになります。
2. 戻り値は「点線（破線）」で返すのがUMLルール
メッセージの種類と矢印の形を意識するだけで、図の正確性とプロっぽさが跳ね上がります。
-
呼び出し（リクエスト）: 実線（
--->） -
戻り値（レスポンス）: 点線／破線（
< - - -）
バックエンドのコード（PHPなど）で「成功したら登録した主キーの配列を返す」「エラーの時は例外を出す」という実装をする場合、戻り線の上のテキストに [article_id, contract_id] や 成功: 配列 / 失敗: エラー と書いてあげると、実装するプログラマーが「いつも通りの実装でいいんだな」と一発で理解できます。
3. 条件分岐（alt）が多いなら「画面ベース」で書こう
設計書を書き始めるときに迷うのが「プログラムの関数レベル（処理ベース）」で書くか、「ユーザーの行動レベル（画面ベース）」で書くかです。
「この場合はアラートを出す」「画面で選択したデータを確認画面へ引き継ぐ」といった**画面の振る舞い（フロント側の関心事）が多い仕様の場合は、【画面ベース】**で書くのが圧倒的におすすめです。
画面ベースで書くときのライフライン配置例
- ユーザー（アクター）
- 変更画面（フロント）
- 確認画面（フロント）
- バックエンド / DB
ユーザーがボタンを押して画面が遷移し、条件によってアラートが出たり、DBに保存されたりする「紙芝居」のような流れを追えるようにするのがコツです。
4. 複雑な分岐は「ref」と「マトリクス表」へ逃がす！
ここが最も重要なハイライトです。
実務では、**「全機器移動か一部機器移動か × 表紙合流の有り無し」**のように、条件の掛け合わせで更新するテーブルやロジックが4パターンも5パターンもある複雑な仕様によく遭遇します。
これを1枚のシーケンス図にすべて詰め込もうとすると、条件分岐（alt枠）の中にさらに alt枠が入るという「マトリョーシカ状態」になり、作図ツールも読む人の脳内も崩壊します。
解決策：「図（全体図）」＋「表（マトリクス表）」のハイブリッド構成
-
1枚目（シーケンス図）：全体の画面遷移に集中する
確認画面で「確定」を押した後の複雑な保存ロジックは、UMLのref（参照）枠 を使って「詳細は別紙（ロジック判定表）を参照」と丸ごと省略してしまいましょう。 -
2枚目（別紙）：マトリクス表（掛け合わせ表）を置く
シーケンス図を何枚も量産するのではなく、以下のようなシンプルな表を1つ用意してあげる方が、開発者にとっては最高の「実装チェックリスト」になります。
判定マトリクス表の例
| 機器の移動範囲 | 表紙合流の有無 | 更新対象のテーブル | 処理内容（概要） |
|---|---|---|---|
| 全機器移動 | 合流なし |
TABLE_A, TABLE_B
|
UPDATE処理 |
| 全機器移動 | 合流あり |
TABLE_A, TABLE_B, TABLE_C
|
キーの更新（合流先ID） |
| 一部機器移動 | 合流なし |
TABLE_A（新規登録）... |
INSERT処理 後、関連データをコピー |
| 一部機器移動 | 合流あり |
TABLE_A（新規登録）... |
INSERT処理 後、合流先の新IDで更新 |
この構成のメリット
- 見やすさ抜群: 「画面の流れ（ユーザー体験）」と「データのルール（ロジック）」を脳内で切り離せるので、圧倒的に読みやすくなります。
- メンテナンス性抜群: 仕様変更（「やっぱりこのテーブルも更新対象に加えて！」など）があったとき、図の矢印を引き直すのは大仕事ですが、表なら1マス書き換えるだけで済みます。
結論：見やすくメンテしやすい仕様書を目指して
シーケンス図作成の最大のコツは、**「1枚の図にすべてを語らせようとしないこと」**です。
- ハッピーパス（王道ルート）を中心に、画面ベースで流れを整える
- UMLの基本ルール（点線など）を少しだけ守る
- 複雑な条件の掛け合わせは、マトリクス表に丸投げする
この「全体図＋詳細表」の組み合わせこそが、実務で最速で作れて、最も読みやすく、仕様変更に強い仕様書になります。設計書づくりに悩む方は、ぜひこのアプローチを試してみてください！