業種名より先に、守る業務と変える業務を決める
同じ製造業でも、標準パッケージに業務を合わせたい会社と、独自の工程管理を残したい会社では、調査の目的が異なります。最初に「どの判断に使うか」を定めると、解析対象と必要な成果物を絞れます。
IPAのモダン化解説でも、IT資産と相互関係の可視化、仕様の文書化、標準化する部分と独自性を残す部分の整理が取り上げられています。以下の調査範囲や確認項目は、その背景と当社の解析機能を踏まえた検討例です。
製造業｜生産管理・原価計算の刷新
生産管理を入れ替える前に、独自の計算・例外処理を把握したい。
たとえば、生産実績を取り込む夜間バッチから、在庫更新、月次の原価計算までをひとつの対象にします。品番や数量の受け渡しをたどり、単位換算、端数処理、仕掛品の扱いなど、移行後も確認すべき条件を整理します。
集める候補は、対象のプログラム、ジョブ定義、品目・工程・在庫のデータ定義、入出力のサンプルです。ERPや生産管理パッケージへの移行を検討する場合も、独自ロジックのうち残すものと標準機能に合わせるものを、業務担当者と仕分けます。
- まず調べる範囲：生産実績 → 在庫更新 → 原価集計の一連の処理。
- 確認する例：実績の取消、月をまたぐ計上、単位換算と丸め。
- 人が確かめる点：現場の手修正、実行時刻、残すべき業務上の理由。設備制御やリアルタイム性能の評価は別途必要です。
卸売・小売業｜販売管理・在庫管理の刷新
販売管理を刷新したいが、得意先ごとの例外が設計書に残っていない。
受注、出荷、売上、請求を一続きで確認します。得意先別の単価や値引き、返品時の在庫戻し、締日を過ぎた売上の計上先などは、単一の画面やプログラムだけでは判断しにくい対象です。
価格マスター、請求先・締日の定義、売上集計バッチ、帳票定義と設計書を照合します。たとえば「締日を変更する」場合、日付判定の修正だけでなく、請求書・入金照合・会計連携まで確認するための影響マップをつくります。
- まず調べる範囲：ひとつの受注区分の登録から請求書出力まで。
- 確認する例：締日の直前・当日・翌日、値引きと返品の組み合わせ。
- 人が確かめる点：契約上の価格条件、税計算の扱い、Excelでの補正。コードの動作と業務として正しい条件は分けて承認します。
物流業｜倉庫・配送システムの刷新
倉庫管理を移行すると、荷主や配送先との連携に何が影響するのか知りたい。
倉庫管理（WMS）や配送管理の刷新では、入出庫データの作成から、ファイル転送、相手側の結果受信までを対象に考えます。項目名が同じでも、荷主ごとにコード体系や桁数が異なることを想定し、変換処理と受け渡しの定義を照合します。
プログラムに加えて、HULFT等の転送定義、JP1等のジョブ定義、連携ファイルのレイアウトが調査材料になります。相手側の仕様や設定が提供されていない範囲は、確認待ちとして明示し、連携先との調整に引き継ぎます。
- まず調べる範囲：ひとつの荷主との入荷予定 → 入庫実績の連携。
- 確認する例：桁数変更、欠損項目、転送失敗時の再実行と重複取込。
- 人が確かめる点：連携時刻、締切、障害時の手作業、相手側の受入条件。実環境での疎通と性能の確認は別途必要です。
金融・保険業｜COBOL・基幹バッチの現行調査
COBOL資産を刷新する前に、計算とバッチの依存関係を確認したい。
たとえば、手数料計算や契約更新のひとつの処理を選び、入力条件、計算、保存先、後続帳票の関係を確認します。COBOL本体だけでなく、COPY句、JCL、データ定義、対象に応じたCICS・IMS等の定義も揃えます。
新旧の結果を比べる際は、計算基準日、端数、取消や遡及処理を条件ごとに分けます。外部に持ち出せる資料や利用可能なAI環境を解析前に確認し、規制・監査・業務上の判断は各担当者の承認を受けます。
- まず調べる範囲：ひとつの計算処理と、その前後のジョブ。
- 確認する例：月末・年末、閏日、金額の境界、取消や再実行。
- 人が確かめる点：業務上の正解、対象外の運用、機密情報の取り扱い。本番切替や規制適合性の保証を含むものではありません。
情報システム部門とSIerで、成果物をどう受け取る？
情報システム部門は残す業務と受入条件、業務部門は例外処理と運用、SIer・開発会社は実装上の関係とテスト範囲を確認します。同じ現行仕様と根拠を見ながら、未確認事項ごとに担当と確認方法を決めます。
レガシー刷新AIは、資産台帳、現行仕様、影響マップ、テスト仕様書などの作成を支援します。方言・フレームワーク・資料の揃い方で対応範囲は変わるため、代表的な対象で確認してから広げます。
