UML Unified Modeling Language

UMLとは

　UMLとは、『Unified Modeling Language』の略で『統一モデリング言語』と呼ばれています。

　『オブジェクト指向開発において標準化された図を活用した表記法』であってプログラミング言語ではありません。

　顧客(システム利用ユーザー)の要求を図や絵を主体に顧客にもわかりやすい形で要求定義をまとめる事によりシステム利用ユーザーとベンダー間の意思の疎通を図るべく策定されたものです。

　場合によってはシステム開発における(システム的な表現を一切使用しない)要求定義、(システム的な要素や表現も含めた)要件定義、概要設計、外部設計(基本設計)、内部設計(詳細設計)、プログラム設計、プログラミングなど上流工程から下流工程までの設計書やコーディングの一助として利用されるケースもあるかもしれません。

　従来の(システム開発者寄りの)DFDもその他要求定義手法も、まして要件定義書や仕様書、設計書などは、顧客にはとても理解しやすいものとはお世辞にも言えませんでした。

　この事は、顧客の業界知識に必ずしも長けているとは言えないケースは当然のごとく多く下流工程においても開発チームや、開発者間であっても他チームが作ったものを理解しにくく、チェックが十分に働かず、気づいたときには時すでに遅しというケースも多発しています。

　更にこの為、こうして欲しいと要望した顧客にとっては、どこでどうなっているのかがさっぱりわからないので十分にチェックができず、完成してみたら違うものになっていた。なんて事が多発していました。

　また、逆に開発途中に顧客からいともたやすく変更要求が来る事も多発しています。

　システム開発会社が何をどう作っていて、特にどの部分が根幹をなし、システム上のどことどこが連携していて、その時点での変更要求がシステム全体に与える影響を理解できないために多発しますが、こうなると開発現場は火が噴きます。

　開発現場が火を噴くと納期に間に合わないのですが、一般にこれはどんな理由があろうともほとんどの場合、許されないケースが多い事もあり、中途半端な付け焼刃のシステムが出来上がり、運用するか、または結果的に納期に間に合わない事態につながります。

　つまり、これまでの開発手法が、顧客にわかりにくい事が、顧客にとってもシステム開発会社にとっても不幸な結果を招く大きな原因になっており、システム開発における課題、命題でもありました。

　そんな折ですから、UMLの考え方が採用される事により開発過程のどの時点でも(少なくともこれまでの開発手法以上に)開発者間や顧客が理解しやすい為、こうした不手際も起こりにくくなるという点で注目されている技法です。

　但し、必ずしも顧客がUMLを理解しているわけではないので要求定義の際にUMLの表記法を厳格に求める事はかえって混乱を招く場合もあるので、顧客とベンダー間において「わかり易い図解を用いた要求定義」程度に留め、その内容をベンダーが持ち帰ってUML化し、(システム側の)要件定義書作成の参考にしたり、添付資料とする事が多いと思われます。