レガシーシステムの問題点|症状別の見分け方と優先順位の決め方
レガシーシステムの問題点を技術・データ・コスト・組織の4分類14項目で整理。症状別の見分け方、セルフチェック、影響度×緊急度による優先順位の決め方を解説。
レガシーシステムの問題点|症状別の見分け方と優先順位の決め方 続きを読む
レガシーシステムの問題点を技術・データ・コスト・組織の4分類14項目で整理。症状別の見分け方、セルフチェック、影響度×緊急度による優先順位の決め方を解説。
レガシーシステムの問題点|症状別の見分け方と優先順位の決め方 続きを読む
テストはすべて「PASS」。それでも、新しいシステムが業務要件に照らして正しいと言い切れるでしょうか。 この問いは、AIがMigration(マイグレーション)プロジェクトに深く関わり、マイグレーションテストの自動化が進むほど重要になります。レガシーコードのリバースエンジニアリング、ドキュメントの再構築、コード変換、テストケースの生成など、これまで多くの時間を要してきた作業は、AIによってより短時間で処理できるようになっています。生成される成果物が増えるほど、品質の焦点は「どれだけ多く生み出せるか」から「生み出したものが本当に正しく、検証できる根拠を備えているか」へと移ります。 レガシーシステムはベースラインだが、正解そのものとは限らない ドキュメントが不足しているMigrationプロジェクトでは、稼働中のシステムが事実上、重要なベースラインになることが少なくありません。現行の振る舞いを記録する特性化テスト(Characterization Test)も、レガシーシステムの現在の振る舞いを記録し、改修や移行の際に想定外の変化を検知するという考え方に基づいています。 しかし、現状を記述することは、その現状が正しいと保証することとは異なります。レガシーシステムはしばしば複雑な集合体であり、保全すべき中核的なルールと同時に、暫定的な回避策(workaround)、技術的負債(technical debt)、そして当初の理由がすでに不明確になったまま何年も残り続けてきた判断が混在しています。 したがって、移行の品質は、まず期待結果(expected result)を正しく定義できるかどうかに大きく左右されます。この作業では、実際の振る舞い、データ構造、いまも価値のある一部のドキュメント、そして現行の業務要件を突き合わせ、明確な受け入れ基準(acceptance criteria)へと変換していきます。過去の挙動は、その判断材料の一つとして扱います。 そのため、現状評価(Assessment)の工程は、コード行数を数えたり技術スタックを列挙したりする段階にとどまりません。プロジェクトチームは、データフロー、バッチ処理、連携ポイント、依存関係(dependency)、そしてシステムの動作を支える業務ロジックを明らかにし、そのうえで、保全すべき資産、変更してよい領域、管理すべきリスク領域を、移行方式を選択する前に見極める必要があります。 一つの誤りが、AIの連鎖全体に伝播するとき Migrationのスピードは、前工程の出力が次工程の入力へと自動的に引き継がれるときに大きく高まります。ドキュメントはコード生成に用いられ、そのコードと関連ドキュメントは、さらにテストケース生成の土台になります。この構造は工程の多くを自動化しますが、同時にエラー伝播(error propagation)が生じる余地も作り出します。出発点にある一つの誤った前提が、後続の工程へと次々にコピーされていくためです。
AIで加速するMigration。テストが「PASS」でも、それだけでは品質を証明できない理由 続きを読む
【無料ウェビナー】MigrationはAIで加速。品質は、どう守る? AIは、レガシーコードの解析や仕様書の再構築、テストケースの生成、テスト自動化に至るまで、マイグレーションプロジェクトの進め方を大きく変えつつあります。 その一方で、AIの活用範囲が広がるほど、より重要になるテーマがあります。 AIが生成した成果物を、どのように検証するのか。 AIの活用によって、開発や移行作業のスピードを大幅に高めることが可能になります。しかし、AIが生成した成果物を十分に検証できなければ、マイグレーション全体の品質を確保することは難しくなります。 特に、要件や業務ロジック、既存のテストケースが不足している、あるいは内容が不明確になっているレガシーシステムでは、検証の重要性はさらに高まります。 そこで生じる問題は、単なる技術的な不具合だけではありません。誤りを早期に発見できなければ、修正コストの増加やプロジェクトの遅延、納品物の品質低下につながり、最終的には顧客からの信頼にも影響を与える可能性があります。 本ウェビナーでは、AI活用の前後で、マイグレーションにおける品質保証の考え方がどのように変化するのかを整理するとともに、AI活用によって新たに生じる課題と、一貫した検証の仕組みをどのように構築するかについて解説します。 さらに、実際のケーススタディとデモを通じて、AIのスピードを活かしながら、品質を客観的に示せる根拠を確保し、生成されたアウトプットを適切に検証・コントロールする方法をご紹介します。 ウェビナーにご登録いただいた方に、「Migration QA自己診断チェックリスト」をご提供いたします。すでにMigrationに取り組まれている方は、現在の品質管理体制を確認するために、これからMigrationを検討される方は、事前に確認しておきたい評価基準を整理するためにご活用いただけます ウェビナーに申し込んで、チェックリストを受け取る こんな方におすすめ マイグレーション/モダナイゼーション案件を推進するための人材や専門知識が不足しており、顧客提案の説得力を高める具体的なツールや事例を求めている方
MigrationはAIで加速。品質は、どう守る? 続きを読む
HBLAB JSCは、技術者体制、導入実績、およびお客様のプロジェクトにおける成果に関する各要件を満たし、アマゾン ウェブ サービスより「アドバンストティアサービスパートナー」に昇格いたしました。 2026年8月24日、創業以来11年以上にわたり日本市場を中心に事業を展開するソフトウェア開発企業であるHBLAB JSC(以下「当社」)は、アマゾン ウェブ サービス(以下「AWS」)のパートナー制度「AWSパートナーネットワーク(APN)」において、「AWSアドバンストティアサービスパートナー」に昇格いたしましたので、お知らせいたします。 APNのティア制度では、サービスパートナーを「セレクト」「アドバンスト」「プレミア」の3段階に区分しています。「アドバンスト」は上から2番目に位置づけられ、高度な技術力と専門知識を有し、かつAWSによる検証を受けた導入実績を持つパートナーが認定されるティアです。 本ティアの認定にあたっては、以下の3つの評価領域における要件を、いずれも同時に満たす必要があります。 Knowledge(知識):AWS認定資格を保有する技術者の人数、および保有資格の専門性の水準 Experience(実績):AWS上で実施したプロジェクトの件数および規模 Customer Success(顧客の成功):お客様およびAWSによって確認された実際の成果
HBLAB JSC、AWSアドバンストティアサービスパートナーに昇格 続きを読む
ソフトウェア開発のAI活用を開発生産性の視点で解説。AI駆動開発・仕様駆動開発などの手法、主要なAIコーディングツール、導入ステップと注意点を整理しました。
ソフトウェア開発におけるAI活用とは?開発生産性を高める手法・ツールを徹底解説 続きを読む
レガシーシステムは経過年数で定義されるものではありません。次の3つの兆候で定義されます。中身を全体として理解している人がもういない、変更にかかるコストがシステムが生み出す価値を上回るペースで増えていく、そして新しいシステムやデータとつながらない——この3点です。 刷新が必要になる時期は、システムが壊れたときではありません。多くの老朽化したシステムは、最後の日まで安定して動き続けます。その時期は、3本の曲線が交差したときに訪れます。保守コストが上がり、保守できる人の数が減り、サポート終了(EOL)の期限が近づく、という3本です。 本記事は、レガシーシステムをどう移行するかを論じるものではありません。その前段にある問い——自社の既存システムは本当に「問題」なのか、問題であるならどれほど緊急なのか——にお答えします。自社のレガシーシステムを自己評価するための測定可能な4つのシグナル、ブラックボックス化の度合いを確かめるチェックリスト、そして経営層に上げる際に課題を財務の言葉で表現する方法をお持ち帰りいただけます。 お忙しい方向けの要約: 見分けるための3つの兆候 — 判断のための4つの定量シグナル — そして1つの原則。先延ばしはコストを据え置きにしません。先延ばしは対象範囲を膨らませます。 レガシーシステムとは?年数ではなく「症状」で定義する 「システムは何年経つとレガシーシステムと見なされるのか」という問いは、そもそも立て方が誤っています。実際のコンサルティングの現場では、18年稼働していながら極めて健全に運用されているシステムもあれば、納品から3年で、業界の文献が「レガシー」と呼ぶ状態にちょうど陥ってしまったシステムもあります。 レガシーシステムを見分ける3つの兆候 ツールを使わず、いますぐ使える見分け方です。 理解できない
レガシーシステムのリスク、先延ばしのコスト、そして刷新すべき時期 続きを読む
System Modernizationとは、言語・アーキテクチャ・データ・運用プロセスのいずれかが古くなったシステムを、新しい技術基盤のもとで開発・連携・拡張を続けられる状態へと移行させるプロセスです。「システムを書き直す」ことと異なるのは、Modernizationが、現在稼働中の資産——ソースコード、業務ロジック、データ、そして長年にわたって運用されてきた業務フロー——を起点とする点にあります。System Modernizationの目的は、新しいシステムを手に入れることではありません。企業が引き続き理解・修正・拡張でき、データやAIとも連携できるシステムを保有し続けることです。本記事では、実際のプロジェクトが通る順序どおりに、System Modernizationの全体ロードマップを解説します。レガシーシステムの問題を認識する → Assessment・リバースエンジニアリング → アプローチの選定 → AI × Migration → テスト・QC
System Modernization:レガシーシステムから発展の基盤へ 続きを読む
HBLAB Modernization Solution(Migurei AI Inside): Unblock the Blackbox — ブラックボックス化したシステムを解き明かし、安全な移行へ。 「ブラックボックスになるシステムの中身が分からない」「移行のコストが読めない」——長年運用してきた既存システムは、いまや事業継続のリスクになっています。HBLABのMigration Solutionは、独自AIツール「Migurei AI Inside」で既存システムを読み解き(Unblock
株式会社エイチビーラボジャパン、システム移行の新ソリューション「Modernization Solution(Migurei AI Inside)」を提供開始 続きを読む
HBLABは、2026年8月3日(月)より、東京オフィスを下記の新住所へ移転し、業務を開始いたしますのでお知らせいたします。 新オフィス情報 住所:〒105-0012 東京都港区芝大門1丁目3番4号 グランファースト芝大門 6階 最寄り駅 都営浅草線・都営大江戸線「大門駅」より徒歩4分 都営三田線「御成門駅」より徒歩5分 JR・東京モノレール「浜松町駅」より徒歩8分 今回のオフィス移転は、日本市場における事業拡大および人員体制の強化に伴うものであり、HBLABのさらなる成長に向けた新たな一歩となります。また、日本国内でのサービス提供体制を一層強化し、お客様により迅速かつきめ細やかなサポートを提供することを目指しています。さらに、AIを中核とした長期的な成長戦略のもと、お客様への新たな価値創出を推進していく取り組みの一環でもあります。 新オフィスは、オープンなレイアウトや自然光を活かした快適なワークスペース、充実したミーティング・応接エリアを備え、今後の事業成長を支える環境として整備いたしました。 引き続き東京中心部に拠点を構えることで、お客様・パートナーの皆様にもご来訪いただきやすい立地となっております。 また、この移転を機に、皆様へのお披露目を兼ねたオフィス移転記念イベントを計画しております。当日は弊社の今後の戦略についてご説明するほか、皆様同士での貴重な情報交換の場となればと考えております。詳細につきましては、追って別途ご案内させていただきます。
株式会社エイチビーラボジャパン(以下、HBLAB JAPAN)は、2026年7月21日、御茶ノ水ワテラスコモンホールで開催された「第2回 リテールIT Flash Talks」に登壇しました。 本イベントは、日本小売業協会のCIO研究会プログラム内で開催され、IT関連企業と小売企業との接点を広げるとともに、小売企業がDX戦略の参考となる最新技術や導入事例に関する情報を得ることを目的としています。 HBLAB JAPANは、登壇企業3社のうちの1社として選出され、「『独自AI』を手に入れるためのデータ基盤・システム刷新戦略」をテーマに発表しました。 イベント概要 「第2回 リテールIT Flash Talks」は、IT企業が小売企業に向けて、自社の製品・サービスやDX推進に関する取り組みを紹介するショートピッチ形式のイベントです。 当日は、HBLAB
HBLAB JAPAN、「第2回 リテールIT Flash Talks」に登壇 続きを読む