モデル活用のメリットは何か？

日経エレクトロニクス2011年8月8日号に、「違ったものになりがちなモデルとソース・コード」という記事が載っていた。モデル駆動開発を目指してUMLを導入したものの、現場ではなかなか活用できていないというのはよく聞く話だ。

ある民生機器メーカーのソフトウェア開発リーダーは、「一部の開発者だけが細々とモデルを使い続けるものの、他のメンバーはすぐにモデルを使わない開発に戻ってしまう」と嘆いていた。
日経BP SHOP｜日経エレクトロニクス2011年8月8日号

記事ではETロボコンに参加したチームでの活用状況を調査し、モデルとソースコードがかけ離れてしまったチームが意外に多いことを指摘している。本来密接に関わるはずのモデルとソースコードが別々の方向に進んでしまい、モデルを利用することもなくソースコードを書くチームも有ったらしい。

今回の調査で浮き彫りになったのは、モデルの通りにソース・コードを実装しなかったチームが多く有ることだ。
（中略）
我々が行った各チームへのヒアリングでは、「モデルはチームの一人だけで作成し、その他のメンバはほとんどモデルを参照せずにソース・コードを開発した」という声もあった。
日経BP SHOP｜日経エレクトロニクス2011年8月8日号

現場の開発者の感覚では「作るべき仕様書の一つとしてUMLという厄介なものが増えた」という認識すら珍しくないので、モデルの活用がなかなか進まないのも当然のことかと思う。背景として、このような要因があるのではないかと思っている。

モデル作成の直接的なメリットが見えない
ユニットテストなら回帰テスト実行時にその恩恵が開発者へダイレクトに伝わってくるものの、モデルを作ってもソフトの品質が上がるという利益が発生するのか疑わしく、仮にそのようなメリットが生じても開発者側へ還元されて来ない。
既存のモデル資産が存在しない
開発の現場では、既に存在するソースコード資産を元に派生開発を行う事例が多いはずだが、実際問題として既存のモデル資産なんて無いケースが殆どだ。そのようなベース無しに、差分開発部分のみをモデル化するのも不可能な話だろう。
ソースコードの変更にモデルの修正が追いつかない
最初はそれなりのモデルを作っても、いざソースコードでの実装になると予想もしていなかった変更・追加が次々と入り、結果的に当初のモデルとは段々と違う姿になってしまう。そんな面倒な修正を行う人なんていないので、結果的に「現状のソースコードとは全く異なる昔のモデル」が負債として残るだけになってしまう。

開発規模が大きくなるにつれてソースコードのような粒度の小さいものではなく、より抽象度の高いレベルでの把握が必要不可欠になるのだが、そんな俯瞰的に把握をするという楽な方法よりも、徹夜をしてソースを隈なく解析するという面倒な方法を選んでしまう点に、生真面目な開発者の習性を感じてしまう。

実際には起こらなかった問題を取り上げて「これがUML導入のメリットです」と説明しても、（一部のやる気のある開発者を除いて）納得できる人はほとんどいないだろう。開発者側に利益がもたらされることを、もっと具体的な形で示す必要があるのではないかと思っている。