【実務で使えるUML 後編】設計フェーズ別の図活用×作図ツール徹底比較×コード7選

🔁 本記事は後編です。前編はこちら → 【実務で使えるUML 前編】“伝わる設計図”で炎上ゼロ！7種類の図とその使い分け

---

📐 設計フェーズ別 UML 活用整理

プロジェクトのフェーズによって、UML図の活用方法は大きく異なります。ここでは、開発ライフサイクルの各段階でどのUML図が特に役立つのかを見ていきましょう。

設計フェーズ	ユースケース図	クラス図	シーケンス図	アクティビティ図	ステートマシン図	配置図	コンポーネント図
要件定義	✅			✅
基本設計	✅	✅（初期）		✅		✅（初期）	✅（初期）
詳細設計		✅	✅		✅	✅	✅
運用設計				✅	✅	✅
検証	✅		✅	✅	✅
運用				✅		✅

要件定義 (Requirements Definition)

プロジェクトの根幹を定める重要なフェーズです。ここで認識齟齬があると、後々大きな手戻りにつながります。

• ユースケース図: 顧客やステークホルダーとの間で、システムが提供する機能の範囲を明確にし、合意を形成します。「このシステムで何ができるのか？」をユーザー視点で捉え、機能の抜け漏れを防ぐのに最適です。
• アクティビティ図: 業務プロセスを可視化し、システム導入によって業務がどのように変化するか、あるいは既存業務のどの部分をシステムが担うかを明確にします。

基本設計 (Basic Design)

要件定義で固めた「何をやるか」を、どのように実現するかへと具体化する最初のステップです。

• ユースケース図: 要件定義で洗い出したユースケースをさらに詳細化し、それぞれのユースケースに紐づく具体的なシステム機能や、サブユースケースを定義します。
• アクティビティ図: 主要な業務フローやシステム機能の処理シーケンスを詳細化し、条件分岐や並行処理を含めた全体像を設計します。
• クラス図（初期段階）: 主要なドメインオブジェクトやエンティティを特定し、ごく大まかな関係性を描くことで、システムの中核となる概念を整理します。
• コンポーネント図/配置図（初期段階）: 大まかなシステムアーキテクチャの検討、主要なシステム要素とそれらの配置を概念的に示し、技術選定の検討材料とします。

詳細設計 (Detailed Design)

実装に直結する、最も技術的な側面が強くなるフェーズです。開発者間の共通理解が何よりも重要になります。

• クラス図: システムを構成する全てのクラス、その属性、操作、そしてそれらの間の詳細な関係性を定義します。実装に直結するレベルで、データ構造やモジュールの責務を明確にします。
• シーケンス図: 特定の機能やユースケースにおける、オブジェクト間のメッセージのやり取り（メソッド呼び出し、データフロー）を時間の流れに沿って詳細に示します。複雑なビジネスロジックや複数のコンポーネントが関わる処理で不可欠です。
• ステートマシン図: 複雑な状態を持つオブジェクト（例: 注文、タスク、ワークフロー）のライフサイクルにおける状態と遷移条件、アクションを厳密に定義します。
• コンポーネント図: 各コンポーネントの内部構造や、コンポーネント間のインターフェースを詳細に定義します。
• 配置図: システムの物理的なデプロイメント環境（サーバー、ミドルウェア、ネットワーク接続など）を詳細に示し、本番環境の構築計画に役立てます。

運用設計 (Operation Design)

システムを安定稼働させるための準備を行うフェーズです。運用時のトラブルを未然に防ぐために、可視化が役立ちます。

• 配置図: 運用監視の対象となるサーバー、ネットワーク機器、アプリケーションコンポーネントの配置を明確にし、監視ポイントや冗長化構成を検討します。
• アクティビティ図: バックアップ、リカバリ、定期メンテナンス、ログ収集などの運用プロセスフローを定義します。
• ステートマシン図: システムコンポーネント（サーバー、サービスなど）の運用時の状態（稼働中、停止中、メンテナンス中など）とその遷移を定義し、自動化や障害対応フローの基礎とします。

検証 (Verification / Testing)

システムが要件通りに動作するかを確認するフェーズです。UML図はテストケース作成や問題の特定に役立ちます。

• ユースケース図: テストケースの網羅性を確認するためのベースとして活用します。各ユースケースが正しく実装されているかを検証します。
• アクティビティ図: 特定の業務フローや処理ロジックのテストシナリオを構築する際に利用します。正常系だけでなく、異常系のテストパスも明確にします。
• シーケンス図: 特定の機能におけるオブジェクト間の相互作用が設計通りに行われているか、API連携が期待通りかを検証する際の参照情報として使います。結合テストやシステムテストの設計に役立ちます。
• ステートマシン図: 状態を持つオブジェクトのテストにおいて、全ての状態と遷移が期待通りに動作するかを網羅的に検証するためのテストケースを生成します。

運用 (Operation)

システムが実際に稼働し、継続的に改善されていくフェーズです。構成管理との連携が特に重要になります。

• 配置図: システムの現状の構成を把握し、障害発生時の影響範囲特定、構成変更時の影響分析、リソースのスケーリング計画に活用します。CMDB（構成管理データベース）の情報と連携させることで、常に最新の状態を可視化できます。
• アクティビティ図: 障害対応フロー、リリース手順、定期運用タスクなど、運用プロセスのドキュメントとして活用し、手順の標準化と新人教育に役立てます。

---

🔧 UML 作図ツール比較：PlantUML vs Mermaid

UML図を手書きや汎用ドローツールで描くこともできますが、テキストベースでUML図を記述し、自動生成するツールは、現代の開発ワークフローにおいて非常に強力な味方となります。特に、バージョン管理システム（Git）との相性が抜群です。

PlantUML

テキストベースでUML図を記述し、画像を生成するツールです。シンプルな記法で多様なUML図を作成できます。

• メリット:

  • テキストベース: テキストファイルとして管理できるため、Gitなどでのバージョン管理が容易です。変更履歴の追跡や差分表示がしやすくなります。
  • 軽量: 複雑なGUIツールを必要とせず、テキストエディタで記述できます。
  • 拡張性: 様々なUML図に対応しており、非UML図（ガントチャート、WBS、マインドマップなど）も描画できます。
  • 豊富なIDE連携: VS Code, IntelliJ IDEAなどのIDEでプラグインが提供されており、リアルタイムプレビューが可能です。

• 公式サイト: https://plantuml.com/

Mermaid

Markdown記法に似たシンプルなテキスト記法で、UML図（シーケンス図、フローチャート、クラス図など）を含む様々な図をブラウザ上で描画できるツールです。GitHubやQiitaなど多くのMarkdownレンダラーがMermaidに対応しています。

• メリット:

  • 手軽さ: Markdownファイル内に直接記述できるため、特別なツールなしで図を埋め込めます。
  • Webフレンドリー: ブラウザベースでの表示に最適化されており、Webドキュメントとの相性が良いです。
  • 学習コストが低い: 直感的で簡潔な記法です。
  • 幅広い対応: GitHub、GitLab、Jira、Confluence、Qiitaなど、多くのプラットフォームでネイティブにサポートされています。

• 公式サイト: https://mermaid.js.org/

---

🧪 UMLコードと出力図：7種類のサンプル

ここでは、実際にPlantUMLとMermaidで記述したUML図の例をご紹介します。これらのコードを各ツールのエディタや、Qiitaのような対応プラットフォームに貼り付けてみてください。

1. ユースケース図 (Use Case Diagram)

顧客との要件定義で大活躍。システムが「何をできるのか」をユーザー視点で表現します。

• PlantUML 記述例:

  @startuml
  left to right direction
  actor 顧客
  rectangle ECサイト {
    usecase (商品を検索する) as SearchProduct
    usecase (商品をカートに入れる) as AddToCart
    usecase (注文する) as PlaceOrder
    usecase (決済する) as Checkout
    usecase (注文履歴を見る) as ViewOrderHistory
  }
  
  顧客 -- SearchProduct
  顧客 -- AddToCart
  顧客 -- PlaceOrder
  顧客 -- Checkout
  顧客 -- ViewOrderHistory
  
  PlaceOrder .> Checkout : include
  
  @enduml
  

• PlantUML 出力例:

  

• Mermaid 記述例:

  graph TD
      A[顧客] -- 注文する --> B(ECサイト)
      B -- 商品を表示する --> A
      A -- 決済する --> B
      B -- 注文履歴を表示する --> A
  

• Mermaid 出力例:

2. アクティビティ図 (Activity Diagram)

業務フローやプログラムの処理順序を表現。条件分岐や並行処理も視覚的に分かります。

• PlantUML 記述例:

  @startuml
  start
  :注文受付;
  if (在庫確認?) then (在庫あり)
    :決済処理;
    :商品発送;
  else (在庫なし)
    :注文キャンセル;
  endif
  :注文完了;
  stop
  @enduml
  

• PlantUML 出力例:

  

• Mermaid 記述例:

  graph TD
      A[注文受付] --> B{在庫確認};
      B -- 在庫あり --> C[決済処理];
      B -- 在庫なし --> D[注文キャンセル];
      C --> E[商品発送];
      E --> F[注文完了];
      D --> F;
  

• Mermaid 出力例:

3. クラス図 (Class Diagram)

システムの構成要素（クラス）と、それらの関係性を詳細に表現します。

• PlantUML 記述例:

  @startuml
  class User {
      +String userId
      +String userName
      +String email
      +void register()
      +void login()
  }
  class Order {
      +String orderId
      +Date orderDate
      +double totalAmount
      +void createOrder()
      +void cancelOrder()
  }
  class Product {
      +String productId
      +String productName
      +double price
      +int stock
  }
  
  User "1" -- "*" Order : places
  Order "1" -- "*" Product : contains
  @enduml
  

• PlantUML 出力例:

  

• Mermaid 記述例:

  classDiagram
      class User {
          +String userId
          +String userName
          +String email
          +void register()
          +void login()
      }
      class Order {
          +String orderId
          +Date orderDate
          +double totalAmount
          +void createOrder()
          +void cancelOrder()
      }
      class Product {
          +String productId
          +String productName
          +double price
          +int stock
      }
      User "1" -- "*" Order : places
      Order "1" -- "*" Product : contains
  

• Mermaid 出力例:

4. シーケンス図 (Sequence Diagram)

オブジェクト間でメッセージがどのようにやり取りされるかを、時間の流れに沿って詳細に示します。

• PlantUML 記述例:

  @startuml
  actor User
  participant Browser
  participant WebServer
  participant Database
  
  User -> Browser: 商品検索
  Browser -> WebServer: GET /products?q=keyword
  WebServer -> Database: SELECT * FROM products WHERE name LIKE '%keyword%'
  Database --> WebServer: 検索結果
  WebServer --> Browser: HTML (検索結果)
  Browser --> User: 検索結果表示
  @enduml
  

• PlantUML 出力例:

  

• Mermaid 記述例:

  sequenceDiagram
      participant User
      participant Browser
      participant WebServer
      participant Database
      User->>Browser: 商品検索
      Browser->>WebServer: GET /products?q=keyword
      WebServer->>Database: SELECT * FROM products WHERE name LIKE '%keyword%'
      Database-->>WebServer: 検索結果
      WebServer-->>Browser: HTML (検索結果)
      Browser-->>User: 検索結果表示
  

• Mermaid 出力例:

5. 配置図 (Deployment Diagram)

ハードウェアとソフトウェアの物理的な配置関係を示します。インフラのシステム構成図として非常に有用です。

• PlantUML 記述例:

  @startuml
  ' 明示的に deployment diagram を指定（省略可能だが明示した方が安全）
  ' @startuml deployment
  
  ' ノードとデータベース
  node "Webサーバー" as WebServer
  node "アプリケーションサーバー" as AppServer
  node "データベースサーバー" as DBServer
  database "データストア" as DataStore
  
  ' 接続関係
  WebServer -- AppServer : HTTP/S
  AppServer -- DBServer : JDBC/ODBC
  DBServer -- DataStore : 読み書き
  
  ' クラウドの中にノードを定義するときは、node 定義を cloud 内に入れる
  cloud "データセンター1" {
      node WebServer
      node AppServer
  }
  cloud "データセンター2" {
      node DBServer
      database DataStore
  }
  @enduml
  

• PlantUML 出力例:

  

• Mermaid 記述例:

  graph LR
      A[Webサーバー] --> B(アプリケーションサーバー);
      B --> C{データベースサーバー};
      C -- 読み取り/書き込み --> D(データストア);
      subgraph データセンター1
          A
          B
      end
      subgraph データセンター2
          C
          D
      end
  

• Mermaid 出力例:

6. ステートマシン図 (State Machine Diagram)

オブジェクトやシステムの複雑な状態遷移を表現します。

• PlantUML 記述例:

  @startuml
  state "Initializing" as Init
  state "Active" as Active
  state "Standby" as Standby
  state "Switching_To_Standby" as ToStandby
  state "Switching_To_Active" as ToActive
  state "Fault" as Fault
  
  [*] --> Init
  
  Init --> Active : 選挙でアクティブに / 起動時プライマリ
  Init --> Standby : 選挙でスタンバイに / 起動時セカンダリ
  
  Active --> ToStandby : 手動切り替え / プリエンプション
  Active --> Fault : 重大な障害検出
  
  Standby --> ToActive : アクティブ障害検出 / 手動切り替え
  Standby --> Fault : 重大な障害検出
  
  ToStandby --> Standby : 切り替え完了
  ToActive --> Active : フェールオーバー完了
  
  Fault --> Init : 回復 / 再起動
  
  state Active {
      Active : プライマリ、トラフィック転送中
  }
  state Standby {
      Standby : セカンダリ、同期済み、待機中
  }
  state Fault {
      Fault : 不健全、運用停止中
  }
  @enduml
  

• PlantUML 出力例:

  

• Mermaid 記述例:

  stateDiagram-v2
      direction LR
      [*] --> Initializing
      Initializing --> Active : 選挙でアクティブに / 起動時プライマリ
      Initializing --> Standby : 選挙でスタンバイに / 起動時セカンダリ
      Active --> Switching_To_Standby : 手動切り替え / プリエンプション
      Active --> Fault : 重大な障害検出
      Standby --> Switching_To_Active : アクティブ障害検出 / 手動切り替え
      Standby --> Fault : 重大な障害検出
      Switching_To_Standby --> Standby : 切り替え完了
      Switching_To_Active --> Active : フェールオーバー完了
      Fault --> Initializing : 回復 / 再起動
      Active : プライマリ、トラフィック転送中
      Standby : セカンダリ、同期済み、待機中
      Fault : 不健全、運用停止中
  

• Mermaid 出力例:

7. コンポーネント図 (Component Diagram)

システムの物理的な構成要素とその関係性を示します。大規模なシステムで各コンポーネントの連携を把握する際に有効です。

• PlantUML 記述例:

  @startuml
  package "Client Tier" {
      component "Web Browser" as Browser
      component "Web Application Client" as WebAppClient
  }
  
  package "Application Tier" {
      component "Web Server" as WebServer
      component "Application Service" as AppService
      component "Payment Gateway" as PaymentGateway
      component "Database" as Database
  }
  
  package "Data Tier" {
      component "Data Storage" as DataStorage
  }
  
  package "External Services" {
      component "Third Party Payment Service" as ThirdPartyPayment
  }
  
  Browser --> WebAppClient : requests
  WebAppClient --> WebServer : HTTP/S
  WebServer --> AppService : requests
  AppService --> PaymentGateway : uses
  AppService --> Database : accesses
  PaymentGateway --> ThirdPartyPayment : calls
  Database -- DataStorage : stores data in
  DataStorage -- Database : stores data out
  @enduml
  

• PlantUML 出力例:

  

• Mermaid 記述例:

  graph TD
      subgraph Client Tier
          Browser[Web Browser] --> |requests| WebAppClient[Web Application Client];
      end
      subgraph Application Tier
          WebAppClient --> |HTTP/S| WebServer(Web Server);
          WebServer --> |requests| AppService[Application Service];
          AppService --> |uses| PaymentGateway[Payment Gateway];
          AppService --> |accesses| Database[Database];
      end
      subgraph Data Tier
          Database --> |stores data in| DataStorage[Data Storage];
          DataStorage[Data Storage] --> |stores data out| Database;
      end
      subgraph External Services
          PaymentGateway --> |calls| TherdPartyPaymentService["Third Party Payment Service"];
      end
  

• Mermaid 出力例:

---

✅ まとめ：UMLは未来の「認識齟齬保険」

さて、ここまでUMLの様々な図とその活用法、それが設計書の精度向上といかに密接に関わるか、さらには技術者以外のステークホルダーとのコミュニケーションにいかに役立つか、そしてITIL構成管理と最新の技術トレンドとの融合についても語ってきましたが、いかがでしたでしょうか。UMLは万能薬ではありません。これさえあれば全て解決！というわけにはいきません。

しかし、プロジェクトにおける「言った・言わない」の誤解や認識の齟齬を減らし、設計ドキュメントの曖昧さを解消するための強力なツールであることは間違いありません。特に、システムの複雑さが増す現代において、言葉だけでのコミュニケーションには限界があります。UMLは、目に見えないソフトウェアの構造や振る舞いを**「見える化」することで、チーム全体の理解を深め、よりスムーズな開発を促進します。基本設計書から詳細設計書、さらにはインフラ設計**の構成図に至るまで、UMLの活用は、あらゆる設計フェーズでその真価を発揮します。そして、PMとしてクライアントや利用者との合意形成を図る際にも、視覚的なUML図は言葉以上に雄弁に語り、潜在的な誤解の芽を摘み取ってくれるでしょう。

さらに、UML図をコードとして管理し、Gitベースのコード管理と構成管理（CMDB）を接続することで、設計変更のトレーサビリティが高まり、ITILの構成管理をより実践的かつ効率的に運用することが可能です。これは、システムの「今」を常に正確に把握し、変化に素早く対応するための強力な基盤となります。DevOpsやSREの文脈における構成変更管理、そしてレビュー観点の明確化にも大きく貢献するでしょう。

私の経験から確信していることですが、UMLを導入し、それを設計書に積極的に取り入れたプロジェクトでは、手戻りが減り、開発効率が向上したのを肌で感じました。最初は慣れないかもしれませんが、騙されたと思って使ってみてください。きっと、未来のあなたは「あの時UMLを学んでおいてよかった！」と思うはずです。UMLは、未来の「言った・言わない」を防ぐための、とても手軽で効果的な「保険」だと私は信じています。

さあ、皆さんも今日からUMLで、心地よいコミュニケーションの輪を広げ、よりスマートなシステム管理を実現してみませんか？

💬自社ではどう使ってる？どの図が一番使われてる？ など、ぜひコメントであなたのUML活用術を教えてください！

---

※ITILはAXELOSの登録商標です。