このプロジェクトでは、基幹システムと連携する重要なシステムの内製化を成功させ、外部ベンダーへの依存を解消することができました。さらに、運用効率の向上とコスト削減を実現し、社内での安心かつ安全な運用を可能にする重要なステップとなりました。

当時の様子を長谷さんに振り返ってもらいました。

※この記事の内容は取材当時のものです。

オープンゲートウェイとは

当社のクレジットカード会員専用サービスには、「Netアンサー」やスマートフォンのアプリ「セゾンPortal」といったオンラインで利用状況や請求明細、ポイント残高などを確認できるサービスがあります。

これらのサービスと、クレジットカードの情報を管理する大元のシステム「HELIOS（ヘリオス）」の間に、中継サーバと呼ばれるシステムがあります。この中継サーバがオープンゲートウェイです。

単に情報をそのまま渡すだけでなく、必要に応じてデータを変換したり、制御したりします。これにより、フロントシステムがスムーズに動作し、安定したサービスを提供できるようになります。

システム課題

当社のオープンゲートウェイにはいくつか課題がありました。

特に最後の課題は非常にもどかしい状況でした。

具体的には、フロントシステムの「セゾンPortal」を内製化し、新たにプッシュ通知サービスを導入した際、通知を受け取ったユーザが一斉にアクセスすると、アプリが正常に起動しないという事象が発生していました。

課題解決までの道のり

１．サーバ更新に伴う再構築の検討

2020年7月、 当社のサーバなどの機器が2021年に寿命を迎えるため、新しい機器に単純に交換するか、システム全体の再構築を行うかの検討が開始されました。

当時、当社は外部ベンダーに依存していましたが、インフラ基盤（z/Linuxを含む）の再構築を含めた機能配置の見直しが必要とされ、稟議で予算が承認され、プロジェクトが始動しました。

２．アプリケーション開発の内製化へ

2020年10月、内製開発チームが立ち上がりました。このプロジェクトの継続に関して、「再構築は不要ではないか？」といったさまざまな議論が行われた結果、以下の方針が決まりました。

• 基本的な機能は変えず、再構築する必要はない。

• システムの枠組み（フレームワーク）を新しいものに移行するだけにして、ビジネスロジック（システムがどのように動くかの部分）はそのままにする。

• 必要最低限のテストコードを実装して品質を確保する。

• システムの再配置を行わないことで、他の関連システムへの影響を最小限にする。

この方針により、一部の成果物を取り除いてもコスト削減が可能となりました。
そして、2021年3月にアプリケーション部分を内製開発する方針に切替えました。

３．外部ベンダー依存のインフラ基盤の見直し

内製開発が始まって9か月が経過した頃、システムテストの計画が進む中で、z/Linuxが動作するインフラ基盤の性能が「流量制限（※１）」という問題を解決できるかが懸念されました。

通常、システムテストの後半で行う性能テストを前倒しで行った結果、求められている性能を実現するには、数億円単位の追加の機器の購入が必要なことが分かりました。

※１流量制限：システムが一度に処理できるデータの量に制限があること

４．解決策の模索

オープンゲートウェイを担当している開発チームは、SIer（※２）のアプリケーション開発担当が中心のメンバーで構成されており、これまでAWS（※３）を利用した経験がありませんでした。しかし、問題を解決するために、まずはAWSについて学び始めました。

※２SIer（システムインテグレーター）：企業や組織が必要とする情報システムを設計、開発、導入、運用するサービスを提供する企業や専門家
※３AWS（Amazon Web Services）：　Amazonが提供するクラウドコンピューティングを活用したサービス

当初はOpenShift（※４）を使う予定でしたが、AWSのEKS（※５）を使ってシステムを構築し、アプリケーションを新しいフレームワークに移行しました。この新しい環境で性能テストを行った結果、いくつかの課題はありましたが、すべて解決することができました。

※４OpenShift：Red Hat社が提供するオープンソースのコンテナアプリケーションプラットフォーム
※５EKS（Elastic Kubernetes Service）：Amazonが提供するサービスで、Kubernetesというアプリケーション管理ツールを使いやすくするためのもの

技術検証が完了し、すでに購入してしまっていたz/Linuxの機器を除却してもコストが計画内に収まることが確認できたため、インフラ基盤をAWSに切り替えることを決定しました。この変更は承認され、AWS基盤上でのシステムテストがスタートしました。

そして、2021年12月にインフラ基盤をz/LinuxからAWSに切り替え、完全な内製化が実現しました。

リリースから運用改善へ

リリースまでの流れ

システムをAWS基盤に切り替えたことで、心配していた性能テストも無事にクリアできました。さらに、ジョブスケジューラ（※６）や運用監視システムも新しいものに切替え、内製開発がしやすい環境を整えました。システムテストや移行リハーサルも予定通りに終了し、リリースを目前に控えていました。

※６ジョブスケジューラ：コンピュータシステム上で特定のタスクやジョブを自動的に実行するためのソフトウェアツール

リリースの1週間前に、プロジェクトのキーマンが体調を崩し、コロナ陽性と診断されるというハプニングがありましたが、リリース日前日には復帰し、大きなトラブルなく2022年7月にリリースを成功させることができました。

＜ 内製化前後の比較 ＞

内製化後の改善ポイント

内製化により、以下の点が改善されました。

１．対応時間の短縮

リリース後の小さな修正や新規カード発行などの案件で、申請フローや必要なドキュメントを見直し、対応完了までの時間を半分以下に削減しました。

２．新規案件の効率化

ビジネス部門と打合せ段階から内製チームも参加することで、ビジネス要件とシステム要件を同時に検討していくことができて、最適なサービス導入が可能になりました。

３．運用監視の効率化

内製化により、既知の問題に対する報告業務が不要になり、リアルタイムで運用状況を把握できるようになりました。これにより、ハイセキュリティルーム（※７）に行く機会が大幅に減りました。

※７ ハイセキュリティルーム: 非常に高いレベルのセキュリティが求められる場所に設けられる特別な部屋のこと

４．夜間対応の削減

ジョブスケジューラによるバッチ処理の正常終了をリアルタイムで確認できるようになり、精神的な負担が軽減されました。また、ジョブネットの停止・再開を事前に予約できる仕組みを構築したため、夜間の立ち合いが不要になりました。

その後

自動テストを実装したことで、システムのバージョンアップが容易になり、依存するオープンソースソフトウェア（※８）の脆弱性も管理しやすくなりました。

これにより、ランニングコストを当初の計画から30%削減することができ、課題だった流量制限も大幅に緩和されました。

※８ オープンソースソフトウェア: ソフトウェアのソースコードが公開されており、誰でも自由に使用、変更、配布できるソフトウェアのこと

このプロジェクトは、フロントシステムのように目立つものではないかもしれませんが、基幹システム「HELIOS」とつながる重要なシステムを内製化することに成功し、社内で大規模で安心・安全な運用が求められるシステムにも対応できることを証明する大きな一歩となりました。