モデル駆動開発
モデル(設計・仕様)から自動的にコードを生成する開発手法。2000年代に注目されたが、広く普及することはなかった。
コンセプト
- 高レベルのモデル(UML、DSLなど)で設計を表現
- モデルから実装コードを自動生成
- モデルを「真実の源(Source of Truth)」とする
理想と現実
理想
- モデルを書けば、あとは自動的にコードができる
- 実装の詳細から解放され、設計に集中できる
- プラットフォーム非依存のモデルから、複数のプラットフォームに展開
現実
- 生成されたコードが非効率、読みにくい
- 生成されたコードのカスタマイズが困難
- モデルと実装の乖離(生成後に手動修正すると、モデルが陳腐化)
- ツールのベンダーロックイン
なぜ普及しなかったのか
抽象化のギャップ
モデルと実装の間には、埋めがたい抽象化のギャップがある。すべての実装の詳細をモデルで表現しようとすると、モデル自体が複雑になりすぎる。
フィードバックループの欠如
モデルを先にすべて書くアプローチは、ウォーターフォールと同じ問題を抱える。実装からのフィードバックがなければ、良いモデルは書けない。
ツールの限界
当時の自動生成ツールは、柔軟性と品質の両立が困難だった。
仕様駆動開発との類似性
仕様駆動開発は、MDDと構造的に類似している:
- 仕様/モデルを先に確定
- そこから実装を自動生成
- 人間は実装を触らない
歴史的に失敗したアプローチが、AI時代に再び現れている。
違い:LLMの柔軟性
LLMは、従来のコード生成ツールよりも柔軟で自然なコードを生成できる。この点でMDDとは異なる。
しかし、以下の問題は依然として残る:
- LLMの非決定性により再現性がない
- 仕様と実装の乖離が起こりうる
- フィードバックループの重要性は変わらない
教訓
モデル/仕様駆動のアプローチは、適用範囲が限定的。むしろ、仕様・実装共進化のように、モデルと実装を高速に往復させるアプローチが有効。
成功例:限定的な適用
完全に失敗したわけではなく、特定のドメインでは成功:
- データベーススキーマからのORM生成
- OpenAPI仕様からのAPI クライアント生成
- プロトコル定義(Protocol Buffers、gRPC)
これらは限定的で明確な境界を持つため、自動生成が有効。