技術者の共通言語
技術者の共通言語 UML
この記事でわかること
- UML（Unified Modeling Language）が、なぜ技術者だけでなく、クライアントやPMとのコミュニケーションにも有効なのか
- 基本設計書から詳細設計書、インフラ構成図まで、UMLの各種図を具体的な場面でどう活用するか
- ITILの構成管理や、IaC・CI/CDといったモダンな開発手法とUMLを組み合わせることで、いかに効率的なシステム管理が実現できるか
- UMLを用いた設計書作成における、よくある誤解を防ぐための実践的なヒント
導入部: なぜ、私たちは「言った・言わない」で揉めるのか？
プロジェクトにおいて、私たちは日々様々な人々とコミュニケーションを取っています。お客様、上司、同僚、そしてもちろん、愛しの猫たち…いえ、猫は聞き役専門でしたね（笑）。しかし、このコミュニケーション、一筋縄ではいかないこともしばしば。特に技術の世界では、「言ったはずなのに伝わっていない」「あの時の認識と違う！」なんてことが日常茶飯事です。これ、本当にストレスですよね。私もかつては、設計書一つでチーム内がギスギスするのを目の当たりにしてきました。なぜこんなことが起きるのでしょうか？それは、私たちは皆、独自の「言語」を持っているからです。心の中のイメージを言葉にするのは、案外難しいもの。そして、その曖昧な言葉が設計書という形になったとき、取り返しのつかない誤解を生むこともあります。
さらに言えば、この「言った・言わない」問題は、技術者同士の間に限った話ではありません。PM（プロジェクトマネージャー）として、クライアントやシステムの利用者と話すとき、彼らはシステムの内部構造や複雑な設計には正直、ほとんど興味がありません。彼らが知りたいのは「何ができるのか」「どう動くのか」という結果だけ。言葉だけで書かれたサービスレベル合意書（SLA）や、その実現方法を記したSLO（Service Level Objective）を渡しても、彼らにはそれが何を意味するのか、どこまでが保証されているのか、ピンとこないこともしばしばです。結果として「記述していない機能が勝手に盛り込まれていると解釈していた」「それが普通だと言い張られた」といった誤解が生じ、プロジェクトが暗礁に乗り上げることもあります。実際に、RFP（提案依頼書）や要件定義の段階でUML図を用いることで、顧客との認識齟齬を未然に防ぎ、入札で有利に働いたという事例も耳にします。
そして、システムのライフサイクル全体を通して、この「言った・言わない」問題、そして「今、システムがどうなっているのか？」という疑問は、構成管理という形で常に付きまといます。ITILなどのフレームワークで提唱されている構成管理は、システムのあらゆる構成要素（CI: Configuration Item）を正確に把握し、管理するための重要なプロセスです。しかし、これがまた骨の折れる作業でして、手作業での更新は遅れがち、情報が古くなるともう目も当てられません。
そこで今回ご紹介したいのが、技術者の共通言語ともいえる「UML（Unified Modeling Language）」です。これは単に技術者同士の対話ツールに留まらず、PMとしてクライアントや利用者との間の誤解を防ぎ、スムーズなプロジェクト推進を支える強力な武器となるのです。さらに、UMLで作成された図と、CI/CD（Continuous Integration/Continuous Delivery）やIaC（Infrastructure as Code）といった現代的な開発・運用手法、そしてGitやGitHubを含むGit系ツールといったバージョン管理システムを組み合わせることで、厄介な構成管理を効率化できる可能性を秘めているのです。
UMLって、結局何者？設計図は語る、言葉より雄弁に
さて、本題のUMLについて触れていきましょう。UMLは、ソフトウェア開発における設計や構造を視覚的に表現するための標準的な記法です。なんだか堅苦しい響きですが、要は「設計図」のようなもの。家を建てるのに設計図があるように、ソフトウェアを作る際にも、どのように動くのか、どんな部品があるのかを明確にするための絵が必要なんです。
UMLは、単に絵を描くためのツールではありません。その背後には、オブジェクト指向の考え方があり、システムの複雑さを整理し、理解しやすくするための強力なフレームワークを提供します。OMG（Object Management Group）という団体がその標準化を推進しており、国際的に認められた共通言語なのです。
もし私がUMLを使うなら、やはり一番はチーム内の「認識合わせ」に使いたいですね。言葉だけだと曖昧になりがちな部分も、図にすることで明瞭になります。特に若手技術者の方々にとっては、ベテランの頭の中を覗き見るような感覚で、システムの全体像を掴むのに役立つはずです。もちろん、頑固なベテラン技術者の方々にも、ご自身の経験則を「共通言語」で表現する新たな喜びを感じていただけるのではないでしょうか。
そして何より、技術的なバックグラウンドがない方々にも、システムがどのように動くのかを「見て」理解してもらうための強力なツールとしても活用できます。
近年では、UMLに加えてC4モデルのような階層的アーキテクチャ図（C4モデルはシステムをコンテキスト、コンテナ、コンポーネント、コードの4つのレベルで視覚化することに焦点を当てています。UMLはシステム全体の挙動や構造を多角的に表現する一方、C4モデルはアーキテクチャの階層的な視点に特化している点が異なります）も注目されていますが、本稿ではUMLの表現力と実務的運用に焦点を当てます。
UMLと設計書の連携で、確かな共通認識を築く実例集
技術者同士の一番の相互理解は、やはり設計書を見ることです。しかし、その設計書自体が曖昧では意味がありません。UMLは、この設計書をより明確で、誰もが誤解なく読み取れるものにするために、大いに役立ちます。
基本設計書を明確にするUML図：顧客と技術者の架け橋に
基本設計書は、システムの「何をやるか」を定義する重要なドキュメントです。顧客の要求を技術的な視点に落とし込む段階で、曖昧な表現が入り込みがちです。UMLの以下の図は、この段階で特に力を発揮します。
ユースケース図:
システムが「何をできるのか」を、ユーザーの視点から表現する図です。顧客との要件定義で大活躍します。
- コミュニケーション効果:
顧客との認識合わせに最適です。「このシステムでは、こんなことができますよ」と明確に示すことで、後々の「こんな機能が欲しかったのに！」というミスマッチを防ぎます。シンプルなため、非技術者にも理解しやすいのが特徴です。曖昧な要件を具体化し、顧客と技術者双方の共通認識を形成する上で不可欠です。
graph TD
A[顧客] -- 注文する --> B(ECサイト)
B -- 商品を表示する --> A
A -- 決済する --> B
B -- 注文履歴を表示する --> A図1：ECサイトのユースケース図例。顧客がECサイトに対して行う操作と、それによってシステムが提供する機能の関係性を示しています。
アクティビティ図:
業務フローやプログラムの処理順序を表現する図です。フローチャートに近い感覚で使えます。
- コミュニケーション効果:
業務担当者と開発者の間で、業務の流れやロジックについて認識を合わせるのに非常に有効です。「この場合はどうするの？」「あの場合は？」といった疑問を具体的に解消できます。これにより、基本設計段階での業務フローの誤解を防ぎます。
graph TD
A[注文受付] --> B{在庫確認};
B -- 在庫あり --> C[決済処理];
B -- 在庫なし --> D[注文キャンセル];
C --> E[商品発送];
E --> F[注文完了];
D --> F;図2：ECサイトの注文処理フローのアクティビティ図例。注文受付から完了までの業務の流れと、在庫有無による処理の分岐を示しています。
詳細設計書を精密にするUML図：開発者間の共通言語
詳細設計書は、システムの「どうやってやるか」を具体的に定義するドキュメントであり、開発者間の相互理解の要となります。UMLは、この詳細設計の精度を飛躍的に高めます。
クラス図:
システムの構成要素（クラス）と、それらの関係性を表現します。オブジェクト指向開発の根幹をなす図と言えるでしょう。
- コミュニケーション効果:
開発者間の深い議論に役立ちます。「どのようなデータを持つのか」「どんな操作ができるのか」を明確にすることで、設計の抜け漏れを防ぎ、実装の方向性を統一できます。特に、新しいメンバーがプロジェクトに参加した際、システムの全体像を理解するのに非常に有効です。詳細設計において、クラス間の連携やデータ構造を厳密に定義できます。
classDiagram
ClassA <|-- ClassB
ClassC *-- ClassD
ClassE o-- ClassF
ClassG -- ClassH : has
ClassI -- ClassJ : uses
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図3：ECサイトのユーザー、注文、商品のクラス図例。各クラスが持つ属性や操作、およびそれらの間の関連（ユーザーが注文を出す、注文が商品を含むなど）を示しています。
シーケンス図:
オブジェクト間でメッセージがどのようにやり取りされるかを、時間の流れに沿って表現します。
- コミュニケーション効果:
特定の機能や処理がどのように動くのか、その「振る舞い」を詳細に説明する際に力を発揮します。問題発生時の原因究明や、新しい機能追加の際に既存システムへの影響範囲を検討するのに役立ちます。特に、非同期処理や複雑なインタラクションを含む詳細設計では、この図なしには語れないでしょう。
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: 検索結果表示図4：商品検索処理のシーケンス図例。ユーザーがブラウザで商品を検索し、Webサーバー、データベースとの間でメッセージがどのようにやり取りされ、結果が表示されるかという一連の流れを時系列で示しています。
ネットワーク構成図、物理構成図、論理接続図…UMLの「配置図」が示す世界
インフラエンジニアであれば、ネットワーク構成図や物理構成図、論理接続図は日常的に目にし、作成するドキュメントでしょう。これらの図は、システムの物理的・論理的な配置や接続関係を視覚的に表現する上で極めて重要です。UMLの配置図（Deployment Diagram）は、まさにこれらの情報を包括的に表現できる図の一つです。
配置図:
ハードウェアとソフトウェアの物理的な配置関係を示します。システムのデプロイメント環境を理解するのに役立ちます。
- コミュニケーション効果:
インフラ担当者とアプリケーション開発者の間で、システムがどのサーバーに、どのようなミドルウェア上で動くのか、ネットワーク的にどう接続されているのかといった情報を正確に共有できます。これにより、デプロイ時のトラブルやパフォーマンス問題の切り分けが格段に容易になります。論理的な接続と物理的な配置を明確に区別して表現することも可能です。
graph LR
A[Webサーバー] --> B(アプリケーションサーバー);
B --> C{データベースサーバー};
C -- 読み取り/書き込み --> D(データストア);
subgraph データセンター1
A
B
end
subgraph データセンター2
C
D
end図5：「Webサーバー」から「アプリケーションサーバー」へ、そして「データベースサーバー」を経由して「データストア」への接続を示しています。
どのような図になるかは、こちらでご確認ください。(MermaidDiagramming and charting tool)
クライアントや利用者の「誤解」を防ぐためのUML活用術
PMやクライアント、システムの利用者は、詳細な技術的図面には興味がないかもしれません。しかし、彼らが「何を」「どう使うか」という視点でのUML図は、驚くほど有効です。
- 「見せる」図を選ぶ:
クラス図やシーケンス図のような詳細な図は、技術者向けです。クライアントには、前述のユースケース図やアクティビティ図のように、システムが提供する機能や、彼らの業務フローに直接関係する図を見せるのが効果的です。これにより、「このシステムではこういうことができる（できない）」という範囲を明確に視覚で示すことができます。 - 図の「凡例」と「説明」を徹底する:
図を見せれば全て伝わる、というのは幻想です。特にUMLに馴染みのない相手には、各記号が何を意味するのか、この図が何を表現しているのかを丁寧に説明する必要があります。サービスレベル合意書やSLOにUML図を盛り込む際は、必ず図の隣に簡潔な凡例と、その図が示す機能や制約を明記してください。 - 「できないこと」も図で示す:
「記述していない機能が勝手に盛り込まれていると解釈していた」という誤解は、往々にして「できること」ばかりに焦点を当てた説明から生まれます。あえて「このユースケースは対象外である」といった形で、図の中に「できないこと」や「スコープ外」の領域を明示的に示すことも有効です。例えば、特定の機能が「オプション」である場合、それをユースケース図上で表現する、あるいはアクティビティ図の分岐で「このルートは現段階では実装しない」といった注釈を加えることで、無用な期待を抱かせずに済みます。 - インタラクティブな説明を心がける:
一方的に図を見せるだけでなく、図を指し示しながら「この部分はどうですか？」「もしこういう操作をしたら、次に何が起こると思いますか？」といった問いかけをすることで、相手の理解度を確認し、潜在的な誤解を発見することができます。まるで、子供に絵本の読み聞かせをするように、図と一緒に物語を語るのです。
その他の図たち：出番は少ないが、いざという時に頼りになる「縁の下の力持ち」
- コンポーネント図:
システムの物理的な構成要素（コンポーネント）とその関係を示します。大規模なシステムで、各コンポーネントがどのように連携しているかを把握するのに使われます。 - ステートマシン図（状態遷移図）:
オブジェクトの状態がどのように変化するかを表現します。特に、複雑な状態を持つオブジェクトの振る舞いを明確にするのに有効です。
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 : 不健全、運用停止中図7: ステートマシン図（状態遷移図）
どのような図になるかは、こちらでご確認ください。(MermaidDiagramming and charting tool)
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図6:コンポーネント図
どのような図になるかは、こちらでご確認ください。(MermaidDiagramming and charting tool)
これらの図は、普段あまり目にしないかもしれませんが、特定の状況下では計り知れない威力を発揮します。例えば、システムが原因不明のエラーを出す場合、ステートマシン図が意外なヒントをくれるかもしれません。まるで、普段は静かに眠っている古の書物から、突如として真理が導き出されるようなものですね。
UMLとITIL構成管理、そしてバージョン管理の融合：システムの今を可視化する
ITILで提唱されている構成管理は、システムの健全な運用には不可欠なプロセスです。しかし、その実践は往々にして手間がかかり、情報が陳腐化しやすいという課題を抱えています。ここでUMLで表現された様々なシステム構成図が有効活用できます。
例えば、配置図で示されたサーバーやネットワーク機器、インストールされているソフトウェアなどの情報は、そのまま構成管理データベース（CMDB）のCI（Configuration Item）として登録されるべき情報です。
さらに一歩進んで、IaC（Infrastructure as Code）やCI/CD（Continuous Integration/Continuous Delivery）といった現代的な開発・運用手法と組み合わせることで、構成管理は効率化されます。UML図もPlantUMLやMermaid、さらにはStructurizr DSLなどのコードとして記述可能なツールで作成し、それをGitやGitHubを含むGit系ツールのようなバージョン管理システムで管理するのです。
- UML図の「コード化」: UML図をテキストベースの記法で記述することで、プログラムコードと同じようにバージョン管理ができます。
- Gitでのバージョン管理: いつ、誰が、どこを、どのように変更したのかが、コミット履歴として把握しやすくなります。これにより、手作業での図の更新漏れや、古い情報が残るリスクを大幅に減らせます。
- CI/CDパイプラインとの連携: IaCでインフラが構築・変更されるたびに、UMLの配置図も自動的に更新されるような仕組みを構築できれば、常に最新のシステム構成がドキュメントとして保たれるでしょう。Terraformなどから得られる状態をUMLに反映させる試みも進んでおり、これは今後の展望として注目されています。ただし、完全なUML図の自動生成はまだ研究・開発段階にあり、技術的なハードルが高い点はご理解ください。
これにより、「いつどのタイミングでどこの構成を直したのか」が、Gitのコミットログを見ればすぐにわかるようになるのです。これは、DevOpsの文脈でいう「設計の継続的改善」を行うループの一部として、設計資産を効率的に管理し、障害発生時の原因究明や、新しい機能追加時の影響範囲分析において、計り知れないメリットをもたらします。構成管理が「自動化される」レベルに近づくかもしれませんね。将来的には、UMLとLLM（ChatGPTなど）を組み合わせた図の自動生成・更新なども、さらなる効率化の道を開く可能性があります。
まとめ: UMLは、未来の「言った・言わない」を防ぐ保険である（個人的な感想）
さて、ここまでUMLの様々な図とその活用法、それが設計書の精度向上といかに密接に関わるか、さらには技術者以外のステークホルダーとのコミュニケーションにいかに役立つか、そしてITIL構成管理と最新の技術トレンドとの融合についても語ってきましたが、いかがでしたでしょうか。UMLは万能薬ではありません。これさえあれば全て解決！というわけにはいきません。しかし、プロジェクトにおける「言った・言わない」の誤解や認識の齟齬を減らし、設計書の曖昧さを解消するための強力なツールであることは間違いありません。
特に、システムの複雑さが増す現代において、言葉だけでのコミュニケーションには限界があります。UMLは、目に見えないソフトウェアの構造や振る舞いを「見える化」することで、チーム全体の理解を深め、よりスムーズな開発を促進します。基本設計書から詳細設計書、さらにはインフラの構成図に至るまで、UMLの活用は、あらゆる設計フェーズでその真価を発揮します。そして、PMとしてクライアントや利用者との合意形成を図る際にも、視覚的なUML図は言葉以上に雄弁に語り、潜在的な誤解の芽を摘み取ってくれるでしょう。
さらに、UML図をコードとして管理し、Gitと連携させることで、ITILの構成管理をより実践的かつ効率的に運用することが可能です。これは、システムの「今」を常に正確に把握し、変化に素早く対応するための強力な基盤となります。
私自身の経験からも、UMLを導入し、それを設計書に積極的に取り入れたプロジェクトでは、手戻りが減り、開発効率が向上したのを肌で感じました。最初は慣れないかもしれませんが、騙されたと思って使ってみてください。きっと、未来のあなたは「あの時UMLを学んでおいてよかった！」と思うはずです。これはあくまで個人的な感想ですが、UMLは、未来の「言った・言わない」を防ぐための、とても手軽で効果的な「保険」だと私は信じています。さあ、皆さんも今日からUMLで、心地よいコミュニケーションの輪を広げ、よりスマートなシステム管理を実現してみませんか？
※ITILはAXELOSの登録商標です。
ショップ リンク – SHOP LINK –
お問い合わせ・ご相談窓口
ITインフラ、Web活用、セキュリティのことでお悩みなら、ぜひご相談ください。貴社の課題に合わせ、最適な解決策をご提案します。
ランサーズ / クラウドワークスからのご依頼も受付中
コメントを残す コメントをキャンセル