システムが「業務の記憶」を引き取ったとき——レガシー刷新の前に問うべきこと

システムは業務の鏡として始まる。受注の流れ、請求の条件、例外処理の扱い——最初は必ず、業務ルールを反映してシステムが設計される。

しかし10年、20年と改修を重ねるうちに、その関係は逆転する。「なぜこの処理があるのか」という理由は口頭の記憶の中に溶け込み、担当者の交代とともに薄れていく。気づけばシステムが先にあり、業務はシステムの動きに合わせて語られるようになる。

システムが「業務の記憶」を引き受けていく過程

問題はそこから先だ。刷新を検討したとき、ベンダーは「要件定義書をください」と求める。しかし発注側が出せるのは「今のシステムと同じように動かしてほしい」という一言だけだ。この会話が成立した瞬間、プロジェクトは静かに行き詰まり始める。

改修のたびにシステムは更新されるが、「なぜ」は更新されない。その知識を持っていた担当者がすでにいない、あるいは「昔からそうだったから」としか答えられない状況は、怠慢ではなく構造的な結果だ。システムは、失われた業務知識の唯一の証跡として残り続ける。

「説明できない」が引き起こす実務上の詰まり方

刷新プロジェクトが停滞する原因として、予算不足や技術選定の難しさが挙げられることは多い。だが現場で見えてくるのは、もっと手前の詰まりだ。

• 要件定義のヒアリングで担当者が「システムがそうなっているから」としか答えられない
• 例外処理の意図を誰も知らないため、新システムにもそのまま転記しようとする
• 「変えていい部分」と「変えてはいけない部分」の区別がつかず、スコープが固まらない
• 結果として見積もりが出ず、稟議が通らず、プロジェクトが先送りになる

これは、カンやコツに依存した業務が生む構造的なリスクと同じ問題の別の顔だ（引き継げない業務が、会社をもろくする）。知識が人の頭の中にある間は問題が見えない。しかしその人が替わったとき、知識はシステムの動作の中にしか残っていない。

「今のシステムで動いているから、これが正しい業務だ」——この言葉が出てきたとき、業務の可視化が必要なサインである。

刷新の前に、何をやり直すか

システムを刷新する前に取り戻すべきものは、業務の言語だ。具体的には次の手順で進める。

1. 現行システムを「業務の手がかり」として読む　画面遷移、帳票の項目、条件分岐の一覧を作る。これはシステム仕様を理解するためではなく、「なぜ存在するのか」を問うための素材を揃えるためだ。
2. 現場と一緒に「なぜ」を掘り起こす　一覧を持って現場に入り、「この処理はどんなとき使うか」「例外はどういう条件で起きるか」を問い直す。答えが出ない項目が、ブラックボックスの地図になる。
3. 口頭のルールを書き起こす　取引先との慣行、元担当者が決めたルール、誰かのメモに残った例外。これらを一つずつ文書に落とす。

この作業は「刷新のための準備」ではなく、「業務そのものの再記述」だ。業務フロー図がない会社がDXの成果を出しにくいのは、まさにこの再記述が欠けているからに他ならない。

可視化が終わったとき、初めて「変えてよい部分」と「守るべき部分」の境界線が引ける。刷新の本当のスタートラインは、そこにある。システムを変える前に、業務を取り戻す——その順番を間違えると、新しいシステムは古い問題を引き継いだまま走り始める。

---

どこから手をつけるか迷う場合は、しぼる（DX伴走支援）で伴走の進め方をご覧ください。