はじめに

実務でシーケンス図を描いてみたものの、「線が渋滞して何がしたい図か分からなくなった…」「条件分岐がマトリョーシカ状態になって混乱した…」という経験はありませんか？

この記事では、初心者が設計時に迷いがちなポイントを振り返り、図を劇的にスッキリ＆正確に見せるための実践的な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の基本ルール（点線など）を少しだけ守る
複雑な条件の掛け合わせは、マトリクス表に丸投げする

この「全体図＋詳細表」の組み合わせこそが、実務で最速で作れて、最も読みやすく、仕様変更に強い仕様書になります。設計書づくりに悩む方は、ぜひこのアプローチを試してみてください！