輸出入リスクに対する保険を提供する日本貿易保険は2007年4月、メインフレーム上で稼働していた保険業務システムの再構築を完遂した。設計、開発は日本IBMが担当。その開発規模はJavaで400万行に上る。仕様漏れによるやり直しから、当初計画より稼働が1年3カ月遅れた。
「『来月にはプロジェクトの遅れを取り戻せる』と先月言っていたが状況は変わっていない。いったいどうなっているんですか」。
ベンダーの経営層が集まるプロジェクト進捗会議の席上、日本貿易保険（NEXI）の情報システム担当理事である大林直樹氏は、保険業務システムの遅れについて日本IBMの役員に問いただした。約2年で完了予定のプロジェクトが、残り半年にきたところで遅れが拡大していた。それとともに、大林理事の不安は膨らんでいった―。
結果的にその不安は現実のものとなる。稼働開始が1年3カ月遅れ、ユーザー、ベンダー合わせて数十億円とみられる予算超過が発生した。NEXI側の人数が少ない中で、開発規模に対し開発期間が短かったこと、プロジェクト・マネージャと現場とのコミュニケーションが不足していたこと、が主な原因である。ただ、確実に守る必要がある貿易保険制度の改正時期には間に合った。
大規模だが情シスはたった10人
このプロジェクトは、メインフレーム上にあるすべての基幹システム「貿易保険情報システム」をオープン系サーバーで再構築するもの。最大の目的は、プログラム保守費用の削減である。1992年から利用してきたメインフレーム（NECのACOS-6）上のシステムが、機能追加で複雑かつ巨大になっていた。 COBOLプログラムのコード量は稼働開始当初の倍以上、550万ステップである（図1）。
 |
| 図1●日本貿易保険は、保険業務システムをJavaで再構築した |
加えて、機能面でも近い将来大きく変える必要に迫られていた。07年4月の制度改正で、これまでNEXIが独占していた貿易保険事業に民間事業者が参入する。それと同時に、保険契約方式が大きく変わる。
このプロジェクトには、“大規模なレガシー・マイグレーション”というだけでない難題が、内在していた。
まず、既存システムの細かい仕様まで熟知している担当者がいなかったこと。元々、メインフレームのシステムはNECが保守していたが、今回参加していない。NEXI側の情報システム担当者は約10人しかおらず、業務とシステムの両方に通じている担当者は限られていた。要件定義書は、03年からニッセイ情報テクノロジー（NIT）がNEXIの各部署にヒアリングをかけ、作成した。
貿易保険情報システムのうち、保険業務システムを日本IBMが請け負う形になったのは、このプロジェクトが中央省庁のIT調達改革の一環であり、既存ベンダーを指定する随意契約をやめたからだ。一般競争入札の結果、予定落札価格を20億円近く下回る約40億円で日本IBMが落札。戦略的に金額を設定して獲得したとみられる（図2）。
 |
| 図2●貿易保険情報システムの全体像と各ベンダーの開発分担 政府が推し進めているIT調達改革ルールを先取りする形で分割発注方式を採用した |
また、開発環境にも制約があった。アプリケーションは、OSやハードウエアに依存しない形で開発する必要があり、Javaが必須条件となった（図3）。アプリケーション開発とハードウエアの調達を個別に実施する“分離調達”を取り入れたからだ。早くハードウエアを定めると、稼働時期には古いスペックになってしまうので、システム開発の入札がハードウエア調達の入札より先になった。
 |
| 図3●貿易保険情報システム全体のハード/ソフト構成 メインフレーム（ACOS）で稼働していたシステムをUNIXとWindowsでオープン化した [画像のクリックで拡大表示] |
ユーザーのIT人員不足に事前対策
「難易度が高い」。そう考えていたNEXI側の北薗隆システム企画グループ長らは、プロジェクトのリスクを軽減するために、2つの事前策を講じた。1つが、ユーザー側の立場でアドバイスするシステム顧問を置いたことだ。NITの紹介で、ITコンサルタントの松波正巳氏と土佐育也氏を顧問として採用。両氏は過去に大規模な金融系システムの開発にかかわった経験を持つ。
もう1つが、「トップマネジメント会議」の定期開催である。ユーザーとベンダー双方の経営トップが一堂に会し、毎月、プロジェクトの進捗状況や問題点を報告し合う。責任の所在を明確にするために設置した。NEXI側はトップである理事長とシステム担当理事、システム室長、顧問が会議に参加。日本IBM側は2人の役員が社長代理として出席することが決まった。
こうした体制を整えた上で、04年4月、日本IBMはNITが作成した要件定義書を基に保険業務システムの基本設計に着手した。
