はじめに

2025 年 9 月 18 日に AWS Innovate: Migrate and Modernize が開催されました。

10 月 1 日まで全セッションオンデマンド配信中で、すべての講演資料もダウンロード可能とのことです。

その中のお客様事例セッションを備忘録的にまとめました。

NEOBANK を支える AWS を活用したモダナイゼーションへの挑戦

スピーカー

渡邊弘様
- 住信SBIネット銀行株式会社システム本部副本部長執行役員

内容

AWS活用状況
- 勘定系を除く全ての商用系ワークロードで活用
  - 2019年に、オンプレデータセンターからAWSへ移行完了
    - 商用系はAWS、OA系はAzure
  - 以降、順次モダナイズ化
課題：2019年のAWS移行完了時
- 技術的負債
  - すべてLift＆Shiftで移行
  - 長年の技術的負債
    - プログラムの複雑化
    - 機能集約
    - ベンダーロックイン
  - 銀行オペレーションにも影響
    - 機能・オペレーションごとにUIが異なり、使いづらい
      - オペレーションごとにチーム化され、情報・ナレッジがサイロ化
      - 各々がエクセルマクロやRPAを活用し独自のやり方で効率化
取り組み
- EKSを用いたマイクロサービス化戦略
  - EKSで共通基盤「Sprinkle」を2021年リリース
    - プロダクトファースト
      - 開発者はサービス洗練に注力してほしい
        
        課題として、学習コストが高い
        
        Wikiなどで、開発者の情報共有
    - ベストプラクティス設計
    - すべての機能はAPIへ
    - マルチベンダー開発
    - レジリエンシー＆オブザーバビリティ
  - 利用システム
    - インターネットバンキング（2023年から。2026年完成予定）
      - 機能をサービス単位に分割
      - 6つのフェーズで順次移行
    - 住宅ローンシステム（2021年から。2027年完成予定）
      - フロント部分のフェーズは完了
    - 顧客事務システム（計画策定中）
      - 開業以来スクラッチで内製開発されてきたシステム。技術的負債盛りだくさん
        
        当初は、口座開設オペレーションを担うだけだった
        
        今では顧客情報管理、オンラインに組み込まれるなど、どんどん重厚長大化
        
        オンライン化に伴い、トランザクションが多い日は要スケールだが、有償ソフトが障壁
      - AWS DevTxプログラムの活用
        
        内製開発者の中にモダナイゼーションの有識者がおらず、進めなかった
        
        PACE(Prototyping and Cloud Engineering)チームと伴走し、ドメイン駆動設計
        
        業務のモデル化を行い、システムを適切に分割するPOCを実施
        
        レポートと、具体的なシステムアーキテクチャの提案までしてもらえる
    - 銀行オペレーションシステム（勘定系は2025年完成予定、その他は順次）
- マイクロサービス開発導入によって変わったこと
  - 仮説実験を繰り返す文化
  - 開発コスト最適化
    - 委託・内製・オフショア
  - 考える社員増加中

シームレスな移行を実現～ホストから SAP、そして Amazon QuickSight によるデータ活用事例～

スピーカー

鈴木年様
- 株式会社富士通ゼネラル　デジタルイノベーション推進部部長代理
佐々木寛様
- 株式会社富士通ゼネラル　デジタルイノベーション推進部エキスパート

内容

基幹システムの課題
- IT負債の解消が急務
  - 基幹業務システムを長年塩漬け
    - 30数年来の使用
  - メインフレーム、COBOL、バッチ処理
    - 一部は昭和歴を使用
  - 管理・集計業務はメインフレームから抽出したデータをExcelで２次加工
    - 分析、予測に時間が割けない
  - 属人的システム運用体制、ホストIT人材の枯渇
    - ベテランIT社員の退職でブラックボックス化
- 2024年度までに刷新し、業務改革とビジネスモデル改革に対応可能な基盤とする
取り組み１：SAP導入プロジェクト
- 競争優位性のないバックオフィス業務はクラウドのERPパッケージを採用
  - COBOLマイグレーション方式は業務・システム構造が改革出来ないため採用せず
  - 導入ベンダーが豊富で調達しやすいためSAP S/4HANA Cloudを選択
    - 会計、販売、購買領域に適用
  - プロジェクトの目的
    - 全体最適を図ること：パッケージの持つ標準業務に合わせて生産性の向上を図る
    - データドリブン型経営を推進するため、実績や予測情報をタイムリーに収集、分析できるようにすること
    - レジリエンスを強化し、ビジネス環境の変化に即応させること
- プロジェクトのスコープを定義
  - 全社レベルで業務ミッション、システム構造、データマネージメントレベルを明確化
  - その中で今回のERP（SAP）導入スコープを定義
    - 日本の単独決算をスコープに
    - 他部分は個別のパッケージを採用する方針
- トップヒアリング実施
  - KPIが明確に
    - 次工程以降でKPIに必要なパラメータを明確にし、どのプロセスから取得できるか定義
- スケジュール策定
  - 27か月後の本稼働をコミット
  - Fit to Standard方式での導入、早期稼働を狙う
- 要件定義フェーズで苦戦
  - Fit to Standard方式での導入を目指すも、現行踏襲に傾いてしまう
    - 業務要件が収束しない
      - 現行踏襲、現行保証
      - 現行通りにならない場合は残課題
    - アドオン要件が膨らむ
      - 開発期間が延伸。コスト増
  - 原因
    - 部門担当者は現行システムに不満がない
    - ITをコーディネートするスキルがIT部門に足りない
  - 対応策
    - ステップ１としてIT基盤刷新を優先
      - マインド・推進力不足、スケジュールキープのため、業務改革はステップ2
      - 期待値のコントロールが重要
        
        適宜ステコミでスコープなどを承認
      - SAP導入の経験者を採用
  - プロジェクト評価
    - ステップ１のIT基盤刷新を計画通りに23年10月から本稼働
      - 受注、引当、出荷から業務開始。事業停止などの重大な障害は発生せず
        
        稼働時に「運用対策室」を設置、業務運用の監視・フォローを徹底
      - 24年4月以降は社内SEでシステム運用開始
        
        導入ITベンダーから切替え済
    - 課題
      - PJ方針の周知不足
      - SAP標準画面の操作性不満
      - アドオン抑止の不満
    - プロジェクトの要諦
      - 期待値のコントロール
        
        新業務プロセスで業務の成立性を検証
        
        実行系/管理系/顧客要件/社内要件
        
        システム化スコープを絞る
        
        プロジェクトマネジメントの徹底
        
        リスク管理として、障害でシステム無し2-3日ができるよう準備
取り組み２：データ分析プラットフォームにSAPデータ分析を追加
- データ分析プラットフォーム
  - S3/Athena/QuickSightを組み合せ、データ分析基盤を構築
  - QuickSightを標準BIツールとして全社に普及させ、データ活用を拡大
  - SAPデータ分析を追加し、非SAPデータも含めデータを一元管理
- 開発方針
  - スピードと柔軟性の両立
    - 自社開発することで、要望に迅速に対応
    - 継続的に改善できる体制を構築
  - 安定性の確保
    - 開発から運用まで2名で担当
    - 少人数でも安定稼働できる仕組み
  - コスト最適化
    - サーバレスサービスを活用
- 技術課題
  - HANA Cloudからのデータ取得
    - Athenaのフェデレーテッドクエリを利用
    - Glue Job（python shell）でAWS Data Wranglerを使用してSQLを実行し、取得データをS3に保存
      - Lambdaでは15分の制約のため非採用
      - 取得情報をSNSでメール通知し、成否の確認を省力化
- システム稼働状況、利用状況把握
  - CloudTrailのログを分析、QuickSightで可視化
- 運用上の課題と対策
  - 売上データの増加に伴い、データ更新時間も拡大
    - 売上データを月別に分割し、ファイル単位で管理
    - 直近3ヶ月分（四半期）のデータのみを毎日更新
- 効果
  - 400名のユーザが利用
  - 年間3,000万円の工数削減効果

オンプレ仮想化基盤から AWS への大規模移行～CCoE と共に実現する安全なクラウド環境への移行～

スピーカー

村岡健様
- 株式会社リコーデジタル戦略部プロセス・ＩＴ・データ統括コーポレートＩＴ統括センター　ＩＴインフラ統括室戦略グループ

内容

AWS活用状況
- CCoE設立
  - 2020年に掲げた「Cloud First方針」を契機に、 AWSの利用が増加
    - 以前は、各事業部が独自にアカウント発行していた
    - AWSアカウント数、AWSに関するコストが年々増加
      - ガバナンスの強化が急務
  - 2021年にCCoEを設立
    - セキュリティガードレールの展開、コスト最適化を推進
- CCoEの体制
  - CCoEチームリーダー以下、3チームで800強のAWSアカウント利用者を支援
    - 支払い代行チーム
      - 請求、コスト、予算管理
      - クラウド利用受付
    - 基盤運用・構築チーム
      - アーキテクチャ・プロセスルール化
      - 基盤環境の構築・運用
    - クラウド構築支援チーム
      - 技術支援
- AWS基盤環境
  - 以下2環境をセキュリティガードレールを適用した上で利用者に向けて提供
    - 専用線環境
      - 社内基幹系システム・社内システム向け
      - 拠点 ⇔ AWS 間を閉域網専用線(Direct Connect)で接続
      - 拠点 ⇔ AWS VPC間でプライベートIPアドレスによる通信が可能
      - 専用線環境から直接インターネット(In/Out)接はできない
    - 非専用線環境
      - 社外サービス向け
      - Direct Connectは未使用。通常のパブリッククラウドと同じ
      - 各利用者のVPCから直接インターネット(In/Out)接続ができる
      - 拠点から非専用線環境に接続する場合は、インターネット経由
  - セキュリティガードレール方針
    - 俊敏性・柔軟性やコスト効果を損なわない統制
    - 利用者が「セルフサービスで」クラウドサービスの豊富なメニュー・機能を利用できるべき
  - セキュリティガードレールの仕組み
    - OrganizationsのSCPで、組織アカウントの制限ポリシーを一元管理
    - 各種セキュリティ関連サービスを標準利用
      - CloudTrail、Config、GuardDuty、Inspector、Security Hub、Security Lake
      - ログ収集アカウントで、セキュリティ関連ログを一元管理
移行プロジェクトにおけるCCoEの取り組み
- プロジェクト背景
  - オンプレ仮想化基盤のEOSを契機に、26年2月までにクラウド環境に移行
- スケジュール
  - 企画：FY23 1Q
    - オンプレ仮想化基盤の終了周知、新規受付停止
    - VM利用状況ヒアリング・棚卸
    - クラウドシフト方針の提示
  - 計画：FY23 2Q
    - 利用者側でのクラウド移行計画の策定
    - 移行計画策定の個別サポート、お困りごとヒアリング
  - 実行：FY23 3Q～
    - 利用者主体でクラウドへ移行
- プロジェクトのポイント
  - IT部門主導のもと、事業部が主体的にクラウドへ移行する
    - 移行主体の方針
      - 自分たちで移行できる部門は、自ら計画を立て移行
      - 自分たちでは移行できない部門は、CCoEや AWS が連携・協力
    - CCoEの具体的な対応
      - クラウド勉強会の開催
      - お困りごとヒアリングシートの展開
      - AWS オフィスアワーの活用
        
        AWSが対応。RI/SPsを含むコスト最適化の相談やDB移行についての相談が多い傾向
      - 個別相談会の開催
      - クラウド構築支援チームのサポート
        
        要件ヒアリング、 AWS 移行後のコスト見積、 AWS 環境構築を実施
        
        Terraformを使ったコード化で構築を効率化
  - CCoEが提供する AWS 環境は、利用者は安心・安全にシステムを運用できる
    - 従来のオンプレ仮想化基盤では、セキュリティ対応は利用者に任せることが多く、統一的な対策が困難だった
    - セキュリティガードレール適用により、安心して運用
      - セキュリティ関連ガイドを利用者向けに展開
      - Critical、Highのセキュリティアラートは即時利用者へメール通知して是正を促す
      - 週次、月次レポートを利用者向けに通知して是正を促す
  - MAP2.0クレジットによる AWS 移行時のコスト削減を実現
    - AWS Migration Acceleration Program 2.0（MAP2.0）を締結
      - 約32%のコスト削減
  - 組織アカウントのコスト最適化状況を一元管理
    - Organizationsにて、Cost Optimization Hubと Compute Optimizerを有効化
    - コスト最適化のポテンシャルの確認、推奨アクションを管理可能
    - 利用者にアカウントの利用状況や最適化ポテンシャルについて説明・推進
移行後の課題
- 組織としてのコスト意識向上
  - コストを意識して運用している利用者は限定的
  - 勉強会の開催やガイドラインの発信を通して、意識向上を図る
  - 部門単位でのコスト利用状況や最適化ポテンシャルを可視化するダッシュボードを整備
- 組織としてのセキュリティ意識向上
  - アラート対応は利用者自身だが、対応できているのは限定的
    - 「セキュリティサービスを利用しているから安心」ではなく、アラートの是正が必要
  - セキュリティリスクを伝えた上で対策の必要性を発信
  - 部門単位で対応状況を可視化するダッシュボードを整備

ディップ株式会社の脱 Exadata で始めるマイグレーションとモダナイゼーション

スピーカー

藤原朋広様
- ディップ株式会社　ソリューション開発本部　プラットフォーム開発統括部　プラットフォーム部　部長

内容

脱Exadataの背景と課題
- 全面的にAWSへの移行を推進、計画
- データセンターにてOracle Exadataが稼働
  - 約40システムからアクセスされる基幹システム
  - 課題を解決するために脱Exadata
- 課題と、移行のメリット
  - 高額なライセンス費用 -> 従量課金モデル
  - ハードウェアの老朽化 -> 柔軟なリソース拡張
  - スケーラビリティの限界 -> マネージドサービス利用
  - 運用負荷の増大 -> 運用負荷の大幅削減
脱Exadata移行
- 移行戦略
  - リプラットフォームを選択
    - 40システムからアクセスされており、複雑さを勘案
- 移行先DB選定
  - 候補
    - RDS for Oralce
    - Aurora PostgreSQL
  - Insight Database TestingによるSQLテスト
    - 本番環境で実行されているSQLを自動収集
    - テスト・評価し、実行可否　実行結果　実行速度を比較
  - App改修コストと移行リスクを重視し、RDS for Oralceを選定
- プロジェクト体制
  - プロジェクト全体で70名
  - AWS Account Teamと早期から支援
    - CSM、データベーススペシャリスト、マイグレーション＆モダナイゼーション等の支援
- 移行方式
  - 要件：システム停止を極力短くする
    - Oracle Data PumpとAWS DMSを採用
- 当日の移行スケジュール
  - 通常運用
    - データ移行
      - Data Pumpによるオブジェクト移行
      - AWS DMSでフルロード
      - 継続的レプリケーション（CDC）
      - 文字コード変換
  - システム切り替え（停止）
    - データ移行
      - 差分の継続的レプリケーション（CDC）
      - 文字コード変換
    - システム移行
      - Appをデプロイ（DB向き先変更）、App動作確認
  - 通常運用
    - データ移行
      - 事後作業
    - システム移行
      - サイト再開後のApp動作確認
      - Appエラーログ確認
- 課題と対応
  - 本番移行時の停止時間の見積、本番データの移行の担保
    - 本番環境を利用して、AWS DMSによるデータ移行検証を実施
    - 多くの課題の対処を確認するため、リハーサルを計４回実施
  - UTF-8変換により日本語文字のバイト数が増加
    - 既存のマルチバイトを含むchar型、及びすべてのvarchar型の桁数を2倍へ増加
  - レコードが多いテーブル（XX億レコード）はAWS DMSで時間がかかる
    - 条件（Where）で絞り、AWS DMSを多重で実行
  - 半角文字化けデータが存在
    - サイト停止中にデータメンテナンスを実施
- Next Step（モダナイゼーション）と狙い
  - RDS for Oracle -> Amazon Aurora
    - 脱Oracleによるライセンスコスト削減
    - マルチAZ、マルチリージョンによる可用性向上
  - EC2 -> ECS,Lambda
    - コンテナ化・オートスケール導入
    - サーバレス化

SaaS 型 CMS プロダクトの進化～.NET アプリケーションの AWS/OSS マイグレーションと AI 実装による変革～

スピーカー

藤本太一様
- 株式会社インフォネット　業開発部／制作開発部／AI推進室, General Manager

内容

CMSサービスをリニューアル
- 経営課題
  - 現行はフルカスタマイズ前提、構築や運用が高コスト
  - 技術スタックが古く、採用や教育に高コスト
  - 販売・構築も自社で行うモデルで、販路拡大がしずらい
  - プロダクトの根本の構造の鮮度低下で、顧客満足度が相対的に低下
- どうやったか
  - サーバレスアーキテクチャの採用
  - マルチテナントSaaS化
  - セキュリティと可用性の向上
  - 技術スタックの刷新
  - UI/UXの改善
LENSAhubのサービス構成概要
- 静的CMS
- 管理サイト側のS3からWebサイトのファイル群を、公開サイトのS3に出力
- 大阪リージョンに定期的にバックアップ。DR環境としても提供
管理階層の分割
- システム管理：サービス作成管理、機能追加の資材反映（インフォネット）
- サービス管理：プラン作成管理、サイト作成管理（インフォネット）
  - 本階層ごと、他社に運用代行が可能
- サイト管理：サイト編集・公開（ユーザー）
- メリット
  - 運用効率化
  - パートナーの参画が可能に（サービス管理の移管）
運用設計（資材反映・新規作成）
- 資材反映～新規作成の運用を、Git パイプライン/管理画面 GUI から実現可能に
ASP.NET から TypeScript、React への移行
- 開発言語の移行の理由
  - 採用の難しさ、技術情報の収集の難しさ　の改善
  - 開発コスト面、新旧並行運用を考え、新規構築の方が効率的
- TypeScript、React を選定した理由
  - 技術の成熟度と豊富なエンジニアによる採用競争力の強化
  - フロント/バックの言語統一による開発リソースの最適化
  - AWS との高い親和性を活かしたクラウドネイティブ開発
AWS を選んだ理由
- 大規模サーバレスサービスの構築実績の多さ
- エンジニアの層の厚さ
- OSSとの親和性

おわりに

他にもいろいろなセッションがありますが、最も興味を引く事例セッションをまとめてみました。
昨今はテーマがAIのものが多いため、移行やモダナイズに絞ったイベントは大変勉強になります。
この記事がどなたかのお役に立てれば幸いです。