さよなら

「一芸を締めくくる」　　　　　　 椿　正明

　辻さんに初めてお会いしたのは１９７９年の秋だから、２８年前になる。私は千代田化工建設を辞めて日本システミックスに入社したばかり、ＪＭＡＳ社と一緒に郵政省の次期簡保システムの基本設計のコンサルを担当した時だった。こちらは上野則男さんと私、ＪＭＡＳからは北川さんと辻さんがメンバーだった。郵政省での検討会の前日にＪＭＡＳのお二人と事前打ち合わせをしたが、辻さんの資料はまるで何にもできていない。大丈夫かなと思っていると翌日にはちゃんとした資料ができていて、桑門さんや、うるさ型の鶴谷さんの参加された会議をなんなくクリアする。私にはとてもまねのできない「一夜漬けの天才」という印象を持った。

　その後も、ヴァル研究所の（故）島村さんにもご協力いただいて一緒にセミナーをやったり、継続していろいろなお付き合いをいただいたが、ＤＯＡについての会話はなく、私のＤＯＡをどれだけご理解いただいているかはさっぱりわからなかった。その謎はしかし、最近の新ＭＩＣ（多様一芸人くらぶ）で分かったような気がした。「経営と情報通信」研究会には確かに、ＡＳＰ屋から気功に至るまで、「一芸人」がたくさんおられる。辻さんはその「興行主」で、その興行を楽しんでおられる。会社を作ったり、あるひとつの道を追求したりするのは辻流ではないのだ。

　それならば、一芸人たるもの、存在を忘れられないように芸を披露しなければなるまい。そこで、「経営と情報通信」に参加した初めのときに一度話をする機会を頂いて以来の、最後にもう一度、まだ現役の方もいらっしゃるのだし、やや硬い話になるが、ＤＯＡがらみで最近私の考えていることをお話しし、一芸を締めくくることにしよう。

　「ＤＯＡ＋コンソーシアム」を始めて４年になる。システムの基盤はデータだから、これをしっかり捉えるＤＯＡを育ててもっと普及しようというわけである。ＤＯＡにも流派がいろいろある。ざっくり言えば、ＤＯＡはデータモデル図の書き方と手順方法論から成る。ＯＯの場合は図の書き方を統一しＵＭＬができたので、これと同様「データモデル図の書き方を統一せよ」との声も聞こえているが、やはり書き方だけでは不十分と、考え方・手順・方法論などを比較検討しており、それらの異同がはっきりしてきた。

　まだコンセンサスは得られていないが、流派の違いの発生する根本は次の２つ、

①スコープを、
（Ａ）個別アプリごとに考えるか、
（Ｂ）アプリ横断の全社で考えるか
②進め方を、
（Ｃ）実装独立の段階ではＲＤＢの大まかな構造を決めるにとどめ、実装段階で詳細を詰めるか、
（Ｄ）実装独立の段階でデータの整合性を完成させるか

になるようだ。そして、欧米系の方法に基づく一般のＤＯＡ方法論はＡ・Ｃであり、我々のＴＨモデルに基づくＰＬＡＮ－ＤＢ方法論はＢ・Ｄである。

　（Ａ）はユーザ部門のニーズに直接応える自然なアプローチであり、パッケージベンダーやＳＩｅｒに取っ付き易い。しかし、アプリ横断のデータ流通の難しい孤島システムを作り易い。一方、（Ｂ）はアプリ横断のデータ流通ニーズを見越してリソースデータ（マスターデータ）の一元化などをあらかじめ仕組んだ方法である。システム化の初期段階は、このような業務横断のデータ流通のニーズは希薄なため、会社にもよるがプロジェクトの立ち上げが難しい。

　（Ｃ）は、過去の経験を生かす、いわゆるトップダウン方式と呼ばれるのもで、実装独立にはあまりこだわらずＲＤＢの物理設計をターゲットにするため、一般にＤＢ設計チームと業務設計チームが分業するケースが多い。一方（Ｄ）は、加工データ処理に登場する、物理ＤＢにストアされないデータを含めて、すべてを対象にデータモデリングして整合性をチェックする。このため、データチームとプロセスチームの分業はなく、分業は実装設計に入ってからになる。また、実装独立段階で処理をトレースするためＳＰＦ（Schema Process Flow）チャートを活用する。

　先憂後楽型の宿命で顧客の少ないわれわれの方法論は、これまで苦戦してきたが、ＳＯＡなど業務横断のデータ流通のニーズが顕在化する時代になって、今後が楽しみと期待される。

　今年の第一の話題はＳＯＡである。「従来の製造の観点ーロジックの再利用などーからモジュールを切り出そうと言うのでは基準がはっきりしないし、個人差が出やすいから、サービスの観点からモジュールを切り出そう」と言うのがＳＯＡだと、私は考える。すなわち、モジュールをサービスで隠蔽するのだ。サービスとは何か。ユーザとの接点、ＩＯではないか。これは、ＩＯやメッセージで処理を隠蔽するとするわれわれの方法と同じではないか。

　「ＤＯＡの反対はＰＯＡ（Program Oriented Approach）だ」と言ってきたが、「ＳＯＡの反対もＰＯＡ」だと言える。それなら実装独立でもあり、ＤＯＡ＝ＳＯＡとなるではないか。違うのは、ＤＯＡではＳＱＬのような言語によってプロセスがデータにアクセスするものとの暗黙の前提があるが、ＳＯＡではＷｅｂサービスのようなもう少し自由なインターフェースでデータにアクセスするところではないか。われわれは、「イベントデータは出来事の記録、リソースデータはこれを記述するための用語。リソースＤＢは広辞苑のようなもの、これがアプリごとにいくつもあるのはまずい、一元化せよ」と３０年言い続けてきた。ＳＯＡがはやりだして、アメリカではＭＤＭ（Master Data Management）がはやりだしている。

　ＤＯＡでは、通信場を介してプロセスがコミュニケーションする。通信場／ＤＢを先に設計－ポイントは標準化－する。これによってHub & Spokeができ、Ｎ＊Ｎ個の通信パスがＮ個になる。これがＤＯＡの本質だが、ＳＯＡにも全く同じことが言える。われわれが考えているＤＯＡアーキテクチャはＳＯＡアーキテクチャと同じになるに違いない。これが今、「ＤＯＡ一芸人」の私が考えていることである。

（注）ＳＯＡとは、既存アプリはそのまま使い続けながら、最小の追加・変更により他アプリとのデータ流通を実現するものと考える。したがって、既存アプリレベルの通信場／ＤＢのほかに、アプリ横断の上位の通信場を設け、アプリはここで通信する。このハイレベル通信場設計に当たっては、アプリ間でやり取りされるメッセージ／トランザクションを素材にDB設計することになる。そのとき得られるリソースは、全社で一元化されたリソースになる。これと異なるリソースを持っているアプリは、メッセージ交換に当たっては、全社標準にあわせるための変換が必要になる。この変換には、ハイレベル通信場を規定するリポジトリが使われる。ハイレベル通信場は、通常はデータウエアハウス機能を持つＤＢと考えるのが素直であるが、パーフォーマンスに問題がなければ仮想化されても良い。その場合、通信場の実体はリポジトリ、通信の主役はＥＳＢということになる。なお、ＥＳＢはＥＡＩのようなバンドエイドＳＯＡ－個別のPeer to Peerの通信でパスがＮ＊ＮのままのＳＯＡ－にも使われうるので注意が必要である。
　［2007.12.18］

　特集企画　目次へ