APジェネレータが導くシステム開発の新パラダイム
2007/2/20
J-SOX法への対応を機に情報システム開発のパラダイム転換を！
|
|||
上場企業、そのグループ企業では、内部統制が待ったなしの状況になり、いろいろ悩んでいるのではないでしょうか。問題は、文書化や監査のために膨大なコストが発生することです。ともかく、企業としては、主体性を持って、実状にあったやり方でクリアする以外にありません。
ご存じのように、新会社法と日本版SOX法（以下、J-SOX法）の2つの法律への対応をしていかなければなりません。最終的には財務諸表の信頼性確保が目標ですが、それにとどまらず、企業のリスク全体に対するエンタープライズ・リスクマネジメントという視点が当然含まれています。内部統制の充実は大きな負担になりますが、規制への対応だけで終わっては意味がありません。J-SOX法でも、ITを積極的に活用するとともに情報システムの透明性確保を強く求めています。
- - PR -
そこで、企業はシステムの刷新を迫られます。日本ではIT部門を内部で抱えている企業が非常に多く、しかも独自の業務プロセスにこだわっていますから、レガシーシステムがかなり残っています。早くから情報化を確立した企業ほど、レガシーシステムが残っているのです。レガシーシステムは、どうしてもブラックボックス化しやすい環境にあるので、透明性の面で大きな問題が出てきます。内部統制の充実を阻む最大の要因の1つが、レガシーシステムだというのは、皆さんも一致しているのではないでしょうか。
レガシーシステムを含む情報システムへの投資が止められない理由は、業務プロセスと情報システムが、完全にリンクしているからです。これまで企業は、業務のいろいろなノウハウをロジック化して情報システムに入れ、情報システムの助けを得て業務を改善・高度化してきました。この業務とシステムの間に“プログラム”が存在しています。業務を変えたいと思っても、プログラムコードの書き替えに手間が掛かるようになると、思うような変更・改善ができません。システムが大きくなりすぎてしまって再構築できないのです。
■知識ベースとジェネレータの活用
このスパイラルから抜け出すためには、開発の仕方を変える必要があります。今回のJ-SOX法対応で、システムを刷新する際の最重要課題は、再構築したシステムを二度とレガシー化しないこと。それには業務プロセスあるいはシステム設計と、ソースコードをうまく分離し、かつ連携もすることです。分離と連携をうまく仕組みの中に作っていかなければ駄目でしょう。
 |
| 情報システム刷新の際の「最重要課題」 |
これまで、システム仕様を基に詳細設計してプログラムソースを作るという開発プロセスが一般的ですが、それを1つ迂回して「知識ベース化」していこうという動きがいま出ています。知識ベース化しておくと、新しいシステム環境に合ったジェネレータを使うことでシステムを素早く刷新でき、同時にシステムのドキュメンテーションもできます。つまり、既存のシステムをメタデータ化し、新たなIT環境のコードジェネレータを通して、システムを刷新していくという考えです。こうした方法をそろそろ導入していかないと、悪循環から抜け切れないと思います。そこから、さらにもう一歩進めて、システム仕様を知識ベース化することを、きちんと確立することが大切です。
最近、アプリケーションジェネレータという概念が出てきています。ゼロからシステムを構築していく際に、システム要件をどんどん知識ベース化して持っておけば、システム環境が変わってもコードジェネレータを通すだけでシステムが新しくなります。
ですから、これからのシステム開発は、経営環境の変化やビジネスモデルの変化に応じてデータモデルが容易に、あるいは自動的に変更できて、IT革新が進んでもシステムの再構築が必要ないという形になっていくと思います。使い込むほどにシステムが成熟、進化していくというわけです。
南米に行くと、20年前にCOBOLで作ったシステムとまったく同じ内容のシステムが、いまはJavaで動いているという例がたくさんあります。日系企業のブラジルホンダやブラジルトヨタでは、十数年前にそれを導入しています。
 |
| これからの情報システム開発 |
仕組みを説明していきましょう。業務プロセス、トランザクション、プロシジャ、帳票・画面を知識ベース化していきます。南米では主要解析のところをPrologで組んでいます。Prologといえば、かつて第5世代コンピュータというのがありましたが、そのときにはやっていた言語です。ウルグアイ公立大学にブレオガン・ゴンダさんという、なかなかすごい先生がいまして、IBMが目をつけたのです。IBMはこの仕組みをAS/400に移植して、いま売りまくっています。これがいよいよアジアに入ってきたわけです。
この仕組みを使うと、例えばIT関係しか変わっていない、業務は変わっていないという場合には、ミドルウェアのコードジェネレータのところだけメタデータ化したシステムを流すと、新しいシステムに変わります。ブラジルトヨタやブラジルホンダではそういう形でシステムをどんどん更新していっています。
業務が変わったときには、変更個所だけを再定義します。そうするとデータモデルが変わります。データモデルが変わったら、データベースの変更プログラムが動きます。それによって変更したプログラムがセレクトされ、その部分だけがジェネレートされます。それをコンパイルして実行コードを作っていくわけです。南米では、こういったやり方がかなり浸透してきています。
■ユーザーは新規開発＝業務改善に注力すべし
このウルグアイのシステム──「GeneXus」といいますが──を、IBMが最初に担いだのは17〜18年前です。現在ではオラクル、ヒューレットパッカード、マイクロソフト、IBMの4社が戦略パートナーになっています。日本IBMもようやく戦略パートナーにGeneXusを入れるようになりました。まだローカライゼーションが全部済んでいませんが、かなりの進ちょくで動いており、すでに日本の企業でも導入しているところがあります。こういったものを使っていけば、先ほどいったコンバージョン（システム刷新）が非常に楽になり、ユーザーはITの変革にエネルギーを注がなくても済みます。自分たちは業務プロセスの改善に専念すればいいという環境になっていくわけです。
そういう中で、J-SOX法対応の賢明な方策を考えると、第1段階としてはともかくレガシーシステムを可視化することです。残っている資産、いま動いているシステムのソースコードだけであっても、それを可視化していくことを考えます。可視化できればリスクを洗い出せますし、リスクの重要度が特定できますから、内部統制の整備も考えることができます。
可視化ができれば、第2段階です。そのシステムをよく点検・評価して、延命できる部分はコンバージョンし、オープン化します。それだけで運用コストも下がってきます。
第3段階は、いよいよ新しいアーキテクチャやプラットフォームへの移行──、いまならSOA基盤というのでしょうか、そういうものに展開していけばいいだろうと思います。その際にも使えるロジックは、コンバージョンできるように整備しておけば、開発費の削減、開発期間の短縮ができ、またいま動いているものをコンバージョンするため、品質も保証されるのです。
このように、知識ベースさえ作れれば、その後はレガシー化させないような形でシステムを運用していけるのではないかと思います。
関連リンク
- GeneXus.com（ARTech社）
- ジェネクサス・ジャパン
 |
Page 1 J-SOX法への対応を機に情報システム開発のパラダイム転換を！ 知識ベースとジェネレータの活用 ユーザーは新規開発＝業務改善に注力すべし |
| Page2 モダンシステムは、既存システムの可視化の共有よりスタートするモダンシステムは、既存システムの可視化の共有よりスタートする ModernArchによるシステム近代化の手順 システム近代化の戦略とコンバージョン |
