第1章仕様を答えられない状態から、復元すべき情報を決める

廃止できないシステムで、仕様の問い合わせに答えられない

担当したのは、約20年前に当社の中心的なソフトウェアとして開発された、多機能なシステムだった。独自の機能を長年使う利用者・愛用者が多く、終了を検討したことはあっても、単純には廃止できなかった。

担当して間もなく、社内から仕様について問い合わせを受けた。

既存仕様書には画面、ボタン、操作手順の説明があったが、内部構造や処理フローはほとんど書かれていない。古い記述も更新されておらず、その日のうちに資料だけで明確な回答をすることはできなかった。

結局、ソフトウェアを実際に動かして挙動を確認する必要があった。現在の担当者も詳細を把握できず、長期間担当している委託作業者だけが知る情報もあった。仕様書が存在していても、現行仕様へ到達できる状態ではなかった。

内部仕様が社内で共有されていないため、小さな調査や軽微な変更も委託へ依存していた。人件費の高騰もあり、委託費削減は部門の課題だったが、問題は費用だけではない。社員の調査・理解にかかる時間や、意思決定の遅れも積み重なっていた。

既存仕様書を整形し直すだけでは、欠けている処理や背景は埋まらない。

ソースコードを確認の起点とし、UI、実動作、既存資料、担当者の知識を合わせて、現在の仕様と構造を再構成することにした。

古い資料は調査材料として使い、記載があることだけを正しさの根拠にはしなかった。

新規開発や全面刷新を先に進めても、何を維持し、何を変えるかを説明するには現行システムの理解が必要になる。

そこで、まず調査結果を他の人も参照できる形に残し、仕様の確認や変更の検討へ再利用することを優先した。

目標は、委託費だけでなく、社員の調査・理解・判断にかかる工数を減らすことだった。単に仕様を抽出するのではなく、必要な情報を探し、根拠を確認できる状態を作る。

次章では、そのために何を把握する必要があったかを、対象システムの構造から整理する。