PR
4/1朝まで
どなたでも有料記事が読み放題「無料開放デー」開催中!

アセスメントから運用までのタスクを定義し、スケジュールを作成して移行費用を見積もる。技術検証は実アプリで行う、ツールに頼りすぎないなど、プロジェクト運営の注意点を押さえる。当初のアーキテクチャーに固執せず、クラウド化の目的に立ち返った意思決定が重要だ。

 前回までに、アーキテクチャーの側面からみたクラウド移行の進め方や考慮点を紹介した。今回は、クラウドへの移行計画や移行におけるプロジェクト管理の観点から考慮すべき点を取り上げる。クラウド移行を計画する際、通常は図1のアプローチを取る。

図1●クラウド移行計画と検討ポイント
図1●クラウド移行計画と検討ポイント
[画像のクリックで拡大表示]

 最初に現行システムのアセスメントによりシステムの構成を把握。そのうえで移行に際しクラウド側の技術的な検証を行いながらPoC(概念実証)を実施したり標準仕様を作成したりし、技術的に問題がないことを確認してから移行作業を実施する。

 計画段階でアセスメントから運用までのタスクを定義し、スケジュールを作成して移行費用を見積もる。クラウド移行に関して社内で承認を得るには、最大限のコスト効果の捻出、リスクの少ないアプローチ、PoCによる事前検証の定義など取り組むべきタスクを定義する必要がある。ところが、より安く簡単に移行できるとの甘い期待から当初の段階で十分な影響分析を行わず、後々になって問題が発生するケースがある。クラウド移行プロジェクトの流れに沿っていくつかのキーワードから問題点や考慮点をひも解いていく。

現行踏襲という定義の罠

 既存のオンプレミス(自社所有)環境のシステムをクラウドに移行する際、「現行のアプリケーションの仕様を全く変えないままクラウドに移行する」という現行踏襲で移行するアプローチがある。移行方式の一つである「リホスト」の場合、現行システムの仮想サーバーからクラウド上の仮想サーバーに移行するだけで、アプリは何も変えずに動くという想定に基づいている。現行システムをそのまま移すだけのケースでは、クラウド側に移行してリグレッションテストをすれば、動作確認が終わりとなるようにテスト期間を圧縮し、短期間で移行が完了する計画をスケジュール作成時に立てることがある。

[画像のクリックで拡大表示]

 ところが、実際は仮想サーバーをそのまま移行しただけでは動かないケースの方が多い。認証システムの参照や、データベースやインタフェースシステムの接続先の設定変更では、たとえ動いたとしても、クラウド環境ではオンラインやバッチ処理で十分な性能が出ないことがある。本来、このタイミングでアーキテクチャーの見直しを含めて考慮すべきなのだが、「現行踏襲」という言葉にひきずられ、システム構成やアーキテクチャーを全く変えずに、なんとか現行構成のままで動かせるよう対応することがある。

 もう一つ、現行システムのミドルウエアのバージョンが古く、サポートが終わっている場合に「リビルド」するケースがある。この場合、画面のユーザーインタフェースや機能仕様を全く変えない方式をとるケースがある。その際、ソフトウエアのライセンスコスト削減のために商用ソフトウエアからOSS(オープンソースソフトウエア)に変更することが考えられる。この場合も、画面は現行システムと全く同じでよいことから、設計工程を圧縮したり、現行のテストデータやテストシナリオを流用する前提でテストスケジュールを圧縮したりすることがある。

 何もかも現行踏襲で進めるのは無理がある。プロジェクトの初期段階で現行システムやアーキテクチャーのリファクタリングを行って、設計書のリバースエンジニアリングから、現行システムの正しい設計書やクラウド化に適応した標準を定めることが重要である。