モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか

下記の記事で、モデルの粒度とトレーサビリティの問題はモデリングツールではなくUMLそのものに真因がある、という事実に気づいたのでメモ。
以下、ロジカルでないラフなメモ書き。

【参考】
プロジェクトを成功させるモデリングの極意（3）：UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MONOist（モノイスト）

akipiiさんのツイート: "「UMLの使いにくいところと開発現場での実際的対応」の内容が本当に同感。UMLそのものが大規模案件で使うことが想定されてない問題があると思う。プロジェクトを成功させるモデリングの極意（3）：UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MO… https://t.co/qHIjmtpMKt"

【1】(引用開始)
UML/SysMLの使いにくいところと、それを使いこなすコツ
　UMLとSysMLは組み込み系開発で比較的多く使われていますので、ここではUMLとSysMLの使いにくいところと、開発現場でそれを克服して使いこなすコツを紹介していきます。

UMLの使いにくいところと開発現場での実際的対応

（1）階層記述ができない
　UMLで大規模なシステムをモデリングするときに、使いにくい欠点としては「階層記述」ができないという点を挙げることができます。大規模なシステムでは、ユースケースやクラス、オブジェクト、シーケンスなどの個数が膨大な量になり、ユースケース図やクラス図、シーケンス図などを描くときに階層記述ができないと非常に大きな紙が必要になります。A3用紙であっても描ききれなくなります。

　そこで開発現場では何らかの工夫をして、これらの図を階層記述をしているのが実情です。しかし、階層記述の方法が統一されていないため、各組織や各プロジェクト、さらに個人で違う記述をしていることがあります。結果として、階層記述の方法を確かめるところから、レビューを始めるということになります。

（2）要求図が弱い
　UMLで要求をまとめる図はユースケース図とそれを補間するシナリオ記述、さらに詳細に記述するためにアクティビティ図などを用いますが、要求図としての分かりやすさとしては不十分です。

　ユースケース図で要求とそれらの概略の関係は分かりますが、要求の一覧や要求間の関係、特に内包関係、要求の差分、要求の優先度などの記述は弱いものになっています。それを補間するシナリオ記述は基本的に自然言語で記述するため、モデラーの表現能力に大きく依存します。逆にアクティビティ図は機能がありすぎて、要求を記述すると別の図のようになってしまいます。

　開発現場ではユースケース図で要求の概略を表現し、詳細や一覧は昔ながらのExcelを使って自然言語で記述し、それに要求番号を振って、トレーサビリティを高めているような記述方法をよく見かけます。

（3）仕様が膨大で不統一
　UMLはその歴史から分かるように、モデル図と仕様が膨大になっていて、その思想も記述も不統一です。平たく言えば、図がばらばらで多すぎます。図が多いので、真面目なメンバー（融通がきかないメンバー）はどうしても多くの図を描いてしまいます。類似の情報を複数の図やその説明で見かけることになります。さらに悪いことにその用語や使い方がモデル図間で統一されておらず、同じ用語でもモデル図で違う情報になっていることもあり、どれを信用するか分からなくなります。まさしく魑魅魍魎な図になりがちです。

　開発現場では新規の開発よりも既存開発（改良開発）が多く、既存の多数のUML図をほぼコピペして再利用していることが多くなっています。コピペで低コストなのはいいことかもしれません（本当はそんなことはありません！）が、図が多いため、差分管理ができずに、全ての図の全ての部分を延々と保守続けることになります。いざ差分を探そうとすると、非常に面倒なことになります。

（4）トレーサビリティが弱い
　各モデル図で使用した要求やクラス、オブジェクト、シーケンスなどが他の図でどのようになっているかを追跡するときに、UMLでは弱すぎます。UMLツールによって、ある程度のトレーサビリティは保証されますが、図として見た場合は、トレーサビリティがなく、見にくくなっています。

　開発現場では、ここでもUML図とは別にExcelなどを使って、トレーサビリティを保証するようにしている場合が多くなっています。

（5）目的が総花的
　仕様が膨大という欠点と同様ですが、UMLを描く目的が曖昧になるとUMLで作ったモデルも総花的になりがちです。このため、モデル図は大きくなり、大きな紙（A3用紙）を必要とします。

（6）コード生成が弱い
　UML2.0になってコード生成は強化はされていますが、UMLでコード生成をするのは弱く、はっきり言って、使いものになりません。特に例外処理のコードも含めると面倒なことになります。最初の1回はコード生成をしても、その後、プログラムを変更する必要が生じたときに、モデル図から変更するのは骨が折れます。心が折れます。

（7）差分表記（相違性と共通性の表記）が弱い
　これはUML特有の欠点ではなく、多くの図的表現に当てはまりますが、以前のシステムとの差分、以前のモデル図との差分の記述が明示的にできません。ソフトウェアプロダクトラインエンジニアリング（SPLE）で使われるフィーチャー図のように差分を明示的に記述できません。開発現場では前のモデル図とどこが変わったのか、逆にどこが同じなのかを何らかの方法で記述し、共通部と差分（派生部）を明確に示す必要があります。

（5）その他のコツ
　UMLの各図では目的を絞って描く、コード生成には使わない、一覧表示などの管理は別にするなどがあります。
　ここではUMLの悪口とその対応の面倒くささを紹介した形になりましたが、これは逆に開発現場でUMLが定着し、使っている人が多いからこそです。この記事を読んで別のものを使おうとせずに（苦労はするかもしれませんが）UMLを使ってみてください。
(引用終了)

【2】astahをずっと使い続けてきて、モデルの粒度とトレーサビリティ、変更管理に関して不満があったので、その問題点について下記で考えていた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

しかし、上記の記事を読むと、モデリングツールの問題ではなく、UMLの仕様そのものに真因があるようだ。
UMLでは、アーキテクチャを描いたモデルの階層化やトレーサビリティに関する仕様またはプラクティスがほとんど見られない現状がある。

一方、実際の開発現場では、要件定義から基本設計、詳細設計へ工程が進むにつれて、モデルの粒度はどんどん詳細化していく。
もっとモデルを詳細化すべきだ、という認識になったら、普通は次フェーズの工程で作業するように予定する。
つまり、各工程の設計モデルに関する粒度については、基本は設計者の間で認識は統一されているのが一般的だ。

また、要件から画面帳票の詳細設計書に至るまで、普通は設計書の間でトレーサビリティを確保するように、開発プロセスを計画する。
なぜなら、各工程のアウトプットが次工程のインプットになるので、トレーサビリティを意識しなければ、詳細設計書の正当性を保証できないからだ。
一般に、Excelの管理台帳で、要件定義書、基本設計書、詳細設計書の一覧を管理し、それらの間の関係を何らかの形で保守し続ける。

そういう現実を考えると、UMLでは各工程の成果物の粒度やトレーサビリティに関する基本方針がない点に問題があるような気がする。

【3】では、なぜ、UMLでは粒度やトレーサビリティに関する問題点にあえて触れていないのか？

理由はおそらく、粒度やトレーサビリティに関する仕様は、各案件で多種多様な運用ルールがありうるので、標準化する作業そのものが難しいからだろう、と推測する。
もし、粒度やトレーサビリティに関する標準ルールを決めたとしても、抽象的すぎて、実際の現場では、その仕様に耐えうるテーラリングにすごく時間や労力を費やすしかないのではないか。

似たような事例として、過去に、IPAがソフトウェアタグという仕様を定めて普及しようと頑張っていた事例があったけれど、実際の現場にはほとんど影響しなかった。

IPA 独立行政法人 情報処理推進機構：ソフトウェアジャパン2009 IPAフォーラム

コンピュータソフトの開発過程が一目でわかる仕組みを世界で初めて規格化 複雑化、大規模化する製作状況に対応した「ソフトウェアタグ」｜奈良先端科学技術大学院大学

理想論としては、ソフトウェアタグのような符丁をソフトウェア成果物に組み込めば、農産物や製品のトレーサビリティのような運用が可能なはず。
しかし、ソフトウェアはそれらモノとは違って、実体が曖昧で管理しにくいために、現実に運用しにくい。
結局、粒度やトレーサビリティに関するExcel管理台帳が余計に増えていくだけで、その保守コストが増えていくだろう。

【4】また、UMLで変更管理や構成管理の問題を解決するアイデアはないのか？
UMLの仕様に関する最新情報は知らないので、この辺りは分からない。

しかし、UMLでモデルをお絵描きしても、その後の保守で問題となるのが、構成管理や変更管理の話題だ。
実際、本番リリース後の保守フェーズで、細かな仕様追加や仕様変更が発生すれば、その都度モデルを修正していくコストが発生する。
その作業コストは意外とバカにならない。

また、仕様変更前のモデルと仕様変更で変わった後のモデルの差分を表示する機能がモデリングツールでは弱い。
だから、その後の保守作業で、作業者が頻繁に入れ替わったら、変更理由や本来の意図も分からなくなりがちだ。

さらに、Gitならフィーチャーブランチを切って、マージする時にプルリクエストを送ってコードレビューを依頼する、という一連のプラクティスをモデリング作業に適用しにくい。
つまり、モデリングのレビューは、昔ながらのレビュースタイルで実施せざるを得ない。

モデルの構成管理、変更管理に関する問題は、10年以上前からほとんど進歩がないように思える。

【5】さらに、UMLそのものにその弱点が内包されているとすれば、どんな影響が出てくるのか？

僕は、大規模システムでは特に、モデルの粒度とトレーサビリティに関する枠組みがなければ、現実的に運用しにくいだろう、と考えている。

たとえば、大企業向けのERPは、販売管理、発注管理、生産管理、会計管理、人事管理など数多くのサブシステムで組み立てられている。
それらサブシステム単位に要件から仕様まで数多くのモデルがあり、それらが階層化されて、トレースされていなければ、描いたモデルは設計書の代わりにはならない。

また、描いたモデルの粒度について認識が合わなければ、設計者と開発チームのコミュニケーションを促進されないだろう。
さらに、大規模システムでは、数多くのテーブル、画面帳票、バッチがあり、機能が複雑に絡み合っているので、元々混乱しがち。

10年以上前に、オブジェクト指向開発プロセスが流行していた頃、全ての設計書をEnterprise Architectのモデルで描いて、Javaで実装するWebシステム開発案件に加わっていたが、内実は混乱していたのを思い出す。

【6】このように、UMLの仕様そのものに、モデルの粒度とトレーサビリティ、変更管理の問題が内包されているので、その仕様そのものを実現したモデリングツールもその問題点をそのまま現状に反映しているだけ、と理解できる。
つまり、モデリングツールに罪はない、と僕は考えた。

一方、モデリングツールがUMLの弱点を解決していく、という方向性もあるのではないか、と考えている。
つまり、モデルの粒度とトレーサビリティ、変更管理に関する問題は、むしろ、モデリングツールが積極的に解決できる分野ではないか、と考えている。

実際、業務フローやアーキテクチャをモデリングしていたら、モデラーは自然に、自分が描いているモデルの粒度を揃えたり、詳細化していく時にトレースしながら仕様を詰めているはずだ。
よって、モデリングツールが、モデラーの思考行為そのものを支援するように操作性を向上させることは可能なはずだ。
つまり、モデリングツールは、モデラーのモデリング作業を補完する統合設計環境であるべきだろう。

その辺りも今後考えてみる。

【追記】
モデル駆動開発の考え方について、良い記事があるのでリンクしておく。

モデル駆動開発におけるモデル変換の役割 (1/2)：CodeZine（コードジン）

akipiiさんのツイート: "モデル駆動開発用ツールBridgePointを使って、クラス図とステートマシン図を作成して実際にシステムを動かすお話。面白い。モデル駆動開発におけるモデル変換の役割 (1/2)：CodeZine（コードジン） https://t.co/StxjQjZ8pg"