1. 37万5000ユーザーが利用するアプリケーションをパブリッククラウドで開発
2. クラウドの制約に抵触しオンライン処理が停止することが設計段階で判明
3. クエリー数の制約回避で起こったバッチ処理の時間超過は処理の多重化で解消

 「パブリッククラウドでアプリケーションを動かすには、いろいろな制約を回避する必要があるのか…」。損保ジャパン・システムソリューション(SJS)の佐々木智尋氏(SJシステム統合本部 保険システム第二グループ テクニカルチーム 主任システムズ・エンジニア)は、初めて利用するセールスフォース・ドットコムのPaaSサービス「Force.com」を調べていたとき、制約回避の重要性に気付いた。

 佐々木氏は、親会社である損害保険ジャパン(以下、損保ジャパン)の代理店ポータルシステムの開発プロジェクトに携わっている。担当は、オンラインとバッチのアプリケーション開発。代理店数が急増してもユーザー数の設定変更だけでシステムインフラを拡張できるように、パブリッククラウドで動かす(図1)。

図1●損保ジャパンがパブリッククラウドで構築したシステム
図1●損保ジャパンがパブリッククラウドで構築したシステム
顧客向けサービス向上や新しい保険商品の開発などを手掛けるリテールビジネスモデル革新プロジェクト「PT-R」の一環として、パブリッククラウドを使って代理店向けシステムの開発に取り組んだ
[画像のクリックで拡大表示]

 開発するオンラインアプリケーションは二つある。損保ジャパンと代理店の間で、契約手続きや事務処理といった作業進捗を管理する「ToDoリスト」と、代理店向けの連絡事項を伝えるための「お知らせ」だ。電話やファクシミリを使った従来のやり方よりも、効率よく情報共有することを狙う。

 一方のバッチアプリケーションは、オンラインで必要なデータを、保険事務や契約管理などの社内の基幹系システムから、日々取り込むためのもの。対象データは1日に50万件にもなる。

 企画段階では、SJSが損保ジャパンに適用した実績を持つSaaSサービス「Salesforce CRM」の採用も検討した。しかし、画面のデザインを代理店ポータルに合わせる必要があるため、今回はForce.comでの開発が決まった。

制約に起因する課題に二度も直面

 佐々木氏は開発で十数人のメンバーを率いる。開発に先立って、損保ジャパンや約4万6000の代理店にいる37万5000ユーザーが同時利用できるかどうかを、セールスフォース・ドットコムに確認。ユーザー数、データの処理量などを伝えて評価を依頼したところ、問題ないという回答が得られた。

 Force.comの画面開発フレームワーク「Visualforce」や、専用の言語「Apex」を使って開発を試行し、これまでのオープンシステムの開発経験が生かせることを確かめた。データベース操作はSQLの知識があれば問題ないことも分かった。

 冒頭の佐々木氏の気付きはこのときのものだ。Force.comには、アプリケーションの処理に対して「ガバナ制約」と呼ぶさまざまな制限があり、抵触するとエラーが発生して処理は停止する。複数のユーザー企業が同じインフラでアプリケーションを動作させることを踏まえての制限である。

 佐々木氏らは、2008年6月から2009年10月までのプロジェクト期間中、ガバナ制約に起因する大きな課題に、二度直面する。一度目は2008年9月からの外部設計で、二度目は2009年春のプログラム開発/単体テストで起こった(図2)。いずれもクラウドがエラーを発するほど、データ件数や問い合わせ回数が多いことが原因で起こった。順に詳しく見ていこう。

図2●パブリッククラウドでの開発スケジュールと直面した課題
図2●パブリッククラウドでの開発スケジュールと直面した課題
パブリッククラウド関連プロジェクトでは、オンラインアプリケーションとバッチアプリケーションのそれぞれで課題に直面した。いずれの課題もクラウドサービスに組み込まれている「ガバナ制約」に起因したものだった。「 PT-R」 ではパブリッククラウド関連プロジェクトのほか、代理店ポータルシステム、事故受付システムなどの開発を並行して進めた
[画像のクリックで拡大表示]