アプリ移行

アプリ移行の概要

コンピュータの世界では、ソフトをあるコンピュータから別のコンピュータへ移す手順です。また、既存のウェブページ群をクラウド上の新しいホスティング環境へ移す場合にも使われる用語です。

この手順では、いくつかの困難に直面する可能性があります。多くの既存アプリは特定のOSやクラウドサービス向けに作られているため、新しい方法へ切り替えるのはより複雑です。移行を始める前に、考慮すべき点を十分に盛り込む必要があります。

費用、安全性、法規制など、さまざまな要因を検討することが求められます。また、各アプリ固有の要件や依存関係も、クラウドでの移行プロジェクトの成功に大きく影響します。信頼できるホスティングプロバイダーの選定は欠かせませんが、唯一の要因ではありません。なお、プログラムをクラウドへ移す方法には、仮想やハイブリッドといったさまざまな選択肢があり、以下で一般的な方法を紹介します。

‍

アプリ移行戦略

同一環境内でも、いくつかのサービスが様々な方法でクラウドへ移行できます。

• Rehost - ラフト＆シフトによる移行

この手法は、アプリを改変せずにあるサーバから別のサーバへ移すという考えに基づいています。問題のアプリを新しい環境で再展開します。たとえば、仮想マシンをパブリッククラウドへ移す、または安全なデータセンター間で移すといった現実的な選択肢があります。

最もスムーズな方法で、他の運用に与える影響も最小限です。ただし、アプリを単に移すだけではメリットを十分に享受できず、最適なコスト効果も期待できません。

これらの手法は、時間とともに効率性や経済性を追求するために、調整が求められる場合があります。

• Refactor - 再設計による移行

この方法は、クラウドで利用できるようにアプリを改変する手法です。コードを書き換え、より効率的な環境に合わせることで、移行を円滑に進めます。

単一のアプリを変更する際は、他の機能に影響が出ないように十分に確認する必要があります。クラウド移行には、追加のストレージや使いやすさ、柔軟性を考慮した大幅な再設計が求められる場合があります。

• Repurchase - ドロップ＆ショップによる移行

既存アプリを再設計して移行の準備を進める際、期待通りの成果が得られないリスクも伴います。不要なシステムを廃止し、サブスクリプションまたは買い切りに切り替えることで、費用を削減する方法も検討されます。

サードパーティの方法は、内製と比較して効果的で低コスト、かつ管理が容易な場合が多いです。中小企業にとって、一からオーダーメイドのソフトを作るよりも実現しやすい選択肢となります。

• Retain - 維持＆再検討による移行

特定のアプリを廃止せず、内製または別のホスティング環境で今後も稼働させる方法もあります。プロジェクト完遂が難しい、全体移行が困難、あるいは現段階でのダウンタイムが許容できない場合、現状維持を選ぶことが検討されます。

‍

アプリ移行のプロセス

一般的な移行プロセスには、以下のステップが含まれます。

• 計画

成功する移行戦略は、対象アプリ、ビジネス目標、関係チームを十分に検討することから始まります。既存のリソースの強化を考慮し、サードパーティ製の移行ツールやサービスを活用することで、データ管理やプラットフォーム移行、詳細な解析・監視が容易になります。

• テストの実施

実際の移行に入る前に、シミュレーション移行を行ってプロセスを最適化することが推奨されます。各移行後は、新しいホスティング環境で転送データを検証し、結果を記録してください。定期的なテストやサンドボックスでのチェックが、問題発生前の早期発見に役立ちます。

• 移行ウェーブ

アプリをグループ化し、段階的に移行する方法が望ましいです。戦略的な計画ツールを用いて各ステップを記録し、関係者と情報を共有することが重要です。

• その後の対応

クラウドへの移行が完了した後、計画通りに進んだかを確認するためのフォローアップテストが必要です。アプリの動作状況、停止の有無、データベースの安全性を確認することが、このプロセスに含まれます。

アプリ移行の影響

クラウドへのアプリ移行は、運用効率の向上、展開期間の短縮、コスト削減など多くのメリットがありますが、企業は以下のような問題にも対処する必要があります。

• 明確な計画がない場合、クラウドへの移行およびその後の展開で長期的な成功を収めることが難しくなります。データセンターやアプリごとに移行の難易度が異なるため、一律の戦略では対応できません。
• プライバシーや法令遵守 — 移行時には転送データの機密性を確保し、適用される法令や基準を守る必要があります。
• 費用見積もりの誤差 — 移行と運用に必要な費用を正確に予測し、初期費用、運用費用、そして移行自体の費用を十分に検討する必要があります。
• スキルギャップ — クラウド移行では、円滑な実施を担う人材の確保が難しい場合があります。移行専門家の採用が困難な場合は、社内教育を行うか、適切なスタッフを持つベンダーの活用が求められます。これにより、クラウド関連のスキルも向上します。

‍

アプリ移行の段階

AM計画により移行プロセスが容易になります。企業アプリの移行前には、しっかりとした計画が必要です。移行プロジェクトでは、以下の4点に注目してください。各ステップを見ていきます。

1. アプリの分析と特定

まず、既存の企業システムを十分に評価し、重要性やクラウド移行で得られる価値、複雑さの観点から順位付けを行います。また、各アプリを「重要でないもの」と「業務上重要なもの」に分類してください。

各アプリを移行する前に、大幅な変更やコードの書き直しが必要かどうかを検討することで、移行すべきプログラムや、廃止または交換すべきものが明確になります。

2. 総所有コストの算定

移行プロセスでは、予算超過が現実の問題となり得ます。クラウドへのアプリ移行は高額となる場合があるため、総所有コスト（TCO）の算出が重要です。

類似ケースを参考にし、移行に伴う初期費用や不便さに対して長期的なメリットが得られるか、また不要なアプリの置き換え費用、さらに人材教育や新環境の維持費用も含め、全体の費用を検討する必要があります。

3. プロジェクト期間とリスクの評価

予期せぬ障害や問題が発生する可能性は常にあります。しかし、移行プロジェクトに必要な期間と伴うリスクをできる限り見積もることが求められます。

完全に正確な予測は難しいですが、潜在的なリスクを事前に把握し、その影響を評価することで、問題発生時の対応が容易になります。

また、全員が適切な移行ツールを利用できる体制を整えることで、潜在的なリスクを軽減でき、主要な作業の自動化にもつながります。

レガシーアプリの移行

古い技術は意外にも広く使われています。世界有数の大企業の中には、一部が未だに「レガシーシステム」すなわち最新技術に取って代わられたシステムに依存している場合もあります。

高コストや移行時の中断といった理由から、古いアプリを使い続ける判断には合理的な根拠があります。『壊れていなければ直す必要はない』という考え方を採用する企業も多く、必ずしも最新の選択肢が直ちに求められるわけではありません。

レガシーソフトの場合も同様です。古く互換性の低いアプリのクラウド移行は、手間がかかるだけでなく、保守コストが高くなる傾向があります。

古いアプリの移行については、十分な評価が必要です。場合によっては、現状のまま、もしくはわずかな変更で移行できることもあれば、代替が必要になることもあります。

アプリ移行チェックリスト

各アプリの可能性を評価し、移行可能なものを優先順位付けする必要があります。以下の3つのCを念頭においてください。

1. ‍複雑度

• 自社で作成されたアプリですか？開発者は現在も同じ組織に在籍していますか？
• アプリのドキュメントは容易に入手できますか？
• ソフトはいつ頃開発され、どの程度の期間稼働しましたか？

2. ‍重要性

• どれだけ多くのワークフローや他のアプリが依存していますか？
• 定常的な利用者はどの程度いますか？
• 停止しても業務に与える影響は、どれだけ長く許容されますか？
• 本番、開発、テスト（ペネトレーションテスト）として利用されていますか？
• 他のアプリと連動して稼働する必要がありますか？

3. ‍遵守

• 該当する規制要件は何か確認してください。

‍

AMのベストプラクティス

以下は、アプリ移行を計画・実行する上で推奨される手法です。

• ビジネス目標と最終的な目標を関係者全員に明確に伝える。移行の目的、方法、内容を整理することで、全員が意欲的に取り組めます。
• 慎重かつ段階的に構築する。まずは1つのアプリから始めることで、チームが自信をつけ、問題点を把握しながら成果を実感できます。また、安全な環境でテスト移行を行うのも有効です。
• 内製のスキルに加え、外部の支援やツールを活用する。アプリ移行は複雑なプロセスであり、ミスやデータ損失が大きなコストにつながる恐れがあります。万全の体制を整えるために、必要なリソースへの投資が重要です。