現行と同じ機能で作り直したい企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、同じものを作る前に、不要機能と現場独自運用を整理することを重視して進め方を整理します。
この記事では、現行と同じ機能で基幹システムを作り直す「現行踏襲」方式を選ぶ際の注意点を整理します。業務は変えずにシステムだけ新しくしたいと考えている企業の担当者・経営者に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
「同じものを作る」は最も見積が甘くなりやすい
現行踏襲は一見シンプルに見えますが、実際には最も見積が狂いやすい方式です。理由は、現行システムの全容を正確に把握している人がいないケースがほとんどだからです。設計書が古い・存在しない、担当者が退職している、暗黙のルールで動いている処理がある。こうした「隠れた仕様」が開発中に次々と発掘され、追加工数として費用を押し上げます。同じものを作るなら簡単なはずだという期待と、実態との落差が大きいほど、プロジェクトは苦しくなります。
同じものを作る前に「本当に全部必要か」を問う
現行踏襲の最大の問題は、使われていない機能や帳票まで再現してしまうことです。長年のシステムには、過去の担当者が作った一度きりの特殊処理、法改正前のルールで動いている帳票、すでに退職した人しか使わなかった画面が眠っています。これらを忠実に再構築する費用は、純粋な無駄です。作り直す前に「今、誰が、何のために使っているか」を全機能に対して確認する棚卸しを行うことが、現行踏襲の前提条件です。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、現行踏襲だから要件定義は軽くてよいと判断し、調査を省略するケースです。隠れた仕様が開発の中盤〜後半で発覚し、仕様変更の嵐になります。現行踏襲こそ、現行調査に最も時間をかけるべき方式です。
また、「現行と同じ」を合言葉にして業務改善の機会を手放す失敗もあります。非効率な手順、二度手間の入力、不要な承認ステップ。これらを「今と同じ」でそのまま再現すると、費用をかけて非効率を温存することになります。
さらに、旧システムの画面レイアウトをピクセル単位で再現しようとして、新しい技術の利点が活かせなくなるケースもあります。操作性の維持と画面の忠実再現は別の話であり、085番の記事で述べた仕分けが必要です。
自社で確認できるチェックポイント
現行踏襲を選ぶ前に、次の点を確認しておくと、この方式が本当に適切かの判断が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
現行踏襲ならではの棚卸しポイント
基本のチェックリストに加えて、設計書・仕様書の現存状況、現行を知るキーパーソンの在籍状況、画面・帳票・バッチの総数と利用状況（日常・月次・使われていない）、データベースに埋め込まれた処理（ストアド・トリガー）の有無、そして「このシステムで不便だが我慢していること」の一覧を確認してください。不便の一覧が出てくる時点で、純粋な現行踏襲が最適解でない可能性が高まります。
現行踏襲の費用を正しく見積もるには、まず現行の全容を知る調査（リバースエンジニアリング）が必要です。この調査は数百万円の投資になりますが、調査なしの見積は必ず甘くなるため、結果的に調査費用は回収できます。調査の結果「現行踏襲より機能を絞って作り直したほうが安い」という結論になることも珍しくありません。
現行踏襲を選ぶ場合でも、技術基盤（プログラミング言語・データベース・フレームワーク）は新しいものに更新することを強くおすすめします。ロジックは同じでも、保守しやすい技術で書き直すことで、今後の改修のスピードとコストが大きく改善されます。古い技術で踏襲すると、数年後にまた同じ問題に直面します。
テストの計画も現行踏襲ならではの工夫が必要です。「現行と同じ結果が出ること」が合格基準になるため、現行システムの出力結果を事前に保存しておき、新システムの出力と突き合わせるリグレッションテストが中心になります。この準備をテスト直前ではなく、開発開始時から始めておくのが成功の秘訣です。
延命・部分改善で対応できるケース
現行踏襲を全面的に行う前に、次のような折衷案も検討する価値があります。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
「現行踏襲＋棚卸し」——全機能を棚卸しし、使われていない機能を除外して必要な機能だけを再構築する方式は、純粋な現行踏襲より2〜3割安くなることがあります。業務は変えないが不要物は除くという中庸が、最も費用対効果の高い落としどころになるケースは多くあります。
また、中核の業務ロジックは踏襲しつつ、画面や帳票のUI（見た目と操作）は現代的に刷新する「ロジック踏襲・UI刷新」も有力な選択肢です。現場の操作性は向上し、中核の安定性は維持できます。
費用の目安は、小規模な現行踏襲（画面20〜30本）で1,000万〜2,000万円、中規模（画面50〜100本）で3,000万〜5,000万円、それ以上は億単位になることもあります。ただし現行調査で不要機能を3割除外できれば、費用は相応に圧縮されます。調査への投資が最も割のよいコスト削減策です。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
次のような状況では、現行踏襲ではなく別の方式を検討すべきです。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
業務が標準的であれば、現行踏襲でスクラッチを選ぶよりパッケージに業務を寄せるほうが、長期の保守コストを含めた総額が安くなることがあります。現行踏襲とパッケージ移行の5年総額を比較してみてください。
周辺開発で補うケース
現行の中核ロジックは残し、UI・帳票・連携だけを周辺開発で刷新する構成は、現行踏襲の部分適用として現実的です。変えるべきところだけ変える、という判断が可能です。
スクラッチ再構築が向くケース
業務自体を再設計する意志があるなら、現行踏襲ではなく要件定義からやり直すスクラッチ再構築のほうが、長期的には健全な投資です。踏襲の名のもとに非効率を温存することが、最大の無駄だからです。
マクティズムの見解
マクティズムの見解として、現行システムと同じ内容で作り直すときの注意点では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、同じものを作る前に、不要機能と現場独自運用を整理することを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
現行踏襲のご相談で私たちが最初にお伝えするのは、「同じものを作るほうが新しく設計するより簡単だとは限りません」という事実です。隠れた仕様の発掘にかかるコストを正直にお伝えし、棚卸しによる除外で浮く金額も合わせてお示しします。全部残すことも全部変えることも安易であり、一つずつ判断する誠実さが結局いちばん安くつくと考えています。
相談前に準備しておく情報
現行踏襲の相談では、現行の設計書・仕様書の有無、画面・帳票・バッチの概数、現行を知るキーパーソンの有無、不便ながら我慢している点が分かると、初回から方式の適否を具体的に話せます。
実務では、現行調査で全機能の利用実態を棚卸しし、開発前診断で「踏襲・除外・改善」の三分類に仕分けたうえで、現行踏襲＋棚卸し方式と全面再設計方式の費用を比較してご提案する流れをおすすめしています。
棚卸しを経た現行踏襲は、不要物を除くことで新システムが身軽になり、保守費も軽くなるという副次効果があります。再構築の機会は、ぜい肉を落とす機会でもあるのです。
「同じものを新しく」は、正しく実行すれば安定性の高い選択です。ただし「正しく」とは、見えないものを先に見えるようにする調査と、不要なものを勇気を持って手放す棚卸しを、先にやり切ることです。
進め方は、現行調査（リバースエンジニアリング）、機能の棚卸しと三分類、費用の比較、構築方針の確定、の順です。調査と棚卸しを省略した現行踏襲は、必ず後から高くつきます。
そして何より、現行踏襲であっても要件定義は省略できません。「同じものを作る」の「同じ」を定義する作業こそが要件定義であり、ここが曖昧だとゴールのない開発になります。現行調査の結果を仕様書として文書化し、双方が合意する工程を省かないでください。
現行踏襲は「何も変えない」のではなく、「何を変えないかを意識的に選ぶ」ことです。この意識の差が、同じ方式でもプロジェクトの質を決めます。意識的な踏襲は、無意識の踏襲よりはるかに強い選択です。
作り直す機会は滅多に来ません。その貴重な機会を、不要物の除去と基盤の近代化に使うだけでも、十分に価値のある投資になります。
調査と棚卸しの手間を惜しまなければ、現行踏襲は安定性の高い選択になります。その手間こそが、この方式の成功条件です。
正しい踏襲は、正しい調査から始まります。まずは現行を知ることからです。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。現行の設計書の有無と画面数の目安が分かれば十分に相談を始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。棚卸しで不要機能を除外することで費用を抑える方式が最も現実的です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。現行踏襲とパッケージ移行の5年総額比較も含めて、一緒に検討します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。現行調査だけを先行して依頼いただき、結果を見て方針を判断する形が安全です。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。まず現行の状況を伺い、踏襲が最適かどうかの判断からお手伝いします。
