日本は、SaaSの普及が他国に比べて遅れていると10年以上前から言われてきました。『DX白書2023（IPA）』によると、日本でITシステムの開発手法・技術として「SaaSを活用している（全社的に活用している＋事業部で活用しているの合計）」と回答した企業の割合は40.4％で、米国の53.4％を10％以上下回っています。

なぜSaaS移行は進まないのか？ SaaS移行を推進するために企業の担当者は具体的に何をすべきなのか？ 本記事では5つのポイントで解説いたします。

【1】前向きな‟守り”の施策としてSaaS移行に早期に着手する

レガシーシステムのSaaS移行に対して最も足かせとなるのが、"既存システムで業務が回っている”という経営者や現場の考えです。コロナ禍や既存システムの不具合、保守期限など、日本において既存システムのモダナイゼーションは競争力を獲得するといった‟攻め”の戦略としてではなく、必要に駆られて行われることが多く、それが国内と国外の差異を生んでいるとも言われています。

しかし、社内システムの構造や利用状況とクラウドの両方の知見を持ち、リーダーシップを持って移行プロジェクトを進められる人材は非常に希少であり、プロジェクトの遂行には数年がかりの計画と、社内人材とベンダーの密な協力が欠かせません。

すなわち、相応のコストと期間をかけられる早期に着手することがプロジェクト成功の重要なファクターとなるということです。いずれ訪れる必要性に向けて、前向きな‟守り”の施策としてSaaS移行を進めていくマインドセットは施策を進める上での重要な前提となります。

【2】ブラックボックス化したシステムの解析に着手する

SaaS移行が進まない背景に、既存システムとの相性やデータ移行の失敗を原因としたシステム停止やデータ消失などの影響が業務におよぶ懸念があるのは間違いありません。

しかし、そう考える企業の多くでシステム構成のブラックボックス化が生じているのではないでしょうか。長年の蓄積により複雑化したシステムの改修は容易ではなく、仮にインシデントが発生すれば対応に多くの手間やコストがかかることは想像に難くありません。すなわち、既存システムの依存関係や構成を解析することはやはり、前向きな‟守り”の施策として避けては通れないのです。

SaaS移行には、「一度既存システムをそのまま移行（ストレートコンバージョン）し、徐々にシステムを再構築していくリフト＆シフト」や、「データ構成や業務の流れをまるごと見直すリプレース」など複数のアプローチがあり、ブラックボックス化したシステムをそのまま移行（リフト）し、クラウド化と解析を並行して進めるケースもあります。

【3】新たなシステムを構築するイメージを共有する

リフト＆シフトにせよ、完全にリプレースするにせよSaaS移行を推進するにあたって重要なのが新しいシステムを構築するというイメージの共有です。独自開発した既存システムからSaaSへのデータ移行が最初からスムーズにいく場合や、これまでと全く同じ形で業務システムを利用できる場合は多くありません。そこで、データ連携に向けたAPIの開発やSaaSのカスタマイズが求められることになりますが、完璧を求めようとするほど計画は長期化し結局前に進まない可能性は高まります。

そのため、取得できる範囲のデータでSaaS移行を達成し、取得が難しいデータに関しては旧システムで対応する、画面の操作性や機能の変化についてはこれまでの慣れや操作性よりも標準化を優先する意味の周知に努めるなどの対応が必要な場面もあります。その上で、既存システムではなく切り分けた業務ごとの目的に合わせて開発を進める「ルール駆動開発」などの手法を取り入れ、新システムを自社に最適化していきましょう。

【4】SaaS導入後の目的達成を支える体制・環境を構築する

SaaS導入の目的として多く見られるのが運用の手間やコストの削減です。しかし、導入後思ったような効果が得られなかったという企業がオンプレミス回帰に向かう動きもここ数年見られました。

SaaS導入が手段から目的化すれば、当然ながら‟移行しただけで計画がストップする”可能性は高まり、リフト＆シフトの「リフト」から前に進めないという声も少なからず耳にします。また、クラウドを管理し、新規アカウントのオンボーディング・退職時のオフボーディングを行うためIT人材が不足しているのもそのような状況に拍車をかけているようです。

そのような状況を避けるためには、当初からポートフォリオを入れ替えながら自社をSaaS活用企業とする前提で体制を整える必要があります。日米ではそもそもSaaSの導入率以上に一社当たりのSaaSの利用数に大きな差があり、SaaS管理の一元化やオンボーディング・オフボーディングの自動化の必要性に対する意識も異なります。

目的を明確に設定することはもちろん、それを実現するための投資としてSaaS管理ツールや ITSM（ ITサービスマネジメント）ツールの活用が効果的と考えられます。

【5】契約やSLAを通して責任範囲を明確化する

セキュリティ上、自社で情報保護を行いたいという理由から、SaaS導入に進めないと判断される場合は少なくないはずです。実際、SaaSベンダーからのデータ流出が生じる可能性は否定できません。

SaaS、IaaS、PaaSなどクラウドサービスのセキュリティを考える上で重要なキーワードに「責任共有モデル」があり、これはサービスの利用における責任範囲についてベンダーとユーザーで事前に合意を結ぶことを意味します。2021年9月に公表された『クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）』（総務省）ではSaaSにおいては下記の通り、責任分担が行われるのが一般的と記述されています。

クラウドサービス利用者の責任範囲：データ、アプリケーション（限定的）
クラウドサービス事業者の責任範囲：アプリケーション、ミドルウエア、OS、仮想環境、ハードウエア、ネットワーク、施設・電源

上記の通りアプリケーションの責任範囲は重複することが想定されており、実際には交渉を経て契約・SLAで明文化することとなります。ゼロトラスト時代において、責任範囲を明確化しセキュリティ責任を問う体制を整えることはSaaS移行を推進するための基盤となります。

SLAについて詳しくは『SLAとは？ 締結のメリットや見るべきポイント、SLOとの違いを解説』をご一読ください。

SaaS導入を後押しする知見はこの10年で増加している

変化への抵抗感、システムのブラックボックス化、クラウド人材の不足などSaaS移行を推進していくにあたって壁となる要素をピックアップし、それらに対処するためのヒントをご紹介しました。2025年の崖回避に向けたDX推進の流れやコロナ禍などをきっかけとしてSaaS導入は10年前よりも進んでおり、ベストプラクティスは増加しています。前向きな‟守り”の施策としてSaaS移行をぜひご検討ください。