このシリーズの記事一覧:
2006年にクラウドサービスが展開されて以来、クラウドサービスの市場は拡大を続けており、日本の金融機関においてもクラウドサービスの活用が拡大している。
一方でクラウドサービスの活用範囲としては電子メールを始めとする一部サービスに限定されており、変化に強く効率的な改修が求められている証券システムにおいてはクラウド化が進んでいるとは言い難い。
本稿ではクラウド化を推進する際に陥りがちな“失敗”と求められる“対応”について弊社事例を踏まえてご紹介したい。
1.証券システムにおけるクラウド活用の実態
2006年にAmazonが法人向けのクラウドサービス「Amazon EC2/S3」を展開して以来、クラウドサービスの市場規模は拡大している。英国の調査会社であるOMDIAによると、2020年時点の世界のパブリッククラウドサービスの市場規模は約40兆円となっており、今後も加速度的に拡大し2030年には約270兆円に達する見込みである。
日本においてもクラウドサービスの利用は各企業において推進されており2020年に1兆円、2021年に1.5兆円と堅調に推移している。但し、クラウドの活用状況に目を向けると電子メールやファイル保管といった一部サービスの利用に限定されており(図表1)、クラウドネイティブ技術(コンテナ化・マイクロサービス化など)の活用や既存システムのPaaSを利用したシステム再構成等、システム再構成/再構築を必要とするクラウドマイグレーションについてはまだまだ様子見である状況が見て取れる(図表2)。
金融システム、とりわけ証券システムにおいては、商品サービスの多様性、短期間で変更される法規制、営業チャネルの多様化、新たな競合の登場等、常に変革が求められ続けており、変化に強く効率的に改修が可能なシステムを構築することは重要な経営課題である。
クラウド環境を活用することで新規サービスの素早い展開や市況に合わせた柔軟な拡張を満たすことが可能となると同時に、EOL/EOSの対応から解放されコスト削減にもつながるといった実用的なメリットも得られるが、思ったよりも証券システムのクラウド化が加速化していないのはなぜなのだろうか。
2.陥りがちな“失敗”
クラウド化の必要性についてCIOを始めとする経営陣が理解し、適用化に向けた評価診断等を行い、トップダウンで推進する企業も増加している。
一方で、実際にクラウド化を推進する際は、課題が発生しクラウド化自体が頓挫するケースや、期待していたほどのメリットが得られないケースも発生している。本章では実例に基づいた陥りがちな“失敗”について述べる(図表3)。
過度なカスタマイズの実施
オンプレミスからクラウドシステムへの移行の際に、自社でスクラッチ開発を行ったシステムから、SaaSサービスへの切り替えが行われることも一般的ではあるが、業務ユーザからの要望で過度なカスタマイズを行ってしまうケースが多い。
そもそも、SaaSサービスではカスタマイズ可能な部分が限定されていることも多く、注意が必要である。また、業務ユーザ要望を満たすためにアドオン的なシステムを開発することもあるが、SaaSサービスでは一定間隔でサービスのアップデートが行われるため、これに合わせて頻繁な改修が求められる可能性がある。
業務特性に応じたカスタマイズは一定程度必要ではあるものの、特にSaaSサービスを利用する場合は、過度なカスタマイズは抑制することが望ましい。また、自社でスクラッチ開発を行った既存のシステムをクラウド化せずに、SaaSサービスを導入することが適切であるかは、慎重な検討が必要である。
現行構成のままクラウド化
自社でスクラッチ開発を行ったシステムをクラウドに移行する際、アプリケーション部分には手を加えず、基盤部分だけをクラウド化し、現行構成のまま移行を行うケースも多い。
このケースの場合、IaaS中心の構成となるため、これまでと同様の保守・運用体制が必要となる可能性が高い。また、クラウド費用に加え、ソフトウェア(Oracleなど)のライセンス等も必要となるため、想定よりもクラウド導入によるコスト削減が見込めない可能性がある。
一部アプリケーションの改修が必要となるため、目先の導入コストは高くなるものの、クラウドのメリットを享受しやすいPaaSサービスを活用したクラウド化を行うことも必要である。
既存システムとの複雑な接続
クラウド化の恩恵を受けやすい顧客や営業員が操作するチャネル系のシステムからクラウド化を行いたいといったケースも多いが、これらは既存システムとのデータ連携を必要とすることが多い。
このケースの場合、既存システムはオンプレミスに構築されていることが多いため、クラウドとオンプレミス間での通信が必要となるが、セキュリティの関係から単純な接続が出来ず、各種調整や複雑な接続に変更する必要が発生し、想定以上の時間を要する可能性がある。
証券システムにおいては特にセキュリティ面での担保が求められるため、プロジェクトを円滑に進めるためにも、予め関係部署との調整やルールについて策定しておくことが肝要である。
サービスレベルの担保
システムを冗長化し障害に備えることはオンプレミスでも、クラウドでも必要ではあるが、クラウド化した部分の管理はクラウドベンダーに移るため、各クラウドサービスで設定されているサービスレベル(SLA)を意識する必要がある。
但し、特にIaaS、PaaSを中心に構築しているケースにおいて、適切な構成が検討出来ておらず、結果として現行よりもSLAがダウンしているケースも散見される。また、クラウドサービスが定義する以上のSLAが求められるシステムの場合、自社で更なる可用性向上策の検討が求められるため、特に高可用性が求められるシステムについてはオンプレミスと比較して本当にメリットがあるか慎重な検討が必要となる。
3.求められる“対応”
前述で実例をもとに陥りがちな対応について記載してきたが、最後にクラウド化を推進するにあたり、弊社で考える各社で求められる対応について論じたい(図表4)。
“推進者”の増加
クラウド化を加速させるためには成功事例を増やし、現場レベルで“推進者”を増やすことが欠かせない。クラウドの利用の検討を一般的とする文化の醸成のためにも必要不可欠な存在である。
“セントラル”なサポート
クラウド化を推進するにあたっては“セントラル”なサポートを行う組織も必要である。前述でも述べたとおり、クラウド導入においては、様々な関係部署と調整を行う必要が多く、部署横断で調整を行う組織の存在は必要不可欠である。また、横断組織により、ナレッジの集約化も効率的に実施することが可能である。
業務部門の“理解”
最後にシステム部門だけでなく業務部門もクラウドのメリットを理解することが重要である。クラウドは多数のメリットをもたらすが、制約事項が発生することも多い。この点を業務部門・システム部門ともに理解することが重要である。
4.おわりに
これまで陥りがちな“失敗”と求められる“対応”について述べてきたが、クラウド化を推進するためには、これら知見があるメンバーと共に適用範囲を見極めたうえで推進していくことが重要である。
弊社としてもクラウド化推進に向けたパートナーとして共に歩めると幸いである。
※FSアーキテクトは、金融業界のトレンド、最新のIT情報、コンサルティングおよび貴重なユーザー事例を紹介するアクセンチュア日本発のビジネス季刊誌です。過去のFSアーキテクトはこちらをご覧ください。