PR

図1●基幹システムをオープンソース・ソフトで再構築
有線ブロードネットワークスは2003年7月まで,基幹システムとして汎用機(NonStop Himalaya)にWindowsサーバーを組み合わせて利用してきたが,運用コストの負担に耐えきれずシステムの再構築を実施。各所にオープンソース・ソフトを活用し,システム開発を内製に切り替えた結果,運用コストの大幅な削減に成功した
 「これ以上,無駄な保守料金を垂れ流す訳にはいかない」――有線ブロードネットワークスは2003年8月,汎用機NonStop Himalaya上で稼働していた基幹システムを破棄し,LinuxやPostgreSQL,Apacheなどのオープンソース・ソフトを活用してシステムを刷新した。それにより年間約3億円かかっていた保守料金を約1/5の6500万円にまで減らすなど大幅な圧縮に成功。システム開発をほぼすべて内製に切り替えたことで,トラブル時に迅速に対応できる体制を整えた。

ベンダー混在がトラブルの始まり

 同社が旧基幹システムの刷新に踏み切ったのは,そもそも当初のシステム設計に無理があり,その歪みに耐えきれなくなったためだ(図1[拡大表示])。新システムの再構築を請け負ったのは,同社の関連会社であるユーズコミュニケーションズ。開発作業に携わったISP事業部システム技術部部長の長谷川朋之氏は旧基幹システムについて「末期症状に近い状態でテコ入れが急務だった」と振り返る。

 旧システムは,同社がブロードバンド(BB)・ビジネスに参入した2001年に,顧客情報や工事スケジュールなどを管理する目的で構築した(カットオーバーは10月)。顧客情報を管理するHimalayaを中心にWindows 2000上で稼働する課金システムや債権管理システムなど10数個のサブシステムが連係して動作していた。BBサービスはその年の3月からスタートしており,半年遅れでシステムが稼働したことになる。その当時,開発に関わっていなかった長谷川氏は,「伝え聞いた話だが,とにかく突貫工事でシステムを構築したようだ」と打ち明ける。

 当時は,必要な機能を実装し,できるだけ短期間で作り上げることが至上命題だったため,納期に間に合わせるため複数のインテグレータに個々のシステム案件をばらまいた。結果的に5つのインテグレータが手掛けることになったが,「プラットフォームが統一されず,ミドルウエアやハードウエアがバラバラの状態だった。機能設計を優先したがために,インフラ周りの設計がおろそかになっていた」(長谷川氏)。

データの不整合が多発

 カットオーバー後のシステムの改修作業にも手を焼いたという。あるシステムに修正を加えると,関連するシステムでも修正作業が必要になる悪循環が続いた。本来は1つあれば済む顧客データベースが,個々のシステムごとにマスター・データを保持していたことが原因の1つ。「トラブルが起こるべくして起こるシステム設計だった」(長谷川氏)。

 さらに,バグが追い打ちをかけた。システム間でデータの不整合が頻発し始めたのだ。開発元が違う複数のシステムが複雑に接続されていたため,データ更新のタイミングをシステムがハンドリングしきれず,データの不整合を引き起こしていた。例えば,収容情報管理システムでは開通しているユーザーが,課金システム上では開通していないと表示される,などだ。この状態では,サービスを提供しているユーザーから集金できないことになってしまう。

 トラブル時の対応も一筋縄でいかなかった。異なるベンダーが開発したシステムが接続されていたため,トラブルを引き起こしたマシンを特定する切り分け作業が難航した。「結局,トラブルは営業担当者が日報を持ち寄り,日付を頼りに手入力で正しいデータに書き直すといった作業で乗り越えていた」(長谷川氏)。

コストに見合わぬ汎用機を撤去

 保守費用も大きな問題を抱えていた。最も高額なのが2億円のNosStop Himalayaの保守料金。その次に,インターネット・サービス・プロバイダ(ISP)向けパッケージ「Prism」の年間ライセンス料金が4000万円と続く。そのほか開発を依頼した5社のインテグレータに支払う保守料金などを足し合わせると年間の保守料金は3億円に達する。

 安定稼働を重視して導入を決めたHimalayaではあったが,「オーバースペックぎみだった」(同氏)ため,保守費用の高さを嫌って撤収を決めた。

 ISP向けパッケージのPrismに関しては,機能要件を一から洗い出してみたところ,製品本来の機能を生かし切っていないことが判明。「Visial Basicでアプリケーションを開発すれば,パッケージを使う必要がないことが分かったので即刻利用の中止を決めた」(同氏)。


(菅井 光浩=sugai@nikkeibp.co.jp)