報告と根拠
2026年4〜6月 PoC(手法が使えるかの検証)
公開
2026年4月〜6月に dele が実施した活動の報告です。本格的な調査に投資する前に、「本番システムに一切触れずに、どこまで実態を把握できるか」を確かめる期間でした。分析の結論そのものは 資産評価レポート(2026年7月4日報告)にあります。本ページはその3ヶ月間の活動そのものの記録です。
この3ヶ月の要点
① 手法が成立することを確認しました。 本番に触れず、ご提供資料だけから 596本 のプログラムと 389本 の呼び出し関係を復元できました。 ② 判定の物差しを作りました。 5つの証拠(実データの動き・つながり・実行契機・DB操作数・仕様書)で100点満点の採点方式を定め、397本 に適用しました。 ③ 削減余地の当たりを付けました。 採点済みの 32.2%(128本) に現役の証拠が見つかりませんでした。ただしこれは推定であり、次の期間で現場に当てて確かめる必要があります。
フェーズの現在地
| フェーズ | 期間 | 状態 |
|---|---|---|
| PoC(手法の妥当性検証) | 2026年4〜6月 | 完了 ← この報告の範囲 |
| 限定適用(判定を現場で確かめる) | 2026年7月 | 予定 |
| 本格展開A(全社スクリーニング) | 2026年8〜9月 | 予定 |
| 本格展開B(意思決定と第1次切除) | 2026年10〜12月 | 予定 |
| 実行・定着(モダナイゼーション) | 2027年1月〜 | 予定 |
目次
1. この期間の目的
基幹システムの刷新は、対象が見えないまま始めると必ず膨らみます。一方で「まず全部調べます」と言って数千万円の調査費を先に決めるのも、経営としては呑みにくいものです。
そこで 範囲を領域A〜D + 共通基盤に絞り、手法が成立するかどうかだけを先に確かめることを目的にしました。判断したかったのは次の2点です。
- 本番に触れずに、失われた全体像(どのプログラムが何を呼んでいるか)を復元できるか
- 「このプログラムは今も使われているか」を、人の記憶ではなく証拠で言えるか
2. やったこと
| 時期 | 活動 |
|---|---|
| 4月 | 資料の受領・棚卸し(ソースコード・DB定義・機能仕様書・実行ログ) |
| 4〜5月 | dele 社内に「分身環境」を構築。本番に触れずに動かせる状態を作る |
| 5月 | 依存グラフの復元。呼び出し痕跡から、資料に無いプログラムも名前で拾い上げる |
| 5〜6月 | 死活推定の採点ロジックを設計・適用 |
| 6月 | 領域ごとの評価と、経営への提言の組み立て |
| 7月4日 | 資産評価レポート として報告 |
数字で見た成果は次のとおりです。
- 棚卸ししたプログラム: 596本(呼び出し関係 389本 のエッジとして復元)
- 死活の推定判定: 397本(推定現役 269 / 推定休眠 82 / 推定死亡 46)
- 収集した機能仕様書: 246点
- 証拠期間: 2026年4〜5月の実行ログ
3. 分かったこと
- 削減余地は約1/3です。 採点済み397本のうち128本(32.2%)に現役の証拠が見つかりませんでした。
- 止められない領域は健全でした。 需給運用・給電(領域C)は推定現役の比率が高く、削減ではなく堅牢化の対象です。削減余地は古い請求系と、使われないまま保守費だけ払っている共通基盤に集中していました。
- 199本は判定できていません。 名称と呼び出し痕跡から存在は分かるものの、実ソースが未提供のプログラムが199本あります。今回の提供範囲外にあるのか、正本・所在が管理できていないのかを、次の期間で照合します。
領域ごとの内訳は 全社システム資産マップ、プログラム1本ごとの判定根拠は プログラム別分析 で確認できます。
4. 手法の評価と積み残し
この時点で言えること・言えないこと
言えるのは「証拠が見つからなかった」までで、「使われていない」ではありません。実行ログは2ヶ月分、DBデータは断面1回分です。月次・年次でしか動かない処理は、この期間には記録として表れません。推定を現場に当てて確かめる工程が必ず要る、というのがこの期間の最大の学びです。
積み残しは3つです。
- 推定と現場感覚のズレを測っていない(→ 限定適用へ)
- ソース未提供199本の正本・所在が未照合(→ 構成管理の確認へ)
- 対象が基幹5領域に限られており、発電・ERP等は手つかず(→ 本格展開Aへ)
5. 次の期間へ
7月は、この推定を現場に当てて確かめることと、判断に使える形で全社に配ることに充てます。続きは 2026年7月の活動報告 をご覧ください。