ユースケース図とロバストネス図の違いを徹底解説：使い分けと実務のコツ

---

ユースケース図とロバストネス図の違いを理解する基本ポイント

ユースケース図は、システムが提供する機能とそれを使う人や他のシステムの関係を高レベルで整理する道具です。主な目的は要件の境界を明確にして、関係者全員がどんな機能を欲しているのかを共有することです。通常はアクターとユースケース、そしてシステム境界線を矩形で囲んで表現します。図の楕円は機能名を、人物や別システムのアイコンはアクター名を表します。ここで大切なのは、内部の処理やデータの流れを細かく描かない点です。

ロバストネス図は、システムの振る舞いを内部設計の視点で整理する道具です。外部から見えるユースケースはそのまま置きながら、内部の責任分担を分解します。境界クラス、コントローラ、エンティティといった役割分担を矢印でつなぎ、どの情報をどのオブジェクトが扱うのかを示します。目的は実装のギャップを早く発見し、再利用性とテスト容易性を高めることです。

この二つの図は“階層的な設計のステップ”として補完的です。ユースケース図が外部の要件を取りまとめ、ロバストネス図が内部の設計の道具になることで、初期の議論と後の実装のギャップを減らせます。違いを理解しておくと、プロジェクトの関係者が混乱せずに話を進められ、要件の変更にも強くなります。

具体的な違いの要点は三つです。第一に抽象度です。ユースケース図は高レベル、ロバストネス図は詳細寄りです。第二に対象です。ユースケース図は“何をするか”を中心に描き、ロバストネス図は“どう作るか”の観点を含みます。第三に目的です。前者は要件共有、後者は設計検討と整合性の確保に役立ちます。

実務での活用は、要件定義の初期段階でユースケース図を作って全体像を共有することから始めます。その後、システムの複雑さが見えてきた段階でロバストネス図へ落とし込み、クラス分割や責任の委譲を検討します。両方を同時並行で進めると、変更対応がしやすく、設計の品質を高めることができます。

最後に実務のコツです。関係者全員の視点を取り入れてアクターを網羅すること、ユースケース名は現場で使われている言葉を選ぶこと、ロバストネス図では境界・コントローラ・エンティティの三つを常に意識すること、この三点を守るだけでもプロジェクトの要件理解と設計の透明性がぐっと高まります。

able>要素ユースケース図での表現ロバストネス図での表現対象システムが提供する機能とアクターシステムの内部設計の役割分担境界システム境界線で外部と内部を区切る境界クラスを使って外部と内部の境界を表現目的要件の共有と機能の整理設計の具体化と責任分担の明確化ble>

実務での使い分けと手順

使い分けの基本は作成時点の目的と対象の透明性です。前半は要件の整合性を確認するためにユースケース図を使用します。関係者が何を求めているのかを直感的に把握でき、追加の機能要望を見逃しにくくします。

次に設計フェーズではロバストネス図を使います。ここではデータの流れ、処理の順番、責任の分担を具体化して、実装やテスト計画を安定させます。

実務のコツとしては、両方を同時進行で進め、同じ用語を使うこと。アクター名、ユースケース名、境界の呼称を統一することで混乱を避けられます。

また、表現の粒度を段階的に上げること。初期は大まかなユースケースで十分で、ロバストネス図では後からクラスや属性を追加していきます。

実際の作業手順例としては、まず要件を洗い出す→ユースケース図に落とす→優先度順に上位ユースケースを抽出する→ロバストネス図に転写する→設計レビューを行う、という流れが効果的です。

注意点: 仕様変更が生じた場合、ユースケース図とロバストネス図の両方を更新する癖をつけること。片方だけ更新してもう片方が古くなると、チーム内の認識ズレが生じ、開発遅延の要因になります。

使い分けの実践ガイドとしては、初期は要件の全体像をつかむこと、次に内部設計の健全性を確保すること、両方の図を同期させることを心がけてください。これらを守ると、変更が発生したときにも迅速に対応でき、品質の高いソフトウェア開発につながります。

観点	ユースケース図	ロバストネス図
主な成果物	機能の一覧と関係者の整理	設計の責任分担とデータの流れの設計
適用場面	要件定義・要件の共有	詳細設計・実装準備

ピックアップ解説

友達A: ユースケース図とロバストネス図の違いって、要は外側と内側の2つの視点を使い分けることだよね。B: そう。ユースケース図は“何をするか”を表す看板みたいなもの。アクターが何を求めているかを直感的に伝える。ロバストネス図はそれを受けて“どう作るか”を決める地図。境界、コントローラ、エンティティなどの役割を分担して、実装の設計を具体化するんだ。A: なるほど。要件→設計の順で使えば、変更にも強くなる。B: うん。両方を同じ言葉で表現する癖をつけると、混乱が減って協力もしやすくなるよ。

---