第2部:UMLに関する素朴な疑問・誤解解決篇
Q2-1)UMLを導入するにはどうするのが近道ですか?
羽生田栄一
株式会社豆蔵 取締役会長
2003/4/16
UMLに関する素朴な疑問・誤解解決篇の第1回は、どうやってUMLを自分の組織に導入するか、上司をどうやって説得するか、という難題です。よく、こんな質問をいただきます。
◆「UMLを事業部長に説明しなければならなくなりました。忙しい経営者に一言でUMLのことを伝えるとしたらどういうふうにいえばよいのでしょう」
一言で言うと、「Q1-1)UMLダイアグラムの基本を教えてください」の説明を読んでください。というのもあんまりなので、以下のような説明を試みてはどうでしょう。
「ソフトウェアやシステムの仕組みをビジュアルに表現する設計図面の描き方、文法がUMLです。業務に含まれるモノや概念、システムを構成するモジュールやデバイスをオブジェクトとして、それらの構造と動作、関係などを複数のダイアグラムを組み合わせてビジュアルに分かりやすく描写することができるのです。UMLは世界標準のモデル記述言語ですから、いまでは、世界中のシステムエンジニアが、さまざまな業務システムやシステム製品を開発する際に、UMLのダイアグラムを利用して企画、設計、実装を進めていますよ。インドのエンジニアも中国のプログラマも米国のシステム設計者も皆UMLが理解できる可能性が高いので、世界規模の分散開発、チーム開発においてコミュニケーションを高めるのにも有用ですよ」と。
またこんな質問もあります。
◆「UMLを導入したいのですが上司を説得するために、 具体的な手っ取り早いメリットを教えてください」
上の説明を再度繰り返せばばっちりです。というのもあんまりなので、以下のような個条書きで整理されてはいかがでしょうか。
ビジュアルな設計図をソフトウェア開発に導入することで、「ソースコードよりも扱いやすく理解しやすい」=「図面を中心にプロジェクトの企画や設計、管理を進めていくことができる」ようになる |
図はソースコードと違い、広げることで多人数が同時に参照できるので、企画や設計、レビューなど、共同作業・チーム開発におけるコミュニケーションを支援してくれる。それにより、認識のズレや誤解を解消する機会が増える |
1人で分析や設計をするときでも、図面を描くことで、業務やシステムの全体像、第三者的な視点、異なる観点同士の比較や切り替え、といった多様な物の見方が手に入り、デザイン作業がやりやすい |
UMLの一部のダイアグラム(ユースケース図や単純化した概念クラス図、アイコンで装飾したアクティビティ図など)をうまく使うことで、「エンドユーザー、クライアント」と「開発者」とのコミュニケーションの助けになる可能性がある |
UMLは、世の中で広く普及し始めているので、他社との共同開発作業を行うときに必要となるコミュニケーションのツールとなる。つまり、世界共通の言語として、要求や仕様・設計をやりとりするのに有効な手段となる。特に、近年の国際的な分散開発においてインドや中国の開発者とのコミュニケーションには、共通ビジュアル言語としてのUMLを使う可能性は甚だ大きいといえよう |
組織内で、分析や仕様策定、設計に関する文書をUML図面という形で蓄積していくことにより(当然そこに、モデル図面の整理・共通化・資産化のための担当者やチームの存在が欠かせませんが)、モデルや設計ノウハウの共有による「再利用」という可能性が開けてくる |
UML自体は単なるモデル記述言語にすぎないが、UMLの導入をきっかけにして、さらにその背後に控えているオブジェクト指向の繰り返し型ソフトウェア開発プロセスやコンポーネントベース開発方法論といった新しい開発スタイルにまで到達できれば、組織の生産性や開発力は格段に向上し、経営に資するところ大といえよう |
表1 UML導入のメリット |
あと一番手っ取り早いのは、すでにA社のXX事業部でも、B社の情報システム部門でもUMLによるモデリングを導入してプロジェクトを成功させていますよ、といった事例で攻めることでしょうか。ネットや雑誌でうまく上司の心に迫る具体的事例を探してみてください。
さらに、こんな質問もありますね。
◆「UMLの組織への導入はどんな手順で進めていけばよいのでしょうか」
以下のような点に注意して、個々の組織で使えるダイアグラムから徐々に導入を進めていきましょう。先行チームが成功事例を作ることで、一気に横展開する、というパターンが理想ですね。それぞれの組織に合った導入戦略を立ててみてください。
取りあえずUMLクラス図の初歩だけ勉強する |
クラス図やシーケンス図などUMLの必要な部分だけ取りあえず使う |
日常の身の回りの事象をUMLでモデリングする訓練をする |
Javaや.NET/C#などの言語でプログラミングする前に必ずUMLで簡単な設計方針を描いてからコーディングする癖をつける |
小さなプロジェクトやプロジェクト内のサブシステムで実践し、徐々に周囲に広げていく |
UMLをトップダウンで開発共通言語にすると宣言してもらうようトップに根回しする |
UMLを使って、開発で得たノウハウをモデルテンプレートやパターンとして記録する癖をつける |
表2 組織へのUML導入の注意点 |
上司を説得する前に、まずは自分がUMLの利点を知らなくてはなりませんね。そのため、こんな質問もよくあります。
◆「UMLに関するお薦めの本を紹介してください」
近年UMLに関する書籍は出版ブームでどれを選んでいいか分からないといった状況です。惑わされずによい本を選びましょう。取りあえず1冊というときには『やさしいUML入門-Javaオブジェクト・モデリング』をお薦めしています。Javaとのマッピングを通して、取りあえずUMLで分析、設計、実装するための基本中の基本が非常に丁寧に押さえてあります。
もう少しモデリングに踏み込んで各UMLダイアグラムを理解したいという人向けには『UML モデリングのエッセンス第2版』がお薦め。UMLの実践的知識とオブジェクト指向開発プロセスの基本を一通り知ることができます。
UMLという言語そのものを仕様からきちんと理解したいという言語マニアには、『UMLユーザーガイド』と『UML仕様書』の2冊が必読。
UMLによるモデルの実例が見たいという人には一種のサンプルモデル集として『即戦UMLモデリング-業務・業種別サンプル集』と『わかりやすいUML入門』の2冊がお薦め。ただし本当の実業務のモデルではないので、あくまでも学習用と割り切って読む必要があります。
IT Architect 連載記事一覧 |