翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

スコープ、戦略、タイムライン

すべてのプログラムの構成要素と、大規模な移行におけるそれらの関連性を構成する重要な要素は、スコープ、戦略、タイムラインの 3 つです。

移行の準備を整えるには、移行プログラムの開始時からこれらの要素を調整し、理解しておく必要があります。これらの要素のいずれかを変更すると、他の要素にも影響します。変更がどれほど基本的で賢明であるかにかかわらず、すべての変更に再調整を考慮する必要があります。

スコープ — 何を移行していますか?

移行の途中であっても、プログラムの全範囲が未定義になることがよくあります。これは、さまざまな要素が後の段階まで解明されない可能性があるためです。たとえば、移行の途中で、構成管理データベース (CMDB) に記録されていないシャドーITのポケットが見つかるかもしれません。あるいは、アプリケーションの実行に必要なサポートネットワークやセキュリティサービス (AWSパートナーへの VPN 接続、証明書に署名するための VPN 接続など) を考慮せずに、サーバービューに焦点を当てた計画も考えられます。目標とするビジネス成果から逆算して、対象範囲の定義に時間をかけることをお勧めします。最終的には検出ツールを使用して資産を発見することになるかもしれません。ベストプラクティスについては、このガイドの後半で説明します。

大規模な移行には不明な点があるため、範囲は変わります。これらの未知数は、その関連性がほとんどまたはまったく理解されていないまま、環境の考古学の一部となったシステムや、計画に遅れや移行をもたらす生産上のインシデントなどの形である可能性があります。重要なのは、柔軟性を保ち、緊急時対応計画を立ててプログラムを進めることです。

戦略 — なぜ移行したいのですか?

AWSへの移行を計画する理由として次のものが考えられます (複数が組み合わさる場合もあります)。

理由が何であれ、ビジネス組織やIT組織は、これらすべての理由やその他の理由を思い浮かべるでしょう。ドライバーとは何かを理解し、伝え、優先順位を付けることが重要です。要因が増えるたびに、すでに大規模な移行に時間、コスト、範囲、リスクが追加される可能性があります。戦略がタイムラインと範囲に与える影響を十分に認識することが重要です。

移行戦略を定義したら、成功への主な鍵の1つは、さまざまな利害関係者やチーム間で要件を調整することです。移行を実行するには、インフラストラクチャ、セキュリティ、アプリケーション、運用など、組織全体でさまざまなチームが必要です。これらのチームには、個別の優先事項や、すでに開始されている可能性のある他のプロジェクトがあります。これらのチームがそれぞれ異なるスケジュールや優先事項に取り組んでいる場合、移行計画の合意と実施はより困難になります。移行チームと主要な利害関係者は、関係するすべてのチームが単一の目標に向かって取り組み、優先順位を移行の単一のタイムラインに合わせる必要があります。

望ましいビジネス成果をさまざまなチーム間でどのように調整できるかを検討することをお勧めします。たとえば、保存中のストレージに移行してAWSAWS Key Management Service (AWS KMS) を使用してストレージを暗号化すると、移行とセキュリティの両方の目標が達成される可能性があります。

多くの場合、企業はアプリケーションをモダナイズしてインフラストラクチャのアップグレードにつながる可能性がありますが、インフラストラクチャチームは質素でインフラストラクチャの変更を最小限に抑えたいと考えています。大規模な移行では、できるだけ基本的な考え方をする必要があります。関係するチームは、すべてを一度に行おうとすることを避けなければなりません。

そのためには、プロジェクトの早い段階で適切な期待値を設定してください。重要なメッセージは、「まず移行してから最新化する」ということです。このアプローチにより、組織は技術的負債を減らし、最終的には大規模に運営できるようになるだけでなく、AWS クラウドが提供できるスケーラビリティと俊敏性を利用することで、さまざまな最新化アプローチへの道が開かれます。長期的に考えることは、インフラストラクチャチームがインフラストラクチャの導入と管理を合理化するのに役立ちます。その結果、ビジネス部門は機能のリリースサイクルを短縮できます。

タイムライン — いつ移行を完了する必要がありますか?

ビジネスケースによっては、割り当てられた時間内に達成できる以上の作業を行わないようにする必要があります。移行の推進要因が決まった完了日を基準としている場合は、そのタイムラインの要件を満たす戦略を選択する必要があります。大規模な移行のほとんどは、こうした時間ベースの制約に基づいているため、移行戦略には、延長やオーバーランの余地がほとんどなく、明確なスケジュールと結果が必要です。

このような時間のかかる移行では、「まず移行してから最新化する」アプローチをお勧めします。これは期待値を設定するのに役立ち、チームが個々のプロジェクト計画と予算を全体的な移行目標と一致させるように促します。プロジェクトのできるだけ早い段階で意見の相違を見つけ出し、迅速に失敗して運営委員会レベルで意見の相違に対処し、適切な利害関係者を巻き込んで連携を図ることが重要です。

逆に、移行の主な目的がアプリケーションの最新化のメリットを享受することである場合は、プログラムの早い段階でそのことを説明する必要があります。多くのプログラムは、期限を定めた初期目標からスタートし、未解決の問題や問題を解決しようとする利害関係者からの要求に応える計画を立てていません。これらの問題がソースシステムに何年も存在していたケースもありますが、今では人為的に移行を妨げる原因となっています。

移行中の最新化アクティビティは、ビジネスアプリケーションの機能に影響を与える可能性があります。オペレーティングシステムのバージョン変更など、小規模なアップグレードと見なされるものでも、プログラムのタイムラインに大きな影響を与える可能性があります。これらは些細なものと見なすべきではありません。