愛憎のUML～なぜ「設計図」は消え、「スケッチ」として生き残ったか

「UML」という言葉を耳にしなくなった今、なぜ一つのツイートが10万超の閲覧を記録したのか。
そこにはエンジニアたちの深い愛憎と、理想と現実の乖離がある。
時代が求める「モデル」の形はどう変容したのか。
重厚長大な開発から俊敏なWeb開発へ、設計図からスケッチへと姿を変えた、その生存戦略に迫る。

【1】なぜか、下記のツイートがバズって10万件以上の閲覧、1千件近いいいねがついた。
僕もなぜバズったのか理由も分からない。
単に記事のリンクを貼って、自分用のメモにしただけ。

(1) Xユーザーのakipiiさん: 「これ面白い。なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？｜pdfractal https://t.co/gMUjbOYO7X #zenn」 / X

【参考】
なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？

イントロダクション：複雑化したUMLを救え | 日経クロステック（xTECH）

UML再考: プログラマの思索

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

仕様書にもExcel脱却が求められている: プログラマの思索

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 | 増田 亨 |本 | 通販 | Amazon

改訂新版　良いコード／悪いコードで学ぶ設計入門 ―保守しやすい　成長し続けるコードの書き方 | 仙塲 大也 |本 | 通販 | Amazon

UML モデリングのエッセンス 第3版 | マーチン ファウラー |本 | 通販 | Amazon

ドメイン駆動設計をはじめよう

【2】なぜ、UMLの記事がバズったのか？
理由は、皆、UMLに愛や憎しみがすごく溜まっているので、的確に分析した記事に思わず反応してしまったのだろう。

オブジェクト指向が流行っていた時代、モデリングといえばUMLだった。

UMLを積極的に使っている人は、プログラミングできるだけでなく、モデリングも重要という認識を持ち、非常に高い能力を持つ人が多かったのではないかと思う。
しかし、理想と現実の狭間が大きすぎた。

しかし、UMLで作った設計ドキュメントと実際のソースコードに乖離があり、同期しづらく、労力が掛かる割にはメリットが少なかった。

下記のツイートに一番共感できた。

(1) XユーザーのDr.K Laboratoryさん: 「@akipii Rational Roseを使ってRUPを実践する中でブループリントとしても、双方向ツールのTogetherを使ってプログラミング言語としても経験した身として、身につまされる思い。 RUPは一定以上の規模のプロジェクトだとかなり良かった。 Togetherは使い物にならず。 ファウラーが正しかったという結論かな。」 / X

【3】なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？の記事で、非常に優れた分析だと思う点は、リリース周期の長さと厳密なモデル設計がトレードオフである点だ。

SaaSのようなWebサービスであれば、リリース頻度は1日数回、あるいは何万回もデプロイまでしているだろう。
よって、動くソースコードとモデルを同期するメリットよりも、無駄なコストがかかるというデメリットの方が上回る。
なぜならば、リリースサイクルが極端に短すぎるために、モデルを書いてソースコードを自動生成して同期させる作業がリリース速度に間に合わないからだ。

したがって、動くソースコードそのものが設計書、モデルそのものになる。

一方、UMLのようなモデルが生き残った領域は、重厚長大な産業領域だ。
たとえば、車載ECU、医療機器、防衛装置のように莫大な費用がかかり、ISOのような認証や監査が必要な領域では、モデルとソースの一貫性が求められるからだ。
たしかに、ECU開発ではAUTOSARが事実上の業界標準であり、要件からモデル、ソースコードまでのトレーサビリティを一気通貫で管理できる

しかし、とても重たいプロセスだ。
現場で見ていて、やり方は綺麗だが、設計者も開発者もトレーサビリティの維持にたくさんの労力をかけていて、膨大なドキュメントを作って監査を通す作業に時間を費やしている。
正直見ていて楽しいと思えそうな作業ではなかった。

【4】他方、平鍋さんがイントロダクション：複雑化したUMLを救え（2ページ目） | 日経クロステック（xTECH）で述べているように、、現場でのUMLの利用方法を「スケッチとして（UML as sketch）」「設計図として（UML as blueprint）」「プログラミング言語として（UML as programming language）」の3つに分類して、UMLの生き残りを図る考え方もある。
その結果、なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？の記事の通り、「スケッチとして（UML as sketch）」だけが生き残り、UMLという言葉と関係なく、モデリングという行為そのものが普及したのが現状ではないだろうか。

たとえば、MermaidやPlantUMLのように、MarkdownやテキストでUMLのモデルそのものが簡単にかける環境では、AIにプロンプトで指示すれば、簡単にモデルを描くことができる。
アーキテクチャドキュメントやアーキテクチャデシジョンの1つの資料として、生き残ったのではないだろうか。

そんなことを思うと、UMLは当初の意図から違った歴史を経て、未だに生き残っていると言えるだろうと思う。