この記事では、仕様書がなく、中身が分からない基幹をどう見直すか知りたい企業に向けて、判断すべきポイントを実務目線で整理します。マクティズムでは、いきなり作り直すのではなく、延命・部分改善・パッケージ活用・周辺開発・スクラッチ再構築のどれが現実的かを、現行業務と帳票・データから確認することが重要だと考えています。
この記事で分かること
- 仕様書がなくても画面と帳票から調査できる
- 業務ヒアリングが重要
- 帳票・バッチ・データを棚卸しする
- 一度に作り直すと危険
- 残すべき操作性を整理する
- 段階導入を検討する
- 社内稟議用資料を作る
まず結論
結論として、ブラックボックス化した基幹システムを再構築する進め方で最初に見るべきなのは、システムの古さそのものではなく、業務への影響、保守できる体制、データ量、帳票・連携の複雑さ、今後の変更予定です。まだ動いているから大丈夫と考えがちですが、保守期限や担当者退職、パッケージ不適合が見えている場合は、検討開始が遅れるほど選択肢が狭くなります。まずは現状を棚卸しし、作り直す範囲と残す範囲を切り分けることが必要です。
よくある背景・失敗しやすい理由
このテーマで相談が増える背景には、古い基幹システムのブラックボックス化があります。設計書が一部しか残っていない、帳票の意味を説明できる人がいない、サーバーやデータベースの保守期限が近い、パッケージを検討したが標準機能では現場業務が回らない、といった状況です。現場では業務を止めないためにExcelやAccess、CSV加工で補うことが多く、その場しのぎの対応が積み重なるほど、再構築時の調査範囲とリスクが大きくなります。
確認すべきポイント
1. 仕様書がなくても画面と帳票から調査できる
仕様書が残っていなくても、現在使われている画面、入力項目、帳票、CSV、データベースのテーブルなどを確認すれば、システムが担っている機能を一定範囲まで把握できます。特に帳票は、入力された情報がどのように加工され、どの部署や取引先へ渡るかを知る手掛かりになります。
調査では、画面を一覧化するだけでなく、入力元と出力先、利用者、利用頻度、関連する処理を結び付けて整理します。使われていない画面や重複機能も確認し、再構築で残す機能と廃止できる機能を分けることで、不要な再現に費用をかけずに済みます。
2. 業務ヒアリングが重要
システムのソースコードだけを調べても、なぜその処理が必要なのかまでは分からないことがあります。担当者へのヒアリングを通じて、通常の業務手順だけでなく、月末処理、返品、分納、在庫調整などの例外処理も確認することが重要です。
ただし、担当者の記憶だけに頼ると、部署ごとに認識が異なったり、低頻度の業務が漏れたりします。実際の画面や伝票を見ながら聞き取りを行い、回答内容を操作ログや帳票、データと照合すると、現行業務をより正確に把握できます。
3. 帳票・バッチ・データを棚卸しする
日中に利用する画面だけでなく、請求締め、在庫更新、データ連携、バックアップなど、夜間や月末に自動実行されるバッチ処理も棚卸しします。担当者から見えにくい処理ほど、停止した場合の影響や他システムとの依存関係を見落としやすいためです。
データについては、件数や容量に加え、必須項目、重複、文字化け、不正値、過去データの参照頻度を確認します。新システムへ移すデータと保管だけするデータを分け、移行前にクレンジング方針を決めておくと、本番切り替え時の手戻りを減らせます。
4. 一度に作り直すと危険
ブラックボックス化したシステムでは、調査を進めるまで機能間の依存関係が見えないことがあります。その状態で全機能の一括再構築を計画すると、後から要件が増え、予算超過やスケジュール遅延につながる可能性があります。
まず止められない業務と影響範囲の小さい業務を分け、優先度の高い領域から検証するのが現実的です。試験移行や並行稼働の期間を確保し、旧システムへ戻す条件も決めておけば、切り替え時の事業リスクを抑えられます。
5. 残すべき操作性を整理する
古い画面をそのまま再現する必要はありませんが、入力順序、一覧表示、検索条件、キーボード操作などが現場の処理速度を支えている場合があります。特に受注入力や出荷処理のように件数が多い業務では、操作数の増加が日々の負担に直結します。
現場が慣れているという理由だけで残すのではなく、作業時間、入力ミス、教育コストへの影響を確認してください。改善すべき不便さと、業務効率のために維持すべき操作性を分け、試作画面を現場担当者に評価してもらうことが有効です。
6. 段階導入を検討する
販売、在庫、請求、生産などを業務単位で分けて導入すると、一度に発生する教育やデータ移行の負担を抑えられます。先行導入した範囲で問題を洗い出し、その結果を次の工程へ反映できる点も段階導入の利点です。
一方、移行期間中は新旧システム間のデータ連携や二重入力が必要になる場合があります。どのシステムのデータを正とするか、連携エラーを誰が確認するか、旧システムをいつ停止するかまで計画に含める必要があります。
7. 社内稟議用資料を作る
再構築の必要性は、システムが古いという説明だけでは経営側に伝わりにくいことがあります。障害時の停止範囲、保守担当者の不足、サポート終了時期、手作業の工数などを数値や事実で示し、対応しない場合のリスクを明確にします。
稟議資料には、延命、部分改修、パッケージ導入、スクラッチ再構築などの選択肢を並べ、概算費用、期間、効果、移行リスクを比較して記載します。段階導入を行う場合は、各段階の対象範囲と判断時期も示すと、投資の妥当性を説明しやすくなります。
自社で整理できること・外部に相談すべきこと
社内でまず整理できるのは、業務範囲、画面、帳票、困っている作業、保守期限、利用部署、関連するExcel・Access・CSVです。一方で、影響範囲が複数部門にまたがる、データ移行や外部連携が絡む、パッケージ比較が必要な場合は、外部の開発会社と一緒に現状整理した方が安全です。
社内で棚卸しを行う際は、資料の完成度を上げることよりも、分からない点を明示することを優先してください。「担当者が不明」「処理の目的を説明できない」「停止時の影響が分からない」といった情報も、現行調査の優先順位を決める重要な材料になります。
外部へ相談する場合は、単に新システムの見積もりを依頼するのではなく、現状調査の範囲、成果物、再構築の判断基準を確認します。調査結果として画面・帳票・連携の一覧や課題、概算費用、移行順序が整理されれば、複数案の比較や社内合意にも活用できます。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 軽微な不具合・一部帳票の変更 | 延命・保守・部分改修 | 本体再構築の前に影響範囲を確認 |
| データ量増加・動作遅延・バックアップ不安 | DB改善・性能改善 | 根本的な業務課題が残らないか確認 |
| パッケージ標準で業務が合う | パッケージ導入 | 帳票・例外処理・データ連携を事前確認 |
| パッケージで足りない機能が明確 | パッケージ＋周辺開発 | 責任範囲と連携仕様を明確にする |
| 独自業務・例外処理が多い | スクラッチ再構築 | 要件整理と段階導入が重要 |
| 判断が難しい | 開発前診断・刷新ロードマップ | 社内稟議や他社比較に使える資料化を行う |
相談前に準備しておく情報
相談前にすべての資料を揃える必要はありません。ただし、現行システム概要／利用部署・人数／画面一覧／帳票一覧／データ項目／外部連携／保守期限／困っている業務／パッケージ検討状況／想定予算・時期 などが分かると、初回相談の精度が上がります。
マクティズムの見解
マクティズムでは、ブラックボックス化した基幹システムを再構築する場合、最初から現行機能をすべて作り直す前提にしないことが重要だと考えています。まず業務、画面、帳票、バッチ、データ、外部連携を調査し、現在も必要な機能と、慣習として残っているだけの機能を分けます。
現行調査では、ソースコードやデータベースの解析だけでなく、現場で使われているExcel、Access、CSV、紙の帳票も確認します。システム外の手作業には、既存機能の不足や例外業務が表れていることが多く、そこを把握しないまま再構築すると、新しいシステムでも同じ非効率が残るためです。
また、再構築方法はスクラッチ開発だけではありません。現行システムを一定期間延命しながら一部を改善する方法、標準業務をパッケージへ移す方法、独自業務だけを周辺システムで補う方法もあります。業務への適合度、費用、期間、保守性、データ移行の難易度を同じ基準で比較する必要があります。
特に重要なのは、ブラックボックスをそのまま新しい技術へ置き換えないことです。現行仕様を無条件に再現すると、不要な処理や複雑な例外まで引き継ぎ、再び保守しにくいシステムになるおそれがあります。再構築を業務整理の機会と捉え、標準化できる部分、独自性として残す部分、廃止する部分を関係者間で合意します。
規模が大きい場合は、優先順位を付けた段階導入が現実的です。業務を止めない移行順序、試験方法、並行稼働、障害時の切り戻しまで含むロードマップを作成し、各段階で効果とリスクを確認します。マクティズムは、現行調査の結果を根拠に、延命と再構築の境界を明らかにすることが、失敗を避ける第一歩だと考えています。
よくある質問
中身を分かる人が社内にいなくても大丈夫ですか？
はい。関係者ヒアリング、画面・帳票・データ確認から現行調査を進められます。
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
