「動いてはいる、けれど、もう限界かもしれない」——基幹システムを長く使い続けている中堅企業の経営者から、ここ数年で最も増えているご相談のひとつです。本記事では、汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた立場から、中堅企業の経営者が基幹システム刷新を判断するために押さえるべき進め方・費用・期間・失敗パターンを解説します。3 分で要点をつかめる構成にしました。
古い基幹システム、次の一歩は？ 刷新の選択肢整理は専門家に相談を。 無料相談 ＞「動いてはいる」けれど、もう限界ではないでしょうか
多くの中堅企業の経営者にお話を聞くと、共通して出てくるのが 「動いてはいる、保守してくれている、だから手をつけずに来た」 という言葉です。
でも、心のどこかで気づいている方も多いはずです。販売管理画面で確認できるはずの数字が、結局 Excel に転記しないと見えない。受注の取り消しは、長く勤めている特定の担当者しか手順が分からない。請求書の様式を変えたいけれど、改修費用の見積もりだけで何百万円と言われる。何より、システムを作った人も、運用してきた人も、もう社内にいない。
これらは 『古い基幹システム』が静かに引き起こしている経営課題 です。表面上は「動いている」ので、決算書には現れません。けれど、業務の現場では確実に効率が落ち、属人化が進み、いざシステムが止まったときに誰も対応できない状態が、毎月少しずつ深まっています。
基幹システム刷新を経営判断のテーブルに乗せる必要があるのは、まさにこういう 「動いてはいるけれど、もう限界に近い」 状態のときです。完全に止まってから動いたのでは、対応コストが何倍にも膨れ上がります。
なぜ今、基幹システム刷新が必要なのか
「いずれは刷新が必要だ」とは多くの方が分かっています。けれど「いつ」が判断できない。ここで知っておきたいのは、『先延ばしにすればするほど、コストもリスクも非線形に増える』 という事実です。
1. 物理的な老朽化と保守終了リスク
汎用機・オフコンの保守は、メーカーが正式に終了をアナウンスすると、その先 1〜2 年で部品供給が止まります。延長保守は可能でも、年間費用は通常の数倍になり、それでも完全な部品確保は保証されません。「壊れたら終わり」のリスクは、確実に近づいています。
2. 属人化・ブラックボックス化による『見えない経営リスク』
20〜30 年運用された基幹システムには、ベンダーへの度重なる改修指示の積み重ねで、社内の誰も全体像を把握できない部分が必ず生まれます。仕様書は古いものしかなく、現行の挙動と一致しない。経営者から見れば、「自社の主要業務が、退職予定の担当者ひとりの記憶に依存している」 という状態です。これは、決算書には現れない、最も重い経営リスクのひとつです。
3. 業務変化への対応コストが新規開発を超え始める
受発注の多様化、トレーサビリティ要求、現場での Excel 運用の拡大——業務の変化に対して、古い基幹システムを改修し続けるコストは、年々膨らみます。ある時点で、「改修費用の年間累計が、新規構築費用を上回る」 という逆転現象が起きます。この時点で経営判断を先送りすると、毎年お金を捨て続けているのと同じ状態になります。
基幹システム刷新の進め方｜6 段階の標準フロー
基幹システム刷新の進め方には、規模や手法によって違いはありますが、外せない 6 段階のフローがあります。経営者として理解しておきたいのは、各段階で「何を決めるか」と「誰が責任を持つか」です。
| 段階 | やること | 所要期間の目安 |
|---|---|---|
| ① 現状把握 | 業務とシステムの棚卸し。現行業務の見える化 | 1〜3 ヶ月 |
| ② 目的とゴール定義 | 「何のために刷新するか」を経営判断として明文化 | 1 ヶ月 |
| ③ 方式選定 | リプレース／リライト／リホストから方針決定 | 1〜2 ヶ月 |
| ④ ベンダー選定・要件定義 | RFP 作成、ベンダー選定、要件詳細化 | 3〜5 ヶ月 |
| ⑤ 設計・開発・テスト | システム開発、移行テスト、ユーザー教育 | 6〜12 ヶ月 |
| ⑥ 稼働・定着化 | 本番稼働、運用安定化、業務定着支援 | 3〜6 ヶ月 |
この中で 最も軽視され、最も失敗の原因になりやすいのが ①「現状把握」 です。多くの企業が「うちのことは分かっているから」と現状把握をスキップし、いきなりベンダー選定に入ります。けれど、刷新検討の入口で必要なのは、システム側の情報だけでなく 『業務側のリアル』 を社内で共有することです。
販売管理が長らくブラックボックス化していた中堅製造業のケースでは、要件定義の前に 2 ヶ月かけて業務棚卸しを行ったことで、「現場が本当に困っている 5 つの業務」と「実は使われていない機能の 4 割」が初めて社内で共有されました。この『見える化』があったからこそ、その後のベンダー選定とスコープ判断が、まったくブレずに進められたという例もあります。
費用と期間の現実｜中堅企業のリアルな数字
「いくらかかるのか」は、経営判断で最初に気になる論点です。ただしネット上の費用相場は、大企業のメガプロジェクトを含む平均値だったり、ベンダー支払額のみで自社工数を含まなかったりと、中堅企業の判断に使いづらいものが多いのが実態です。
ここでは、中堅企業（売上 30〜300 億円規模、従業員 50〜500 名程度）で実際によくある数字を整理します。
方式別の費用感（中堅企業の典型例）
| 方式 | 費用レンジ | 期間 | 向く企業 |
|---|---|---|---|
| リプレース（パッケージ導入） | 3,000 万〜8,000 万円 | 10〜14 ヶ月 | 業務をパッケージに合わせられる企業 |
| リライト（業務改革を伴う再構築） | 8,000 万〜2 億円 | 18〜24 ヶ月 | 業務の独自性が強い企業 |
| リホスト(オープン化のみ) | 2,000 万〜5,000 万円 | 8〜12 ヶ月 | 時間的猶予がなく、まず延命したい企業 |
期間の見方も重要です。「半年で稼働させたい」という希望を持つ経営者は多いのですが、要件定義から稼働までを 1 年以内で押し込もうとすると、ほぼ確実にテスト工程が削られます。本番稼働直後の障害は、業務停止という形で経営に直接ダメージを与えるため、「期間を縮めること」よりも「テスト時間を確保すること」のほうが経営判断としては重要 です。
中堅企業のリアルな刷新パターン
大企業のメガプロジェクトとは違い、中堅企業の刷新には、典型的な 3 つのパターンがあります。
パターン A：パッケージ導入で標準化に振り切る
ERP やクラウド型業務システムを導入し、自社の業務をパッケージの標準機能に合わせていくパターン。業務改革とシステム刷新を同時に進められる 反面、現場の抵抗が大きく出るため、経営層が現場を巻き込み続ける覚悟が必要です。
パターン B：オープン化で延命してから、段階的に作り直す
まず物理的に老朽化したハードウェアからオープン系のサーバーに移し、業務はそのまま稼働させる方式。時間的猶予を作ってから、業務改革と機能刷新を段階的に進められる 利点があります。中堅企業で最も現実的な選択肢になることが多いパターンです。
パターン C：業務最適化を伴う再構築（フルスクラッチ）
自社の業務独自性が強く、パッケージに合わせられない場合の選択肢。業務にぴったり合うシステムを作れる 反面、費用も期間も大きく、社内のプロジェクト責任者の負荷も最大です。事業の競争優位が「業務プロセスそのもの」にある企業向けの選択です。
失敗が起きる 6 つのパターンと、回避する考え方
基幹システム刷新の失敗には、技術的なものよりも 判断や進め方の失敗 が圧倒的に多いです。25 年の経験から見てきた、典型的な 6 パターンを整理します。
失敗 1：現状把握を飛ばしてベンダー提案に乗る
「分かっているつもり」で現状把握を省略し、ベンダーの提案資料に書かれた『あるべき姿』を採用してしまうケース。要件定義が終わったあたりで現場から「これでは仕事にならない」という声が噴出します。
失敗 2：現行業務の完全踏襲を要求する
「現行の業務をすべて再現してほしい」と要求した結果、カスタマイズが肥大化し、パッケージの利点が消え、費用が当初見積もりの 2〜3 倍に膨らむケース。『標準で残す部分』と『独自性を維持する部分』を仕分ける議論 を、要件定義の入口でしないと、これが必ず起きます。
失敗 3：経営層が要件定義以降の関与をやめる
キックオフは華々しいが、要件定義以降は「あとは現場とベンダーで頼む」と経営層が引いてしまうパターン。判断が必要な節目で誰も決められず、プロジェクト全体が漂流 します。最終的に経営層が介入したときには、すでに後戻りが難しい段階に進んでいます。
失敗 4：プロジェクト責任者を社内に置けない
ベンダーに全面的に進行を任せ、社内には窓口担当者しかいない状態。業務の意思決定が必要なときに、社内で答えが出せず、結果としてベンダーの提案を受け入れるしかなくなります。『業務側の意思決定責任者』を社内に明示的に置く ことが不可欠です。
失敗 5：スコープを途中で肥大化させる
「ついでにこれもやってほしい」「あれも入れたい」が積み重なり、最初のスコープが 1.5 倍、2 倍と膨らんでいくケース。初期のスコープを守るための『追加要件の判断ルール』 を、プロジェクト開始時点で経営層が決めておく必要があります。
失敗 6：稼働直後の運用支援を計画していない
開発と稼働には予算をかけたが、稼働後の運用安定化と業務定着化に予算と人員を割いていないケース。本番稼働直後の数ヶ月は問い合わせとトラブル対応が爆発するため、稼働『後』の体制計画こそが、成功を左右 します。
経営者が刷新を判断するための 7 つのチェックリスト
プロジェクトを始める前に、経営者として確認しておきたい 7 つの問いを整理しました。3 つ以上「いいえ」が出る場合は、まず現状把握フェーズから着手すること をおすすめします。
- 現状の正確な姿は、社内で把握できているか？
── 現行業務の全体像と、システムの動作を、文書化された形で社内に持っていますか？ - 保守できる人は、3 年後にも社内（または近い距離）にいるか？
── 主担当者の退職や引退によって、業務知識が失われるリスクは織り込めていますか？ - 『業務改革を伴う前提』として議論できているか？
── 「現行業務をそのままシステム化する」のではなく、業務そのものを見直す覚悟がありますか？ - ベンダーは『対話できる相手』か？
── こちらの業務を理解しようとし、課題を一緒に整理してくれる相手ですか？ - プロジェクトの業務側責任者を、社内に置けるか？
── 判断が必要な節目で、社内で決められる体制を作れますか？ - 経営層自身が、定期的に関与する仕組みがあるか？
── キックオフだけでなく、要件定義以降も月次以上の頻度で進捗を見る仕組みはありますか？ - 「一気に全部」ではなく、段階的な計画になっているか？
── 一度に全機能を切り替えるのではなく、業務領域ごとに段階的に進める計画ですか？
これら 7 つは、技術的な問いではなく 『経営判断としての問い』 です。情シスや現場に答えを求めるのではなく、経営層が自分で答えるべき問いとして整理しています。
まずは「次の一歩を整理する」から
ここまで、基幹システム刷新の進め方・費用・期間・失敗パターン・判断軸を整理してきました。けれど、自社の状況に当てはめて『次に何をすべきか』を判断するのは、簡単ではありません。
私たち株式会社クオンツでは、「いきなり提案」ではなく「現状を一緒に整理する」 ところから始めるご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
「まだ刷新を決めたわけではないが、判断材料を集めたい」という段階のご相談も歓迎しています。難易度の高い案件ほど燃えるタイプ なので、複雑に絡んだ古い基幹システムや、属人化した業務の解きほぐしも、お気軽にお声がけください。
