業務の明確化、内部統制の実現へ向け新システムを構築

総合商社の三井物産はその名の通り非常に多岐にわたる商品を扱っており、そのそれぞれが異なる手順で取引されている。2004年11月稼動のSAP/R3による新業務システム導入に伴い、 業務処理プロセスのBPRが実施された。ここで、決済業務、物流業務はこれを専門に実施するサポートセンターで行い、業務の効率化を図ることとなった。その結果、営業担当者とサポートセンターの担当者の間で、 商品ごとの手順を明確に定めた情報の共有が必要となった。こうした要求を受け、三井物産では業務の内容、手順を明確に定義でき、その情報を共有できるシステムとして業務処理マニュアル作成支援システムを構築することとした。 また同システムの構築により、営業担当者のみが把握していた業務手順を明文化することができ、業務が効率的に行われているか?手順どおりに処理されているか?といったチェックが可能となり、内部統制の側面からも、システムの導入効果が期待された。

 

ケーススタディー

開発時の問題:稼働開始時期は決まっていたが、具体的な要求仕様が不明確

三井情報開発株式会社 主席コンサルタント 土田 良夫業務処理マニュアル作成支援システムの検討は2003年の10月に始まった。同システムの構築が期待される一方で、開発の現場は多くの問題を抱えていた。 当時を回想し、システム開発を担当した三井情報開発の土田良夫は語る。

「検討を始めた段階では、まだシステムの具体的な要求仕様が決まっておらず、そのためどの ような技術、ソフトを使って構築を進めればよいのか誰も把握していませんでした。しかし、システムの稼働開始時期は6カ月後と決まっていたのです」

このような状況でも 開発は進めなければならないため、開発はスパイラル形式で進めることとした。スパイラル形式とは、一気に全体を開発するのではなく、確定した最小限の機能について本番開始を目指し、それと平行して要求仕様、採用技術、利用ソフトを 見極め、順次機能アップ、改修を実施することで、より理想的なシステムの構築を目指すというものであった。

問題発生:開発がある程度進んだ時点でパフォーマンスの問題が発生

始めにドキュメントシステムの開発実績があるSIベンダーが提案するパッケージソフトとXMLDBでの開発を決定した。しかし設計段階でSIベンダー提案の 他社XMLDBでは想定データ量を管理できないことが判明し、暫定的にRDBであるSQL ServerにXMLデータ構造を持ったデータとして格納することとした。 問題はさらに続き、柔軟な画面構造や動きを実現しようとした場合、採用したパッケージソフトではXMLデータからHTMLフォームを生成する際、サーバーに負荷がかかり、 性能低下が起きたのである。

しかし、マニュアルデータを表現するにはXMLデータが非常に有用であると判断し、この路線で開発を継続しながら、対応を練ることとした。

先行していた共通業務マニュアルの入力機能については、入力するXMLデータの組み合わせが単純なためこの方式で本番稼動を開始。しかし、個別業務マニュアル入力機能では、大容量かつ 複雑なデータがネックとなり、同様の対応はとれなかった。

業務処理マニュアル作成支援システムでの主なXMLデータの構成

解決の糸口:サーバー増設は不可、XMLDBを復活させ問題解決を目指す

この状況を打破するためにSIベンダーが提案してきたのが、サーバーの増設であった。しかし、サーバーの増設は構築費はもちろん、その後の運用・保守の手間を増大させてしまうため、受け入れることのできない提案であった。

また、XMLデータを格納するデータベースにもボトルネックがあった。XMLデータは暫定的にSQL Serverのテキスト型カラムにまるごと格納されていたのだが、XMLデータの特定の項目のみ参照する場合、アプリケーションレベルでの検索となるため、RDBベースでは実用にならないものと判断された。

この時、プロジェクトに参加していた三井情報開発が提案したのが、他社SIベンダーが あきらめたXMLDBの採用をNeoCoreを利用することで復活し、アプリケーションは負荷の少ない.NET Frameworkでの開発に方針を変更することであった。

方針変更:性能に問題なし、XMLDBとしてNeoCoreの採用を決定

三井物産株式会社 セールスマネジャー 中村 昌平 氏そこで検討されたのが三井情報開発が扱うNeoCoreであった。評価の結果、Solaris版のNeoCoreであれば、 100GB超のXMLデータを処理した場合も、実用に耐えるパフォーマンスが発揮されることがわかった。
さらにNeoCoreの採用と.NET Frameworkの採用を組み合わせることで柔軟で効率的なシステムを開発しようという意見が支配的になってきた。当時を振り返り 三井物産の中村氏は語る。

「パッケージソフトだと細かな部分で思い通りにならない。サーバーの大幅増設を提案したSIベンダーに不安を感じた。こうした意見が よく聞かれました」

そして2004年4月に三井物産はNeoCoreと.NET Frameworkの組み合わせにより再開発を行うことを正式に決定。三井情報開発が開発を主導することとなった。

XMLDBの柔軟性の高さが理想的なシステムの構築を可能に

業務処理マニュアル作成支援システム概念図

しかし、決められていた稼働開始時期は月内に迫り、再設計の猶予はなかった。そこで共通業務マニュアル入力機能については パッケージソフトで開発したものを暫定稼働させ、手順情報を入力してもらうこととなった。そして蓄積されたデータをNeoCoreに移行し、同時に寄せられた修正要望を 再開発版に反映させることとした。

この結果、当初の予定通り2004年4月に稼働を開始することができ、同年6月にはデータベースをNeoCoreに、一部アプリケーションを .NET Frameworkに移行させることができた。

その後も要望に応じ、機能追加、変更が行われている。こうしたリアルタイムな対応が可能なのも、柔軟性の高いXMLDBを 採用したことによるところが大きい。さらに追加された機能で注目すべきはPDF出力機能だ。これはシステム上での取引を履歴としてPDFで保管、確認を可能にするもので、内部統制の 観点から重要な機能といえる。

最後にNeoCoreの特長を紹介する。

 

特徴

高速! 特許技術により、XMLデータの超高速検索を実現

一般的なRDBMSに比べ、パフォーマンスが劣ると思われているXMLDBだが、 NeoCoreは、Xpriori社の特許技術DPP (Digital Pattern Processing) と呼ばれる独自の検索技術を採用することで、データ量やデータ構造に依存しない超高速検索を実現、たとえば1GBと 100GBのデータ量での検索性能に差がほとんど出ない(*)という、高いパフォーマンスを発揮している。

*:データ容量、対応環境により異なります。

簡単! インデックス設計に頭を悩ませる必要がない

データベースが大規模化したときに検索パフォーマンスを向上させる最も効果的な手段がインデックスの定義である。しかし、インデックスを定義すると更新時に再計算をする必要が生じるため、大量のインデックス定義は、更新パフォーマンスを低下させてしまう。そのため、インデックス 設計には多くのエンジニアが頭を悩ませている。NeoCoreでは、XMLドキュメントを登録する時にすべてのエレメントに対して自動的にインデックスが定義されるので、もうインデックス設計に頭を悩ませる必要がない。

柔軟! データは変化するもの、NeoCoreはその変化を吸収できる

NeoCoreでは、スキーマを定義することなく、XML形式のデータであれば柔軟に吸収することができるので、データベース設計が不要となり、 開発、運用にかかるコスト、時間を削減することができる。また、将来的にデータ項目を変更、追加する場合も容易に対応できるため、これまでデータベース化を躊躇していた半定型データのデータベース化も可能だ。

 

主な仕様

 
製品名 NeoCore
クライアント側OS
クライアント側対応プロセッサ
クライアント側必要メモリー容量
クライアント側必要ディスク容量
クライアント側その他動作環境
サーバー側OS Windows2000 Professional / 2000 Server and Advanced Server / XP Professional / 2003 Server
サーバー側対応プロセッサ Intel(R) Pentium II 以上
サーバー側必要メモリー容量 512MB以上 1GB推奨
サーバー側必要ディスク容量 HDD:300MB以上
サーバー側その他動作環境 Solaris 2.8 Ultra5以上
その他特記事項 API:Java,COM,C++,HTTP
通信インターフェース:HTTP
データタイプ:XML 1.0
Queryサポート:XPath,XQuery

価格情報
Windows版 250万円/1CPU(税別)
Solaris版 400万円/1CPU(税別)

パートナー企業:


ページのトップへ