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

範囲、戦略、タイムライン

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

移行ジャーニーのステージを設定するには、移行プログラムの開始時からこれらの要素を調整して理解する必要があります。これらの要素のいずれかを変更すると、他の要素に影響します。再調整は、変更がどの程度基本的または賢明であるかにかかわらず、すべての変更を考慮する必要があります。

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

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

大規模な移行には不明なものがあるため、スコープは変更されます。これらの未知は、関連性をほとんどまたはまったく理解せずに環境のアーキオロジーの一部となったシステム、または計画の遅延や移行を引き起こす本番環境のインシデントの形式である可能性があります。重要なのは、プログラムを前進させるための柔軟な対応と緊急時対応計画を整えることです。

戦略 – 移行する理由

次の AWS 1 つ以上の理由により、 への移行を計画している場合があります。

理由が何であれ、これらの理由などはすべて、ビジネス組織や IT 組織の頭の中にあります。ドライバーとは何かを理解し、伝達し、優先順位を付けることが重要です。ドライバーを追加するたびに、すでに大規模な移行に時間、コスト、範囲、リスクが加わる可能性があります。戦略がタイムラインとスコープに与える影響を完全に認識することが重要です。

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

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

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

これを実現するには、プロジェクトの早い段階で適切な期待を設定します。キーメッセージは「最初に移行してからモダナイズする」である必要があります。このアプローチにより、組織は技術的負債を減らし、最終的に大規模に運用できるだけでなく、 が提供 AWS クラウド できるスケーラビリティと俊敏性を使用することで、さまざまなモダナイゼーションアプローチの道を開くことができます。長期検討は、インフラストラクチャチームがインフラストラクチャのデプロイと管理を合理化するのに役立ちます。その結果、ビジネスはより高速な機能リリースサイクルを実現できます。

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

ビジネスケースによっては、割り当てられた時間内に達成できる以上の作業を行っていないことを確認する必要があります。移行のドライバーが固定の完了日に基づいている場合は、そのタイムライン要件を満たす戦略を選択する必要があります。ほとんどの大規模な移行はこれらの時間ベースの制約に基づいているため、移行戦略は、拡張やオーバーランの余地をほとんど持たずに、定義された固定されたタイムラインと成果を持っている必要があります。

これらの時間的制約のあるタイプの移行では、「最初に移行してからモダナイズ」アプローチをお勧めします。これにより、期待値を設定し、チームが個々のプロジェクト計画と予算が移行目標全体と一致していることを確認することができます。プロジェクトでできるだけ早く意見の不一致を見つけ、迅速に失敗し、ステアリング委員会レベルで意見の不一致に対処し、適切な利害関係者を関与させて調整を整えることが重要です。

逆に、移行の主な目的がアプリケーションのモダナイゼーションのメリットを得ることである場合は、プログラムの早い段階でこれを呼び出す必要があります。多くのプログラムは、固定された期限に基づいて初期目標から始まり、未解決の問題や問題を解決したいステークホルダーの要件を計画していません。場合によっては、これらの問題はソースシステムに何年も存在していますが、現在は移行の人為的なブロック要因となっています。

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