おすすめの特集
第1回では、那覇市に本社を置く損害保険会社、大同火災が1975年から約50年にわたり使い続けてきたメインフレームからの脱却を開始するまでの道のりをご紹介しました。
(No1記事リンク)
” 2025年の崖”の衝撃の真っ只中で進められたプロジェクトは、リリース延期もあったものの、活発な部内コミュニケーションやパートナー会社との信頼関係構築によって着実に前進。プロジェクトは業務の効率化やコスト削減にとどまらず、会社全体にポジティブな変化をもたらしました。

BEFORE & AFTER

1975年から使用している基幹システムは独自のOSやハードウェアを利用。さらに2008年から導入したサーバー環境とのハイブリッド運用のため運用コストが膨らみ、新規IT投資(攻め)と維持管理費(守り)の割合が1:9の構造になっていた。また、システム環境の制限からオンライン利用やペーパーレス化が難しい状況だった
  • 3年でのメインフレームからの脱却を計画。「契約管理システムの機能拡張」「新たな保険金管理のシステム構築」「マイグレーション」の3プロジェクトを2022年12月までに完了。システム処理コスト30%削減、全帳票の電子化、運用処理自動化を行い、攻めと守りのコスト構造を4:6へ転換する変革を成し遂げた

5社の協力体制でシステムを構築するも、リリースは延期に

大同火災のメインフレーム脱却に向けたプロジェクトは、契約管理システム機能拡張や新たな保険金管理システムの構築を2021年12月までに完了。

「マイグレーション」は、大同火災とパートナー会社(開発・保守・運用・印刷など)の計5社の体制で進みます。

具体的には、メインフレームのシステムをサーバー環境へ移行、メインフレーム上で稼働中の旧システムと、サーバー環境上の新システムを並行稼働し、データおよび出力帳票との検証作業が行われました。

そのフェーズ1として、2021年1月からサーバー環境ですべての処理が異常終了することなく最後まで実行されるか、3カ月かけて動作検証。その後、帳票などの最終的な出力物を比較検証するフェーズ2に移行し、不一致のある部分の原因究明・修正を約6カ月かけて実施しました。

そして年度末の決算処理など年に数回の重要処理の検証を実施するフェーズ3に移行しましたが、この段階でまだ品質がリリース可能なレベルに達していないことが明らかになります。

この結果を受け、品質に問題があり、予定していた2022年5月リリースは延期せざるを得ないことを情報システム部から経営層に報告。新たなリリーススケジュールを決めるため、パートナー会社と話し合いの場を持つことになります。

パートナー会社と目指すゴールを明確化。品質を確保してリリース

プロジェクトを主導した阿波連さんは、その話し合いの場で、「会社の立場からの建て前の意見ではなく、現在の品質状況からどのくらい時間が必要なのかを考え、確実にリリースできる時期をコストも踏まえて議論してほしい」と伝えます。その結果決まった期日は2022年12月でした。

当時の情報システム部長、阿波連宗哲(あはれんむねてつ)さん

複数のパートナー会社とフラットな立場で話し合うことで、「品質を確保したシステムを2022年12月にリリースする」というゴールを明確化。阿波連さんが「この話し合いがキーポイントになった」と振り返るとおり、この後に行われた検証作業(フェーズ4)で品質は大幅にアップ。

フェーズ3までは、評価項目5項目のうち3項目に△(不一致)が見られましたが、リリース延期後のフェーズ4ではすべて完全一致か条件付OKとなっています。

フェーズ3からフェーズ4で品質が大幅に向上

フェーズ4の後に行われた最終フェーズでは、数日前の直近データを使用し、一部自動化を行った運用体制で継続的に安定運用できるかという最終チェックも併せて行いました。
検証の結果、リリース可能な品質が確保できたことから、当初の予定からは7カ月遅れたものの、2022年12月、パートナー会社と決定した期日でのリリースへとこぎつけたのです。

約30%のコスト削減。メインフレーム脱却による様々な成果

メインフレーム脱却により、大同火災はシステム処理コストの約30%削減を達成。既存システムを維持管理する「守り」のコストと、新たなIT投資のための「攻め」のコストの割合を9:1から6:4へと転換することに成功しました。

守りと攻めのコスト割合が9:1から6:4に。既存事業拡大・新規事業開拓へと向かう足がかりに

メインフレーム脱却の効果は、コスト構造の転換のみにとどまりません。基幹システムから出力していた帳票類は、統廃合を行い1152種類のうち一部を廃止、残りはオンライン化または電子帳票化。その結果、テレワーク可能な環境構築にもつながりました。

また、外部委託していたシステムへ入力のパンチ(大量かつスピードが要求されるデータ)原票82種類もオンライン化、またはエクセルからデータを吸い上げる仕組みに変更。一部紙での処理が残っていますが、2023年9月にはゼロになる予定です。

「送られてくるまま、とりあえずファイリングしていた書類も多かった」と営業部に在席していた時代を振り返るのはシステム管理課長の儀部頼之(ぎぶよりゆき)さん。長年の蓄積から内容が重複した書類、何に使うかわからない書類が多かった状況も大きく改善されました。

システム管理課長の儀部頼之さん

契約データのバックアップはクラウドへ移行し、それまで使用していたLTO(データ保存用磁気テープ)は不要に。そのほか様々なデータのやりとりに使用していたCDやフロッピーディスクなどもオンライン化され、物理的な破損や搬送中の紛失などによる外部流出リスクを軽減することにもつながっています。

メインフレーム脱却で得られた成果の一部

さらに、長年の運用の結果、過去発生したミスの再発防止策の積み重ねにより、非常に多くのチェックや手作業があることもわかりました。
運用の効率化のため、運用自動化ツールの機能を最大限に活用し、2023年10月頃にはさらなる運用効率化や処理高速化を推進する予定で、運用時間の圧縮を実現できることになります。

プロジェクトを動かす”人”への姿勢が大きな追い風に

多くのプロジェクトが同時進行する中でのメインフレーム脱却という、部内からも不安の声が上がるほどのチャレンジ。阿波連さんは、プロジェクトへの関わり方を常に意識していた、と語ります。

「管理過多ではうまくいかないと考え、スタッフ一人一人の経験やスキル、性格から、『ここまでなら大丈夫だろう』というラインを見極め、仕事を任せるようにしました。手に余る様子があれば、担当者の会議に入り具体的な指示をするなど、状況によっての関わり方を常に意識していました」(阿波連さん)

任せられる範囲は任せ、必要な場合は適切にサポートを行う管理体制が整えられ、毎日開催される部内ミーティングは率直な意見も飛び交うオープンで活発な議論の場に。その結果、情報システム部内のモチベーションが高く維持されたと比嘉さんは考えています。

「指示されて動くだけでなく、『次はどうしたいのか』を意識させる工夫があり、自発的に取り組む雰囲気が生まれたと感じます。阿波連部長(当時)がシステム部の思いを経営層に届けながら提案してくれることも大きかったです」(比嘉さん)

システム開発課長 前原潤(まえはらじゅん)さん

「プロジェクト定例進捗会議を週1回、課題発生や方針決定の際には随時会議を行いましたが、プロジェクト前半は各パートナー会社との認識の相違に苦労しました。私たちの期待する進め方、成果を伝えたつもりでも、各社で受け取り方が違っていたり、コミュニケーションのギャップが色々な場面で起こり、なかなか前に進まない状況でした。
こちらの意図するところをしっかり伝えられるよう、口頭ではなく図解なども使った資料を用意する、何について議論するのかトピックを明確にする。資料や会議運営にも工夫が必要だと学びました」(前原さん)

プロジェクトを動かすのは人コミュニケーションに関わる様々な心配りは、プロジェクトを成功に導く大きな追い風となったのです。

運用開始後、障害はゼロ。今後もブラッシュアップを継続

リリースから約1カ月が経過した2023年1月末現在、新システムは順調に機能しています。

現在の情報システム部長、石垣正彦(いしがきまさひこ)さんは、プロジェクトの品質を次のように評価しています。

2021年から情報システム部長を務める石垣正彦さん

「業務遂行上支障が出るものやお客様にご迷惑をおかけする『障害』に当たる案件は1件も発生していないんです。障害の手前の『インシデント』は数件ありますが、速やかに対応できている。新規開発ではないので差し引いて考える必要はありますが、プロジェクトの規模、金額を考えると障害が起きていないのはとても珍しいケースと言えると思います」(石垣さん)

新システムの名称はLBS(レガシー・バッチ・システム)。その名付け親はシステム管理課統括主任の比嘉岬(ひがみさき)さんです。

1975年から稼働しているシステムを引き継いだことを忘れず、今後もモダナイズ(最新化)を怠らないために、あえてレガシーという言葉を使いました。プロジェクトに携わったメンバーが人事異動などでいなくなったとしても、思いをバトンタッチできる名前にしたかったんです」(比嘉さん)

システム管理課統括主任 比嘉岬さん

主要なオンライン系システム(※1)は既に使用している開発言語java(ジャバ)で稼働するシステム上に構築したり、新しいプラットフォーム上で新規開発する対応ができましたが、コストと時間の関係から、バッチ系システム(※2)は旧システムで使用されていたCOBOL(コボル)を引き継ぐ形で構築されています。こうしたプログラムを保守できる人材は今後減少していくとされていることから、今後数年をかけて置き換えを進め、クラウド化、ハイブリッド化といった選択肢も視野に進めていく予定です。

また、現場からは、デジタル化が進み業務が大きく変わったことを歓迎しつつも、ブラウザを経由することでシステム画面の表示速度に遅れが出る、旧システムで可能だったことができない、といった声も。

各システムの動作の遅れはストレスに直結するため、改善は最優先で対応すべき課題でした。一部の画面表示速度は6~7秒を1秒まで短縮し、利用部門からようやくお褒めの言葉をいただけました(笑)。現在、各システムの画面表示3秒以内を実現するため、体制を強化して日々改善に努めています」(前原さん)

※1オンライン系システム:ユーザーに対してリアルタイムで応答するシステム
※2バッチ系システム:大量のデータを一括して処理する方式。処理結果を出すまでに一定の時間が必要となる

社内が活性化し、新たなチャレンジへと向かう機運が生まれた

デジタル技術活用に向けた基盤整備を終え、SoR(System of Record/データを正確に記録するシステム)をしっかりと整えた大同火災。

2022年度から新たに始まるIT戦略計画では、”DX推進による業務変革と新たな価値創造”をテーマに、SoE(System of Engagement/顧客との絆を深めるシステム)やSoI(System of Insight/情報を分析し、顧客ニーズや購買プロセスを探るシステム)構築に力を注ぎ、営業、社内業務、損害サービスでもDXを進めるほか、データ利活用のための分析基盤構築にも着手しています。

「メインフレームの継続を選択していたら、維持管理費の負担で攻めのコストを捻出することは不可能。計画の内容はかなり限られたものになっていたでしょう。メインフレームの脱却をはじめとする各種プロジェクトを完遂できたことは、情報システム部の自信になったことはもちろん、会社全体にも活気をもたらせたと思っています。
多くのプロジェクト案件を並行して進めていく難易度の高いものでしたが、当社とパートナー会社で健康を害したり、離脱した人が一人もいないことは自慢です」(阿波連さん)

プロジェクトをやり遂げた5人は「こんなチャレンジングな計画はもう十分です」と口を揃えますが、その表情は晴れやか。

50年来のシステムを抜本的に改革する思い切ったチャレンジは、DX実現への大きな足がかりとともに、会社全体に自信と明るく前向きな風ももたらしました。

【会社概要】
会社名 大同火災海上保険株式会社
事業内容 損害保険
代表  取締役社長 与儀達樹
設立 1971年
所在地  沖縄県那覇市久茂地1-12-1
従業員数 315人
平均年齢 40.8歳

おすすめキーワード

支援情報を探す

目的から探す

支援制度から探す

イベント情報