メインコンテンツへスキップ

何をお探しですか?

私たちのサービスを探索し、目標達成をどのようにお手伝いできるかをご覧ください

Client Workspace

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

レガシーシステム評価では、費用をかける前に10の領域を確認します:ビジネス価値、ユーザーとプロセス、コードとアーキテクチャ、プラットフォームサポート、セキュリティ、データ、インテグレーション、運用、人材と知識、そしてコスト。各領域で意見ではなく根拠を収集し、ビジネス価値と技術的健全性をスコアリングしたうえで、現状維持・リプラットフォーム・リファクタリング・再構築・廃止の候補を絞り込みます。

ソリューションレビューを予約する 関連サービスを見る

著者: Netbase Consulting and Transformation Desk · 監修: David (CEO) · 更新日 · 1 分で読める

star

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

このガイドの内容

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

以下のトリガーが発生したときに構造化評価を実施してください。定期的なスケジュールではなく、状況に応じて判断します。

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

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

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

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

領域 確認すべき内容 収集すべき根拠
ビジネス価値 どの収益・サービス・コストがシステムに依存しているか、1日停止した場合に何が影響を受けるか 業務プロセスの特定、影響を受けるユーザー、ビジネスオーナーと合意したダウンタイムの影響
ユーザーとプロセス 誰が、何のために使用しているか、どこでシステムを回避しているか プロセスマップ、システム周辺のスプレッドシートと手作業ステップの一覧
コードとアーキテクチャ アーキテクチャの種類、結合度、テストカバレッジ、カスタムコードの規模、既知のホットスポット アーキテクチャ図、リポジトリアクセス、テストレポート、カスタムモジュールの一覧
プラットフォームとサポート 言語、フレームワーク、データベース、OSのバージョンとサポート終了日 ベンダーの公表するサポート終了日を含むバージョン一覧
セキュリティ 既知の脆弱性、認証、アクセス制御、暗号化、ログ スキャン結果、アクセスリスト、過去の監査またはペネトレーションテストのオープン指摘事項
データ データモデル、品質、ボリューム、所有権と保持ルール スキーマ、レコード件数、データ品質サンプル、各データ種別のオーナー
インテグレーション データを送受信するすべてのシステムとその方法 プロトコル、方向、頻度、エラー処理を含むインターフェース一覧
運用 稼働率、インシデント、バックアップ、復旧目標、および復旧テストの実施状況 インシデント履歴、バックアップスケジュール、RPO・RTO、最後の復旧テスト
人材と知識 誰がシステムを変更できるか、何が文書化されているか 担当メンテナーの特定、ドキュメント、誰かの頭の中にしかないルール
コスト ライセンス、ホスティング、サポート契約、および維持に費やすスタッフの工数 内部工数とワークアラウンドを含む12カ月分のコスト

2つの領域には特に注意が必要です。プラットフォームサポートについては、CISAとFBIがサポート終了ソフトウェアの使用を製品セキュリティの特に危険な慣行の1つとして挙げています。サポートされていない製品はセキュリティ修正の提供が停止されるためです。セキュリティについては、OWASP Application Security Verification Standard(ASVS)のような公開標準を使用することで、独自の要件を考案することなく、テスト対象の要件リストをすぐに入手できます。

評価の実施方法

1つのシステムに絞った評価は、短期間で完結する作業です。以下の固定された手順で進めてください。

  1. オーナーを明確にする。

    システムの価値を把握できるビジネスオーナーと、コード、サーバー、クラウドアカウント、ベンダー契約のすべてにアクセスできる技術オーナーを指定します。

  2. インタビュー前にデータを収集する。

    バージョン、依存関係、アクセスリスト、コスト、インシデント履歴を先に取得することで、インタビューは事実を生み出すのではなく確認するものになります。

  3. ソフトウェアだけでなくプロセスをマッピングする。

    実際の受注、申請、またはリクエストを端から端まで追い、すべての手作業ステップとスプレッドシートを記録します。

  4. システムを回避しているユーザーにインタビューする。

    ユーザーは、どのレポートが誤っていて、どのフィールドを誰も信頼していないかを知っています。

  5. リスクの高い前提を1つテストする。

    例えば、前夜のバックアップをテスト環境に復元する、またはリポジトリのみからコードをビルドしてデプロイするなどです。

  6. 各領域をスコアリングする。

    以下の価値と健全性のスケールを使用し、すべてのスコアの根拠を1文で記述します。

  7. 候補リストと未解決事項を記述する。

    スコア、残る2〜3の移行方針、および引き続き確認が必要な事項をまとめた簡潔なレポートを作成します。

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

ビジネス価値と技術的健全性を別々に、1(低)から5(高)などのシンプルなスケールでスコアリングします。数値は精度ではなく比較のためのものであり、記述された根拠の方が重要です。

  • 高価値・低健全性。 緊急ケース:ビジネスが脆弱またはサポートされていないシステムに依存しています。まずモダナイズします。
  • 高価値・高健全性。 現状維持し、インテグレーションや自動化などで拡張への投資を続けます。
  • 低価値・低健全性。 廃止候補:その機能を別のシステムに移すか、停止します。
  • 低価値・高健全性。 そのままにしておき、新しい作業を追加することは避けます。

複数のシステムを評価する場合は、1つを選ぶ前にすべてを同じ2つのスケールに配置します。技術が最も古いシステムが最初にモダナイズすべきシステムとは限りません。収益、サービス、またはコストを妨げているシステムが通常は優先されます。デジタルトランスフォーメーションロードマップでは、ビジネス全体にわたって施策をランク付けする方法を解説しています。

調査結果から移行方針の候補リストへ

評価は選択肢を絞り込むものであり、最終的な判断を下すものではありません。AWSプレスクリプティブガイダンスは7つの移行戦略を挙げています:廃止、現状維持、リホスト、リロケート、リパーチェス、リプラットフォーム、リファクタリングです。中堅企業はフルリビルドも検討します。調査結果を使って選択肢を除外してください。

  • プラットフォームサポートがまもなく終了するがビジネスルールが適合している場合は、リプラットフォームをリストに残します。
  • コードに価値があるが変更が遅い場合は、スライス単位のリファクタリングをリストに残します。
  • 設計が目標プロセスを支えられない場合は、リビルドまたはパッケージ製品をリストに残します。
  • システムが適用しているルールを誰も説明できない場合は、リビルドの前にディスカバリーを追加します。

どの方針が残るにせよ、スライス単位で進められるものを優先してください。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のコンサルタントと次のステップを計画する

よくある質問

既存システムのビジネス価値と技術的健全性を構造的にレビューするものです:どのように使われているか、どのように構築・サポートされているか、どの程度安全か、どのようなデータとインテグレーションを保持しているか、そしてコストはいくらかを確認します。移行方針の候補とその根拠をまとめた結論で終わります。

システムの規模、ドキュメントの状況、アクセス権の付与速度によって異なります。先にデータを収集してからインタビューを行うことで期間を短縮できます。アクセス権の欠如が最も一般的な遅延要因です。

ビジネスオーナーと技術オーナーが連携し、結果に利害関係のない人物も参加すべきです。チームがシステムを構築した場合、またはベンダーが保守している場合は、独立したレビュアーが偏りを軽減します。

いいえ。サポートされており、安全で、ロードマップの妨げになっていないシステムは現状維持し、後で改めて検討できます。まず収益、サービス、またはコストを妨げているシステムをモダナイズします。

このチェックリストのスコアリングは移行方針の決定で終わります。方針が承認されたら、モダナイゼーションリスクとビジネス価値の測定によって調査結果を定量化されたリスクスコアに変換し、ビジネス価値を段階的に追跡します。

次のステップ

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

納品計画まで完結するAI活用のDXコンサルティング 納品計画まで完結するAI活用のDXコンサルティング

Netbaseは、スライドデッキではなく納品計画付きの優先度付きロードマップを必要とする中堅企業向けにDXコンサルティングを提供しています。AIが手作業を削減できる箇所を含むすべての変更を価値とリスクで順位付けし、同じチームが構築まで担当します。CEO Huy Nguyen(David)によれば、Netbaseは2012年以来、80か国の500社以上にサービスを提供してきました。

詳しく見る
line
受注とデータを守るAI支援レガシーモダナイゼーション 受注とデータを守るAI支援レガシーモダナイゼーション

Netbase は、コマース・業務チームが Magento 1 ストアなどの老朽化したプラットフォームを、受注・顧客・データを失わずにサポート対象の技術へ移行するためのレガシーアプリケーションモダナイゼーションサービスを提供しています。AIがコード分析とデータマッピングを加速し、すべての移行はリハーサル・段階的カットオーバー・ロールバックを備えた書面・人間承認済みの計画に基づいて実施されます。これは Netztech の Magento 2 への移行で実証済みです。

詳しく見る
line
マルチベンダーマーケットプレイス開発:ベンダー・カタログ・支払い・AIサーチを一基盤に統合 マルチベンダーマーケットプレイス開発:ベンダー・カタログ・支払い・AIサーチを一基盤に統合

マルチベンダーマーケットプレイスとは、多数の独立した販売者が一つのストアフロントで商品を出品・販売し、売上を受け取るコマースプラットフォームです。Netbaseのマーケットプレイスソリューションは、ベンダーオンボーディング・共有カタログ・分割決済・支払いをカバーし、検索・出品情報の補完・不正検知にAIを活用します。あるEUファッションテックマーケットプレイスでは、GMVが47%成長し、ベンダーオンボーディング時間が60%短縮されました。

詳しく見る
line

Netbaseにリモートで依頼する

Netbaseのすべての案件はリモートで納品されるため、どの国・業界のクライアントとも協業できます。これまで80か国のクライアントと実績があります。契約・請求書はNetbase JSCが発行し、支払いはNetbase JSCの銀行口座への振込またはPayPal Businessで行います。CEO・Huy Nguyen(David)にWhatsAppまたはメールでご連絡ください。

Netbaseに問い合わせる

プロジェクトを相談する

Netbase JSCは、デジタルプロダクトおよびAI活用ビジネスシステムの設計・構築・モダナイゼーション・運用を支援します。
プロジェクトのお問い合わせ

project@netbasejsc.com

WhatsApp

+84 937 869 689

オフィス所在地

91 Nguyen Chi Thanh, Dong Da, Hanoi, Vietnam

ご連絡ください

構築・モダナイゼーション・運用したい内容をお聞かせください。

構築・モダナイゼーション・運用したい内容をお聞かせください。

Netbaseに問い合わせる