資産評価レポート（未来明るく電力・領域A〜D）

プロジェクト名: 未来明るく電力 基幹システム 資産評価 PoC（レガシー資産の死活棚卸し） 対象: 領域A（料金・顧客情報 CIS）／領域B（送配電設備管理）／領域C（需給運用・給電）／領域D（電力取引・託送）／共通基盤 評価時点: 2026年7月4日（資産評価PoC）／証拠期間: 2026年4〜5月の実行ログ 作成: dele

目次

はじめに — 本レポートの読み方

本文に入る前に、「この調査で何をしたのか」「どの範囲を見たのか」「判定表記の意味」を先に押さえておく。ここを読んでおけば、本文の数字や判断がどこから来たのか、迷わず読み進められる。

本調査（PoC）で行ったこと — 3行で

本調査は、本格的なシステム刷新に着手する前の実証調査（PoC: Proof of Concept）である。deleが行ったことは次の3つに要約できる。

1. 未来明るく電力の基幹システムから、ソースコード一式・依存関係の手がかり(ソース/バッチ定義)・2026年4〜5月の実行ログ・機能仕様書をお預かりした
2. それらを手がかりに、dele社内に「本番に触れない分身環境」を再現し、提供されなかった情報はAIで依存グラフ上に復元・補完した
3. その分身の上で、**「何が動いていて、何が休眠し、何が死んでいると推定されるか」**を、プログラム1本ずつ証拠に基づいて採点・可視化した

つまり本レポートの数字は、ヒアリングの集計や机上の空論ではなく、実物のコードと実行ログを突き合わせて確かめた観測値と、それに基づく推定である。

判定表記について — 「推定」の意味

本レポートおよび本サイトのプログラム死活判定（現役・休眠・死亡）は、すべて 2026年7月4日時点の推定 であり、「推定現役 / 推定休眠 / 推定死亡」と表記する。この表記には次の意図がある。

• 判定の根拠は、ご提供いただいた資料（ソースコード・依存の痕跡・2026年4〜5月の実行ログ・機能仕様書）の範囲内の証拠である。実際の本番環境での稼働の確証を得たものではない
• 例えば「直近2ヶ月の実行ログに登場しない」ことは休眠の強い証拠だが、年次処理・制度改正時のみ動く処理・災害時にしか起動しない縮退運用系が観測期間外に動く可能性は排除できない
• とりわけ電力事業では、年1回の料金改定バッチ・容量市場の年間約定処理・数年に一度の制度対応処理など、稼働頻度が極端に低いが「止めてはいけない」プログラムが存在する。これらを機械的に休眠・死亡と断ずることはしない

今後は、(1) 実行ログの継続観測と (2) 現場確認(段階的停止と影響観察) の両輪で、この推定を確証に近づけていく（第6章 次フェーズ計画を参照）。判定が更新された場合は、本サイトのプログラム別分析にも反映する。現場・ログで確認された事実は、推定判定を書き換えず「現場確認」として重ねて表示する。

最小限の用語

本文は、この8語さえ分かれば読み通せる。

数字の読み方

本レポートには「プログラム数」が数え方の違いで複数登場する。混同を避けるため、初出箇所で必ず数え方を明記する。

• 依存グラフ 596本: 呼び出し関係に名前が登場する実体の総数。うちソース提供 397本(66.6%)、呼び出し痕跡から復元 199本(33.4%)
• 死活採点 397本: 実物のソースが提供され、5証拠で採点できた本数。復元199本は「存在・つながり・役割の推定」までにとどまるため、採点対象から除く

以降、単に「採点」と言うときは397本を指す。

エグゼクティブサマリー

レガシーシステムからの脱却は、情報システム部門の技術課題ではない。発送電分離・制度改正・レジリエンス強化が同時進行するいま、事業継続と機動的な制度対応のために経営が直視すべきアジェンダである。

まず、現状認識を正確に示す。

人間の健康に例えるならば、突然死の兆候はないが、健康状態には偏りがあり、生活習慣を見直すべき状態である。今すぐ全系統が止まるわけではないが、放置すべきではない領域が明確に見えている。

確定した数字

今回の資産評価PoCで観測・採点した確定値は次の通り（2026年7月4日時点の推定）。

採点397本のうち、3本に1本弱で稼働の証跡が確認できなかった。これが「約1/3の削減余地」という経営メッセージの技術的な裏付けである。ただし内訳は領域によって大きく異なり(第5章)、削減余地は請求系と基盤に偏在している。

レガシー放置が電力事業にもたらす5つの経営リスク

レガシーシステムの放置がもたらすリスクは、「システムが古くて動かなくなる」というIT部門の問題に留まらない。以下の5つが、事業の持続可能性と制度対応の機動力を静かに、しかし確実に蝕んでいる。

問題は「保守に人や費用をかけること」自体ではない。限られた経営資源が、本来注力すべき制度対応・レジリエンス・DX領域ではなく、局所的なレガシー維持に固定化されている——これが本質的な経営課題である。

経営メッセージ — どこは生きていて、どこに余地があるか

今回の採点を領域別に俯瞰すると、未来明るく電力の資産はくっきりと2つに分かれる。

• 止められない領域は健全: 需給運用・給電(領域C)の推定非稼働率は1.9%。24時間365日の系統運用・給電指令を担うミッションクリティカル領域は、ほぼ全プログラムが現役で、無駄がほとんどない。ここは「守る・堅牢化する」対象であり、削減対象ではない
• 請求系と基盤に余地が偏在: 料金・顧客情報(領域A CIS)は41.6%、共通基盤は**42.5%**が非稼働。制度改正のたびに得意分野別・料金メニュー別にプログラムを増築してきた結果、使われなくなった資産が「誰も止めていない」まま残っている

止められない領域(需給・給電)はちゃんと生きている。一方、レガシー請求系と塩漬け基盤に全体の約1/3の削減余地。ここから安全に切る。

本レポートのストーリー

1. 直ちに全系統が壊れる兆候はない
2. しかし、資産の健康状態には偏りがある
3. 需給・給電(C)は健全。請求系(A)と共通基盤に非稼働資産が集中している
4. その結果、維持コスト・人材固定化・制度対応の遅延という経営課題が生じている
5. 採点397本のうち128本(約1/3)で稼働の証跡が確認できなかった
6. とりわけ推定死亡46本は、根拠が明確で安全に廃止に着手できる
7. deleは、本番に触れない分身環境とAI解析により、これを短期間で可視化した
8. 次フェーズでは他領域(発電・ERP等)へ拡張し、段階的停止・影響観察で安全に切除・整理していく

本レポートの構成

1. 調査の対象範囲

本章の問い: 今回の資産評価は、未来明るく電力のどの範囲を、どの粒度で見たのか。

対象とした4領域＋共通基盤

未来明るく電力の基幹システムのうち、今回は業務の中核である以下の4領域と全社共通基盤を対象とした。発電設備制御・ERP(会計/人事/資材)・情報系(BI/データ基盤)は今回のスコープ外とし、次フェーズ(全社スクリーニング)で扱う。

各領域が扱う代表的なデータ(テーブル)は次の通り。

調査の粒度 — 依存グラフ596本

今回構築した全体地図(依存グラフ)は、呼び出し関係に名前が登場する実体596本で構成される。

• 採点(死活判定)は、実物のあるソース提供397本を対象とした。復元199本は中身が確認できないため、「存在する/どことつながっている/どんな役割か」の推定までにとどめ、死活採点からは除外している
• 依存エッジ389本は、プログラム間の呼び出しとプログラム-テーブル間の読み書きを含む配線の総数である

今回の対象外(次フェーズで扱う)

以下は今回のスコープ外である。全社スクリーニング(第2クール)で、同じ手法を横展開して評価する。

なぜこの範囲から始めたか

領域A〜Dは、発送電分離後の未来明るく電力の「送配電・小売・取引」を支える中核であり、かつメインフレーム時代(COBOL/JCL)からクライアントサーバー時代(VB6/.NET)までのレガシーが層状に堆積している領域である。ここを起点に選ぶことで、(1)最もレガシー債務が重い請求系の実態を把握でき、(2)止められない給電系が本当に健全かを確認でき、(3)確立した手法をそのまま全社へ横展開できる。「まず一番見えていない中核を、証拠つきで見えるようにする」——これが対象選定の意図である。

技術構成の実態 — 層状に積み上がったレガシー

今回対象とした資産の技術構成は、未来明るく電力が制度改正のたびに増改築を重ねてきた歴史をそのまま反映している。世代の異なる技術が層状に積み重なり、それぞれに固有のリスクを抱える。

なお、詳細な言語別のコード規模・世代別の分布は、全社スクリーニング(第2クール)で全領域を横断集計したうえで定量化する。本PoCの主眼は「量」ではなく「どれが生きているか(死活)」の判定にある。

2. 調査手法 — 本番に触れずに棚卸しする

本章の問い: 稼働中の基幹システムに一切触れず・止めずに、どうやって「何が生きているか」を確かめたのか。

deleが行ったことを一言で言えば、「層状に積み上がった数十年分のブラックボックスを、本番に指一本触れずに開けて、中身を並べて見せた」である。手順は次の3ステップ。

Step 1: 本番に触れない「分身環境」を再現する

提供いただいたソースと依存の手がかりだけを頼りに、本番と同じ構造のデータベース・実行環境をdele社内に再構築した。

• 本番系統の運用に影響を与えないよう、dele側に隔離した分身環境を構築。ここでなら「このプログラムを止めたらどうなるか」という実験を、業務リスクゼロで何度でも行える
• 電力の基幹系は24時間365日の給電・検針・託送を止められない。だからこそ本番に触れないことが絶対条件であり、分身環境はそのための土台である

工場に例えるなら、「設計図が一部欠けた数十年物の設備を、図面と部品リストだけから別の場所に組み上げ、動く状態にした」ということである。

Step 2: 欠けた設計図を、AIで依存グラフ上に復元する

提供資産だけでは全体像は見えなかった。

ここで当然の疑問が湧く——「実物が提供されていないのに、なぜ『ある』と分かるのか?」 種明かしはシンプルで、プログラムは互いに『名前』で呼び合っているからである。提供されたソースやバッチ定義には「次に◯◯を実行せよ」「△△を呼び出せ」という命令が無数に書かれている。この「呼び出される側の名前」をAIですべて拾い集めた結果、重複を除いて596本のプログラム名が地図上に現れた。ところが、その名前に対応する実物が提供資産の中に見つかったのは**397本(66.6%)だけ。残る199本(33.4%)は「呼び出し命令に名前は載っているのに、本人がどこにもいない」**状態だった。

deleはここにAIを投入した。

• 提供された全ソースをAIに読み込ませ、「このプログラムは何を読み、何を計算し、どこに書き込むのか」を1本ずつ復元した
• 実物がない199本は、呼び出し元の記述・バッチの実行順序・DBアクセスの痕跡を手がかりに、AIが役割とつながりを推定して依存グラフ上に補完した
• COBOLが参照する共通部品(コピーブック)やDBテーブルの構造も、コード中の定義文・SQL文から再構成した

人手であれば熟練技術者が年単位を要する読解・復元作業を、短期間で完了している。COBOL・VB6を読める要員が枯渇しつつある電力業界において、この「AIによる読解の肩代わり」が本手法の核心である。

Step 3: 実行ログと突き合わせ、5つの証拠で採点する

再現した依存グラフと、2026年4〜5月の実行ログを突き合わせ、全プログラム・全テーブルのつながり(エッジ389本)を「配線図」として可視化した。人間ドックに例えるなら、問診ではなく全身CTスキャンを撮ったということである。

そのうえで、ソース提供397本を1本ずつ5つの証拠で100点満点採点し、点数で推定現役/推定休眠/推定死亡に3分類した。判定は感覚ではなく、証拠に基づく点数である(採点ロジックの詳細は第3章)。

一般的な調査手法との違い

情シスが影響範囲を見通せない3種類の「見えない依存」

依存グラフを再構成する過程で、ソースコードを素直に読むだけでは追えない「隠れた依存」が3種類あることが確認された。これらを可視化できたことが、死活判定の精度を支えている。

これらは「ソースにCALLが書かれていない」ため、静的解析だけでは途切れて見える。deleはバッチ/JCL定義とDBアクセスの痕跡を突き合わせることで、この途切れを補完した。推定死亡の判定で「孤立」を主張するには、この3種類の見えない依存をすべて潰したうえで、なお誰ともつながっていないことを確認する必要がある。孤立判定の確度は、この補完作業の徹底度に依存する。

解析で見つかった象徴的な例

料金計算(RY)系のあるCOBOLプログラム(数百行)をAIで解析したところ、その処理の正体は、月次の料金明細ワークを全件ループしながら1件ずつ集計・更新するだけの内容であり、現代の技術なら1本のSQLに置き換えられることが判明した。20年以上前の技術制約の中で数百行を費やして書かれた処理が、今では数行で済む。

この種の「実は簡単に置き換えられる資産」がレガシー請求系に多数眠っている。これは(a)モダナイズのコストが従来見積より大幅に小さくなりうること、(b)COBOL要員に依存せずAIの助けで読解・変換できることを示唆する。「全面書き換えに数年」という前提そのものが、AI解析によって崩れる——次フェーズのモダナイズ方針の根拠の一つである。

提供資産のカバレッジ分析

依存グラフ596本のうち、実物のソースが提供されたのは397本(66.6%)。残る199本(33.4%)は、呼び出しの記述に名前が登場するのに実物が見つからない。この199本は、次の手がかりから役割とつながりを推定して地図上に補完した。

• 呼び出し元の記述: どのプログラムから、どんな引数・文脈で呼ばれているか
• バッチ/JCLの実行順序: どのジョブ列の、どの位置で起動されるか
• DBアクセスの痕跡: 呼び出し前後で読み書きされるテーブルから、役割を推定

この「名前は残っているが実物がない」状態は、構成管理(正本の一元化)の不在の直接の証拠である。全社スクリーニングで対象を広げれば、同様に実物の所在が分からない資産がさらに現れる可能性が高い(第6章 提言2)。

従来の全面書き換えとの違い

レガシー刷新というと「全面書き換え」を思い浮かべがちだが、deleのアプローチは前提が異なる。

要点は、**「残すものだけを、必要なものだけ改善する」**という順序である。まず死んでいる資産を切り、次に残すと決めたものだけをAIの助けで高速にモダナイズする。COBOL要員の枯渇が進む電力業界では、この「AIが読解を肩代わりする」ことが、モダナイズを現実的なコスト・期間に収める鍵となる。

本手法の限界と、その手当て

正直に書いておくべき限界が3つある。いずれも「知らないまま進める」のではなく、手当てを設計済みである。

3. 死活推定の採点ロジック — 5つの証拠・100点満点

本章の問い: 「生きている/休眠している/死んでいる」を、何を根拠に、どう判定したのか。

判定は感覚ではない。プログラム1本ごとに、5つの証拠を集めて100点満点で採点し、点数で3分類する。すべて2026年7月4日時点の推定であり、稼働の確証ではない。

5つの証拠と配点

証拠1(実データの動き)と証拠2(つながり)に配点を厚くしているのは、「実際にデータが動いていて、かつ他とつながっている」ことが、稼働の最も強い証拠だからである。逆に、この2つがともに欠けるプログラムは、死亡の疑いが濃い。

各証拠の見方をもう少し具体的に示す。

判定の閾値

採点の例(illustration)

採点がどう働くかを、代表的な例で示す(プログラム名は本サイトの表記に合わせた架空名)。

• RY0142(料金計算・従量本計算) — 読み書きするRYOKIN・KENSHINに直近2ヶ月で実データが動き、収納(SU)・帳票(CH)から呼ばれ、月次JCLに登録済み。推定現役(92点)
• KNB210(旧検針取込・特定料金メニュー向け) — つながりは残るが、実行ログに一度も登場せず、読み書きの実データも動いていない。スマートメーター移行で役割を終えた疑い。推定休眠(34点)
• SB330S(設備台帳・旧様式変換) — どのテーブルも読み書きせず、誰からも呼ばれず、実行契機もない。同名の新版が別フォルダに存在する重複旧版。推定死亡(11点)

このように、同じサブシステムの中でも1本ずつ点数が違う。だからこそ「領域まるごと残す/切る」ではなく、「この1本は切れる、この1本は残す」という粒度の経営判断が可能になる。プログラム1本ごとの採点内訳はプログラム別分析で確認できる。

採点の内訳がどう積み上がるかを、上記3例の証拠別スコアで示す(illustration)。

注目すべきは、SB330S(死亡)が仕様書だけは7点取っている点である。「仕様書は残っているのに、実物は動いていない」——これは重複旧版に典型的なパターンで、文書だけを見ると生きているように誤認しやすい。5証拠を合算するからこそ、文書の存在に惑わされず死活を見抜ける。

4. 結果 — 全体分布と非稼働率

本章の問い: 採点397本は、全体としてどういう状態だったか。

全体分布

• 推定非稼働率 = 32.2%(推定休眠82＋推定死亡46＝128本 / 397本)
• 言い換えると、採点した3本に2本は現役だが、残り1本は稼働の証跡が確認できない

非稼働は領域によって偏在している

重要なのは、この32.2%が全領域に均等に散らばっているわけではないという点である。

• 給電系(領域C)はほぼ全部が現役(非稼働率1.9%)。止められない領域は、無駄なく生きている
• 請求系(領域A CIS)と共通基盤に非稼働が集中(それぞれ41.6%・42.5%)

つまり削減余地は「請求系と基盤」に偏っている。切るべき場所と、守るべき場所が、データではっきり分かれている——これが今回の最大の発見である。領域別の詳細は第5章で述べる。

主要ハブ — 変更影響が集中する結節点

依存グラフ上で、多くのプログラムから読み書きされる「ハブ」を特定した。これらは変更時の影響範囲が広く、モダナイズの際に慎重な扱いを要する。

ハブへの変更影響は影響シミュレーションで対話的に確認できる。

処理パターンの分類

採点397本を処理の型で分類すると、レガシー請求系に典型的な5つのパターンに大別できる。パターンごとに削減・統合のアプローチが異なる。

推定死亡・休眠は、とりわけ**パターンA(得意分野別に増殖した取込・変換)とパターンD(旧様式帳票)**に集中している。これは「制度・料金メニュー・様式が変わるたびに新規プログラムを増築し、旧版を止めずに残してきた」というレガシー請求系の増殖メカニズムを、データが裏付けている。

「見えていなかった」ことの定量化

今回の可視化で初めて数字になった「見えなさ」を整理する。

3本に1本が「実物の所在不明」、3本に1本弱が「稼働証跡なし」——この二重の不可視が、制度対応の遅延と維持コスト高止まりの正体である。可視化はその第一歩にすぎないが、出発点なしには何も動かせない。

4-1. 推定死亡・推定休眠の内訳と根拠パターン

推定死亡46本・推定休眠82本が「なぜそう判定されたか」を、根拠のパターン別に整理する。判定は単一の理由ではなく、複数の証拠が同時に欠けていることで確定している。

推定死亡(46本)の代表的な根拠パターン

推定死亡46本は、上記のうち複数のパターンに同時に該当するものが大半である(例: 孤立かつ実行ログ無ヒット)。根拠が重層的なため、廃止の確度が高い。ただし前述の通り、廃止は段階的停止＋影響観察で進める。

代表的な推定死亡の例を、根拠パターンとともに示す(プログラム名は本サイト表記に合わせた架空名)。

いずれも「作られたが、役割を終えた後も誰も止めていない」構造である。廃止によって失われる価値はなく、維持コストと依存グラフの複雑さだけが残っている——これが推定死亡の共通像である。

推定休眠(82本)の代表的な根拠パターン

推定休眠は「止めていいか判断できないから全部維持」という状態の温床である。維持コストは払い続けているのに、価値を生んでいるかが不明——ここに整理の余地がある。休眠判定の確度を上げるには、実行ログの継続観測(観測期間の延長)が最も効く。

推定死亡・推定休眠の廃止・整理の進め方

1. プログラムの利用状態を分類する(完了 — 本PoC。推定として)
2. 推定死亡46本を優先candidateとして整理する(完了 — 本PoC)
3. 推定死亡から段階的停止＋影響観察で廃止に着手する(次フェーズ)
4. 推定休眠82本は実行ログの継続観測・現場確認で確度を高めてから段階的に整理する(次フェーズ)

推定死亡・休眠・重複を横断した削減候補の一覧とCSV出力は削減候補リストを参照。

5. 領域別の評価

本章の問い: どの領域に、どれだけの削減余地があるのか。守るべきはどこか。

領域別サマリー

採点397本を領域別に見ると、非稼働率は1.9%〜42.5%と20倍以上の開きがある。削減余地は請求系(A)と共通基盤に偏在し、給電系(C)は健全である。

以下、領域ごとに所見を述べる。

領域A — 料金・顧客情報(CIS): 非稼働率41.6%

最も削減余地が大きい領域。検針(KN)→料金計算(RY)→収納・消込(SU)→請求(帳票CH)の一連を担う、未来明るく電力の請求系の心臓部であり、同時に最もレガシー債務が重い。

領域Aは「削減余地が最大」であると同時に「制度対応の俊敏性を最も損なっている」領域でもある。ここを整理・近代化することが、料金改定対応のリードタイム短縮に直結する。

サブシステム別に見ると、非稼働の偏りと処置方針は次のように整理できる。

To-Beの方向性: 得意分野別・料金メニュー別に増殖した取込・計算処理を、定義駆動の統合基盤へ集約する。料金改定を「プログラム新規開発」から「定義ファイルの追加・変更」に変えることで、制度対応のリードタイムを大幅に短縮できる。ただし料金計算・収納の中核は停止リスクが高いため、並行稼働・差分検証で慎重に進める。

領域B — 送配電設備管理: 非稼働率35.7%

設備台帳(SB)・工事管理(KJ)・保全計画(HZ)・図面/GIS(GS)・停電管理(TD)を担う。設備の長寿命に合わせてシステムも長期運用され、旧様式変換の残置が多い。

サブシステム別の傾向は次の通り。

To-Beの方向性: 設備の長寿命に合わせ、台帳・GISは「長く正確に保つ」ことが最優先。旧様式変換の残骸(Retire)を除去して見通しを良くしつつ、停電管理(TD)は災害対応の観点で監視・冗長化を強化する。

領域C — 需給運用・給電: 非稼働率1.9%(健全)

需給計画(JK)・給電指令(KD)・系統運用(KT)・予備力管理(YB)を担う、24時間365日止められないミッションクリティカル領域。

**「止められない領域はちゃんと生きている」**という経営メッセージの、そのものの証拠がこの1.9%である。削減の話をここに持ち込む必要はない。

領域D — 電力取引・託送: 非稼働率21.2%

卸電力取引JEPX(TR)・インバランス精算(IB)・託送業務(TS)・スイッチング(SW)・需要予測(YS)を担う。電力自由化・市場制度の整備に合わせて比較的新しく構築された部分が多く、非稼働率は中程度。

共通基盤 — 全社基盤: 非稼働率42.5%(整理効果が全社に波及)

マスタ管理(MS)・帳票基盤(CH)・連携基盤ESB(RN)・認証/権限(NB)・バッチ基盤(BT)を担う。全領域が依存する土台でありながら、非稼働率は最も高い。

サブシステム別の傾向は次の通り。

To-Beの方向性: 共通基盤は全領域が依存する土台のため、**「周辺の死んだユーティリティから除去し、ハブ本体は包んで守る」**のが定石。マスタ管理のコード体系統一(呼称・供給地点の名寄せ)は、領域をまたいだデータの突合精度を上げ、経営情報の提供速度改善にも波及する。

6. 経営提言と次フェーズ・ロードマップ

本章の問い: この評価結果を受けて、経営として何を、どの順番で実行するか。

処置方針 — 5つの分類(Disposition)

全プログラムを、以下5つの処置方針に振り分けて実行する。「まとめて刷新」ではなく、1本ずつ最適な扱いを選ぶのが要点である。

処置方針の全体像は2軸で粗分類できる。

• 停止リスク高 × 変化頻度高 → Modernize最優先(料金CIS中核)
• 停止リスク高 × 変化頻度低 → Keep/Wrap(給電系・停電管理)
• 停止リスク低 × 変化頻度低 → Retire(推定死亡)
• 停止リスク低 × 変化頻度高 → Refactor→Modernize(共通ユーティリティ)

提言1: 推定死亡46本の廃止に着手する

最も確度が高く、最初に着手すべき施策。

• 対象: 推定死亡46本(孤立・空・重複旧版・実行ログ無ヒットが重なるもの)
• 方式: 即削除ではなく 段階的停止＋影響観察。まず本番からの参照を切り、一定期間問題が出ないことを確認してから廃止確定。問題が出れば即座に戻す
• 効果: 管理対象を確実に圧縮し、依存グラフの見通しを改善。「切れるところから切る」外科手術の初手
• 優先順位: 共通基盤・料金CISの推定死亡から(整理効果が全社に波及し、かつ停止リスクが低い)

提言2: 構成管理(正本の一元化)を導入する

復元199本(全体の1/3)が「実物のありかが分からない」状態であることは、制度対応の俊敏性を直接損なう根本課題である。

• 対象: 本番稼働バイナリと提供ソースの照合による正本確定、バージョン管理(Git等)の導入、物理ディレクトリ退避による重複旧版のアーカイブ化
• 効果: 「本番で動いているのはどれか」に即答できる状態を作る。制度改正時に「まずソース探しから」という無駄を解消
• 位置づけ: 廃止・モダナイズの前提整備。これがないと「残すと決めたもの」の改修すら安全に始められない

提言1の実行手順(Phase 0)

推定死亡の廃止は、リスクを抑えるため次の順で進める。

1. 対象確定: 推定死亡46本のうち、共通基盤・料金CISの「孤立＋実行ログ無ヒット＋重複旧版」が重なるものを最初のバッチとして選ぶ(停止リスク最小)
2. 見えない依存の再確認: ファイル経由・共有テーブル・Shell/JCL経由の3種類の隠れた依存を再点検し、本当に誰ともつながっていないことを確認
3. 参照の切り離し: 本番からの起動・参照を停止(削除ではなく無効化)
4. 影響観察: 一定期間(月次処理を1〜2サイクル含む)、業務・後続処理に問題が出ないか観察
5. 廃止確定 or 復帰: 問題がなければ廃止確定・アーカイブ化。問題が出れば即座に復帰し、休眠へ再分類

この「段階的停止＋影響観察」は、電力の基幹系で絶対に必要な安全弁である。判定を過信せず、いつでも戻せる状態を保ったまま切る。

提言3: 全社スクリーニング(第2クール)を実行する

今回の手法(分身環境・依存グラフ・5証拠採点)は、そのまま他領域に向けられる「全身スキャナー」として完成している。

• 対象: 今回スコープ外とした発電設備制御・ERP・情報系・次世代検針基盤内部
• 進め方: 全領域を広く簡易採点(血液検査相当)し、削減余地とリスクを「ヒートマップ」で可視化。異常が出た領域を精密採点(A〜D同等)する2段階アプローチ
• 効果: 領域A〜Dで確立した装置を再利用するため、2回目以降はより短期・低コスト・高精度で進む。全社の削減余地を経営が一望できる

ヒートマップは領域ヒートマップ、全社の把握状況は全社システム資産マップで継続的に更新する。

次フェーズの進め方 — 安全に解体し、置き換える

現行システムを一括置換するのではなく、領域単位で切り出し、旧環境と新環境を並行稼働させながら出力の一致を検証する段階的移行を基本とする。電力の基幹系は止められないため、この「安全第一」の方式が前提となる。

1. 領域(またはサブシステム)ごとに切り出す
2. 旧環境と新環境を並行稼働させる
3. 入出力結果を比較する(差分検証)
4. 差異を検証し、問題なければ段階的に切り替える(段階移行・安全な切替)
5. 問題が発生した場合は即座に旧環境へ戻す(ロールバック可能)

ロードマップ

処置方針別・領域別の実行計画はロードマップ、制度対応の観点はコンプライアンスで継続的に管理する。

意思決定のタイムライン

経営として「どこから切るか」を決めるための時間軸は次の通り。

評価指標(KPI) — 何を測って進捗を管理するか

削減・整理は「本数を減らすこと」自体が目的ではない。維持コスト・制度対応力・レジリエンスの改善を測る。

主なリスクと対策

レジリエンス — 「切る話」と「守る話」を分ける

本レポートの提言は「削減」に力点があるが、電力事業では**削減と同じ重みで「守る」**を語る必要がある。両者を混同すると、守るべき系統に削減の論理を持ち込む事故が起きる。

とりわけ災害・広域停電時に稼働する縮退運用系や停電管理(TD)は、平常時の実行ログに現れにくい。これらを死活採点だけで判断せず、「災害時にしか動かないが不可欠」という電力特有の性質を織り込んで救済する。レジリエンス投資は削減の逆方向だが、削減で生まれた原資と人材の余裕を、ここに再配分するのが本筋である。

体制