我が国においてもこの数年間、DX は大きな経営テーマになっています。いまだに「 DX とは？」という議論もありますが、経産省がこの数年発行している「 DX レポート」によって、あるべき DX の像はだいぶ方向性が見えてきたように感じています。
本日は、当社が旧 Pivotal 時代から開催している SpringOne イベントでの金融企業の DX ジャーニーの事例をご紹介します。この事例は昨年（2021年）に発表されたものですが、DX ジャーニー自体は 2018 年からの約3年に渡るストーリーです。
ボヤ・ファイナンシャル （ Voya Financial ）について
ボヤ・ファイナンシャル （以下、Voya ）は、退職・投資・保険・福利厚生を手がける米金融持株会社です。6,000名の従業員で1,430万人の顧客を担当し、2021年は 42 億ドルの売り上げという大手企業です。退職事業では機関投資家向けリタイアメントプランやリテールウェルスマネジメントを手がけています。投資管理事業では債券やエクイティ、マルチアセット、オルタナティブ商品などを提供。福利厚生事業では中・大規模企業雇用者や専門職協会向けの団体保険商品を提供している企業です。
Voya のデジタル変革ジャーニーとそのの背景
Voya の DX ジャーニーは 2018 年に始まりました。Voya の成長の理由のひとつは、さまざまな企業を買収統合してきたことにあり、結果として冗長かつ時代遅れのシステムが存在していました。2018 年、彼らは「お客様の要求のスピードに応える」必要を認識していましたが、レガシーシステムではこの要求に応えられないと判断し、モダナイゼーションとシンプル化の旅に踏み出すことを決定しました。
Voya の DX ジャーニーはテクノロジー領域にとどまらず全体的なアプローチを採用しました。注力したのは以下の４点です。
1. 開発生産性の向上
DevSecOps パイプラインによるビルドとテストの自動化によって、特に品質チェックにかける時間を削減しました。また、開発者は環境の入手やファイヤウォールの設定を依頼するために数多くのチケットを発行するという無駄な時間を費やしていました。これが開発者の生産性を低下させる要因のひとつでした。これらの設定作業をプラットフォームに行わせることで開発生産性が劇的に高まりました。
2. アジャイル開発プロセスの改善
特にビジネスチームと IT チームのコラボレーション、パートナーシップの改善を心がけました。具体的にはバックログの優先順位付です。これにより、四半期ごとのリリースが月次のリリースに改善しました。
3. モダンなアーキテクチャの採用
クレデンシャル管理を強化することで API 開発の生産性が高まり、アプリケーションがダウンした際もプラットフォームが自動復旧してくれる、スケーラビリティに優れたプラットフォームを導入しました。
4. インフラのシンプル化
セキュリティパッチについてもユーザーの影響を受けることなく行うことができ、ピークの負荷にたいしても自動的にスケールしてくれる、また、チケットを発行しなくても自動的にプロビジョニングをおこなってくれる、シンプルなインフラを採用しました。
ITケイパビリティの進化
2017 年当時はモノリシックなアーキテクチャを運用していました。当時はビジネスのアイデアが本番へデプロイされるまで３ヶ月を要していました。プラットフォームを採用することでこのサイクルは１ヶ月に短縮されています。また、開発者の生産性を向上させるためにサンドボックスを採用しました。DX を推進する上で、すべてのアプリとインフラをプライベートクラウドに集約しました。一貫性のあるプラットフォームによって、開発者にとってすばらしいメリットを享受しています。今後はパブリッククラウドとハイブリッドクラウドへの移行を通じて、ワークロードの適切な配置を行う予定です。
ミッションステートメント：業界をリードするデジタル体験を提供すること
このミッションを実現するために、どこにフォーカスするかを定義しました。その結果は以下の３点です。
1つめ、そして常に最上位に来るのは「カスタマージャーニー」です。お客さまにすぐれたデジタル体験を提供するために、アプリケーションをコンテナで動かし、常にセキュリティを担保し、より早い市場投入スピードを実現する必要がありました。そのために、モダンなアーキテクチャを採用しました。
この基盤を創るジャーニーは、VMware のエキスパートとともに小規模なチームを組成し、オンプレミス上にプラットフォームを構築すること( Platform Dojo )から始めました。一方でエンジニアリングチームは、アプリケーションのトランスフォームに取り組みました。最初のアプリケーションを選び Spring Boot を使って 12 factor apps に沿う形でアプリケーションに完全にリファクタしました。
ビルドとデリバー
PaaS プラットフォームはオンプレミス環境上に構築しました。エンジニアリングチームに PaaS プラットフォームを引き渡す前に、セキュリティチームと協力しファイヤウォールのルールを確立し、CI/CD パイプラインを整備し、新たな開発者体験を提供するカスタムプラグインを追加しました。これによってエンジニアリングチームは新しいアプリケーションを開発する際にビルドとデリバリーに集中できるようになったのです。
VMwareの PaaS プラットフォーム
4つの隔離された基盤
後工程で問題が見つかるということを避けるために、開発ステージごとに異なる基盤が欲しかったのです。そこで、4 つの隔離された基盤を構築しました。最初はパッチ適用による影響を検証するための基盤です。この基盤はリサーチや PoC の環境としても使用しました。この環境を使用して開発チームはクリエイティブなアイデアを実装し検証することが可能になりました。プラットフォームへのパッチ適用サイクルには CI/CD パイプラインを適用し自動化を行いました。コンサンプションレポートを生成することで、プラットフォームの成長するコンサンプションを理解することが可能になりました。
ベネチアへの旅
私たちは20年の間にレガシーシステムに埋め込まれたビジネスルールを紐解き、マイクロサービスの世界へと旅立ちました。これが私たちが真のアジャイルになった瞬間です。私たちはまもなくアムステルダムへ到着するでしょう。
セッションタイトルについて
このセッションのタイトル、不思議に思いませんでしたか？
「ベニスへの旅の予定がアムステルダムへ行ったお話し」
これはメタファーでした。当時24種のデジタルアプリケーションを運用していたそうです。当初はこれらをリプラットフォームし、主要なアプリケーションのひとつをリライトしてマクロサービスに分解、データもマイクロサービスに従い独立した構造をとり、サービス間の連携はAPIで実現するという美しいアーキテクチャを計画しました。
これは、旅行に例えると美しい運河のあるベニスへ行こうという比喩です。
ただし、現実を考えると、20年間動かしてきたレガシーアプリケーションを完璧なアーキテクチャに書き換えるというのはあまりにも複雑すぎるということがわかりました。
そこで、アプリケーションを書き換えるのではなく、アプリケーションを稼働させるプラットフォームを置き換えるという結論に達しました。
つまり、完璧な理想（美しい運河のあるベニスに行く）よりも、ほどほどの理想（ほどほどの運河のあるアムステルダムに行く）へ行くことを決断したというストーリーなのです。
この講演は以下からご覧いただけます。
