システム開発や業務改善の打ち合わせで、「この機能は誰が使うのか」「どの画面からどの処理に進むのか」「データ同士の関係はどうなっているのか」がうまく伝わらないことがあります。
口頭で説明していると、その場では理解できた気がしても、あとから認識がずれていたことに気づくことがあります。特に、開発者、業務担当者、管理者、外部ベンダーなど、立場の違う人が関わるプロジェクトでは、言葉だけでシステムの全体像を共有するのは簡単ではありません。
そこで役立つのが、UMLです。
UMLは、システムの構造や動きを図で表現するための共通言語です。難しそうに見えるかもしれませんが、初心者はまず「システムを図で説明するための道具」と理解すれば十分です。
UMLを使うと、誰が何をするのか、システムの中でどのような処理が行われるのか、データや部品がどのように関係しているのかを整理しやすくなります。
この記事でわかること
・UMLとは何か
・UMLは何に使うのか
・UMLの基本的な考え方
・UMLの使い方
・UMLの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「UMLはシステムの構造や動きを図で整理するための型だ」とつかめれば十分です。
UMLとは？
UMLとは、Unified Modeling Languageの略で、日本語では「統一モデリング言語」と呼ばれます。
簡単にいうと、UMLはシステムの仕組みを図で表現するための共通ルールです。
システム開発では、文章だけでは説明しにくいことがたくさんあります。たとえば、ユーザーがログインして商品を検索し、注文し、決済する流れを文章だけで説明すると長くなります。しかし、図にすると関係者が同じイメージを持ちやすくなります。
UMLには、さまざまな種類の図があります。代表的なものには、次のような図があります。
・ユースケース図
・クラス図
・シーケンス図
・アクティビティ図
・状態遷移図
・コンポーネント図
・配置図
初心者が最初に覚えるなら、まずはユースケース図、クラス図、シーケンス図の3つで十分です。
ユースケース図は「誰が何をするのか」を整理する図です。クラス図は「データや部品の関係」を整理する図です。シーケンス図は「処理の流れややり取りの順番」を整理する図です。
一言でいうと、UMLはシステムの構造や動きを図でわかりやすく整理するためのフレームワークです。
UMLは何に使うのか
UMLは、システム開発や業務システムの設計で使われます。特に、関係者間でシステムの理解をそろえたいときに役立ちます。
主な用途は次のとおりです。
・システムの全体像を整理する
・ユーザーとシステムの関係を明確にする
・処理の流れを図で説明する
・データや機能の関係を整理する
・開発者と業務担当者の認識を合わせる
・要件定義や設計内容を見える化する
・外部ベンダーへの説明資料を作る
・既存システムの構造を理解する
・業務改善やDXプロジェクトでシステム像を共有する
UMLは、プログラマーだけが使うものではありません。業務部門の担当者やプロジェクトマネージャーにとっても有用です。
たとえば、新しい営業管理システムを作る場合、営業担当者、営業管理者、システム管理者がそれぞれどの機能を使うのかをユースケース図で整理できます。また、案件登録から承認、売上見込み集計までの流れをシーケンス図やアクティビティ図で表せば、業務とシステムのつながりが見えやすくなります。
どんな人に向いているか
UMLは、次のような人に向いています。
・システム開発に関わる人
・要件定義や設計を担当する人
・業務システムの導入を検討している人
・外部ベンダーとシステム仕様を打ち合わせる人
・DX推進や業務改善を担当している人
・既存システムの構造を整理したい人
・プログラミング学習中の人
・プロジェクトマネージャーやリーダー
・IT部門と業務部門の橋渡しをする人
特に、業務側の担当者がUMLの基本を知っておくと、開発者との会話がしやすくなります。
もちろん、すべてのUML図を専門家のように描ける必要はありません。まずは「誰が使うのか」「どの順番で処理が進むのか」「どのデータが関係するのか」を図で考える習慣を持つだけでも、システム開発の理解は大きく進みます。
UMLの基本的な考え方
UMLの基本的な考え方は、システムを複数の視点から図で表すことです。
システムには、さまざまな見方があります。
・利用者から見たシステム
・処理の流れから見たシステム
・データ構造から見たシステム
・部品のつながりから見たシステム
・状態変化から見たシステム
・配置やインフラから見たシステム
UMLでは、これらを目的に応じて異なる図で表します。
ユースケース図
ユースケース図は、誰がシステムを使い、何を行うのかを整理する図です。
たとえば、営業管理システムであれば、利用者には営業担当者、営業マネージャー、システム管理者などがいます。それぞれが、案件登録、商談履歴入力、売上見込み確認、ユーザー管理などの操作を行います。
ユースケース図では、利用者を「アクター」、利用者が行う操作や目的を「ユースケース」として表します。
初心者向けに言えば、ユースケース図は「誰が何をするかを整理する図」です。
クラス図
クラス図は、システムで扱うデータや概念の関係を整理する図です。
たとえば、営業管理システムであれば、顧客、案件、商談、見積、担当者などの情報があります。顧客には複数の案件があり、案件には複数の商談履歴があるかもしれません。
このような情報同士の関係を整理するのがクラス図です。
プログラミングでは、クラス図はオブジェクト指向設計と深く関係します。ただし、初心者はまず「システムで扱う情報の関係を整理する図」と理解すれば十分です。
シーケンス図
シーケンス図は、処理の流れや、システム内のやり取りの順番を整理する図です。
たとえば、ユーザーがログインするときには、次のような流れがあります。
・ユーザーがIDとパスワードを入力する
・画面が認証処理を呼び出す
・認証処理がユーザー情報を確認する
・認証に成功すればメニュー画面を表示する
・認証に失敗すればエラーメッセージを表示する
このようなやり取りの順番を表すのがシーケンス図です。
初心者向けに言えば、シーケンス図は「誰が、何に対して、どの順番で処理を依頼するかを整理する図」です。
アクティビティ図
アクティビティ図は、業務や処理の流れを整理する図です。
業務フロー図に近い感覚で使えます。申請する、確認する、承認する、差し戻す、完了する、といった流れを表すのに向いています。
業務改善やワークフロー設計では、アクティビティ図が役立ちます。
状態遷移図
状態遷移図は、ある対象がどのように状態を変えていくかを整理する図です。
たとえば、注文データであれば、未処理、受付済み、出荷準備中、出荷済み、キャンセル済みといった状態があります。
状態が複雑な業務では、状態遷移図を使うとルールを整理しやすくなります。
UMLの使い方
手順1 何を図で整理したいのかを決める
UMLを使うときは、最初に「何を整理したいのか」を決めます。
初心者がよく迷うのは、どのUML図を使えばよいかという点です。しかし、最初からすべての図を使う必要はありません。
目的に応じて、次のように考えると分かりやすくなります。
・誰が何をするかを整理したいなら、ユースケース図
・業務や処理の流れを整理したいなら、アクティビティ図
・処理の順番ややり取りを整理したいなら、シーケンス図
・データや概念の関係を整理したいなら、クラス図
・状態の変化を整理したいなら、状態遷移図
UMLは図を描くことが目的ではありません。関係者の理解をそろえることが目的です。
そのため、プロジェクトの初期段階では、ユースケース図やアクティビティ図のように、業務担当者にも理解しやすい図から始めるのがおすすめです。
手順2 登場人物や対象を洗い出す
次に、システムに関わる登場人物や対象を洗い出します。
ユースケース図であれば、アクターを考えます。アクターとは、システムを使う人や外部システムのことです。
たとえば、社内申請システムであれば、次のようなアクターが考えられます。
・申請者
・承認者
・経理担当者
・システム管理者
・通知システム
クラス図であれば、システムで扱う情報を洗い出します。
・申請書
・社員
・部門
・承認ルート
・添付ファイル
・承認履歴
この段階では、完璧に整理しようとしすぎる必要はありません。まずは、業務で出てくる人物、情報、処理をざっと書き出すことが大切です。
手順3 関係や流れを整理する
登場人物や対象を洗い出したら、それらの関係や流れを整理します。
ユースケース図であれば、アクターがどの機能を使うのかを線で結びます。
たとえば、申請者は申請書を作成する、承認者は申請を承認する、経理担当者は支払処理を確認する、といった関係です。
シーケンス図であれば、処理がどの順番で進むのかを整理します。
たとえば、申請システムであれば、次のような流れです。
・申請者が申請内容を入力する
・システムが入力内容をチェックする
・システムが承認者に通知する
・承認者が内容を確認する
・承認者が承認または差し戻しを行う
・システムが申請者に結果を通知する
このように流れを整理すると、必要な機能や例外処理も見えやすくなります。
手順4 図をシンプルに描く
UMLは、細かく描こうと思えばいくらでも複雑にできます。しかし、初心者が最初から複雑な図を描く必要はありません。
むしろ、最初はシンプルに描くほうが実務では役立ちます。
意識したいポイントは次のとおりです。
・1つの図に情報を詰め込みすぎない
・関係者が理解できる粒度にする
・専門用語を使いすぎない
・業務上重要な流れを優先する
・例外処理は必要に応じて別図に分ける
・図だけでなく、補足説明も添える
UMLは、正確さも大切ですが、コミュニケーションの道具でもあります。読み手が理解できないほど複雑な図は、実務では使いにくくなります。
手順5 関係者とレビューする
UML図を描いたら、関係者とレビューします。
レビューでは、次のような観点で確認します。
・利用者の役割に漏れはないか
・必要な機能が抜けていないか
・処理の順番は実際の業務と合っているか
・例外処理が見落とされていないか
・データ同士の関係に矛盾はないか
・業務部門にも理解できる図になっているか
・開発者が設計に使える粒度になっているか
UML図は、一度描いて終わりではありません。要件定義や設計が進むにつれて、修正されるものです。
最初はラフな図でよいので、関係者と会話しながら改善していくことが重要です。
UMLの具体例
例 社内申請システムを設計する場合
ある会社で、紙やメールで行っていた社内申請をシステム化することになりました。
対象となる業務は、備品購入申請です。申請者が申請内容を入力し、上司が承認し、経理担当者が確認する流れです。
この場合、まずユースケース図の考え方で、誰が何をするのかを整理します。
アクターは次のようになります。
・申請者
・承認者
・経理担当者
・システム管理者
それぞれのユースケースは次のように考えられます。
・申請者は、申請を作成する
・申請者は、申請状況を確認する
・承認者は、申請内容を確認する
・承認者は、承認または差し戻しを行う
・経理担当者は、承認済み申請を確認する
・システム管理者は、承認ルートを設定する
次に、シーケンス図の考え方で、申請から承認までの流れを整理します。
・申請者が申請内容を入力する
・システムが入力内容を確認する
・システムが承認者へ通知する
・承認者が申請内容を確認する
・承認者が承認する
・システムが申請者へ結果を通知する
・システムが経理担当者へ確認依頼を送る
さらに、状態遷移図の考え方で、申請データの状態を整理します。
・下書き
・申請中
・差し戻し
・承認済み
・経理確認済み
・完了
・取消
このようにUMLを使うと、社内申請システムの全体像を複数の視点から整理できます。
別の例 ECサイトの商品注文機能を考える場合
別の例として、ECサイトの商品注文機能を考えます。
ユーザーが商品を選び、カートに入れ、注文し、決済する流れです。
ユースケース図の考え方では、次のようなアクターと機能を整理できます。
アクターは次のとおりです。
・購入者
・管理者
・決済システム
・配送システム
ユースケースは次のように整理できます。
・購入者は商品を検索する
・購入者は商品をカートに入れる
・購入者は注文する
・購入者は決済する
・管理者は商品情報を登録する
・管理者は注文状況を確認する
・決済システムは決済結果を返す
・配送システムは配送情報を受け取る
シーケンス図の考え方では、注文処理の流れを整理できます。
・購入者が注文内容を確認する
・システムが在庫を確認する
・システムが決済システムへ決済依頼を送る
・決済システムが決済結果を返す
・システムが注文データを作成する
・システムが配送システムへ出荷依頼を送る
・購入者に注文完了通知を送る
クラス図の考え方では、扱う情報の関係を整理できます。
・購入者
・商品
・カート
・注文
・注文明細
・決済
・配送
たとえば、1つの注文には複数の注文明細があり、注文明細は商品と関係します。注文には決済情報と配送情報も関係します。
このように、UMLを使うことで、ECサイトの注文機能を「利用者」「処理の流れ」「データ構造」の観点から整理できます。
具体例でわかるポイント
具体例から学べるポイントは次のとおりです。
・UMLはシステムを複数の視点で整理できる
・ユースケース図は誰が何をするかを考えるのに向いている
・シーケンス図は処理の順番を整理するのに向いている
・クラス図はデータや概念の関係を整理するのに向いている
・状態遷移図はステータス管理が重要な業務に向いている
・図にすることで関係者の認識を合わせやすくなる
・最初から詳細に描きすぎず、業務理解に役立つ粒度で描くことが大切
UMLは、システムの説明をわかりやすくするための道具です。図を正確に描くことだけにこだわるのではなく、関係者が同じ理解を持てるかどうかを重視しましょう。
UMLを使うメリット
UMLを使うメリットは、システムの構造や動きを視覚的に整理できることです。
主なメリットは次のとおりです。
・システムの全体像を共有しやすい
・文章だけでは伝わりにくい内容を図で説明できる
・関係者間の認識ズレを減らせる
・要件や設計の抜け漏れに気づきやすい
・開発者と業務担当者の会話がしやすくなる
・外部ベンダーに仕様を説明しやすい
・既存システムの理解に役立つ
・複雑な処理やデータ関係を整理しやすい
・設計書や引き継ぎ資料として活用できる
特に重要なのは、UMLがコミュニケーションの道具になることです。
システム開発では、同じ言葉を使っていても、人によってイメージしている内容が違うことがあります。たとえば「承認する」という言葉だけでも、誰が承認するのか、どのタイミングで承認するのか、差し戻しはできるのか、通知は必要かなど、確認すべきことがたくさんあります。
UMLで図にすると、あいまいな点が見えやすくなります。その結果、早い段階で認識を合わせることができます。
UMLを使うときの注意点
UMLは便利ですが、使い方を間違えると、かえって分かりにくくなることがあります。
よくある失敗例は次のとおりです。
・すべてのUML図を無理に作ろうとする
・図が細かすぎて関係者が理解できない
・UMLの記法の正確さばかりにこだわる
・業務目的が整理されていないまま図を描く
・図だけ作って関係者と確認しない
・古い図が更新されず、実態とずれる
・読み手に合わせた粒度になっていない
・例外処理やエラー時の流れを見落とす
・専門用語が多すぎて業務部門が参加できない
・図を作ること自体が目的になってしまう
特に初心者が注意したいのは、「UMLをきれいに描くこと」が目的ではないという点です。
UMLの本来の目的は、システムの理解を助け、関係者の認識を合わせることです。記法を厳密に守ることも大切ですが、実務では相手に伝わることのほうが重要な場面も多くあります。
また、UML図は一度作ったら終わりではありません。要件や設計が変われば、図も更新する必要があります。更新されない図は、むしろ誤解の原因になります。
関連フレームワークとの違い
UMLと関連するフレームワークには、要件定義フレーム、BPMN、DFD、ER図、CRUDマトリクスなどがあります。それぞれ目的が異なります。
要件定義フレームとの違い
要件定義フレームは、業務要件、機能要件、非機能要件を整理するための考え方です。
UMLは、整理された要件や設計内容を図で表現するための記法です。
要件定義フレームが「何を作るべきか」を整理するものだとすれば、UMLは「その内容をどう図で表すか」に役立ちます。
要件定義の段階でユースケース図やアクティビティ図を使うと、利用者の行動や業務の流れを整理しやすくなります。
BPMNとの違い
BPMNは、業務プロセスを図で表現するための記法です。
UMLにもアクティビティ図のように業務や処理の流れを表す図がありますが、BPMNは特に業務プロセスの可視化に特化しています。
業務部門との会話ではBPMNが使いやすい場合があります。一方、システムの構造や処理のやり取りまで含めて整理したい場合は、UMLが役立ちます。
DFDとの違い
DFDは、データの流れに注目してシステムを表す図です。
UMLは、利用者、処理、データ構造、状態変化など、さまざまな視点でシステムを表現できます。
DFDは「データがどこから来て、どこで処理され、どこへ行くのか」を整理するのに向いています。UMLは、それに加えて「誰が使うのか」「処理がどの順番で進むのか」「情報同士がどう関係するのか」も表現できます。
ER図との違い
ER図は、データベースの構造を整理するための図です。
UMLのクラス図もデータや概念の関係を表せますが、ER図はよりデータベース設計に近い使い方をします。
初心者向けに言えば、ER図は「データベースの設計図」、UMLのクラス図は「システムで扱う概念や部品の関係図」と考えると分かりやすいです。
CRUDマトリクスとの違い
CRUDマトリクスは、データに対して作成、参照、更新、削除のどの操作が必要かを整理するための表です。
UMLでは、データの関係や処理の流れを図で表現します。一方、CRUDマトリクスは、どの機能がどのデータを操作するかを確認するのに向いています。
UMLで全体像を整理し、CRUDマトリクスでデータ操作の抜け漏れを確認すると、より実務的な設計になります。
UMLはどんな場面で使うと効果的か
UMLは、次のような場面で使うと効果的です。
・新しい業務システムを設計するとき
・システム開発の要件を整理するとき
・外部ベンダーに仕様を説明するとき
・既存システムの構造を理解するとき
・複雑な処理の流れを整理するとき
・データや機能の関係を見える化するとき
・利用者ごとの操作範囲を整理するとき
・業務フローとシステム処理の関係を整理するとき
・開発チーム内で設計内容を共有するとき
・システム改修時に影響範囲を確認するとき
特に、関係者が多いプロジェクトではUMLが役立ちます。
業務部門、IT部門、外部ベンダー、管理職がそれぞれ異なる視点でシステムを見ていると、認識のズレが起きやすくなります。UMLを使って図にすることで、曖昧な部分を早めに発見できます。
また、システム改修や引き継ぎでも有効です。担当者が変わったとき、文章だけの仕様書よりも、UML図があるほうが全体像を理解しやすくなります。
まとめ
UMLとは、システムの構造や動きを図で整理するための統一モデリング言語です。
初心者にとっては、少し専門的に感じるかもしれません。しかし、最初からすべての図や記法を覚える必要はありません。まずは、ユースケース図、クラス図、シーケンス図の考え方を押さえるだけでも十分役立ちます。
ユースケース図は、誰が何をするのかを整理する図です。クラス図は、システムで扱う情報や概念の関係を整理する図です。シーケンス図は、処理ややり取りの順番を整理する図です。
UMLを使うことで、文章だけでは伝わりにくいシステムの内容を見える化できます。関係者の認識を合わせやすくなり、要件定義や設計の抜け漏れにも気づきやすくなります。
大切なのは、UMLを描くこと自体を目的にしないことです。システムを理解し、関係者と合意し、よりよい設計につなげるために使うことが重要です。
まずは、自分が関わっている業務システムについて、「誰が何をするのか」をユースケース図の考え方で書き出すところから始めてみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
要件定義フレームとは？初心者向けに意味・使い方・具体例をやさしく解説
BPMNとは？初心者向けに意味・使い方・具体例をやさしく解説
DFDとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
IT・システム・業務設計で使うフレームワークまとめ｜初心者向けに種類・使い方・選び方をわかりやすく解説
