DOA＋コンソーシアム(ディー・オー・エー・プラス　コンソーシアム）

DOA+とは

研究報告書

記事

2004年01月28日
東京国際大学教授　堀内　一

DOA+コンソーシアムの発足は予想外の反響を呼んでいるようです。
先日、第1分科会の第1回会合に参加させてもらいました。参加者の熱心な討論に正直いって驚かされました。司会の椿会長は、何とかまとめようとしておられましたが、暫くは、成り行きに任せる方がよいのではないか、と思いました。
DOAへの思いは「人の数だけある」という椿会長の説もうなずけました。モデリング方法論と考える人、ソフトウェア開発方法論とする人、オブジェクト指向の一部と考える人、あるいは対立させる人、さまざまです。しかし、会場には、それらを超えた何かを皆が求めている、という雰囲気があったようです。
そこで改めて、今、なぜDOAが注目されたのか愚考してみました。
その結果の一つは、やや大袈裟ですが、「技術の巨大化と細分化」に対する不安と、それを乗りきるための「普遍的な原理への希求があるのでは・・・」、というものです（やはり大袈裟です）。

80年代にオブジェクト指向が登場した頃、RDBの正規化やデータモデリングが盛んに議論され、DOA方法論も数多く提案されました。TH法やT字法をはじめとして、ジャクソン法、ワーニエ法、SSADM、IDEF1X、DFDによる構造化システム分析（SSA）などなどです。当時は、ソフトウェア開発やその生産技術を，多くの方が参加して熱い議論が繰り返されました。そこには、自分の肌で感じられる問題と技術、また、それらへ自分の理念や考えを反映できる喜びもあったようです。今、流行の「スローライフ」といえるかも知れません。先日の第1分科会では、そのような議論の再現を見た思いで、いたく感動した次第です。

ところで、オブジェクト指向は、あらゆるソフトウェア分野で急速に普及していることは言うまでもありません。J2EEや.NETなどプラットフォーム技術だけでなく、UMLやオブジェクトパターンなどのモデリング技術、アスペクト指向さらにWeb技術をベースしてサービス指向、ソフトウェアプロセスなど、新しい技術のことごとくがオブジェクト技術を前提としています。
しかし、UML一つをとってみても、OMGは、MDAの実現を容易とするために、より厳密性を求め、さらにMOFのメタモデルとの統一を図り、UML2.0仕様をつくりました。その仕様書は四百ページに及びます。データモデル図の延長で、概念を表現する図式表記手段としてUMLを使っていた頃と比べると、木製絹張りの飛行機が最新のジェット機になったような印象をうけます。UMLを「理解するだけで精一杯で、とても使う気にならない」などとでもなったら大変です。
オブジェクトによるソフトウェア再利用も、J2EEやEJB、さらにアプリケーションサーバツールの情報量の前に対象を理解する気力すら失いかねません。「だれがこれを使うのか」という気にもなります。
最近、情報システムに限らず、大規模なプラントやシステムでこれまで見なかったような事故が度々、報道されています。「最近の若者は規則を守らないからだ」という若者の自分勝手な振る舞いに憤慨している人の声もあります。しかし、それだけでなく、仕事のマニュアル化と専門領域の細分化が進み、誰も全体を知らない、あるいは全体を見通そうとする意欲を持たない、といった巨大技術に共通する弊害が原因かもしれません。「次に何が起こるか予見する本能の劣化だ」という人もいます。システムのトラブルは、技術分野や役割の縦割り構造に沿って起こってくれるとは限りません。予期せぬ事態への対応能力は、やはり、さまざまな現象を経験することで習得するしかないでしょう。隣の分野も理解しようとする気力、全体を経験するためのジョブローテーション、なんて期待する方が無理という風潮になっているのではないかという気さえします。
オブジェクト指向プラットフォームを使っている技術者は、アプリケーションに関心を持たないし、EJBなどのソフトウェアコンポーネントでソフトウェア開発する技術者もビジネスを知ろうとはしない傾向があるとも聞きます。一方で、ベンダーは差別化のために、毎日のようにプラットフォームに新技術を持ち込み、絶えず新しいバージョンをリリースします。技術者の課題はそれらをいち早くフォローすることとなり。そこに、また生きがいを見出しているかも知れません。
そういえば、本屋に行っても、ソフトウェア技術分野でオリジナルの著書が少なくなったような気もします。殆どが翻訳本です。オリジナルで書かれている本は、ことごとくが、「入門書」です。出版社も売れそうな本だけ出版し売れそうもない専門書を敬遠するからでしょう。技術者にオリジナリティを蓄積する余裕もないのかもしれませんが、こと、ソフトウェア技術分野に限れば、企業がオリジナリティを求めていないからではないか、とも思えます。

DOAの一つの狙いは、プラットフォーム技術に依存しない世界で、システムの本質を把握したい、制御したいという要求を満たすことにあるかもしれません。DOAは、もともとデータ資源概念を重視し、その資源制約を遵守しながらシステム開発を行うことを理念とするものだからです。

その昔、DOAを説明するのに、よく「江戸の火事」の話を使わせて頂きました。つまり、江戸時代の末期、一軒の家を建てる費用を100円とすると、その家を人に貸す家賃が6円だったという話です。そこで、法外な家賃を下げるために採られる対策は、建築費のコストダウンに向けられ、結局、成果が得られないというものです。
家賃が高かった原因を特定してなかったからです。原因は平均3年ごとに起こった「大火事」にありました。つまり、100円の投資を3年間で回収するために6円の家賃となったという話です。
結局、火事を起こさない、あるいは起きても波及させない対策が求められ、区画整理や消火設備などのインフラ整備が必要だった、というものです。
ソフトウェア生産性向上は重要な課題ですが、結局、最新テクノロジーを使って建築費を安くすることばかりに目を奪われているのではないでしょうか。

情報システムにとって資源として基盤（インフラ）化すべきものは情報、またはデータであることは、メインフレームであろうがWebシステムであろうが変わりはありません。　また、オブジェクト指向であろうが構造化手法であろうが同じはずです。
データモデルを開発するのは資源構造を明らかにするためです。今流行のEA(Enterprize　Architecture)も同じです。少なくとも、データモデルやオブジェクトモデルは家を建てるためだけの技術ではないといえます。
家を建てる技術も重要です。しかし、家の基盤はプラットフォームだけでしょうか。ガス・水道といった社会基盤と建蔽率や建築基準法などの規制も必要であり、またそれらを管理・維持する第三者的役割も不可欠です。行政は個々の家を対象に統制を行うことを考えず、社会インフラの構造を制御することで全体を制御します。情報資源管理、データ資源管理という古典的な概念は今でも有効だと思います。
つまり、システム全体の把握やその制御を、データ資源を通じて行おうとする理念がDOAの背景にあるとおもいます。その理念はオブジェクト指向でも同じはずです。
つまり、システム開発は基盤から独立でなく、その制約を受けます。新システムといえども、突然、降って沸いたように登場するものではなく、現行システムと資源の両者の制約を引継ぎながら、それらの制約の下で開発されるものだからです。そのために、データ分析とデータモデリングを通じて資源情報として、データ固有の操作や制約の把握が基本要件となります。

一方で、システムのオープン化も避けられない課題です。オープン化とは、サーバシステムやオープンソースを使うことだけではなく、外部の社会常識と整合するシステムを指すものであり、そのために、自社の情報基盤の外部社会との概念的な共通化、普遍化を進めること、普遍的な情報要素（ValueDomain）に基づくオブジェクト定義、あるいは業界ベストプラクティスモデルへの準拠性を確保すること、などが不可欠となります。

絶えず変化するプラットフォーム技術からの独立性を確保しながら、オブジェクトとして顆粒化するソフトウェアに、その企業のビジネスの意味を正しく反映させる基盤を確保すること、また、オブジェクトモデリングに対する情報ロジスティックを提供することを通じて、巨大化する情報技術に備えることが求められているといえます。
そのような方法論やアーキテクチャを議論することこそ、DOA＋の使命だと思います。