メインフレーム棚卸し完全ガイド 2026｜経営にブラックボックスを説明する 3 ステップ可視化アセスメント

「で、メインフレーム結局いつ刷新するの？」——四半期の経営会議で役員からこの質問が飛んできたとき、情シス部長が言葉に詰まる構造はほぼ共通しています。

理由はシンプルで、対象が見えていないからです。20 年以上稼働している基幹系は、当時の開発者がすでに退職、ドキュメントは紙のバインダー、現役の保守要員 2 名のうち 1 名が来年定年——という現場で「いつ刷新すべきか」に答えるには、まず棚卸しからやり直すしかありません。

本ガイドでは、メインフレーム / 基幹系のブラックボックスを経営説明可能なレベルまで可視化する手順を、6 項目 × 3 ステップで整理します。経済産業省「DX レポート」「DX レポート 2.2」が示した 2025 年の崖の文脈、IPA「DX 白書 2026」の最新数字、そして中堅企業（従業員 1,000〜3,000 名規模）の実務感覚に沿って、稟議が通る粒度の棚卸しに落とし込みます。

メインフレーム棚卸しが経営説明の前提になる理由
棚卸しで可視化すべき 6 項目
3 ステップのアセスメント手法
経営向け説明資料テンプレート
役員別の説明アングル（CFO / COO / CIO / CHRO）
棚卸し後の意思決定フレーム（4R + 段階移行）
中堅企業向け棚卸し費用感
FAQ
関連記事
参考資料

メインフレーム棚卸しが経営説明の前提になる理由

経済産業省「DX レポート」（2018 年公表）が提起した「2025 年の崖」では、レガシーシステムを放置した場合の経済損失が 年間最大 12.7 兆円 と試算されました。後継の「DX レポート 2.2」（2022 年）でも、デジタル投資が「攻め」に向かわず保守運用に偏る構造が指摘されています。

数字を経営目線で読むと、本質は次の 3 点です。

保守費の機会損失：IT 予算の 70〜80% が現行維持に消え、新規事業 / 顧客接点改善に回せる原資が小さい
人材リスクの時限性：COBOL / PL/I / RPG / アセンブラを書ける現役エンジニアの平均年齢が高く、退職に伴うナレッジ消失が不可避
意思決定の遅延コスト：刷新判断が 1 年遅れるたび、保守料金 + 障害対応 + 機会損失が累積する

ここで情シスが直面する現実は「経営層は数字でしか動かない」一点です。「老朽化していて危険です」では稟議は通らず、業務領域 / コード規模 / 残存開発者数 / 年間コスト / 障害頻度 / 撤退条件 の 6 項目を数字で示せて初めて、経営は「いつ・いくらで・どう刷新するか」の議題に入れます。

棚卸しは目的ではなく、経営会議に持ち込むダッシュボードを作る作業です。3 ヶ月の投資で、その後 5〜10 年の刷新判断が前進します。

中堅企業（1,000〜3,000 名）で棚卸しが特に重要な理由

大企業のように専任の EA（エンタープライズアーキテクト）チームを置けず、属人化した保守体制になりがち
中小企業のように一人で全体を把握できる規模ではなく、複数部門にまたがる業務システムが横断的に絡む
ベンダーロックインの度合いが高く、「外に出す」判断が経営マターになりやすい

このギャップを埋めるのが棚卸しの役割です。

棚卸しで可視化すべき 6 項目

経営に説明するための最小単位として、以下 6 項目を 1 シートにまとめます。各項目に「現状値」「許容ライン」「リスク評価（高 / 中 / 低）」を入れる構造が基本です。

項目 1：業務領域

何を支えているシステムか、を業務プロセス単位で書き出します。

チェックポイント：会計 / 販売 / 購買 / 在庫 / 生産 / 給与 / 物流などの主要プロセス別に粒度を揃える
可視化の単位：1 業務領域 = 1 行で経営報告
落とし穴：「販売管理」など大くくりにすると判断材料にならない。受注 / 出荷指示 / 売上計上 / 債権管理まで分解する

業務領域	1 日の処理件数	停止時の影響	代替手段の有無
受注処理	1,200 件	営業活動停止	なし
在庫引当	3,500 件	出荷遅延	Excel 手作業

項目 2：コード規模

棚卸しで最も後回しにされやすい項目ですが、刷新コスト試算の出発点です。

チェックポイント：プログラム本数 / 総ステップ数（KLOC） / 言語別内訳
目安：中堅企業の基幹系は 50〜500 万行（COBOL 換算）が多い
計測方法：JCL / プロシージャ含めて静的解析ツールで自動カウント（Step 3 で詳述）

項目 3：開発者残数とナレッジ集中度

人材リスクを定量化する項目です。

チェックポイント：現役で改修可能な人数（社内 / 社外）、平均年齢、定年退職予定年
可視化の表現：「2030 年までに保守可能人数が 0 になる確率：XX%」のように時間軸で示す
隠れリスク：「ベンダー A 社の B さんしか分からない」状態は属人 1 名 = リスク高

項目 4：年間コスト（TCO）

現行維持にいくら払っているかを、隠れコストまで含めて棚卸しします。

コスト分類	該当項目例
ハードウェア	メインフレーム本体リース、ストレージ、保守料金
ソフトウェア	OS、DB、トランザクションモニタ、ツールライセンス
運用人件費	社内オペレータ、夜間バッチ監視、年末年始対応
改修委託費	ベンダー保守契約、追加開発、改修対応
間接コスト	電力、空調、データセンタースペース、災害対策

中堅企業の場合、5 年間の TCO で 3〜10 億円規模になるケースが一般的です（システム規模次第）。これを刷新後の予測 TCO と並べると、経営の納得感が変わります。

項目 5：障害頻度と業務インパクト

「動いているからセーフ」を反証する項目です。

計測単位：年間障害件数 / 平均復旧時間（MTTR） / 業務停止時間 / 売上影響額
トレンド表示：3 年分の推移を折れ線で。右肩上がりなら経営判断の引き金になる
隠れ障害：日次バッチ遅延、夜間処理の手作業介入頻度なども含める

項目 6：撤退条件 / リミット

「いつまでに刷新しないとダメか」の期限を、複数のリミットを束ねて提示します。

ハード保守期限：メーカー / リース会社の保守終息日
OS / ミドル EOL：COBOL コンパイラ、DB、トランザクションモニタのサポート終了日
人材リミット：保守要員の定年退職タイミング
業務拡張リミット：新事業 / 新規制対応で改修が必要な期日（インボイス、電帳法、適格請求書、海外拠点対応など）

複数のリミットを年表化すると「最も早いリミットがクリティカルパス」になります。これが刷新タイミングの根拠です。

3 ステップのアセスメント手法

6 項目を埋めるための作業を、3 ステップに分けます。期間目安は中堅企業で 2〜4 ヶ月。並列化すれば 6 週間程度に短縮可能です。

Step 1：文書精査（2〜4 週間）

社内に散在する文書を集めて棚卸しします。

集める対象

システム概要書 / 基本設計書 / 機能仕様書
運用設計書 / バッチスケジュール / 障害履歴
ベンダーとの保守契約書 / 改修見積もり履歴
DB スキーマ定義 / I/F 連携一覧
監査対応資料（J-SOX、IT 全般統制）

成果物

業務領域マップ（項目 1 のドラフト）
既知の I/F 連携図
文書化されている範囲の整理表（網羅率 XX%）

落とし穴

「文書がない」と諦めない。監査対応資料は必ずあるので、そこから業務領域を逆算する
古いバインダーの紙資料も対象。スキャン → OCR で 1 週間程度で電子化できる

Step 2：利用部門ヒアリング（3〜6 週間）

文書では見えない「実際にどう使われているか」を、業務部門にインタビューして補完します。

ヒアリング対象

各業務領域のキーパーソン（部長 / 課長クラスの実務責任者）
月次 / 年次の特殊処理を担当する現場担当者
システムを「触らないが使っている」関連部門（経理、内部監査、情報セキュリティ）

質問テンプレート

このシステムが 1 日止まると、いくらの売上影響があるか
過去 3 年で「一番困った障害」と「ヒヤリハット」を 3 つずつ
Excel / 紙で代替している処理はあるか（= 隠れシャドー IT）
システム外で個別最適化されている運用ルール
「実は使っていない機能」はあるか（撤退候補の発見）

成果物

業務領域別の影響度マトリクス（項目 5 の精緻化）
シャドー IT / 個別運用の一覧
撤退候補機能のロングリスト

Step 3：静的解析（3〜6 週間）

ソースコードを機械的に解析し、文書 / ヒアリングで埋まらない項目を埋めます。

解析対象

COBOL / PL/I / RPG / アセンブラなどのソースコード
JCL（ジョブ制御言語）、プロシージャ
DB スキーマ、Copybook、コピー句
バッチ処理定義

解析ツールの選択肢

IPA「アセスメントツール」公開版（無償、限定機能）
商用ツール：Micro Focus Enterprise Analyzer、Modern Systems / TmaxSoft 系、Asysco など
自社開発：grep / awk / Python で簡易分析（小規模ならこれで足りる）

計測する項目

総ステップ数 / プログラム本数（項目 2）
プログラム間 CALL 関係、データ I/O フロー
デッドコード比率（呼ばれていないプログラム）
循環的複雑度（保守困難度の指標）
ハードコード定数（移行時のリスク箇所）

成果物

コード規模ダッシュボード（項目 2）
デッドコード一覧（撤退候補の確定）
高複雑度プログラム top 20（リファクタ優先度）

3 ステップ並列化のコツ

Step 1 終了を待たず、文書化済み領域から Step 2 / 3 に着手する
ヒアリングと静的解析の結果を 2 週間に 1 度、6 項目シートに反映する定例を回す
経営報告は「全項目埋まってから」ではなく、3 ヶ月後の中間報告で粒度 70% を目指す

経営向け説明資料テンプレート

棚卸し結果を経営会議に持ち込むときの 1 ページサマリの構造です。

1 ページサマリの 5 ブロック

現状サマリ：システム名、稼働年数、業務領域数、コード規模、年間コスト、保守要員数
リスク 3 行：最もクリティカルなリスクを 3 つだけ。期日付き
意思決定の選択肢：4R（Rehost / Replatform / Refactor / Replace）+ 現状維持の 5 択を、コスト × 期間 × リスクで対比
推奨アクション：6 ヶ月 / 12 ヶ月 / 24 ヶ月の時間軸で次の一手を提示
判断期限：いつまでに経営判断が必要か（最も早いリミットを根拠提示）

重み付き評価マトリクス（補助資料）

経営層が「なぜこの選択肢か」を確認するための補助資料です。

評価軸	重み	現状維持	Rehost	Replatform	Replace
5 年 TCO	25%	△	○	○	△
業務継続性	25%	○	◎	○	△
拡張性	20%	×	△	○	◎
人材リスク	20%	×	△	○	◎
移行リスク	10%	◎	○	△	×

スコアで点数化すると、説明根拠としての強度が増します。重みは経営方針 / 業界特性で変動するため、CIO だけでなく CFO / COO とすり合わせるのがポイントです。

無料テンプレ DL：上記の 1 ページサマリ + 重み付き評価マトリクスを、Excel / PowerPoint で使えるテンプレートにまとめました。メインフレーム棚卸しアセスメントテンプレート（無料 DL）

役員別の説明アングル（CFO / COO / CIO / CHRO）

経営層と一括りにせず、役員ごとに刺さるアングルを変えます。

CFO（最高財務責任者）：費用と投資効果

キーメッセージ：5 年 TCO 比較、刷新後の保守費削減率（中堅企業実績で 30〜45%）
見せる数字：現状維持シナリオの累積コスト vs 刷新シナリオの NPV（正味現在価値）
避けるべき：技術用語、3 文字略語の連発

COO（最高執行責任者）：業務影響と継続性

キーメッセージ：障害発生時の業務停止リスク、移行期の業務継続計画
見せる数字：過去 3 年の障害件数推移、業務領域ごとの停止時影響額
強調点：段階移行で「業務を止めない」プランの合理性

CIO / 情シス役員：技術負債と戦略整合

キーメッセージ：4R 戦略、クラウド戦略との整合、人材確保見通し
見せる数字：循環的複雑度、デッドコード比率、新規事業のリードタイム
強調点：刷新後のアジリティ向上（リードタイム 6 ヶ月 → 3 ヶ月など）

CHRO（最高人事責任者）：人材リスク

キーメッセージ：保守要員の年齢構成、退職タイミング、若手への技術継承困難度
見せる数字：現役保守可能人数の経年予測、リスキリング計画 vs 刷新計画の比較
強調点：「2030 年までに人がいなくなる」を時間軸で示す

役員別アングルを持つことで、経営会議で「全員が違う角度から納得する」状態を作れます。これが稟議突破の決定要因です。

棚卸し後の意思決定フレーム（4R + 段階移行）

棚卸しが終わった後の選択肢を、4R + 現状維持で整理します。

4R 戦略

戦略	内容	適合ケース	概算費用（中堅規模）
Rehost	OS / インフラだけ移行（リフト）	コードは現役、ハード保守期限が直近	5,000 万〜2 億円
Replatform	DB / ミドルを刷新、コード一部改修	コード品質が中、長期延命したい	1〜3 億円
Refactor	コードを段階的に近代化	規模大、業務変更も伴う	2〜5 億円
Replace	パッケージ / SaaS / フルスクラッチで再構築	業務プロセスごと見直し	3〜10 億円

段階移行の 3 パターン

業務領域別フェーズ移行：受注 → 在庫 → 会計の順で領域を切り出す
ストラングラーパターン：周辺機能から API 化して新システムに置き換え
データ並行運用：旧 / 新システムを一定期間並行稼働、データ整合を毎日確認

中堅企業では「業務領域別フェーズ移行」が最も成功率が高い傾向です。一括移行（ビッグバン）は移行リスクが指数的に上がるため、棚卸し結果がよほどクリーンでなければ推奨しません。

4R を選ぶための判断軸

ハード保守期限までの残期間（< 18 ヶ月なら Rehost ベース）
業務プロセスの変更要否（必要なら Replace 寄り）
コード品質と保守要員の見通し（劣化が深刻なら Refactor / Replace）
投資余力と他施策との優先順位（CFO 同席で判断）

詳細な判断フレームはレガシーシステムの延命 vs リプレース判断フローも併読を推奨します。

中堅企業向け棚卸し費用感

棚卸し自体にいくらかかるか、を経営に提示するための目安です。

パターン 1：自社実施 200〜500 万円

リソース：情シス 2〜3 名 × 3 ヶ月、外部ツールライセンス、外部アドバイザリー（スポット）
適合：社内に元開発者がいる、文書がある程度残っている、規模が小さめ（コード 50〜100 万行）
メリット：コスト低、社内ナレッジが残る
デメリット：本業との兼任で長期化しがち、客観性に欠ける

パターン 2：SI 委託 1,000〜3,000 万円

リソース：SI ベンダー 4〜8 名 × 2〜4 ヶ月、静的解析ツール一式、最終報告書作成
適合：規模大（コード 200 万行以上）、文書がない、社内に元開発者がいない
メリット：客観性、報告書のクオリティ、ベンダーセレクション資料として後工程で再利用可能
デメリット：コスト高、SI のバイアス（自社製品 / 自社サービスへ誘導）

パターン 3：ハイブリッド 500〜1,500 万円

構成：Step 1 / 2 を自社、Step 3（静的解析）だけ専門ベンダーに委託
適合：中堅企業の最頻パターン
理由：業務文脈は社内が一番速く、コード解析だけツール × 専門人材が必要なため

投資対効果（ROI）の目安

棚卸しを 500 万円で実施した結果、刷新費用見積もりの精度が 30% → 80% に上がり、ベンダー競合で 20% コストダウンを実現するケースは珍しくありません。3 億円の刷新案件なら 6,000 万円のコスト改善で、棚卸し投資の 12 倍のリターンです。

FAQ

Q1. 文書がほとんど残っていない場合、棚卸しはどう始めればよいか

A. 監査対応資料（J-SOX、内部統制）から逆算します。会計監査 / システム監査の過程で必ず業務プロセス図と統制点が文書化されているはずです。次に、運用部門が持つバッチ実行カレンダー、障害対応履歴を集めます。文書ゼロのケースは実務上ほぼないと考えてよく、「ない」のではなく「散在している」状態が大半です。

Q2. 経営層が動かないとき、情シスはどう仕掛けるべきか

A. 数字を 3 つ出します。①ハード保守終息日（X 年 X 月）、②保守要員の定年退職タイミング、③過去 3 年の障害件数推移。この 3 つが期日と数字で揃えば、経営は無視できません。さらに「判断を 1 年遅らせるコスト」を試算して提示すると、議題化のスピードが上がります。

Q3. 棚卸し結果の数字が悪すぎて経営に出しづらい場合は

A. 隠さず出します。むしろ「悪いほど稟議が通る」場面が多く、経営にとって「やばい」が定量化されることは投資判断の材料になります。重要なのは「悪い数字 + 推奨アクション + 判断期限」をセットで出すこと。問題提起だけだと経営が動けません。

Q4. アセスメント結果を社内稟議に使うコツは

A. 役員別アングルで資料を分けます。CFO 用に TCO / NPV、COO 用に業務影響、CIO / 情シス役員用に技術詳細、CHRO 用に人材リスク。1 ページサマリは共通、詳細はアペンディクスで役員別に。経営会議で「全員が違う角度から納得する」状態を作るのが稟議突破の決定要因です。

Q5. 棚卸しに 3 ヶ月もかかると、その間に経営の関心が冷めないか

A. 中間報告を 1 ヶ月後に必ず入れます。Step 1（文書精査）が終わった時点で「現状サマリ + 暫定リスク 3 行」を 1 枚で経営に出します。中間報告で議題化しておけば、3 ヶ月後の本報告までに経営側でも検討が進み、意思決定スピードが上がります。

Q6. 棚卸しを SI ベンダーに委託する場合、ベンダー選定のポイントは

A. 3 つあります。①静的解析ツールの実績（自社開発か商用ツールか、対応言語）、②同規模 / 同業種の実績、③刷新本体は別ベンダーで進める前提を契約段階で明示。棚卸しと刷新を同じベンダーに任せると、結論が「自社サービスへの誘導」に寄りがちです。棚卸しは中立性を担保する設計が望ましい構成です。

Q7. 静的解析の精度はどれくらい信頼できるか

A. コード規模、デッドコード、循環的複雑度などの定量項目は 90% 以上の精度で計測できます。ただし「業務的に重要かどうか」は静的解析だけでは判定できないため、Step 2（ヒアリング）と組み合わせて初めて意思決定に使える粒度になります。ツール出力を鵜呑みにせず、業務文脈で重み付けする運用が必要です。

Q8. 棚卸し後、すぐに刷新着手すべきか、別案件と並行検討すべきか

A. 棚卸し結果を踏まえた「ベンダー RFP」「PoC（概念実証）」を 3〜6 ヶ月かけて行うのが標準です。棚卸し → 刷新着手の間に PoC を挟むことで、見積もり精度がさらに上がり、移行リスクの見極めができます。緊急度が高い（保守期限まで 12 ヶ月以内など）場合のみ、棚卸しと並行で RFP を始める判断もあり得ます。

棚卸しから刷新まで GXO に相談する

メインフレーム / 基幹系の棚卸しから 4R 戦略策定、PoC、本格刷新までを伴走します。中堅企業（1,000〜3,000 名規模）の実績ベースで、棚卸しテンプレ・経営報告資料・ベンダー選定の中立アドバイザリーまで提供可能です。

棚卸しテンプレートの無料 DL：メインフレーム棚卸しアセスメントテンプレート
個別相談（無料）：GXO に相談する

参考資料

経済産業省「DX レポート〜 IT システム『2025 年の崖』克服と DX の本格的な展開〜」（2018 年 9 月）
経済産業省「DX レポート 2.2（概要）」（2022 年 7 月）
IPA（情報処理推進機構）「DX 白書 2026」
IPA「アセスメントツール」公開版
JUAS（日本情報システム・ユーザー協会）「企業 IT 動向調査 2026」
IDC Japan「国内エンタープライズインフラストラクチャ市場 2026 年予測」
日本商工会議所「中小企業 IT 利活用実態調査」（2026 年 1 月）

*本記事の試算 / 費用感は 2026 年 4 月時点の公開データおよび一般的な中堅企業（従業員 1,000〜3,000 名規模）の実務感覚に基づきます。実際の棚卸し / 刷新費用は、システム規模 / 業界 / 既存ベンダー契約条件によって変動します。個別の見積もりは GXO お問い合わせフォームより承ります。*

目次