あるソフトウェア技術者の方から、UMLについて問い合わせを受けた。その後、UMLツールやこの本を紹介したら次のような追加質問をもらった。【追加質問】
詳しいご回答をありがとうございました。
書籍は早速購入しました。
ＵＭＬツールを使う上で、オブジェクト指向から学ばなければいけないと思っているのですが、どのようにオブジェクト指向とＵＭＬを勉強していけば良いでしょうか？
【追加質問終わり】
この追加質問の内容で、「ＵＭＬツールを使う上で、オブジェクト指向から学ばなければいけないと思っている」というところにちょっと引っかかりがあった。実質的にはそうなのかもしればいが、安直に UML = オブジェクト指向 関連付けると、組込みの場合特に足を踏み外しそうな気がする。
そこで、以下のような返信を書いた。
【追加質問に対する回答（抜粋）】
UMLは表記法です。極端な言い方をすればフローチャートと同じ表記法です。ただ、フローチャートよりは書き方を修得するのに時間がかかります。
では、なぜ修得に時間のかかるUMLを覚えるのか？
UMLが国際標準の表記法となりつつあり、UMLで書いたモデルはたぶん10年近くは（UMLの表記法を認知している人の中で）通じます。
通じるというのは、UMLのダイアグラムを見ながらディスカッションすれば、ソフトウェアの静的な構造や振る舞いについて、素早く認識できるということです。ソースコードを見ながら議論するよりは、絶対効率的です。
プロジェクト内部だけで通じるブロック図でもいいかもしれませんが、プロジェクトの規模が大きくなって独特なブロック図の表記法について質問してくる人が増えたり、新しい人が入ってきたりすると毎度毎度説明しなければいけません。説明しないでもいいくらい単純な図だと、複雑なソフトウェア構造を示すことができないでしょう。
また、ソフトウェアの開発を海外を含む外部に委託するような場合も同じです。ソフトウェアの構造や振る舞いを共通の記述方法で示すことができれば、表記法の説明を省いて本題に早く入れるようになります。
でも、そんなに大きなプロジェクトではないチームだってあります。では、非常に狭い範囲だけでUMLを使うメリットはなんでしょうか？
同じ市場に対して、同じような製品を、同じメンバーで作り続けている少人数のチームがあった場合、UMLでソフトウェアの構造や振る舞いを表記する必要があるでしょうか？
答えは YES です。
理由は、自分たちのために必要だからです。同じ市場に対して、同じような製品を、同じメンバーで作り続けている少人数のチームであっても、ソフトウェアの規模は年々大きくなっているはずです。この規模が大きくなってしまったソフトウェアシステムの構造や振る舞いをUMLで表現することには意味があります。
例えば次のような目的のためです。
－UMLを使う目的－
- 全体を俯瞰して、どのような責任分担でソフトウェアが分割されているのかが分かる。（上記のようなチームであれば、このモジュール分割が技術者の責任分担にもなる）
- 分割されたサブシステム同士の関係（依存関係、呼び出し関係）が分かる。（サブシステムの独立性を高めるのに役立ちます）
- システム全体もしくは一部の状態遷移が分かるようになる。（状態遷移図・・・古典的ですがやっぱり分かりやすいです）
- そのシステムで何かをしたいときのシーケンスを表現できる。（役割分担と手順が分かると、具体的に何をすればいいか見えてきます）
いままでの小規模なソフトウェアプロジェクトでは1～4までの内容は、そのシステムの構造や振る舞いを最初に設計した技術者（アーキテクト）の頭の中だけに暗黙知として存在していました。考え方によっては、その技術者（アーキテクト）をチーム内にずっとキープしておければ、次々に新しい製品を開発できるとも言えます。
しかし、ソフトウェアシステムの規模は一人のアーキテクトでは把握しきれないくらいの大きさにまで拡大しており、また、ソフトウェアシステムに対する要求が複雑化すると、システム全体の構造を熟知しているアーキテクトしか分からない仕事が増えてしまい、そのアーキテクトの仕事が集中し、ついには破綻させてしまったり、その組織から逃げ出されてしまったりします。
悪循環から脱しきれないソフトウェアプロジェクトは、代わりとなる優秀なアーキテクトを探そうとし、人材不足の世の中、結局代わりのアーキテクトは見つからない場合もあるでしょう。その場合は、残されたメンバーで全体構造がよく分からないままソフトウェアを付け足し続け、最初のアーキテクチャを崩ししてしまい、悪循環のスピードを速めてしまいます。
また、運良く変わりのアーキテクトを見つけることができた場合、見つけられてしまったアーキテクトは前任のアーキテクトと同じように過負荷にさらされることになります。このとき、ソフトウェアシステムの構造や振る舞いを示すドキュメントが存在しないと、ソースコードからそれらを分析することになり、立ち上がりには相当な時間を要するでしょう。
もしも、ソフトウェアシステムの構造や振る舞いをUMLで表現できれば、次のような可能性がでてきます。
－UMLでソフトウェアシステムの構造や振る舞いを可視化できると・・・－
- サブシステム単位で力のいれ具合に強弱を付けることができる。（まずは、このサブシステム、このモジュールの信頼性を高めようというアプローチが可能）
- 再利用資産を抽出することが可能となり、開発の効率を高めることができる。
- 不具合が起こったときに、原因となるサブシステムやモジュールを特定しやすくなる。（責務で分割されているため、発生した現象から原因を作った犯人を見つけやすい）
- 新たな要求が降りかかってきたとき、どのサブシステムやモジュールに影響を及ぼすか事前に分析できる。
- 新たな要求が降りかかってきたときに最小限の変更ですむような、システム構造を変更できる。（アーキテクチャの見直し）
新しい技術を習得するためには、時間や費用が必要です。こられのリソースを確保するためには、組織に対しては修得した技術で開発効率やソフトウェア品質を高め、顧客満足を高めることに貢献できることを説明し、プロジェクトメンバーにはその技術の習得が余裕を生み、クリエイティブな仕事ができるきっかけになることを示さなければいけません。
UMLをなぜ使うのかをしっかりと考えて、先に進んでください。
：
【追加質問に対する回答の抜粋終わり】
P.S.
上記の回答文章は質問に返信するつもりで書いたが、結局はブログネタとして使い本当の回答文章はもっともっと簡略化した。だって、こんな長い文章をメールで返信したらどう見てもへんでしょ。
