Point
1. 2000営業所で6万人の営業職員が利用するWebシステム
2. オフラインでもクライアントPC上でサーバー・サイドJavaを実行可能
3. トラフィック低減を狙い，各拠点にキャッシュ・サーバーを導入
| ||
|
この巨大なWebシステムをスムーズに開発/運用する最適解として，システムのインフラを構築する「基盤チーム」はフレームワーク整備やネットワーク負荷軽減など4つの工夫を凝らした（図1[拡大表示]）。
センター集中で保守コスト削減
日本生命が新システムの構想に着手したのは，クライアント/サーバー（C/S）型の旧システムが稼働してからわずか2年後だった。同社は5年のサイクルで大規模システムを刷新しているためだ。その理由を基盤チームのユーザー側責任者を務める立岡聡氏（システム企画部 課長補佐）は，「システムの陳腐化を防ぎ，保守コストの増加を抑えるため」と説明する。
実際に旧C/Sシステムでは，陳腐化したVisual Basic 4アプリケーションのメンテナンスやモジュール配布の手間，ならびにオフラインで使う携帯端末向けとオンラインで使う社内PC向けに，同一の機能を二重に開発する必要があるなど，高い保守コストが問題だった。
これを受けて基盤チームは，J2EEによるWebベースの新システムを構築することに決定。センターにアプリケーションを集中できるため，保守コストを下げる効果が見込めるからだ。
従来2000台のAS/400に分散していた処理をセンターに集中するに当たり,サーバーのハードウエアは，APサーバーにハイスペックのUNIXサーバーを8台配置し，DBサーバーにメインフレーム2台を利用するのが妥当と判断。これは，サーバー処理のデータ量が旧システムと比べて数百倍になると試算したためだ。旧システムの電文は約1Kバイトだが，WebシステムのHTMLは数百Kバイトになる。
2層のフレームワークで開発効率化
ハード構成の次は具体的なシステム基盤の検討に入った。保守コストの抑制に加え，開発効率も上げたいという日本生命の要望に対して，基盤チームのベンダー側責任者を務める，ニッセイ情報テクノロジー（以下NIT）の高倉禎氏（フォーラム21推進部 上席プロジェクトマネジャー）は，Javaフレームワークの利用を提案した。
このフレームワークには2つの特徴がある。一つは業務アプリケーションの共通機能を，業務系とインフラ系に分類して2層のフレームワークにまとめること。もう一つは下層のフレームワークがオープンソースのMVCフレームワーク「Struts」をベースにしていることだ（図2[拡大表示]）。当時，フレームワークはまだ注目度が高くなかったが，既にNITはStrutsの利用実績があり，有用性を高く評価していた。
後者の特徴から説明しよう。Struts 1.1は，アプリケーションの起動時に，差し替え可能な処理を実行させる「プラグイン」という機構を備える。高倉氏はこの「差し替え可能」な点に着目。ユーザー認証や権限チェックなど，業務システムで共通するインフラ系機能をプラグインで開発しておけば，将来の保守が容易になる。Strutsとプラグインをまとめて「日本生命標準フレームワーク」として完成させた。
業務共通機能を徹底的に洗い出す
日本生命標準フレームワークの上に作成する「ドメインフレームワーク」は，業務での共通機能をまとめたものである。今回実装する業務は，旧システムと同じ(1)顧客管理，(2)設計書作成などの保険提案，(3)チラシ印刷などの販売支援，(4)マニュアル閲覧などの事務支援――。機能仕様に大きな改変はない。ただし，ビジネス・ロジックのCOBOLは一部再利用できるものの，プレゼンテーションはVisual BasicからJ2EEへ実装し直す必要がある。
特に今回は大規模開発だ。開発はもちろんのこと，保守の効率を考えると，共通処理を事前にクラス実装しておくことが不可欠となる。基盤チームは，4つの業務を徹底的に分析。業務ごとに用意したクラス群を「ドメインフレームワーク」と命名した。
フレームワークの整備と並行して，開発規約も細かく規定した。例えば，「画面は50Kバイト以内，帳票は100Kバイト以内，1機能のオブジェクト数は300以内」などだ。開発者には規約の厳守を命じ，逸脱する場合は必ず基盤チームに相談するように徹底した。
