レガシーシステムアセスメントとは、現行システムを「刷新するかどうか」「どこから刷新するか」を事実にもとづいて判断するために、ソースコード・データ・バッチ・外部連携・業務ロジック・非機能要件・運用体制の7領域を調査し、リスクと優先順位を文書化する工程です。 期間は規模により4〜12週間、成果物はアセスメント報告書と移行ロードマップになります。
レガシーシステムアセスメントを省いたモダナイゼーションが失敗するのは、移行作業そのものが難しいからではありません。現行システムを誰も正確に説明できないまま、見積もりと計画が先行してしまうからです。
アセスメントが必要とされる背景は、技術の未成熟ではありません。移行の技術は、この20年で十分に成熟しました。COBOLからJavaへの変換も、オンプレミスからクラウドへの移設も、方法論は確立しています。それでも刷新プロジェクトが止まったり、予算が倍に膨らんだりするのは、「何を移すのか」が最後まで確定しないからです。
この記事では、アセスメントで具体的に何を見るのか、どう進めるのか、結果をどう意思決定に変えるのか、報告書には何が書かれているべきか、そして費用・期間・委託先の選び方までを、実務の順番どおりに整理します。
📌 この記事でわかること
- アセスメントで評価する7領域と、領域ごとのチェック項目・現場でよくある発見・成果物
- 4ステップの進め方、体制と分担、各段階でつまずきやすい点
- 評価結果を「維持・強化・刷新・廃棄」の判断に落とす採点方法
- 設計書が残っていないシステムを調べるリバースエンジニアリングの進め方
- アセスメント報告書の標準目次（10章）と、各章に何を書かせるべきか
- 社内稟議・合意形成を通すための資料の作り方
- 費用・期間の目安と、ベンダーに必ず聞くべき5つの質問
レガシーシステムアセスメントとは？「現行システム調査」との違い
言葉の整理から始めます。実務では「現行システム調査」「IT資産の棚卸し」などと混在して使われますが、指している範囲が少しずつ違います。この違いを曖昧にしたまま発注すると、期待していた成果物が得られない事態になりかねません。
レガシーシステムアセスメントが答えを出すべき3つの問い
アセスメントは、次の3つの問いに数字と根拠つきで答えるための工程です。
問い1：このシステムは、いま本当に危険な状態か
「古い」こと自体は、危険の理由になりません。稼働20年でも、ドキュメントが整備され、対応できる技術者がいて、EOLまで5年あるなら、急ぐ必要はありません。逆に稼働8年でも、仕様を説明できる人が1人しかいなければ、その人が退職した瞬間に手がつけられなくなります。危険度は年数ではなく、技術的負債の量・EOLまでの残り期間・属人化の度合いという3つの変数で測ります。
問い2：刷新するとしたら、どこから手をつけるべきか
基幹システムを丸ごと作り直す提案は、多くの場合、金額の大きさがネックになって止まります。アセスメントの役割は、システムを意味のある単位に分解し、どの単位から着手すれば費用対効果が最も高いかを示すことです。全体像を描いたうえで、最初の一歩を小さくする。これができて初めて、計画が動き出します。
問い3：その判断を、経営に説明できる材料がそろっているか
情報システム部門（情シス）が「危ない」と感じていても、それだけでは予算は下りません。保守費が何年でいくらになるのか、障害が起きたら業務がいくら止まるのか、対応できる技術者があと何人いるのか。現場の肌感覚を、経営が扱える単位、つまり金額と期限に翻訳するのが、アセスメントの最後の仕事です。
逆に言えば、この3つに答えられない調査は、どれだけ工数をかけてもアセスメントとは呼べません。「調べました」で終わり、意思決定がまったく進まない報告書は珍しくありません。
現行システム調査・IT資産の棚卸しとの関係
3つの言葉の関係は、次のように整理すると混乱しません。
| 用語 | 主な範囲 | 主な目的 | 典型的な成果物 |
|---|---|---|---|
| IT資産の棚卸し | システム一覧・台帳の整備 | 何があるかを把握する | システム台帳、契約・保守一覧 |
| 現行システム調査 | 個別システムの機能・構成の把握 | どう動いているかを把握する | 構成図、機能一覧、インターフェース（IF）一覧 |
| レガシーシステムアセスメント | 上記＋リスク評価・優先順位づけ・移行方針 | どう判断するかを決める | 評価レポート、移行ロードマップ |
つまりアセスメントは、調査の上に「評価」と「判断材料」を載せたものです。棚卸しと調査は、その前提となる材料にすぎません。
この関係を理解しておくと、見積もりの読み方も変わります。「現行システム調査」の見積もりには、評価と優先順位づけが含まれていないことが多いからです。安く見えた提案が、実は判断材料まで届かない範囲だった、というのはよくある行き違いです。
なお、すでに精度の高い台帳や構成図がある企業ほど、アセスメントは短期間で終わります。準備状況によって期間が2倍近く変わるのは、この部分が理由です。台帳が整備済みなら調査工程を短縮し、評価と方針立案に時間を使えます。
アセスメントを独立した工程として切り出すべき理由
ここが、多くの解説記事が触れていない実務上の分岐点です。アセスメントは、刷新プロジェクトの一部ではなく、その前に置く独立した工程として発注したほうが安全です。
理由は3つあります。
理由1：予算規模が桁違いに小さく、承認を得やすい
刷新本体が数千万円から億単位になるのに対し、アセスメントはその数％から十数％の規模に収まります。判断材料を得るための支出は、実行そのものへの投資よりはるかに承認を得やすいものです。「まず現状を把握させてください」という稟議は、「基幹システムを作り直させてください」という稟議より、はるかに通りやすくなります。
理由2：「やらない」という結論も選べる
刷新プロジェクトの内側に組み込むと、「刷新する前提」で調査が進みます。調査担当者も、中止という結論を出しにくい立場になります。結果として、本来は延命で十分だったシステムまで刷新対象に含まれ、投資対効果が下がります。独立させることで初めて、「やらない」が選択肢として残ります。
理由3：実装ベンダーとの情報格差が埋まる
自社が現行システムを説明できる状態でRFP（提案依頼書）を出すすのと、ベンダーの調査結果をそのまま信じるのとでは、その後の見積もり精度も交渉力もまったく変わります。前者なら複数社を同じ前提で比較できますが、後者では比較そのものが成立しません。アセスメント報告書は、RFPの別紙として使える資産でもあります。
自己診断：レガシーシステムアセスメントが必要かどうかの10問
次の設問に「はい」がいくつ当てはまるかを数えてみてください。いずれも、当社が現場のヒアリングで実際に判断材料として使っている項目です。
| # | 設問 | この設問が示すリスク |
|---|---|---|
| 1 | 設計書が5年以上更新されていない | 仕様の復元コストが発生する |
| 2 | システム全体の処理を最後まで説明できる人が2名以下 | 属人化・退職リスク |
| 3 | 夜間・月次・年次バッチの一覧が整備されていない | 移行時の処理漏れ |
| 4 | 外部システムとの連携先を一覧で即答できない | 影響範囲が見積もれない |
| 5 | 使われていない画面・機能があると分かっているが、特定できていない | 不要な移行コスト |
| 6 | OS・ミドルウェア・言語のいずれかがEOLを迎えている、または3年以内に迎える | 動かせない期限が迫っている |
| 7 | 保守費がIT予算の半分以上を占めている | 変革予算が確保できない |
| 8 | 小さな改修でも見積もりが「調査から」になり、金額が読めない | 変更容易性の喪失 |
| 9 | 対応できる技術者の採用・育成に不安がある | 維持できる年数の限界 |
| 10 | 刷新の話は出るが、規模も費用も分からず稟議に出せていない | 意思決定の停滞 |
「はい」が3つ以下なら、台帳整備と部分的な調査で十分な可能性があります。まずドキュメントの更新から着手してください。
4〜6つなら本格的なアセスメントの検討時期です。特に6番（EOL）に該当する場合は、期限から逆算したスケジュールが必要になるため、早めの着手をおすすめします。
7つ以上なら、刷新の是非を議論する前に現状把握が必要な状態です。この段階で移行ベンダーに相談しても、「まず調査から」という回答になり、結局アセスメントから始めることになります。
🟡 まずは現状の危険度を把握するところから
HBLABでは、本格的なアセスメントの前段として無償のAI診断をご用意しています。現行システムの概要をご入力いただくだけで、リスクの高い領域と優先度の初期仮説をご提示します。
なぜ今アセスメントが必要か — 「2025年の崖」以降の現在地
必要性の背景を、感覚ではなく公的な数字で押さえておきます。
経済産業省が示したリスクの大きさ
経済産業省のDXレポート（ITシステム「2025年の崖」の克服とDXの本格的な展開）は、既存システムの老朽化・複雑化・ブラックボックス化を放置した場合、2025年以降に年間最大12兆円規模の経済損失が生じうると警告しました。
このレポートの重要性は、金額の大きさよりも、原因を特定した点にあります。指摘されたのは技術の古さそのものではなく、「複雑化・ブラックボックス化により、経営者が全体像を把握できず、意思決定できない状態」でした。つまり問題の本質は、最初から「分からないこと」にあると名指しされていたわけです。
2026年現在、この期限はすでに過ぎています。問題は「崖が来るかどうか」ではなく、自社がその崖のどこに立っているかを説明できるかに移りました。
国としても議論は次の段階に進んでおり、経済産業省は2025年5月にレガシーシステムモダン化委員会 総括レポートを公表し、現状把握と段階的な脱却の重要性をあらためて示しています。一斉に作り直すのではなく、評価にもとづいて優先順位をつけ、段階的に進めるという方向性が、政策レベルでも共通認識になっています。
刷新の失敗は「実行」ではなく「理解不足」で起きる
アセスメントを省いた現場で起きている失敗は、移行技術の問題ではありません。代表的な5つのパターンを挙げます。
① 存在を知らなかった処理が動かなくなる
移行後に、誰も把握していなかった夜間バッチが動かず業務が止まる。ジョブ一覧が整備されていないシステムでは、かなりの確率で起こります。
厄介なのは、発覚が遅れることです。日次バッチなら翌朝に気づきますが、月次なら1か月後、年次なら1年後です。プロジェクトが解散し、体制が縮小したあとに問題が出るため、対応コストは移行中の何倍にもなります。
② 使われている例外処理が抜け落ちる
仕様書どおりに作り直したら、実運用でのみ使われていた例外処理が消えていた。設計書が現実に追いついていないケースです。
特定の取引先だけ締め日が違う、特定の商品カテゴリだけ税計算が違う、といった業務上の例外は、設計書に書かれないまま実装されていることが多くあります。しかも、それを知っているのは情シスではなく業務部門の担当者です。技術調査だけでは見つけることができません。
③ 「不要」と判断した機能が、実は必要だった
使っていないと思って削った画面が、年1回の決算業務でだけ必要だった。利用実態を頻度で測っていないと起こりがちです。
「この機能、使っていますか」というアンケートは、この問題を解決しません。使っている人は回答せず、使っていない人が「たぶん要る」と答えるからです。判断は実行ログの頻度データで行うべきです。
④ データ移行の段階で設計工程に差し戻される
データ品質の問題（型の乱れ、コード値の揺れ、和暦と西暦の混在）が移行テストで発覚し、設計工程まで戻る。最も影響の大きい手戻りです。
たとえば「顧客区分」というコード項目に、設計書には4種類しか定義がないのに、実データには12種類の値が入っている。過去の運用で増えた値が、定義に反映されていないのです。こうした乖離は、実データを見ない限り発見できません。
⑤ 範囲が決まらないまま見積もりだけが膨らむ
現状が分からないためベンダーがリスクを上乗せし、金額が現実的でなくなる。結果として稟議が通らず、また1年先送りになります。
ベンダーの立場に立てば当然の行動です。情報がなければ、最悪のケースを前提に見積もるしかありません。情報の不足は、そのまま金額の上乗せとして返ってきます。
これらはすべて、移行技術ではなく現状理解の欠落が原因です。だからこそ、アセスメントは移行計画の前に置く必要があります。
移行を先送りするコストも定量化する
アセスメントでは「刷新した場合」に加えて、何もしなかった場合のコストも同時に見積もります。
| 項目 | 何が起きるか | 定量化の方法 |
|---|---|---|
| 保守費の逓増 | 有識者が減り、同じ作業の単価が上がる | 直近3〜5年の保守費推移から外挿 |
| EOL対応の緊急出費 | 計画外の延長サポート契約、緊急移行 | 延長サポート費用の見積もり取得 |
| 障害時の機会損失 | 復旧に時間がかかり、業務が止まる | 停止時間 × 1時間あたりの損失額 |
| 改修リードタイムの長期化 | 制度改正・商品追加に追随できない | 過去の改修案件の所要期間の推移 |
| 技術者の確保困難 | 採用できず、外部単価が上がる | 採用実績と、必要人数の将来推計 |
重要なのは、**この5項目が「何もしなければ毎年発生し続ける」**という点です。刷新費用は一度きりですが、先送りのコストは累積します。5年分を並べた比較表を作ると、多くのケースで損益分岐点が3〜4年目に現れます。
この比較表がないと、経営は判断できません。先送りのコストについては、レガシーシステム刷新のリスクと判断時期で詳しく整理しています。
レガシーシステムアセスメントの評価7領域【チェックリスト】
ここからが本題です。レガシーシステムアセスメントで実際に何を見るのかを、7つの領域に分けて具体的に示します。ここまで粒度を落とした一覧は一般的な解説記事ではほとんど見かけませんが、発注時の要件定義にはこの水準が必要です。
| # | 評価領域 | 主な調査対象 | 危険シグナルの例 |
|---|---|---|---|
| ① | ソースコード | 行数・言語・循環的複雑度・重複・デッドコード | 1関数1,000行超、コメントが実装と不一致 |
| ② | データベース／データ | テーブル数・実利用状況・型の乱れ・整合性 | 使われていないテーブルが3割以上 |
| ③ | バッチ／ジョブ | ジョブネット・実行順・依存関係・所要時間 | ジョブ定義が手順書のみで管理されている |
| ④ | 外部インターフェース | 連携先一覧・プロトコル・ファイル授受・API | 連携先の一覧が存在しない |
| ⑤ | 業務ロジック | 例外処理・業務ルール・仕様の復元可能性 | 仕様を説明できるのが1〜2名のみ |
| ⑥ | 非機能要件 | 性能・可用性・セキュリティ・EOL | OS/ミドルウェアがサポート切れ |
| ⑦ | 運用体制・コスト | 保守費推移・体制・属人化・人材確保 | 保守費がIT予算の7割超 |
アセスメントの7領域は独立しているように見えますが、実際には相互に影響します。①〜④が「規模」を決め、⑤が「難易度」を決め、⑥が「期限」を決め、⑦が「切迫度」を決めると考えると、見積もりとの関係が理解しやすくなります。
①ソースコード：規模・複雑度・デッドコード
最初に把握すべきは規模と複雑さです。ここが移行工数の見積もり根拠そのものになります。
何を見るか
- 総行数、言語構成、モジュール／プログラム本数
- 循環的複雑度の分布（どこに複雑さが集中しているか）
- 重複コード率、コーディング規約からの逸脱
- デッドコード（到達不能コード）の特定
- 自動生成コードと手書きコードの切り分け
なぜ重要か
総行数は見積もりの基礎ですが、行数だけでは精度の高い見積もりはできません。同じ10万行でも、単純な繰り返しが多いコードと、複雑な分岐が密集したコードでは、移行工数が数倍違います。循環的複雑度の分布を取ることで、「どこに時間がかかるか」が事前に分かります。
自動生成コードの切り分けも重要です。画面定義から生成されたコードは、移行時に再生成すれば済むため、手書きコードとは扱いが変わります。この区別をせずに総行数で見積もると、実態より高い金額になります。
現場でよくある発見
到達不能なコードが2〜3割含まれているシステムは珍しくありません。たとえば、廃止した業務の処理、切り替え時の暫定対応、使われなくなったデバッグ用の分岐などが、削除されないまま残っているためです。これらを事前に除外できるかどうかで、移行の工数見積もりは大きく変わります。
この領域の成果物：コードメトリクス一覧、複雑度ヒートマップ、デッドコード候補リスト。アセスメントの見積もり根拠は、ここから組み立てます。
なお、ソースコードだけを読んでも「なぜそう書かれているか」は分かりません。この点は、⑤の業務ロジックの領域で補います。
②データベースとデータ品質
テーブル定義書があっても、実際にどのテーブルが使われているかは別問題です。定義と実態の差こそが、移行時の最も大きな手戻りの原因になります。
何を見るか
- テーブル／カラム単位の実アクセス状況（CRUD図〔データの作成・参照・更新・削除の対応表〕の再構築）
- 定義と実データの乖離（型、桁、NULL、コード値の揺れ）
- 同一データの重複保持、外部キー制約の実質的な不在
- 文字コード、日付表現、和暦／西暦の混在
- 履歴データの保持期間と、移行対象とするかの線引き
なぜ重要か
履歴データの扱いは移行費用に直結します。過去10年分をすべて移すのか、直近3年分だけを移して残りはアーカイブするのか。この線引きだけで、移行データ量が何分の一にもなることがあります。法定保存期間と業務上の参照頻度の両方から判断する必要があります。
現場でよくある発見
テーブル定義書に載っているテーブルの3割前後が、実際には一度もアクセスされていない、というケースは少なくありません。また、コード値の揺れ（全角と半角、前ゼロの有無、廃止コードの残存）は、ほぼすべてのシステムで見つかります。
データ品質の問題は、移行の終盤ではなく最初に見つけておくべきリスクです。移行テストの段階で発覚すると、設計に戻る手戻りになります。
この領域の成果物：CRUD図、未使用テーブル候補リスト、データ品質課題一覧、データ量とデータ増加率の実績。
③バッチ処理とジョブ依存関係
現場で最も見落とされやすいのがバッチです。オンライン画面は目に見えるので調査されますが、夜間・月次・年次のバッチは担当者の頭の中にしかないことがあります。
何を見るか
- ジョブ一覧と実行契機（時刻起動・イベント起動・手動）
- 前後関係（ジョブネット）と並行実行の制約
- 想定所要時間と実績、処理時間の増加傾向
- 異常時のリカバリ手順と、再実行可否
- 締め処理・決算処理など、頻度の低い重要ジョブ
なぜ重要か
バッチ処理には、時間の制約があります。夜間バッチが朝6時までに終わらなければ、当日の業務が始められません。処理時間が年々伸びているシステムでは、数年後にこの制約を超える計算になります。移行後の性能要件を決めるうえで、実績値の把握は欠かせません。
また、ジョブ間の依存関係は、段階移行が可能かどうかを左右します。ジョブAの出力をジョブBが使い、その結果を別システムが参照している場合、その連鎖をどこで切り分けられるかが、移行単位の設計を左右します。
現場でよくある発見
ジョブネットが運用担当者の手順書にしか存在せず、システムとして管理されていないケース。そして、年1回しか動かないジョブが一覧から漏れているケース。これを防ぐため、最低でも1年分の実行ログを確認します。ここを省くと、移行後の初めての年次処理で止まる恐れがあります。
この領域の成果物：ジョブ一覧表、ジョブネット図、処理時間実績とトレンド、リカバリ手順一覧。
④外部インターフェース／API連携
多くのシステムは、自社システム単体では完結しません。周辺システム、外部サービス、取引先とのファイル授受まで含めて連携点を洗い出します。
何を見るか
- 連携方式（API／ファイル／DB直接参照／画面連携）
- 連携頻度、データ量、タイミング制約
- 相手側の変更可否（自社で変えられない制約の特定）
- 障害時の影響範囲と、リトライ・再送の仕組み
- 連携仕様の管理者（自社側／相手側のどちらが決めているか）
なぜ重要か
ここで「相手側を変えられない」制約が確定すると、採りうる移行方式が絞り込まれます。たとえば取引先とのファイル形式が固定なら、その入出力は現行仕様を維持する前提になります。判断を早める意味でも優先度の高い領域です。
特に注意が必要なのが、DB直接参照による連携です。他システムが自社のテーブルを直接読んでいる場合、テーブル構造を変えた瞬間に、相手側のシステムが停止します。この依存は構成図に現れないことが多く、アセスメントで意識的に探しにいく必要があります。
現場でよくある発見
連携先の一覧そのものが存在しない、というケースが最も多いパターンです。担当者ごとに把握している範囲が違い、合算して初めて全体像が見えます。また、もう使われていない連携が残っていることも多く、これを移行対象から外せば、その分だけコスト削減につながります。
この領域の成果物：外部連携一覧、インターフェース仕様書、制約条件リスト、連携先ごとの調整要否。
⑤業務ロジックと仕様の復元性
技術情報がそろっても、その処理が業務上なぜ必要なのかが分からなければ作り直せません。7領域のなかで最も難易度が高く、同時に最も価値の高い領域です。
何を見るか
- 実装されている業務ルールと計算ロジック
- 例外処理の意図（なぜこの分岐があるのか）
- 承認フローの実態と、システム外で回っている運用
- 現場が仕様外で使っている「裏技」的な操作
- 法令・業界基準に由来する制約
なぜ重要か
業務ロジックは、企業の競争力そのものが埋め込まれている場所です。他社と同じパッケージを使わず、独自システムを維持してきた理由は、多くの場合ここにあります。だからこそ、「よく分からないので標準機能に合わせる」という判断が、業務の後退を招くことがあります。
一方で、すべてを残す必要もありません。過去の事情で作られたルールが、今は不要になっていることもあります。アセスメントでは「なぜそうなっているか」を明らかにし、残すか廃止するかを、業務部門が判断できる状態にします。
現場でよくある発見
「システムに入力する前に、Excelで事前計算している」「特定の条件のときだけ、手作業で値を修正している」といった、システム外で成立している運用が必ず出てきます。これを把握せずに移行すると、新システムで業務が回らなくなります。
この領域は、ツールだけでは解明できません。ソースコードの解析結果を手元に用意したうえで、業務担当者にヒアリングする順番が有効です。白紙の状態でヒアリングしても、「特に問題はないです」という回答しか得られないためです。
この領域の成果物：業務ルール一覧、復元した業務フロー図、確認が必要な論点リスト、システム外運用の一覧。
⑥非機能要件（性能・可用性・セキュリティ・EOL）
機能が同じでも、非機能要件を見落とすと移行後に問題が出ます。
何を見るか
- ピーク時の処理性能と、実測値（推定値ではなく）
- 必要な稼働率、許容できる停止時間
- バックアップとリカバリの実績（手順ではなく、実際に戻せたか）
- 脆弱性対応の状況、アクセス制御と監査ログ
- OS・ミドルウェア・言語ランタイムのサポート期限
なぜ重要か
EOLは交渉できない期限です。ここが最も近い制約であれば、それが刷新スケジュールの起点になります。逆にEOLまで余裕があるなら、着手時期を戦略的に選べます。アセスメントで最初に確認すべき数字は、実はこのEOLの日付かもしれません。
性能要件については、「現行と同等」という指定がしばしば問題になります。現行の実測値を測っておかないと、「同等」が何を指すのか誰にも分からないからです。移行後に「遅くなった」という指摘が出たとき、比較する基準がないと議論が収束しません。
現場でよくある発見
バックアップは毎日取っているが、リストアを実際に試したのは導入時の一度きり、というケース。また、稼働率の目標値は決まっているが、実績を測定していないケース。非機能要件は「決まっているつもり」になりやすい領域です。
この領域の成果物：非機能要件一覧（現行実測値つき）、EOLカレンダー、セキュリティ課題リスト。
⑦運用体制・保守コスト・人材リスク
最後は人材とコストです。技術評価だけでは、経営層は判断できません。
何を見るか
- 直近3〜5年の保守費推移と、その内訳
- 運用体制と要員数、対応可能な技術者の年齢構成
- ベンダー依存度（自社で判断できる範囲はどこまでか）
- 障害・問い合わせの発生件数と対応工数の推移
- ナレッジの所在（ドキュメント／個人／ベンダー）
なぜ重要か
「あと何年、このシステムを維持できる人がいるか」という問いは、技術的な指標よりも経営に伝わります。人材リスクの定量化は、稟議を通すうえで最も有効な材料の一つです。
保守費の内訳も重要です。同じ「保守費」でも、障害対応に使われているのか、制度改正対応に使われているのか、新規要望の実装に使われているのかで意味がまったく違います。障害対応の比率が上がっているなら、システムの劣化が進んでいる兆候です。
現場でよくある発見
保守費の総額は把握していても、内訳を分解していない企業が少なくありません。分解してみると、「変革のための支出」がほぼゼロで、全額が現状維持に消えていることが可視化されます。この一枚のグラフが、経営を動かすことがあります。
この領域の成果物：保守コスト推移表（内訳つき）、体制図、人材リスク評価、ナレッジ所在マップ。
アセスメントの進め方 — 4ステップと各段階の成果物
アセスメントの7領域を「どの順番で、誰が」調べるのかを整理します。ここが曖昧なまま始めると、現場の負担だけが増えて成果が出ません。
STEP 1：範囲の確定（2〜3週間）
最初に決めるのは、対象システムと調査の深さです。すべてを同じ深さで調べる必要はありません。
やること
- 対象システム／サブシステムの確定
- 領域ごとの調査深度（全量調査か、サンプリングか）
- 提供可能な資料とアクセス権限の確認
- ヒアリング対象者と実施時期の調整
深さの決め方
調査深度は、領域ごとに変えるのが基本です。たとえば「移行方式が確定している周辺システム」は概要把握で十分ですが、「業務ロジックが集中している基幹部分」は全量調査が必要です。一律に深く調べると費用が跳ね上がり、一律に浅く調べると判断できないため、ここでのメリハリが費用対効果を決めます。
つまずきやすい点
アクセス権限の手配が遅れて、調査開始が2週間ずれるケースが少なくありません。本番環境のログ取得、ソースコードの受け渡し方法、セキュリティ審査。これらはキックオフ前から並行して進めるべき事項です。
規模が読めない場合は、この段階を2〜3週間のプレアセスメントとして切り出し、本調査の範囲と見積もりを確定させる進め方が有効です。結果的に総コストを抑えられます。
STEP 2：7領域の調査（3〜8週間）
領域ごとに並行して進めます。技術調査とヒアリングを同時並行ではなく、技術調査を先行させるのが要点です。
| 先に進める（技術調査） | 後から重ねる（ヒアリング） |
|---|---|
| ソースコードの静的解析 | 業務担当者への意図確認 |
| DB・ジョブ・連携の機械的な洗い出し | 例外処理の背景確認 |
| 実行ログによる利用実態の把握 | 不要機能の判断 |
事実を提示してから聞くことで、ヒアリングの質が変わります。この段階で中間報告を1回入れておくと、認識のズレを早期に修正できます。
体制と分担の目安
| 役割 | 担当 | 主な責任 |
|---|---|---|
| 技術調査 | ベンダー側エンジニア | 静的解析、ログ分析、一覧作成 |
| 業務理解 | ベンダー側BA（ビジネスアナリスト）/SA（システムアーキテクト） | ヒアリング設計、業務ルールの整理 |
| 情報提供 | 自社 情シス | 資料・環境・ログの提供、社内調整 |
| 業務回答 | 自社 業務部門 | 例外処理・運用実態の説明 |
| 意思決定 | 自社 責任者 | 調査範囲の変更判断、優先順位の合意 |
つまずきやすい点
業務部門のキーパーソンの繁忙期と調査期間が重なり、ヒアリングが後ろ倒しになる。これがスケジュール遅延の最大要因です。繁忙期を避けて計画を立てるか、事前に時間を確保しておくことが必要です。
STEP 3：評価と優先順位づけ（1〜2週間）
調査結果を、判断に使える形に変換します。この工程は短いですが、アセスメントの価値が決まる段階です。
- 領域ごとのリスク評価（影響度 × 発生可能性）
- ビジネス価値 × 技術的健全性のマトリクスへのプロット
- 移行シナリオの立案（2〜3案）と概算比較
- Wave（段階）設計
つまずきやすい点
ビジネス価値の評価を情シス部門だけで行ってしまうこと。利用頻度は情シスが測れますが、業務上の重要度は業務部門にしか判断できません。この工程には必ず業務側を巻き込んでください。
STEP 4：報告書とロードマップ（1〜2週間）
成果物をまとめ、経営層向けと技術者向けの二層に整理します。報告書の詳しい構成は後述します。
この段階で、報告会を2回に分けることをおすすめします。1回目は情シス部門との事実確認、2回目は経営層への説明。事実に誤りがある状態で経営に上げてしまうと、内容ではなく精度の議論になり、話が前に進みません。
自社側で準備しておくと期間が短くなるもの
ベンダー任せにせず、次のものを先に用意しておくと調査期間が目に見えて短縮されます。
| 準備するもの | 効果 |
|---|---|
| ソースコード一式とビルド環境の情報 | 解析着手が1〜2週間早まる |
| 現行の設計書（古くても、あるものすべて） | 仕様復元の工数が減る |
| 直近1年分のジョブ実行ログ、アクセスログ | 利用実態の把握が正確になる |
| 保守費の実績と、障害・問い合わせの記録 | ⑦運用領域の評価が即座に可能 |
| 業務側キーパーソンのアサイン | ⑤業務ロジックの復元精度が大きく変わる |
特に最後の項目が確保できるかどうかで、業務ロジックの復元精度が大きく変わります。「誰に聞けばいいか分からない」状態で始めると、調査の後半で手戻りが発生します。
評価結果をどう判断に変えるか — ビジネス価値×技術的健全性マトリクス
アセスメントは、7領域を調べただけでは完結しません。結果を優先順位に変換する段階が必要です。
4象限（維持・強化・刷新・廃棄）の読み方
各システム／サブシステムを、ビジネス価値（業務上の重要度、競争優位への寄与、利用頻度）と技術的健全性（保守性、EOL、属人化、拡張性）の2軸でプロットします。
| 象限 | 状態 | 打ち手 |
|---|---|---|
| 価値：高 × 健全性：高 | 強化 | 積極的に投資し、機能を拡充 |
| 価値：高 × 健全性：低 | 刷新（最優先） | リビルド／リファクタリングの対象 |
| 価値：低 × 健全性：高 | 維持／統合 | 現状維持・監視。他システムへの吸収も検討 |
| 価値：低 × 健全性：低 | 廃棄 | 停止・縮小。作り直さない |
実務で効果が大きいのは、実は「廃棄」の象限を見つけることです。すべてを作り直す前提で見積もった金額が、使われていない機能を落とすだけで大きく下がることは珍しくありません。
なお、ビジネス価値は情シス部門だけでは決められません。業務部門を交えて評価することが、この工程を形骸化させないための条件です。
2軸をどう採点するか
アセスメントで「価値が高い／低い」を感覚で決めると、後から覆されがちです。実務では、次のような採点表を使って数値化します。
ビジネス価値の採点（各5点・合計25点）
| 評価項目 | 5点 | 1点 |
|---|---|---|
| 業務上の重要度 | 停止すると即座に業務が止まる | 停止しても代替手段がある |
| 利用頻度 | 日次で全社が利用 | 年数回、限定部署のみ |
| 競争優位への寄与 | 他社にない独自の仕組み | 汎用的で代替可能 |
| 売上・コストへの影響 | 直接的に売上を生む | 間接的・限定的 |
| 今後の拡張予定 | 3年以内に大きな機能追加を予定 | 変更予定なし |
技術的健全性の採点（各5点・合計25点）
| 評価項目 | 5点 | 1点 |
|---|---|---|
| EOLまでの残存期間 | 5年以上 | すでに超過 |
| 保守可能な技術者 | 社内外に十分いる | 1〜2名のみ |
| ドキュメント整備度 | 最新に保たれている | ほぼ存在しない |
| 変更容易性 | 小改修が数日で完了 | 調査から始まり数か月 |
| 障害発生の頻度 | ほぼなし | 月次で発生 |
両軸とも13点以上を「高」、12点以下を「低」として4象限に振り分けると、議論が「感覚の言い合い」から「点数の根拠の確認」に変わります。どの項目で点が低いのかが見えるため、改善の打ち手も具体化します。
モダナイゼーションの優先順位とWave設計
4象限が決まったら、刷新対象をWave（段階）に分けます。判断軸は次の4つです。
- リスクの大きさ — EOLが近い、障害頻度が高い領域を優先
- 他システムへの依存度 — 依存が少なく、切り出しやすい領域から
- 業務停止の許容度 — 止められる時期がある業務を先に
- 人材の確保状況 — 対応できる要員がいる領域から
一度にすべてを移行する「ビッグバン移行」は、レガシーシステムの場合ほぼ推奨されません。先に切り出せる領域から着手し、成功体験を作ってから本丸に進む設計のほうが、社内の合意も取りやすくなります。
Wave設計の実務的な目安は、1つのWaveを6〜12か月に収めることです。これより長いと、体制の維持が難しくなり、途中で要員が入れ替わります。これより短いと、準備と検証のオーバーヘッドが相対的に大きくなります。
手法選定はアセスメントの後に決まる
リホスト、リライト、リファクタリング、リビルド、リプレース、リドキュメント。モダナイゼーションの手法はよく6分類で語られますが、どれを選ぶかはアセスメントの結果が決めるものであり、先に決めるものではありません。
判断の対応関係を整理すると、次のようになります。
| アセスメントで分かったこと | 選ばれやすい手法 | 理由 |
|---|---|---|
| 業務ロジックは有効だが、基盤のEOLが迫っている | リホスト／リプラットフォーム | 期限が近く、仕様変更のリスクを避けたい |
| コードの資産価値はあるが、言語・技術の維持が困難 | リライト | ロジックを保ちつつ、保守可能な技術に移す |
| 構造が複雑で、機能追加が困難になっている | リファクタリング | 外部仕様を変えず、内部構造だけを整理 |
| 業務要件そのものが現状と合っていない | リビルド／リプレース | 作り直す前提で要件から見直す |
| 仕様が不明で、まず可視化が必要 | リドキュメント（先行） | 判断の前提となる情報が足りない |
実際のプロジェクトでは、サブシステムごとに異なる手法を組み合わせるのが一般的です。全体を一つの手法で統一する必要はありません。
手法そのものの違いは「System Modernizationの全体ロードマップ」で、言葉の使い分けは「モダナイゼーションとマイグレーションの違い」で解説しています。
ドキュメントが無いシステムをどう調べるか — リバースエンジニアリングの実務
「設計書が残っていない」「更新が10年前で止まっている」。アセスメントの現場では、これが例外ではなく標準的な出発点です。ドキュメントの不在は、着手できない理由にはなりません。
静的解析で分かること・分からないこと
静的解析ツールで機械的に取得できるのは、構造の情報です。
- 分かること：呼び出し関係、データフロー、複雑度、デッドコード、テーブル参照関係
- 分からないこと：業務上の意図、その分岐が存在する理由、実際に使われている頻度
つまり、静的解析で地図は作れますが、なぜその道が作られたのかまでは分かりません。ここを理解せずにツール導入だけを進めると、大量のレポートが出たまま活用されない状態になります。
ツール選定でよくある失敗は、出力の量を価値と混同することです。1万ページのレポートは、誰も読みません。重要なのは、判断に必要な情報だけを抽出して構造化できるかです。
業務ロジックを可視化する3ステップ
実務では、次の順番が最も手戻りが少なくなります。
ステップ1：静的解析で構造を出す
処理の骨格と依存関係を機械的に抽出します。この段階の目的は、全体像の地図を作ることであり、細部の理解ではありません。
ステップ2：実行ログで実態を重ねる
どの経路が実際に使われているかを、頻度データで裏づけます。地図に「交通量」を重ねるイメージです。ここで、構造上は存在するが誰も通らない経路が浮かび上がります。
ステップ3：業務担当者にヒアリングして意図を埋める
解析結果を見せながら「この分岐は何のためか」を確認します。事実が手元にあるため、質問が具体的になり、回答も具体的になります。
3番目を1番目に持ってくると、ヒアリングが抽象論になり成果が出ません。事実を提示してから聞くのが要点です。
ヒアリングでは、「この処理は必要ですか」ではなく「この処理は昨年◯回動いています。どの業務ですか」と聞く。これだけで回答の精度がまったく変わります。前者は記憶を頼りにした推測を引き出しますが、後者は具体的な業務の説明を引き出します。
AIはアセスメントのどこを速くするか、そして何を人が決めるか
生成AIの活用は、コード変換の文脈で語られがちですが、効果が最も大きいのは実はアセスメントの工程です。理由は単純で、アセスメントは「大量の情報を読んで要約し、構造化する」作業の集合だからです。
| 工程 | AIの貢献 | 人の役割 |
|---|---|---|
| コード読解 | 大量コードの要約、処理概要の生成 | 業務的な妥当性の確認 |
| 仕様復元 | 設計書ドラフトの自動生成 | 誤りの訂正、抜けの補完 |
| 依存関係の把握 | 呼び出し・参照関係の抽出 | 重要度の判断 |
| 異常検知 | 命名規則の逸脱、類似処理の検出 | 対処方針の決定 |
| 方針決定 | 選択肢の列挙 | アーキテクチャと移行方針の決定 |
| 品質保証 | — | 出力が正しいかの検証責任 |
AIの出力には誤りが混入します。アセスメントの成果物は後工程の見積もりと設計の前提になるため、AIが生成したものを人がレビューして確定させる二層構造が必須です。
ここを省く提案をするベンダーには、検証プロセスを明確に確認してください。「AIで自動生成します」とだけ説明され、誰が・どの基準で・どの範囲を検証するのかが答えられない場合、成果物の品質は保証されません。
🟡 AIで解析し、BA/SAが検証する
HBLABは、AIによるコード解析・仕様復元と、日本語で業務を理解するBA/SAによるレビューを組み合わせた体制でアセスメントを提供しています。
👉 Modernization Solution（Migurei AI Inside）の詳細を見る
アセスメント報告書には何が書かれているべきか【目次サンプル】
アセスメントを発注する側として最も確認しておくべきなのは、最終的に何が手元に残るかです。ここが曖昧なまま契約すると、「分厚いが使えない資料」を受け取ることになります。
報告書の標準目次（10章）と、各章に書かれるべきこと
最低限、次の10章はそろっているべきです。章ごとに、何が書かれていれば合格かを示します。
| 章 | タイトル | 書かれているべき内容 |
|---|---|---|
| 1 | エグゼクティブサマリ | 結論、推奨シナリオ、概算費用、判断に必要な期限。2〜3ページで完結すること |
| 2 | 調査の範囲と前提 | 何を見て、何を見ていないか。未調査領域のリスクも明記 |
| 3 | 現行システム構成 | 全体構成図、サブシステム一覧、外部連携を含む全体像 |
| 4 | 7領域の評価結果 | 領域別のスコアと、その根拠になった実測データ |
| 5 | リスク一覧 | 影響度×発生可能性でランクづけ。放置した場合の帰結まで記述 |
| 6 | ポートフォリオ評価 | 維持・強化・刷新・廃棄の分類と、採点の内訳 |
| 7 | 移行シナリオ比較 | 2〜3案を、費用・期間・リスク・業務影響の4軸で比較 |
| 8 | 推奨ロードマップ | Wave設計、マイルストーン、各Waveの前提条件 |
| 9 | 概算費用と前提条件 | 見積もりの根拠、金額が変動する条件の明示 |
| 10 | 付録 | CRUD図、ジョブ一覧、連携一覧、復元した仕様書 |
4章・5章・7章がない報告書は、判断に使えません。 根拠・リスク・選択肢という、意思決定に必要な3要素がそろわないためです。ここは発注前に成果物として明記させてください。
特に**2章の「何を見ていないか」**は見落とされがちですが、極めて重要です。調査範囲外の領域に残っているリスクを明示しない報告書は、あとで「聞いていない」という事態を招きます。
経営層向けサマリと技術者向け詳細を分ける
アセスメントの報告書は、読み手が違えば必要な粒度も違います。1〜2章は経営層・承認者向け（結論と金額とリスクのみ）、3〜10章は技術者・実務者向けという二層構成にすると、そのまま社内展開できます。
経営層向けの部分で避けるべきなのは、技術用語です。「循環的複雑度が高い」ではなく「小さな改修にも数か月かかる状態」と書く。「属人化している」ではなく「この2名が退職すると改修できなくなる」と書く。翻訳の質が、そのまま承認の通りやすさに直結します。
実務では、報告書とは別に10〜15枚の説明用スライドをセットで受け取れるかどうかも確認しておくと安心です。役員会や部門説明で、報告書本体をそのまま投影することはまずありません。
報告書を受け取ったあとに自社でやること
アセスメントの報告書は、受け取って終わりではありません。次の3つは、自社側で必ず実施してください。
- 事実誤認のチェック — 構成図や一覧に誤りがないか、現場の目で確認する
- 前提条件の確認 — 見積もりがどんな条件で成り立っているかを理解する
- 社内展開用の再構成 — 自社の意思決定プロセスに合わせて資料を組み替える
3番目については、次のセクションで詳しく扱います。
アセスメント結果を社内で通す — 稟議と合意形成の実務
アセスメントの結果が出ても、日本企業の意思決定は担当者が納得しただけでは進みません。稟議と根回しを通すための材料が必要です。ここが弱いと、良いアセスメントをしても投資判断に届きません。
稟議資料の3点セット
稟議資料として効くのは、次の3点です。
① 何もしない場合のコスト vs 刷新した場合のコスト（5年間）
刷新の費用だけを示すと「高い」で終わります。放置した場合の5年累計と並べて初めて、投資判断の材料になります。 保守費の逓増、EOL対応の緊急費用、障害時の損失を積み上げると、多くのケースで3〜4年目に損益分岐点が現れます。
② リスクを金額に換算した表
「属人化しています」だけでは、経営層は動きません。「この2名が退職した場合、外部からの調達に月額◯円、立ち上げに◯か月」と書くと、経営はリスクとして扱えます。障害停止時の機会損失、EOL超過時の緊急対応費用も同様です。
③ 段階的に着手できる最小単位の提示
全額承認を求めないことが重要です。「まず第1Waveの◯◯だけ」という形にできれば、金額のハードルが下がり、意思決定が前に進みます。そして最初のWaveが成功すれば、次の承認は格段に取りやすくなります。
部門ごとに響く論点は違う
同じアセスメントの結果でも、説明する相手によって強調すべき点が変わります。
| 相手 | 最も効く論点 |
|---|---|
| 経営層・CIO | 事業継続リスク、競合との差、投資回収の見通し |
| 財務・経理 | 5年間のコスト推移、支出の平準化、会計処理 |
| 業務部門 | 現在の不便が解消されるか、移行時の業務負荷 |
| 情報システム部門 | 運用負荷の軽減、技術的な実現性、体制 |
| 監査・リスク管理 | セキュリティ、内部統制、法令対応 |
特に業務部門は、「移行時に自分たちの負担が増える」という懸念を持ちます。テスト協力やマスタ整備にどれだけの工数が必要かを、早い段階で具体的に示すことが、協力を得るうえで効果的です。
合意形成でつまずきやすい点
最も多いのは、「現状で困っていない」という反応です。システムが動いている以上、日々の業務は回っています。だからこそ、リスクが顕在化する時期を具体的な日付で示すことが必要になります。EOLの日付、有識者の定年、契約更新のタイミング。期限があるものから議論を始めると、話が進みやすくなります。
アセスメントの費用と期間の目安、そして委託先の選び方
最後に、レガシーシステムアセスメントの発注実務です。ここも一般的な記事では「ベンダーによる」で終わりがちな部分なので、判断の軸を示します。
期間と費用を左右する4つの変数
見積もりが大きく動く要因は、ほぼ次の4つに集約されます。
| 変数 | 影響の出方 |
|---|---|
| ソースコードの規模 | 行数と言語数に比例。複数言語混在は割増 |
| バッチ／ジョブの本数と複雑さ | 依存関係の解析は本数の二乗に近い負荷 |
| 外部連携の数 | 連携先ごとに個別調査と調整が発生 |
| ドキュメントの残存度 | 少ないほどリバースエンジニアリングの比重が上がる |
逆に言えば、この4点を事前に概算で伝えられれば、ベンダーからの見積もり精度は上がります。「分かりません」と伝えるほど、リスク分が上乗せされます。概算でよいので数字を出すことが、結果的にコストを下げます。
規模別の期間目安
| 規模の目安 | 標準的な期間 | 主な進め方 |
|---|---|---|
| 小規模（単一システム、連携少） | 4〜6週間 | 静的解析中心＋ヒアリング数回 |
| 中規模（複数サブシステム） | 6〜10週間 | 領域別に並行調査、中間報告あり |
| 大規模（基幹系、連携多数） | 10〜16週間 | 先行して範囲を絞る予備調査を推奨 |
期間が読めない場合は、2〜3週間の予備調査（プレアセスメント）で範囲を確定してから本調査に入る進め方が、結果的に総コストを抑えます。予備調査の費用は発生しますが、本調査の見積もり精度が上がるため、トータルでは安くなるケースが多くあります。
見積もりに含まれるもの・含まれないもの
金額を比較する際は、範囲がそろっているかを必ず確認してください。ベンダーによって前提が違うため、単純な金額比較は意味を持ちません。
| 通常は含まれる | 別途になりやすい |
|---|---|
| 静的解析とレポート作成 | 解析ツールのライセンス費用 |
| 業務ヒアリング（回数の上限あり） | 上限を超えるヒアリング・現地作業 |
| 報告書と説明会1回 | 役員会向け資料の別途作成 |
| 移行シナリオ2〜3案の比較 | 詳細見積もり、要件定義への展開 |
| 主要な付録（CRUD図・ジョブ一覧） | 全画面・全帳票の仕様書復元 |
「全画面・全帳票の仕様書復元」は、特に金額差が出やすい項目です。アセスメントの段階で全量の仕様書が必要かどうかは、その後の移行方式によって変わります。リホストなら不要ですが、リビルドなら必須です。方式が決まる前に全量復元を発注すると、無駄になる恐れがあります。
アセスメントと実装を同じベンダーに任せてよいか
正直に言えば、利益相反の懸念はあります。実装を受注したいベンダーは、「作り直すべき」という結論に傾きやすくなります。
一方で、現行システムを深く理解したチームがそのまま実装に入るメリットも大きく、引き継ぎのロスがありません。アセスメントで得た暗黙知には、ドキュメントに書ききれない部分が必ず残ります。別ベンダーに引き継ぐと、その部分がゼロから再構築になります。
実務的な落としどころは次のとおりです。
- アセスメント契約と実装契約を分ける（同じベンダーでも、契約は別）
- 報告書に「刷新しない」シナリオを必ず含めさせる
- 移行シナリオを必ず2案以上比較させる
- 成果物を、他社でも読める形式で納品させる
この4つを条件にすれば、同一ベンダーでも客観性はかなり担保できます。逆に、これらを渋るベンダーは、囲い込みを意図している恐れがあります。
ベンダーに必ず聞くべき5つの質問
アセスメントの提案を受ける際、次の5問への答えで、ベンダーの実力をある程度見極められます。
1. 成果物の目次を事前に見せてもらえますか
即答できないベンダーは、標準的な進め方を持っていない可能性があります。過去案件の目次（機密部分を伏せたもの）を出せるかどうかが、実績の裏づけになります。
2. 調査に使うツールと、ツールで分からない部分の埋め方は何ですか
ツール名だけを答えるベンダーは要注意です。ツールの限界を認識しているかが、成果物の実用性を左右します。
3. AIを使う場合、出力を誰がどう検証しますか
検証の担当者、基準、範囲。この3点が具体的に答えられるかを確認してください。
4. 業務ヒアリングは誰が、日本語で実施しますか
業務ロジックの復元精度は、ヒアリングの質で決まります。技術者だけで実施する体制では、業務側の言葉を拾いきれません。
5. 「刷新しない」という結論もあり得ますか
「あり得ます」と即答できるベンダーは、判断の客観性を保つ姿勢があります。ここで言葉を濁す相手は、結論が先にあると考えたほうが安全です。
特に3番目と4番目は、成果物の精度に直結します。AI活用をうたいながら検証体制を説明できないベンダーは避けたほうが安全です。
レガシーシステムアセスメントでよくある5つの誤解
最後に、発注前に解いておきたい誤解を整理します。
誤解1：ドキュメントがないと調査できない
逆です。ドキュメントがないからこそ調査が必要です。静的解析・ログ分析・ヒアリングの3点セットで、実装されている内容は復元できます。むしろ古い設計書だけを信じて進めるほうが危険です。
誤解2：アセスメントをすると刷新することになる
独立した工程として発注すれば、「当面は維持」という結論も十分にあり得ます。判断材料を得ることと、実行を約束することは別です。
誤解3：現場の業務が長期間止まる
調査の大半はソースコードとログの分析であり、業務停止は不要です。業務部門の負担は、ヒアリング数時間から十数時間程度に収まるのが一般的です。
誤解4：全部調べないと意味がない
領域ごとに深さを変えるのが実務です。判断に必要な精度と、調査コストのバランスで決めます。「全量調査でなければ無意味」というベンダーの説明は、必ずしも妥当とは限りません。
誤解5：AIがあれば人は要らない
AIは読解と生成を速くしますが、業務の妥当性を判断し、責任を持つのは人です。この二層構造がない提案は、成果物の品質が保証されません。
HBLABのレガシーシステムアセスメント
HBLABは、AIによる解析と日本語で業務を理解する人の検証を組み合わせた体制で、モダナイゼーションの前段となるアセスメントを提供しています。
AI × BA/SA の二層体制
- AIレイヤー：大量のソースコード解析、仕様書ドラフトの生成、依存関係とデッドコードの抽出を高速に実施
- 人のレイヤー：BA/SAが業務観点で妥当性を検証し、アーキテクチャと移行方針を決定。品質の責任は人が持ちます
この二層構造により、調査のスピードと、判断に使える精度の両立を図っています。AIを移行全体のどこで活かすかについては、「マイグレーションのAI活用」もあわせてご覧ください。
日本語で業務を聞ける体制
業務ロジックの復元は、日本語での対話なしには成立しません。HBLABでは、日本語で業務を理解するBA/SAがヒアリングを担当し、オフショア側のエンジニアと技術情報を共有する体制を取っています。
無償AI診断から始める
いきなり本格的なアセスメントを発注する必要はありません。まずは現状の危険度と優先領域の初期仮説を確認するところから始められます。
🟡 レガシーシステムの現状を、まず可視化しませんか
現行システムの概要をご入力いただくだけで、リスクの高い領域と着手すべき優先順位の初期仮説をご提示します。費用はかかりません。
👉 無償AI診断を申し込む 👉 資料でじっくり検討したい方は Migration Assessment Serviceの解説資料 もご利用ください。
よくあるご質問
Q. アセスメントだけを依頼できますか。
A. 可能です。むしろアセスメントは実装契約と分けて発注することを推奨しています。判断の客観性が保たれ、経営の承認も得やすくなります。
Q. 設計書がまったく残っていませんが、調査できますか。
A. できます。静的解析で構造を抽出し、実行ログで利用実態を重ね、業務担当者へのヒアリングで意図を補完する3ステップで仕様を復元します。ドキュメント不在は例外ではなく標準的な前提です。
Q. COBOLやVB6など古い言語でも対応できますか。
A. 対応しています。言語よりも、バッチ構成・外部連携・業務ロジックの複雑さのほうが工数に影響します。
Q. アセスメントの結果、「刷新しない」という結論もありますか。
A. あります。保守コストとリスクが許容範囲であれば、当面は維持し監視する判断が合理的なケースもあります。その結論も含めて報告します。
Q. 現場の業務を止めずに進められますか。
A. 調査の大半はソースコードとログの分析であり、業務停止は不要です。ヒアリングは合計で数時間から十数時間程度が目安です。
Q. ソースコードを社外に出せない場合はどうなりますか。
A. 解析環境をお客様側に構築する、または作業場所を限定するなどの対応が可能です。契約前にセキュリティ要件をご相談ください。
Q. 自社の情シスだけで実施できませんか。
A. 台帳整備や利用実態の把握までは自社で可能です。ただし、アセスメントの核心は評価にあります。評価の妥当性と移行方式の判断には、複数システムの移行経験にもとづく比較の視点が必要になります。自社で進める場合も、評価部分だけ第三者に見てもらう形が現実的です。
Q. 報告書の内容は、他のベンダーへのRFPに使えますか。
A. 使えます。むしろそれがアセスメントを独立させる大きな目的の一つです。納品時に、他社でも読める形式での提供を条件にしておいてください。
まとめ
現行システムを正確に説明できないまま立てた移行計画は、どこかで破綻しがちです。レガシーシステムアセスメントは、ソースコード・データ・バッチ・外部連携・業務ロジック・非機能要件・運用体制の7領域を調べ、ビジネス価値と技術的健全性の2軸で優先順位を決め、判断に使える報告書に落とし込む工程です。
調査結果は、刷新の是非に加えて、どこから着手するか・いくらかかるか・何もしなければどうなるかという、経営が必要とする答えになります。そして報告書は、そのまま稟議資料とRFPの土台になります。
費用も期間も刷新本体に比べれば小さく、「やらない」という結論も選べます。だからこそ、最初の一歩として最も合理的です。まずは無償AI診断で、自社のレガシーシステムアセスメントに必要な範囲を確認するところから始めてください。
