レガシーシステム評価チェックリスト：モダナイゼーション前に確認すべき事項

このチェックリストは、老朽化したストア、スプレッドシートで維持されているERP、誰も手を加えたがない社内ツールなど、特定のシステムがビジネスの足を引っ張っていると感じているオーナー、COO、CTO、ITマネージャーを対象としています。何を点検すべきか、そしてそのシステムが本当に対処を必要とするかどうかを判断する方法を解説します。移行先の選択は次のステップであり、デジタルトランスフォーメーションとレガシーモダナイゼーションガイドでご確認いただけます。

目次

• 評価を実施すべきタイミング
• チェックリスト：評価すべき10の領域
• 評価の実施方法
• スコアリング：ビジネス価値と技術的健全性
• 調査結果から選択肢の候補リストへ
• 評価におけるAIの活用
• 代替案と選定基準
• Netbase JSCの評価プロセス
• 存在するデリバリー実績と存在しないもの
• このチェックリストの限界
• よくある質問
• 次のステップ

評価を実施すべきタイミング

カレンダーではなく、以下のトリガーが現れたときに構造的な評価を実施してください：

• プラットフォーム、フレームワーク、またはデータベースがベンダーサポートの終了に近づいている。
• 小さな変更に数週間かかり、アップグレードのたびに何かが壊れる。
• スタッフが注文、在庫、または顧客データをシステム間で手作業で再入力している。
• 新しいプロセス、チャネル、またはAIユースケースが、システムが提供できないデータを必要としている。
• システムを理解している担当者が離脱しつつある、または既に離脱した。

評価は逆の誤りからも保護します：サポートされており、安全で、何も妨げていないシステムを置き換えてしまうことです。適切な評価は「現状維持し、来年また見直す」という結論で終わることもあります。

チェックリスト：評価すべき10の領域

答えが明らかに思える場合でも、すべての領域を検討してください。AWSの詳細アプリケーション評価に関するガイダンスは、チームがアプリケーションを完全に理解していると思い込みがちであり、記憶ではなくツールのデータで知識を検証することを推奨しています。

2つの領域には特別な注意が必要です。プラットフォームサポートについては、CISAとFBIがサポート終了ソフトウェアの使用を製品セキュリティの特に危険な慣行の一つとして挙げています。これはサポートが切れた製品がセキュリティ修正を受け取らなくなるためです。セキュリティについては、OWASP Application Security Verification Standard（ASVS）などの公開標準を使えば、独自にリストを作成する代わりに、テスト対象の要件リストをそのまま活用できます。

スコアリング：ビジネス価値と技術的健全性

ビジネス価値と技術的健全性を個別にスコアリングします。1（低）〜5（高）などのシンプルなスケールを使用してください。数値は精度ではなく比較のためのものであり、文書化された根拠の方が重要です。

• 高価値、低健全性。緊急ケース：ビジネスが脆弱またはサポートされていないシステムに依存しています。優先的にモダナイズしてください。
• 高価値、高健全性。現状維持し、インテグレーションや自動化などで拡張に投資してください。
• 低価値、低健全性。廃止候補：その役割を別のシステムに移行するか、停止してください。
• 低価値、高健全性。そのままにし、新しい作業を追加しないようにしてください。

複数のシステムを評価する場合は、1つを選ぶ前にすべてを同じ2軸で評価してください。技術が最も古いシステムが必ずしも最初にモダナイズすべきシステムとは限りません。収益、サービス、またはコストを妨げているシステムが通常は優先されます。デジタルトランスフォーメーションロードマップでは、事業全体でイニシアチブの優先順位を付ける方法を説明しています。

調査結果から選択肢の候補リストへ

評価は選択肢を絞り込むものであり、最終的な決定を下すものではありません。AWSプレスクリプティブガイダンスは7つの移行戦略を挙げています：廃止（retire）、現状維持（retain）、リホスト（rehost）、移転（relocate）、再購入（repurchase）、リプラットフォーム（replatform）、リファクタリング（refactor）です。中堅企業では完全な再構築も検討します。調査結果を使って選択肢を除外してください：

• プラットフォームサポートが近く終了するが業務ルールが適合している場合、リプラットフォームは候補に残ります。
• コードに価値があるが変更が遅い場合、段階的なリファクタリングは候補に残ります。
• 設計が目標とするプロセスを担えない場合、再構築またはパッケージ製品を候補に残します。
• システムが適用しているルールを誰も説明できない場合、再構築の前にディスカバリーを追加してください。

どの選択肢が残っても、段階的に進められるものを優先してください。Martin FowlerのStrangler Figパターンは、旧システムの周囲に新しい部分を構築し、旧システムを停止できるようになるまで徐々に動作を移行する方法を説明しています。ピラーガイドでは再構築、リファクタリング、リプラットフォームの選び方を説明しており、レガシーモダナイゼーションサービスではその移行の計画と準備方法を紹介しています。

評価におけるAIの活用

AIツールは評価の中で最も時間のかかる部分、つまり誰もドキュメント化していないコードとデータの理解を短縮します。モジュールの要約、どの関数がどのテーブルに触れているかのトレース、不足しているドキュメントの下書き、重複または未使用のコードのフラグ付けを人が確認するために行えます。ただし、インタビュー、ビジネスのスコアリング、意思決定の代わりにはなりません。AIによる要約はすべて検証すべきリードとして扱い、承認済みのツール内にコードを保管し、人が確認した調査結果を記録してください。Netbase JSCは主要な商用およびオープンソースのAIツールとモデルを、プロジェクトごとに選定し、人のレビューのもとで活用しています。

代替案と選定基準

4つの基準で選定してください：判断にどれだけの資金とリスクがかかっているか、チームがバイアスなくシステムを評価できるか、システムの知識がどの程度文書化されていないか、そしてプラットフォームの期限がいつ移行を強制するか。

Netbase JSCの評価プロセス

Netbase JSCでは、評価はディスカバリーから戦略的アラインメント、アーキテクチャ計画、アジャイル実行、ロールアウト、継続的サポートまで続く6ステップのデリバリーライフサイクルのディスカバリーステップです。ディスカバリーは書面による推奨ルートとその理由をもって終了し、ほとんどのNetbase JSCプロジェクトはその後ディスカバリー後に合意した請負契約で納品されます。質問が複数のシステムにまたがる場合、デジタルトランスフォーメーションコンサルティングが評価を優先順位付けされた計画に変換します。

セキュリティに関する調査結果は、Netbase JSCが自社のデリバリーに適用しているのと同じ慣行で対処します：セキュアコードレビューとバージョン管理、転送中のTLSと保存時のAES、ロールベースアクセス制御、管理ダッシュボードのMFA、脆弱性スキャンとペネトレーションテスト、ディザスタリカバリーです。Netbase JSCはISO 27001認証とSOC 2 Type II証明を保有していますが、いずれもNetbase JSC自身の業務をカバーするものであり、お客様のシステムをカバーするものではありません。詳細はセキュリティとコンプライアンスをご覧ください。作業開始後の品質ガバナンスについては、アウトソーシングデリバリーのソフトウェア品質ガバナンスをご参照ください。

存在するデリバリー実績と存在しないもの

• 存在するもの。Netbase JSCはNetztech社のMagento 1からMagento 2 Commerceへの移行を35営業日で完了し、11の拡張モジュールの移行を含みました。Netztech移行は、プラットフォームサポートが終了した際に評価が導くリプラットフォームの公開実績です。
• 存在しないもの。その移行の背後にある評価、スコア、期間を説明したNetbase JSCの公開実績はなく、Netbase JSCは標準的な評価価格やタイムラインを公表していません。このページのスコアリングスケールは例示的なものであり、測定された結果を持つNetbase JSCのメソッドではありません。

このチェックリストの限界

• 一度に1つのビジネスシステムをカバーします；数十のアプリケーションのポートフォリオにはポートフォリオツールとプログラム構造が必要です。
• セキュリティ監査やペネトレーションテストの代わりにはなりません；それらが実施されたかどうかと何が発見されたかを記録します。
• ベンダーサポート日程とAWSおよびCISAのガイダンスは変更されます；評価当日に確認してください。
• 多くの新興市場のように、レガシー段階をまるごとスキップしている企業については、新興市場におけるデジタル・AIトランスフォーメーションをご覧ください。

よくある質問

レガシーシステム評価とは何ですか？既存システムのビジネス価値と技術的健全性を構造的にレビューするものです：使用方法、構築とサポートの状況、セキュリティ、保有するデータとインテグレーション、コストを確認します。候補となるルートとその根拠の候補リストをもって終了します。

レガシーシステム評価にはどのくらいの時間がかかりますか？システムの規模、ドキュメントの状態、アクセス権の付与速度によって異なります。先にデータを収集してからインタビューを行うことで短縮できます；アクセス不足が最も一般的な遅延原因です。

評価は誰が行うべきですか？ビジネスオーナーと技術オーナーが協力して、結果に利害関係のない人物と共に行うべきです。チームがシステムを構築した場合やベンダーが保守している場合は、独立したレビュアーがバイアスを軽減します。

すべてのレガシーシステムはモダナイゼーションが必要ですか？いいえ。サポートされており、安全で、ロードマップ上の何も妨げていないシステムは現状維持し、後で再検討することができます。収益、サービス、またはコストを妨げているシステムを優先してモダナイズしてください。

次のステップ

懸念しているシステム、それに依存しているもの、プラットフォームの期限をお知らせください。評価スコープと最初に収集すべき根拠を確認するためのソリューションレビューを予約します。また、Netbase JSCのインサイトもあわせてご覧ください。

関連サービスとソリューション