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

開発時の問題

稼動開始時期は決まっていたが、具体的な要求仕様が不明確

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

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

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

問題発生

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

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

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

解決の糸口

サーバー増刷は不可、XML DBを復活させ問題解決を目指す

この状況を打破するためにSIベンダーが提案してきたのが、サーバーの増設であった。しかし、サーバーの増設は構築費はもちろん、その後の運用・保守の手間を増大させてしまうため、受け入れることのできない提案であった。また、XMLデータを格納するデータベースにもボトルネックがあった。XMLデータは暫定的にSQL Serverのテキスト型カラムにまるごと格納されていたのだが、XMLデータの特定の項目のみ参照する場合、アプリケーションレベルでの検索となるため、RDBベースでは実用にならないものと判断された。

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

方針変更

性能に問題なし、XML DBとして「NeoCore」の採用を決定

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

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

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