• All
  • AI
  • AIエージェント
  • イベント
  • ウェビナー
  • ウェビナー
  • オフショア
  • オフショア開発
  • お客様インタビュー
  • お知らせ
  • データ活用
  • ニュース
  • パートナー提携
  • ブログ
  • プログラミング言語
  • マネージドサービス
  • モダナイゼーション
  • リーテル
  • ローコード
  • 分類されない記事
  • 加盟団体
  • 受賞
  • 業務自動化
  • 生成AI
  • 社内活動
  • 社員の声
  • 製品
  • 認証
マイグレーションテストの進め方|ゴールデンデータと4つの品質軸(Hblab)

マイグレーションテストの進め方|ゴールデンデータと4つの品質軸

マイグレーションテストとは、既存システムを新しい環境・構造へ移行する際に、移行後のシステムが移行前と同じ業務結果を出すことを検証するテストです。リファクタリング型のマイグレーションテストでは、失われた仕様書ではなく旧システムそのものが正解になります。旧システムの出力を「ゴールデンデータ」として記録し、新旧で消えない接合点(シーム)で比較する。そして品質はコードカバレッジひとつではなく、Code・Spec・Test category・Test qualityの4つの軸で、リファクタリングを始める前に測ります。 本記事では、HBLABが実際のマイグレーション案件で使っているマイグレーションテストの進め方を、テストの置き場所、ゴールデンデータの作り方と網羅性評価、AIの役割、差異の分類まで順に解説します。 リファクタリング案件では、仕様書は多くの場合失われているか、いま動いている実態と合わなくなっています。信頼できる唯一の正解は旧システムそのものです。正解の出どころが変わる以上、テストスイートの品質の測り方も変えなければなりません。さらに、コードカバレッジでは最も重要な問いに答えられなくなります。 テーマ:レガシーマイグレーション · リファクタリング | 対象読者:PM、BrSE、QCリード | 連載:第1回/全2回 サンプル入力 ──▶ […]

マイグレーションテストの進め方|ゴールデンデータと4つの品質軸 続きを読む

マイグレーションのAi活用を4つの工程に整理した図

マイグレーションのAI活用|工程別にできること・限界と品質担保

マイグレーションのAI活用が特に効果を発揮するのは、現行資産の解析、業務ロジックの復元と仕様書の生成、そしてテストの生成・検証です。一方で、アーキテクチャの決定、業務ルールの妥当性判断、そして最終的な品質責任は、いまも人が担う領域です。 日本では2030年に約79万人のIT人材が不足するとされ、古い言語を読める技術者はさらに希少になると見込まれます。「AIにコードを読ませる」という選択肢が現実的になったのは、AIが完璧になったからではなく、読める人がいなくなりつつあるからです。 ただし、AIは自信を持って間違えます。請求額が数円ずれる程度の取り違えでも、基幹システムでは重大な事故につながります。本記事では、4工程でAIに任せられる範囲、工数削減が成立する前提条件、ハルシネーションの検知方法、そしてAIと人の責任分界を、実務目線で整理します。 マイグレーションのAI活用とは?——4工程で見る「できることの地図」 AIの話に入る前に、言葉を整理しておきます。マイグレーションとモダナイゼーションを混同したまま議論すると、「AIにどこまで任せられるか」の見積もりもずれてしまうからです。 マイグレーション・モダナイゼーション・リプレースの違い この3つは同じ意味で使われがちですが、投資範囲もリスクの大きさも異なります。 用語 目的 変える対象 代表的な手法 マイグレーション 既存資産を活かしたまま新しい環境へ移す 基盤・言語・インフラ

マイグレーションのAI活用|工程別にできること・限界と品質担保 続きを読む

レガシーシステムが原因でAi活用がPoc止まりになる構造

なぜレガシーシステムはAI活用の壁になるのか?4層で原因を解剖

この記事のポイント レガシーシステムがAI活用を阻む原因は、AIモデルではなく「データ層・連携層・ロジック層・ガバナンス層」の4層にあります。AIがPoC止まりになるのは、PoCと本番でデータの扱い方がまったく違うためです。本記事の12項目のチェックで、自社のボトルネックとなっている層を特定できます。全面刷新をしなくても、詰まっている層から順に手を打てば壁は越えられます。 「生成AIを導入したのに、PoCから先に進まない」。その原因の多くは、AIモデルではなくレガシーシステムにあります。レガシーシステムがデータ活用やAI活用の壁になるのは、データが「取り出せない・意味がわからない・つながらない・統制できない」という構造的な問題を抱えているからです。 Gartnerは、AI-readyデータ(AIに適した形で整備されたデータ)の裏付けがないAIプロジェクトの60%が、2026年までに中止されると予測しています(Gartner, 2025年2月)。日本でも経済産業省のレガシーシステムモダン化委員会総括レポートが、約6割の企業にレガシーシステムが残存しており、それが生成AIなど最新技術との連携・組み込みを妨げていると指摘しています。 本記事では、この壁を4つの層に分解し、PoC止まりの構造、AIレディ診断、層別の刷新アプローチ、経営層への説明の仕方までを解説します。レガシーシステム全体のリスクと刷新のタイミングについては、「レガシーシステムのリスク、先延ばしのコスト、そして刷新すべき時期」をご覧ください。レガシーシステムの定義や代表的な課題から確認したい方は、「レガシーシステムとは?定義・最新の解決策と5つの課題」もあわせてご覧ください。 AI活用が「PoC止まり」になる本当の理由は、レガシーシステムにある 多くの企業で、AIのPoC(概念実証)自体は成功します。問題が起こるのは、その成果を本番業務に広げようとした段階です。まずは、よくある失敗パターンから見ていきましょう。 PoCは成功するのに本番で止まる — よくある3つのパターン PoCと本番の違いは、モデルではなく「データをどう手に入れるか」にあります。現場で繰り返し起きているのは、次の3パターンです。 データ供給が続かない:PoCでは、担当者が手作業で抽出したCSVデータで学習させることができます。しかし本番では日次・時間単位で最新のデータが必要になり、夜間バッチでしか出力できないレガシーシステムでは供給が追いつきません。 本番データで精度が落ちる:整えたサンプルデータでは高精度だったモデルが、実データでは重複した顧客マスタや意味が不明な区分値に引きずられ、誤った回答を返し始めます。

なぜレガシーシステムはAI活用の壁になるのか?4層で原因を解剖 続きを読む

Aiで加速するMigrationとPass結果の根拠を問うイメージ。拡大鏡の中に「Pass」「期待結果」「その根拠は?」を表示。

AIで加速するMigration。テストが「PASS」でも、それだけでは品質を証明できない理由

テストはすべて「PASS」。それでも、新しいシステムが業務要件に照らして正しいと言い切れるでしょうか。 この問いは、AIがMigration(マイグレーション)プロジェクトに深く関わり、マイグレーションテストの自動化が進むほど重要になります。レガシーコードのリバースエンジニアリング、ドキュメントの再構築、コード変換、テストケースの生成など、これまで多くの時間を要してきた作業は、AIによってより短時間で処理できるようになっています。生成される成果物が増えるほど、品質の焦点は「どれだけ多く生み出せるか」から「生み出したものが本当に正しく、検証できる根拠を備えているか」へと移ります。 レガシーシステムはベースラインだが、正解そのものとは限らない ドキュメントが不足しているMigrationプロジェクトでは、稼働中のシステムが事実上、重要なベースラインになることが少なくありません。現行の振る舞いを記録する特性化テスト(Characterization Test)も、レガシーシステムの現在の振る舞いを記録し、改修や移行の際に想定外の変化を検知するという考え方に基づいています。 しかし、現状を記述することは、その現状が正しいと保証することとは異なります。レガシーシステムはしばしば複雑な集合体であり、保全すべき中核的なルールと同時に、暫定的な回避策(workaround)、技術的負債(technical debt)、そして当初の理由がすでに不明確になったまま何年も残り続けてきた判断が混在しています。 したがって、移行の品質は、まず期待結果(expected result)を正しく定義できるかどうかに大きく左右されます。この作業では、実際の振る舞い、データ構造、いまも価値のある一部のドキュメント、そして現行の業務要件を突き合わせ、明確な受け入れ基準(acceptance criteria)へと変換していきます。過去の挙動は、その判断材料の一つとして扱います。 そのため、現状評価(Assessment)の工程は、コード行数を数えたり技術スタックを列挙したりする段階にとどまりません。プロジェクトチームは、データフロー、バッチ処理、連携ポイント、依存関係(dependency)、そしてシステムの動作を支える業務ロジックを明らかにし、そのうえで、保全すべき資産、変更してよい領域、管理すべきリスク領域を、移行方式を選択する前に見極める必要があります。 一つの誤りが、AIの連鎖全体に伝播するとき Migrationのスピードは、前工程の出力が次工程の入力へと自動的に引き継がれるときに大きく高まります。ドキュメントはコード生成に用いられ、そのコードと関連ドキュメントは、さらにテストケース生成の土台になります。この構造は工程の多くを自動化しますが、同時にエラー伝播(error propagation)が生じる余地も作り出します。出発点にある一つの誤った前提が、後続の工程へと次々にコピーされていくためです。

AIで加速するMigration。テストが「PASS」でも、それだけでは品質を証明できない理由 続きを読む

Ai Migration

MigrationはAIで加速。品質は、どう守る?

【無料ウェビナー】MigrationはAIで加速。品質は、どう守る? AIは、レガシーコードの解析や仕様書の再構築、テストケースの生成、テスト自動化に至るまで、マイグレーションプロジェクトの進め方を大きく変えつつあります。 その一方で、AIの活用範囲が広がるほど、より重要になるテーマがあります。 AIが生成した成果物を、どのように検証するのか。 AIの活用によって、開発や移行作業のスピードを大幅に高めることが可能になります。しかし、AIが生成した成果物を十分に検証できなければ、マイグレーション全体の品質を確保することは難しくなります。 特に、要件や業務ロジック、既存のテストケースが不足している、あるいは内容が不明確になっているレガシーシステムでは、検証の重要性はさらに高まります。 そこで生じる問題は、単なる技術的な不具合だけではありません。誤りを早期に発見できなければ、修正コストの増加やプロジェクトの遅延、納品物の品質低下につながり、最終的には顧客からの信頼にも影響を与える可能性があります。 本ウェビナーでは、AI活用の前後で、マイグレーションにおける品質保証の考え方がどのように変化するのかを整理するとともに、AI活用によって新たに生じる課題と、一貫した検証の仕組みをどのように構築するかについて解説します。 さらに、実際のケーススタディとデモを通じて、AIのスピードを活かしながら、品質を客観的に示せる根拠を確保し、生成されたアウトプットを適切に検証・コントロールする方法をご紹介します。 ウェビナーにご登録いただいた方に、「Migration QA自己診断チェックリスト」をご提供いたします。すでにMigrationに取り組まれている方は、現在の品質管理体制を確認するために、これからMigrationを検討される方は、事前に確認しておきたい評価基準を整理するためにご活用いただけます ウェビナーに申し込んで、チェックリストを受け取る こんな方におすすめ マイグレーション/モダナイゼーション案件を推進するための人材や専門知識が不足しており、顧客提案の説得力を高める具体的なツールや事例を求めている方

MigrationはAIで加速。品質は、どう守る? 続きを読む

Aws Advanced Jp

HBLAB JSC、AWSアドバンストティアサービスパートナーに昇格

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アドバンストティアサービスパートナーに昇格 続きを読む

レガシーシステム刷新:保守コスト・保守できる人数・Eol期限の3本の曲線が交差する時期を示す図

レガシーシステムのリスク、先延ばしのコスト、そして刷新すべき時期

レガシーシステムは経過年数で定義されるものではありません。次の3つの兆候で定義されます。中身を全体として理解している人がもういない、変更にかかるコストがシステムが生み出す価値を上回るペースで増えていく、そして新しいシステムやデータとつながらない——この3点です。 刷新が必要になる時期は、システムが壊れたときではありません。多くの老朽化したシステムは、最後の日まで安定して動き続けます。その時期は、3本の曲線が交差したときに訪れます。保守コストが上がり、保守できる人の数が減り、サポート終了(EOL)の期限が近づく、という3本です。 本記事は、レガシーシステムをどう移行するかを論じるものではありません。その前段にある問い——自社の既存システムは本当に「問題」なのか、問題であるならどれほど緊急なのか——にお答えします。自社のレガシーシステムを自己評価するための測定可能な4つのシグナル、ブラックボックス化の度合いを確かめるチェックリスト、そして経営層に上げる際に課題を財務の言葉で表現する方法をお持ち帰りいただけます。 お忙しい方向けの要約: 見分けるための3つの兆候 — 判断のための4つの定量シグナル — そして1つの原則。先延ばしはコストを据え置きにしません。先延ばしは対象範囲を膨らませます。 レガシーシステムとは?年数ではなく「症状」で定義する 「システムは何年経つとレガシーシステムと見なされるのか」という問いは、そもそも立て方が誤っています。実際のコンサルティングの現場では、18年稼働していながら極めて健全に運用されているシステムもあれば、納品から3年で、業界の文献が「レガシー」と呼ぶ状態にちょうど陥ってしまったシステムもあります。 レガシーシステムを見分ける3つの兆候 ツールを使わず、いますぐ使える見分け方です。 理解できない

レガシーシステムのリスク、先延ばしのコスト、そして刷新すべき時期 続きを読む

Scroll to Top