「サーバー増設17台」に絶句　アプリ再開発で4台増に抑える

三井物産

実森仁志

2005.06.13

1. パッケージ・ベースで開発中の業務システムに性能問題が発生
2. 17台のサーバー増設をSIベンダーに提案されたが代替策を検討
3. DB/アプリケーションを総入れ替えして増設を4台に抑える

　「性能が不足しているなら，アプリケーション・サーバーを17台増やしましょう」――。

　パッケージ・ソフトをベースに開発中の業務システムで性能不足に悩んでいた三井物産は，SIベンダーが示した解決策に絶句した。当初の2台構成からは大幅増となるからだ。サーバー数が増えれば，構築費はもちろん，今後数年にわたる運用/保守の手間まで増大してしまう。

　悩んだ末に同社は，「開発中のシステムは“プロトタイプを作った”と考えて見切りをつけた」（経営改革推進部 MICANプロジェクト推進室マネージャー小田智彦氏）。アプリケーションを手組みする方針に切り替えたのだ。その結果，アプリケーション・サーバーの増設は4台に抑えられた。

XMLデータを階層的につなぐ

　性能問題が生じたのは，「MICAN（Mitsui I CAN）」と呼ぶ業務処理マニュアル・システムである（図1）。商品ごとに異なる業務手順の情報を，関連部署の担当者間で共有するためのシステムだ。

図1●業務処理マニュアル・システムの開発中に性能問題が生じた
「SAP R/3（Global Trade）」で業務を電子化するのに伴い，業務手順を登録/参照する業務処理マニュアル・システム「MICAN（Mitsui I CAN）」を開発した。既存業務手順などのデータを入力する目的で本稼働前に入力機能を暫定稼働させる必要があったため，スパイラル型の開発プロセスを採った。ところが，個別業務の入力機能の開発段階で性能問題が生じた
[画像のクリックで拡大表示]

　従来，同社では「商品の引き合い」「契約」「入出庫」「決済」「為替取引」といった一連の業務を営業担当者が主導してきた。このため業務手順の情報は，営業担当者だけが把握していればよかった。

　だが，2004年11月に「SAP R/3」で業務を電子化するのに伴い，契約後の履行業務は新設した専門部署（共通事務処理センター）に委ねることになった。「営業担当者と共通事務処理センターの担当者との間で業務手順の情報共有を確実にするために，MICANを構築することにした」（経営改革推進部 IT戦略企画室室長黒田晴彦氏）。

　要件定義の段階で同社は，新しい商品に対して最適な業務手順を素早く作成するための機能を盛り込むことにした。具体的には，業務手順の情報を部品化してXMLなどで表現し，それらを階層的に組み合わせることで，新しい業務手順（XMLデータ）を作り出すという機能である。

　この機能を実現する技術を検討していた際，たまたまアドビシステムズの電子フォーム・パッケージ「Adobe Form Server 5」と出会った。「想像していたシステム像に近く，2003年秋には採用を決めた」（同推進室業務プロセスチーム小田宗俊氏）。データベースは，SIベンダーの開発実績がある「SQL Server 2000」を選んだ。

スパイラル2巡目で性能問題

　開発プロセスはスパイラル型を採用した。本稼働前に，既存商品の業務手順の情報を各営業担当者に入力してもらう必要があり，そのためにデータ入力機能だけを先行稼働させる必要があったからだ。その後に，印刷や管理など残りの機能を追加開発し，本稼働に間に合わせるという計画を立てた。

　2004年2月に始まったスパイラルの1巡目（共通業務マニュアル入力機能の開発）は順調に進んだ。だが，1カ月後の3月に始まった2巡目（個別業務マニュアル入力機能の開発）で，性能問題が発生した。先行する共通業務マニュアル入力機能をベースに個別業務マニュアル入力機能を開発すると，どうしても性能が出ないのだ。

　例えば，Webページの画面を切り替えるだけで，30秒程度も待たされてしまう（図2）。今後，印刷や管理などの機能を追加したら，性能はさらに低下する。実用に耐えなくなるのは確実だった。