「私の部屋から向いの高層ビルの建築現場がよく見えましてね。日に日にビルが高くなっていくのがはっきり分かる。それに引き替え，私が担当している情報システムときたら何がどのくらいできたのか，さっぱり分からない。ああ，ビルの建築はうらやましい，と毎日思っていました」

　今から7年前に大手カード会社の専務から聞いた言葉である。この専務は同社の基幹情報システムを全面再構築するプロジェクトの責任者をしていた。元々は営業畑の人であり，情報システムに関しては素人と言ってよかった。定期的にプロジェクトの進捗会議を開き，開発チームごとに報告を受けていたものの，情報システムにしろソフトにしろ成果物が目に見えるわけではなく，いつも不安だったそうだ。

　この専務が情報システムの開発責任者として，コンピュータ・センターに赴任したのと同時期に，すぐ近くで高層ビルの建築が始まった。この現場が専務の部屋からよく見えた。建築現場のほうは作業員が何をしているか，大体分かる。しかも実際に少しづつビルが成長していく。1年も経つと彼我の差がはっきりしてくる。

　「情報システムをいよいよ動かす直前になったとき，向いのビルはほとんど完成していました。ところがこちらは本当にできあがっているのかどうか，判定会議でゴー・サインを出した後ですら自信が持てない。なにしろ目に見えませんでしたから」

　最終的にこのカード会社は新システムを完成させることができた。プロジェクトの経緯にも興味深い点があったが，筆者はビルと情報システムの対比を語った専務の発言をよく覚えている。筆者自身，ITの専門家ではない読者に向けて記事を書くときに「ITは目に見えない」という表現を使ったことがある。

　この専務が見えなかったものは二点ある。一つは作っているシステムそれ自体が見えなかった。もう一つは本当にできあがっているのかどうか，進捗状況がよく分からない。

　どちらの問題についても色々な取り組みがされてきた。いわゆるソフト開発の方法論やプロジェクトマネジメント手法は，目に見えない情報システムやソフトと格闘するために先人達が考え出したといってもよいだろう。

見えないものを「モデル」にして見る

　まず，見えないものを何とかして表現し，それを基に大勢で議論する必要がある。IT Proの読者の世界では「MDA（モデル・ドリブン・アーキテクチャ）」が昨今の話題の一つであろう。「見えないものと格闘する」という文脈でMDAについて考えてみたい。

　最近，別件でお目にかかった方から相次いでMDAの重要性を説かれたので，慌てて勉強してみた。MDAは「モデル駆動アーキテクチャ」と訳すそうである。MDAを規定しているのはOMG（オブジェクト・マネジメント・グループ）であるが，OMGは昔からCORBAがどうしたとか，難しい言葉を使うことが多い。モデル駆動アーキテクチャではどうにも分からないと思っていたが，CSKの黒川利明フェローの解説を聞いてようやく分かった。黒川氏はOMGにおけるUMLやMDAの会議に参加してきた人である。

　黒川氏はMDAを「モデル中心体系」と訳したほうがよいと語る。というのはMDAの最大のご利益は「関係者全員がシステムについて議論できる具体的な対象を与えてくれること」だからである。モデルはコミュニケーションを改善する道具，ということだ。モデルを見ながら多くの関係者が議論し，検討する。ここから実際のプログラムを作って動かしてみて，何か問題があればモデルに戻って議論する。

　これまではエンドユーザーや開発者が共通に議論できる対象が無かった。プログラムでは無理である。仕様書は今一つというか，かなり分かりにくい。もちろん現状のUMLで多くの人が理解できるモデルを描けるのか，という点については議論の余地がかなりある。それでもMDAが狙っていることが「コミュニケーションの改善」というならばよく分かる。

自動化も大事だが議論がもっと大事

　MDAは，モデルからプログラムを自動生成するためのものではないか，と思う方がおられるかもしれない。確かにMDAの世界に入ると，モデルからプログラムが生成できるらしい。しかし問題はそのプログラムが，顧客（エンドユーザー）の要請にあったものになっているかどうかであり，自動化それ自体は些末とはまでは言わないが，さほど重要ではない。

　そもそもプログラムを自動生成するツールであれば，20年以上前からあった。4GLとかCASEとか懐かしい言葉がたくさんある。確かにプログラミングの自動化はできたが，出来上がったシステムはそのまま使えないことが多く，別なプログラムを外付けにしたり，あるいは生成したプログラムを再修整したりしていた。

　なぜそのまま使えなかったかというと，どんなシステムを作るか，要件をしっかりと固められなかったからだ。IT Proでいつも議論されている問題である。システム要件の曖昧さのしわ寄せがプログラムに来てしまう。それならプログラムではなくて，その前のモデルの段階で，関係者がもっとしっかり議論しておこうというのが「モデル中心体系」というわけだ。この過程を経て，関係者全員が納得できるモデルができたら，そこから自動生成したソフトは今度こそ利用できるはずである。

ランボー氏が語る「モデルとPMの出合い」

　10月半ばに，MDAなどモデリングのリーダーであるジェームズ・ランボー氏が来日し，講演を行う。テーマは，モデリングとプロジェクトマネジメント（PM）の関わりについてである。ランボー氏がMDAとPMを絡めた話をするのは初めてという。

　ランボー氏は「第2回プロジェクトマネジメント国際会議（ProMAC2004，10月11日～14日）」のキーノートスピーカーを務める。ProMAC2004はプロジェクトマネジメント学会が主催している。PM関連の催しだからランボー氏は無理矢理PMの話をするのかというとそうではない。

　ランボー氏によると，モデリングをきちんと実践するにはPMが必要だし，PMをしっかり実践するためにもモデリングが必要という。次の2行はランボー氏の言葉である。