クラウドシフトに向けたSoE領域のシステム構築
連携基盤を用いてレガシーシステムを含むSoR領域の整理を行った後には、クラウドへの最適化（シフト）に向けたSoE領域のシステム構築を進めていきます。ここでのポイントは、“移行を前提に考えない”ことです。レガシーシステムには整理した業務処理やデータが残っているため、移行を前提に、ガートナーが提唱するモダナイゼーションの移行フレームワークなどの活用を検討する人もいるかもしれませんが、それはおすすめしません。
SoE領域の構築においては、クラウドをベースに新規で構築する必要があります。レガシーシステムはDXを前提として作られていないため、そのまま移行してもDXを推進するシステムにはならないからです。
システム移行をしないと、整理したSoE領域と既存のレガシーシステムで機能やデータが重複するため不安になるかもしれませんが、これまで説明してきた手順に沿って、業務のカプセル化を行って統合連携基盤上にレガシーシステムをつなげられていれば、レガシーシステム上で不要になった機能の利用を停止するだけで良いのです。レガシーシステム上にあるデータも連携基盤を通じて同期するため問題ありません。SoR領域をクラウドへ移行する時に、きれいに整理したうえでモダナイゼーションしていけば良いだけです。
SoEはDXによる変化を最も受ける領域のため、構築時には以下のような環境やニーズ・テクノロジーの変化に柔軟に対応できることが重要です。
- 環境の変化：ユーザーが利用する端末（デバイス）や場所の変化に対応
- ニーズの変化：顧客ニーズの変化に対応（簡単なシステムはユーザー自身でも開発）
- テクノロジーの変化：トレンドの変化に対応
これらを実現するためには、SaaSを中心とした基盤構成にした上で拡張が必要な場合はaPaaSやhpaPaaSで実装する方式が適しています。特にITの領域はトレンドの移り変わりが早いため、新しいテクノロジーに素早く対応できるSaaSを中心とした構成は業務のデジタル活用に役立ちます。
ライセンスコストの観点で考えると、Amazon Web Services（AWS）などIaaSのほうがコストが抑えられるため、そちらを選びがちです。しかし、IaaSは開発する機能自体が多く、開発や保守の工数がかかることで全体的にランニングコストが高くなる傾向にあります。また、新機能への対応にも開発が必要となるためリリースのタイミングも遅くなりがちです。特に昨今は、ユーザー側が新しい機能をすぐに使いたいという要望が強いため、クラウドへの最適化（シフト）という観点からも新機能の実装が早いSaaSを中心とした構成が適しているといえます。
今回は顧客接点基盤の構築方法まで解説を行いました。次回はレガシーシステム移行について解説していきます。
