■ 1. UMLの起源と制度的背景
- UMLはラショナルソフトウェアが主導した標準化プロジェクトとして誕生した
- ブーチ法・OOSE・OMTなど複数の方法論を統一するための記法として設計された
- 当初から業務分析・要求管理・設計・実装・テストをまたぐ共通表現として位置付けられた
- 2003年にIBMがラショナルを買収しUMLはプロセス・製品・教育・監査・成熟度まで背負う存在となった
- この経緯により「UML」という語は重厚長大な印象と不可分に結びついた
■ 2. ファウラーによるUMLの再解釈
- ファウラーはUMLの使い方をスケッチ・ブループリント・プログラミング言語の三種に分類した
- 2000年代に「重いUML」として販売されていた本丸はブループリント用途であった:
- 図を完全な設計書とし実装者がそれを機械的にコードへ写し取る立場
- 設計者と実装者を分離しモデルから実装まで一気通貫で支配しようとする発想
- ファウラー自身はブループリント的立場を否定しスケッチを重視した:
- 図は完全な仕様書ではなく重要な点だけを伝える会話道具である
- 「網羅性は理解しやすさの敵」という立場を明言した
- 役目を果たした図は捨ててよいと述べた
- ファウラーはコードを主文書と位置付けた:
- コードのみが十分に詳細かつ正確である
- 図はコードの理解や対話を助ける補助線にすぎない
■ 3. 2000年代の実務における実態
- 表向きの礼賛と実際の運用の間には当初から温度差があった
- 2007年調査ではUML使用率は52%にとどまり一様ではなかった:
- モデリングツールは主に初期設計で使用された
- コード生成は広く使われていなかった
- 問題点として図の品質・非形式的利用・モデリング規約の欠如が挙げられた
- 多くの現場は最初からクラス図やシーケンス図の一部のみを使い残りはフリーハンドの図で済ませていた
- UMLは「看板だけ巨大で実務は最初から部分利用」であったと見るのが実態に近い
■ 4. MDA(モデル駆動アーキテクチャ)の失敗
- MDAはプラットフォーム非依存モデルから実装コードまでを自動生成する構想であった
- UML制度の最大の約束手形は「図を正しく描けばコードは自動的に出てくる」であった
- 2007年調査が示した通り現場ではコード生成はほとんど使われなかった:
- 生成されるのは骨組みだけで振る舞いは人間が記述する必要があった
- 生成コードを手で修正するとモデルとの同期が崩れ二重管理が常態化した
- MDAの失敗はCASEツール・RUP・監査向け成果物・モデル中心教育の正当化根拠を根元から失わせた
■ 5. 2010年代の技術環境の変化とアジャイルの定着
- 変更速度を引き上げた三方向からの圧力が同時に加わった:
- 供給側: AWS S3(2006年)を起点とするクラウドが環境調達の待ち時間を縮め小刻みな試行を可能にした
- 需要側: iPhone(2007年)がモバイル対応を必須化しアプリストア・OS更新を通じて短い更新周期を市場から要求した
- 運用基盤側: JenkinsによるCI/CDとGitHubを介したコードレビュー文化がコードの変更と検証を日次レベルで回す基盤を確立した
- アジャイルが能動的に勝ったのではなく市場と技術基盤の側がアジャイルの前提条件を満たした
- 2014年のState of Agile調査では回答者の90%が1年以上のアジャイル経験を持ち採用理由の上位は製品提供の加速・優先順位変更への対応・生産性向上であった
- 同調査でアジャイル案件の管理にMicrosoft Excelが68%使用されIBM Rationalは13%にとどまった
■ 6. UML制度の死の本質
- 死んだのは図そのものではなくUMLという制度である:
- 図を完全な設計書にし設計者と実装者を分けモデルから実装まで支配しようとする発想が死んだ
- 二重管理は手間の増加ではなく情報の腐敗構造である:
- コードが変わるたびに図を直す義務が生まれる
- 直されなかった図は残り続け嘘をつき始める
- 変更速度が上がるほど図の腐敗速度も上がる
- 腐った図はないよりも悪い情報源であり新しい図を描く動機まで奪う
- 2010年代にUMLが聞かれなくなったのは図法が間違っていたからではなく維持費が便益を上回ったからである
- 「UML」という語がCASEツール・RUP・MDA・監査文化を連想させる重い語彙になったため現場が軽量化に向かうほど語自体が敬遠された
■ 7. UML制度が死んだ領域と生き残った領域
- UML制度の死は変更速度の高い領域に限定された現象である
- 機能安全・認証が絡む領域ではUMLの系譜は必須の位置を占めている:
- 自動車組込み: ISO 26262
- 航空: DO-178C
- 医療機器: IEC 62304
- これらの領域ではSysML・MATLAB/Simulink・Stateflowが必須の形式的記述として機能する
- 領域間の非対称性はリリース周期の長さで説明できる:
- Web領域はリリース周期が日次・週次に短縮され図の維持費が便益を容易に上回る
- 航空・自動車・医療はリリース周期が年単位で失敗時の損害が人命に直結するため二重管理が安全網として機能する
- 境界線は業界ではなくリリース周期の短さとモデル維持費の損益分岐点にある
■ 8. UML的図法の日常化という逆説
- Web領域でUML制度は死んだがUML的な図はむしろ日常に入り込んでいる
- MermaidはフローチャートからシーケンスÃ図・クラス図・状態図・ER図・C4図まで扱える
- PlantUMLもシーケンス図・ユースケース図・クラス図・状態図などを広くサポートしている
- GitHubではMermaidのレンダリングがIssues・Discussions・プルリクエスト・Wiki・Markdownファイルで利用できる
- Mermaid自身の主目的は「ドキュメントを開発に追いつかせること」であり図を開発速度に追随する軽量文書として扱う
- 死んだのはブランドとしてのUMLであり生き残ったのは図法としてのUMLの断片である:
- 名称として避けられるようになったのはUMLという語が重い連想を持つ語彙になったからである
- 実質としてはシーケンス図や状態図の記述機会はむしろ増えている
■ 9. まとめ
- UMLが2000年代に普及したのは単なる図法ではなく標準化・統合・管理可能性の象徴として売られたからである
- ファウラーが整理した軽いUMLと市場が売り続けた重いUMLの間には当初から深いずれがあった
- MDAのコード生成失敗がUML制度の経済的根拠を失わせた
- クラウド・iPhone・CI/CDという三方向からの圧力が変更速度を引き上げアジャイルの前提条件を満たした
- 先に死んだのは図ではなくUMLという名称に付随していた制度と二重管理であった
- UMLは消えたのではなく名前を失って日用品になった