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

はじめに

2000年代の開発現場では、UML という語は一種の共通語でした。オブジェクト指向を語るならUMLを知っていて当然だとされ、書籍も研修もツールも、その前提で組まれていました。しかし現在、日常会話の中で「UMLを描こう」と言う場面は激減し、代わりにMermaid(軽量な図記述ツール)やPlantUML(テキスト記述からUML図を生成するツール)で必要な図だけを書くという言い方が普通になっています。この落差は、単なる流行語の交代ではありません。設計の正本をどこに置くのかという、開発の重心そのものが移った結果です。

本稿はラショナル起源の重いUML と、ファウラーが後から整理した 軽いUML と、2010年代以降の 高速な開発環境 が、どのようにぶつかったのかということを語ります。結論を先取りすれば、消えたのは図そのものではなく、UMLという名称に付着していた制度と商売でした。そして残ったのは、UMLの中でも本当に役に立つ断片だけだったという話です。

UMLは誰が何のために作ったのか

UMLは、そもそも 重厚長大 な方向に傾きやすい土壌から生まれました。OMG自身の説明では、UMLはラショナルソフトウェアとそのパートナーによって開発されたものであり、ブーチ法、OOSEヤコブソン法、OMTなどを統合した後継記法です。要するにUMLの出発点は、現場のラフスケッチではなく、複数の方法論を統一するための 標準化プロジェクト でした。ここにすでに、「軽い会話の道具」だけでは済まない性格が埋め込まれていました。

しかもこの統合は、単なる図法統一では終わりませんでした。UMLは、業務分析、要求管理、設計、プログラミング、テストまでをまたぐ共通表現として位置付けられました。つまり最初から、UMLには「一つの図法で開発全体をつなぎたい」という欲望が載っていたのです。その欲望自体は理解できますが、後に UML万能論 に化ける原因にもなりました。

さらに2003年にはIBMがラショナルを買収し、ラショナルはIBMのソフトウェア事業の中に組み込まれました。この買収によって、もともと方法論色の強かったUML周辺は、より大企業向けのツール群と結び付きやすくなります。ここでUMLは、単なる記法ではなく、プロセス、製品、教育、監査、成熟度の文脈まで背負う存在になりました。後年「UML」と聞いただけで重い印象が立ち上がるのは、この歴史的経緯のせいです。

ファウラーが擁護したUMLは何だったのか

ここで重要なのが、ファウラー です。彼はできあがったUMLを 切り詰めて読み替えた 人でした。彼はUMLの使い方を スケッチ、ブループリント、プログラミング言語 の三つに分けました。この三つのうち、2000年代にUMLとして売られていた重い姿の本丸はブループリントです。ブループリントとは、図を完全な設計書として扱い、実装者はその図を見ながら機械的にコードへ写し取ればよい、という立場を指します。設計者と実装者を分離し、モデルから実装までを一気通貫で支配しようとする発想は、この延長線上にありました。ファウラー自身はこの立場にはっきり距離を置き、自分が重視するのはスケッチだと明言しました。彼にとって図は、完全な仕様書ではなく、重要な点だけを伝えるための会話道具でした。「網羅性は理解しやすさの敵である」という有名な言い回しは、この立場を端的に表しています。

この立場からすると、ファウラーはUML全部を礼賛していたのではありません。彼は、図が役に立つのは、全体を厳密に記述したときではなく、必要なところだけを選択的に描いたときだと考えていました。しかも彼は、良い図が必ずしも永続成果物である必要はなく、役目を果たしたら捨ててもよいと述べています。これは、後年のMermaid的な軽量図法とかなり近い感覚です。

さらに彼は、コードこそが主文書になりうると明言しています。理由は単純で、コードだけが十分に詳細かつ正確だからです。つまりファウラーの立場は、図を主、コードを従とするものではありません。
コードが正本 であり、図はその理解や対話を助ける補助線にすぎないという整理です。後のアジャイル的な感覚と矛盾しないのは、まさにこのためです。

2000年代の現場は礼賛ほどUMLを使っていなかった

2000年代を振り返ると、UMLは確かに大きな看板でした。しかし、実務がその看板通りに動いていたかというと、そこはかなり怪しいです。実務研究では、UMLは「支配的記法」と呼ばれながらも、現場での利用は一様ではなく、使い方には大きなばらつきがあると報告されています。つまり、表向きの礼賛と、実際の運用の間には最初から温度差がありました。

とくに重要なのは、2007年調査で、UMLの使用率は52%であり、モデリングツールは主に初期設計で使われ、コード生成は広く使われていない とされた点です。これは、MDA(モデル駆動アーキテクチャ)や完全なモデル駆動開発が華々しく語られた時代であっても、現場がそこまで到達していなかったことを意味します。また同じ文脈で、問題点として挙げられていたのは、図の品質、非形式的利用、モデリング規約の欠如でした。要するに、多くの現場は最初から、教科書通りの厳密UMLではなく、UMLっぽい何か で回っていたのです。

だからこそ、後にUMLの熱が冷めても現場は意外と困りませんでした。もともと完全UMLで全工程を回していたなら、そこからの離脱は大事件になったはずです。しかし実際には、現場は最初からクラス図やシーケンス図の一部だけを使い、残りはフリーハンドの箱線図や説明図で済ませていた可能性が高いです。その意味で、UMLは「一度完全に支配してから滅びた」のではなく、看板だけ巨大で、実務は最初から部分利用だった と見る方が実態に近いです。

MDAというUML制度の最大の不渡り手形

UML制度の極北に位置していたのが、MDA です。MDAは、プラットフォーム非依存モデルからプラットフォーム依存モデルを経て実装コードまでを自動生成するという、壮大な構想でした。ここで重要なのは、MDAがUMLという看板が背負っていた 最大の約束手形 だった点です。「図を正しく描けば、コードは自動的に出てくる」という約束です。この約束が果たされていれば、設計者と実装者の分離にも、ブループリント的な重いUMLにも、それなりの経済合理性がありました。

ところが前節で触れた2007年調査が示したのは、現場ではコード生成はほとんど使われていないという事実でした。つまりMDAは 事実上の不渡り を出したのです。生成されるのは骨組みだけで、肝心の振る舞いはどのみち人間が書く必要がありました。しかも生成コードを手で直すと、モデルとの往復同期が崩れ、結局はコードとモデルの二重管理が常態化しました。ファウラーが早くから「コードが主文書」だと言っていたのは、MDAが前提にしていた逆方向の支配構図、つまり モデルが主でコードが従 という構図に、実装面での根拠が乏しいことを見抜いていたからです。

MDAが不渡りを出したことの影響は、UML制度全体に波及しました。CASEツール、RUP、監査向け成果物、モデル中心の教育パッケージは、いずれもMDA的な自動化の夢を背景に正当化されていた面があります。その夢が現実にならなかったため、UMLを重く運用する経済的根拠は根元から抜けました。ここから後の衰退は、半ば必然でした。

2010年代に何が起きたのか

流れを決定的に変えたのは、2010年代初頭に顕在化した 技術環境の変化 です。アマゾンウェブサービスは2006年3月にS3を開始し、アップルは2007年1月に初代iPhoneを発表しました。そして2010年代前半には、Jenkins(オープンソースの継続的インテグレーションサーバ)を中心とするCI/CDの普及と、GitHubを介した日常的なコードレビュー文化が一般化しました。この三つは、同じ経路で開発の前提を変えたわけではありません。クラウドは供給側から働き、環境調達の待ち時間を縮めることで、試しては直す小刻みな作業を可能にしました。iPhoneは需要側から働き、モバイル対応を必須化しただけでなく、アプリストアとOS更新を通じて、短い更新周期を常態として市場から要求する状況を作りました。CI/CDと共有リポジトリ文化は運用側から働き、コードの変更と検証を日次レベルで回す基盤を開発現場に持ち込みました。つまり供給、需要、運用基盤の三方向から同時に圧力がかかった結果、開発の前提である 変更速度 そのものが上がったのです。

ここで見落としてはいけないのは、アジャイル宣言の方が先にあり、環境が後からそれに追いついたという因果の向きです。宣言は2001年の時点で、動くソフトウェアを包括的ドキュメントより重視する、計画に従うことよりも変化への対応を重視する を明示していました。2000年代にはこれが理想論や反骨のスローガンに見えた場面もありましたが、2010年代に入ると事情が変わります。アジャイルが能動的に勝ったというより、市場と技術基盤の側がアジャイルの前提条件を満たしてしまった のです。アジャイルが評価されたのは、環境の方がアジャイルの想定する世界に近づいたからでした。

実際、2014年のState of Agile調査では、回答者の90%が少なくとも1年以上のアジャイル経験を持ち、58%は3年以上の経験を持つとされています。また、企業としての経験でも、3年以上アジャイルを実践している組織が過半に達し、採用理由の上位は、製品提供の加速、優先順位変更への対応、生産性向上でした。つまり2009年から2014年頃にかけて、アジャイルは一部の先進現場の流儀ではなく、かなり普通の実務へと移っていきました。ここで重くなったのが、コードとは別に完全な設計世界を維持するやり方でした。

しかも皮肉なことに、同じ調査では、アジャイル案件の管理にMicrosoft Excelが68%で使われ、IBM Rationalは13%にとどまっていました。これは非常に示唆的です。現場が求めていたのは、方法論の権威や重い統合環境ではなく、すぐ使えてすぐ直せる道具だったということです。ここに、2000年代型のUML商売が急速に居場所を失った理由がよく表れています。

死んだのはUMLではなくUMLという制度である

この転換を「図が不要になった」と理解すると、話を取り違えます。本当に死んだのは、UMLという制度 です。すなわち、図を完全な設計書にし、設計者と実装者を分け、モデルから実装までを一気通貫で支配しようとする発想です。変化の遅い時代ならまだ回っても、変更頻度の高い時代には、これはほとんど確実に 二重管理 へ化けます。

ここで重要なのは、二重管理が単なる手間の増加ではなく、情報の腐敗構造 だという点です。コードが変わるたびに図を直す義務が生まれ、しかも直されなかった図は消えずに残り続け、嘘をつき始めます。変更速度が上がるほど、図の腐敗速度も上がります。腐った図は、ないよりも悪い情報源です。読んだ人間を誤解させ、かつ「一応ある」という事実によって、新しい図を描く動機まで奪うからです。ファウラーが「役目を果たしたら捨ててよい」と繰り返したのは、まさにこの腐敗の問題を避けるためでした。軽量図が生き残ったのは、記法が優れているからというより、捨てやすいから です。

ファウラーがコードを主文書と見なしたのも、この問題に対する現実的な答えでした。コードに実装があり、テストに挙動があり、リポジトリに履歴があるのに、その外側でもう一つ完全なUML世界を同期させるのは高くつきます。変更頻度が低いなら我慢できても、リリース周期が短くなると、それはただの負債になります。2010年代にUMLが一気に聞かれなくなったのは、図法が間違っていたからではなく、維持費が便益を上回った からです。

しかも「UML」という語は、単なる図ではなく、CASEツール、RUP、MDA、監査向け成果物、大企業向け教育パッケージまで連想させます。だから現場が軽量化に向かうほど、その語自体が敬遠されやすくなります。実際にはシーケンス図や状態遷移図を書いていても、それをわざわざUMLと名乗る必要がなくなるのです。ここで消えたのは図ではなく、UMLという看板に付いていた重力 です。

UML制度が死んだ領域と生き残った領域

ただし、UML制度の死は世界中のあらゆる開発領域で起きた現象ではありません。機能安全や認証が絡む領域では、むしろ形式的なモデル記述は現役です。自動車組込みではISO 26262、航空ではDO-178C、医療機器ではIEC 62304が成果物としてのモデルと追跡可能性を要求します。これらの領域ではSysML、MATLAB/Simulink、Stateflow(いずれもMathWorks社によるモデルベース開発ツール群)といった、UMLの系譜に連なる形式的記述が、むしろ必須の位置を占めています。

この非対称性は、リリース周期の長さ で説明がつきます。Web領域はリリース周期が日次や週次に短縮され、図を維持する費用が便益を容易に上回ります。一方、自動車のソフトウェアは型式認証を経る以上、そう簡単には更新できません。航空や医療も同様です。リリース周期が年単位で、しかも失敗時の損害が人命に直結する領域では、図の腐敗速度より変更速度の方が遅いため、モデルと実装の二重管理が成立し、むしろ安全網として機能します。

したがって、UML制度が死んだというのは普遍的な現象ではなく、変更速度の高い領域に限定された現象 だと言うべきです。境界線は業界ではなく、リリース周期の短さとモデル維持費の損益分岐点 にあります。この境界を意識しないまま「UMLは死んだ」と言い切ると、組込みや安全系の現場を見落とすことになります。UMLを殺したのは新しい図法ではなく、変更速度の上昇 であり、変更速度が上がっていない領域では、UMLは依然として生きています。

それでもUML的な図はむしろ広がった

ここがいちばん面白い逆説です。Web領域ではUML制度は死にましたが、UMLっぽい図 はむしろ日常の中に入り込んでいます。Mermaidはフローチャートだけでなく、シーケンス図、クラス図、状態図、ER図、C4図(ソフトウェアアーキテクチャの階層図法)まで扱えます。PlantUMLも、シーケンス図、ユースケース図、クラス図、状態図などのUML図を広くサポートしています。
つまり図法としてのUML要素は、看板を失って拡散したのです。

しかも現在は、図を書く摩擦が昔よりはるかに低いです。GitHubではMermaidのレンダリングが、Issues、Discussions、プルリクエスト、Wiki、Markdownファイルで利用できます。Mermaid自身も、主目的を「ドキュメントを開発に追いつかせること」だと説明しています。これは、図を完成品として奉るのではなく、開発速度に追随する軽量文書として扱う発想です。ファウラーのスケッチ論にかなり近い着地点だと言えます。

したがって、現在起きていることは「UMLの不在」ではありません。むしろ、UMLのうち本当に役立つ部分が、Mermaidや、PlantUMLや、Markdown文化の中へ吸収された結果です。だから見かけ上は「UMLは死んだ」のに、実質としてはシーケンス図や状態図の記述機会が増えていても不思議ではありません。名称として避けられるようになったのは、UMLという語がCASEツール、RUP、MDA、監査文化までを連想させる重い語彙になってしまったからです。死んだのは ブランドとしてのUML であり、生き残ったのは 図法としてのUMLの断片 です。

まとめ

2000年代にUMLが猫も杓子も口にされたのは、それが単なる図法ではなく、標準化、統合、管理可能性 の象徴として売られたからです。その起源はラショナルソフトウェアによる方法論統合にあり、OMGの標準化とIBM時代のツール商売を経て、UMLはますます重い意味を背負いました。その後、ファウラーが打ち立てた軽いUMLと、市場が売理続けた重いUMLの間には、すでに深いずれが生じました。

実務では当初からUML全面運用は限定的で、主として初期設計や非形式的利用にとどまっていました。
UML制度の背骨であったMDAは、コード生成の実用化に失敗し、事実上の不渡りを出しました。そこへ2006年以降のクラウド、2007年のiPhone、2010年代前半のCI/CDと共有リポジトリ文化が重なり、変更速度が上がりました。アジャイルが能動的に勝ったのではなく、環境の側がアジャイルの前提条件を満たしたのです。この環境では、コードと別に完全なモデル世界を維持する費用が急速に重くなり、図が腐敗する速度も上がりました。その結果、先に死んだのは図ではなく、UMLという名称に付随していた制度と二重管理でした。

ただしこの死は普遍的なものではなく、変更速度が高い領域に限定された現象 です。機能安全や認証が絡む領域では、SysMLやSimulink等の、MDA的な枠組みはむしろ必須の位置を占めています。一方、Web領域ではMermaidやPlantUMLのような軽量手段の中で、シーケンス図や状態図やクラス図が普通に使われています。したがって「UML」が聞かれなくなったのは、設計が不要になったからでも、図が嫌われたからでもありません。UMLという看板で売られていたもののうち、不要だった重い部分が切り落とされ、必要だった軽い部分だけが一般化したから です。言い換えれば、UMLは消えたのではなく、名前を失って日用品になったのです。