「まだ動いている」が最も危険なサイン｜基幹システム刷新はいつ始めるべきか
「システムは動いている。今すぐ困っているわけではない。」そう感じている経営者ほど、基幹システム刷新の判断が遅れやすい傾向があります。しかし実際には、問題が見えないうちにこそ、選択肢は失われていきます。このコラムでは、刷新を後回しにすることのリスクと、いま何を考えるべきかを整理します。
こんな方にお読みいただきたい内容です。
- SAP ECCやAS/400の刷新を検討しているが、何から始めればよいかわからない
- システムは動いているが、将来への不安を感じている
- 経営会議で刷新の話題が出始めたが、判断の根拠が整っていない
- ベンダに相談する前に、自社として何を整理すべきか知りたい
なぜ基幹システム刷新は後回しになるのか
企業経営において、基幹システム刷新は優先順位を上げにくいテーマです。営業施策であれば売上向上が見えます。新商品開発であれば将来の成長が見えます。しかし基幹システム刷新は、多くの場合「問題を未然に防ぐための投資」です。そのため「今すぐ困っていない」という理由で先送りされやすい傾向があります。
実際、多くの経営者が次のように考えます。
- システムは動いている
- 現場から大きな不満は出ていない
- 今年は他の投資を優先したい
- 来年でも間に合うのではないか
どれも間違いではありません。しかし基幹システム刷新の難しいところは、「問題が表面化したときには、既に手遅れになり始めている」ことです。
予防接種と同じです。感染してから打っても意味がない。刷新もまた、問題が起きてから動き出すのでは、取れる選択肢が大きく限られます。「今動く理由がない」は、「今動かない理由にはならない」のです。
システムが壊れる前に、判断の自由度が失われる
多くの人は「システムの寿命＝障害が増えること」だと考えています。しかし実際には違います。私たちが支援してきた企業では、システムそのものは動いていました。しかしその裏で、次のような問題が徐々に現れていました。
- 新規事業に対応できない
- データ連携が困難
- 法改正対応が重い
- ベンダ依存が強い
- 業務改善のスピードが上がらない
システムが止まる前に、企業の成長や変化に対応する力が失われていくのです。これは人間で言えば、突然倒れるのではなく、少しずつ体力や柔軟性が失われていく状態に近いかもしれません。
特に深刻なのが、「やりたいことができない状態」が常態化してしまうことです。現場はシステムの制約に合わせて業務を組み替え、Excelや手作業でカバーし、それが「普通」になっていく。その積み重ねが、気づかないうちに企業の競争力を蝕んでいます。
SAP ECCやAS/400の問題も本質は同じ
近年ご相談が増えているのが、SAP ECCやAS/400に関する刷新検討です。しかし誤解してはいけないのは、SAPだから問題なのではなく、AS/400だから問題なのでもないということです。
SAP ECCを利用していても十分に運用できている企業はあります。AS/400も、現在でも重要な業務を支えている企業が数多く存在します。本当の問題は、そのシステムが自社の将来に適応できるかどうかです。
- 新たな事業戦略に対応できるか
- 人材が確保できるか
- 継続的に改修できるか
- 投資対効果が見込めるか
例えば、SAP S/4HANAへの移行を検討している企業の中には、「移行しなければならない」という焦りから、自社の業務要件を十分に整理しないままベンダ選定に入るケースがあります。結果として、フィットしない製品を選び、大規模なアドオン開発が必要になるという本末転倒な事態が起きています。
こうした視点を抜きにして、技術論だけで刷新を判断することが最も危険なのです。
「サポート終了」が危険なのではない
多くの企業が刷新を検討するきっかけは、SAP ECCサポート終了、Windows Serverサポート終了、Oracleサポート終了、開発ツールサポート終了などです。しかし、サポート終了自体が問題なのではありません。問題は、その時点で初めて検討を始めることです。
例えば、2027年にサポート終了するとします。その時点から構想策定を始めれば良いかというと、そうではありません。
- 構想整理だけで半年
- 業務分析で半年
- RFP作成とベンダ選定で半年
- 要件定義で半年
- 開発・移行で1〜3年
というケースも珍しくありません。2027年が問題なのではなく、2027年までしか猶予がないことが問題なのです。期限が迫ってからの検討は、選択肢を自ら狭めることになります。
さらに言えば、期限に追われた状態でのプロジェクトは、ベンダ側が有利な交渉になりやすく、コスト増・品質低下のリスクも高まります。余裕のあるうちに動き出すことが、最終的なコスト削減にもつながるのです。
刷新のタイミングを見誤る企業の特徴
「担当者がいるから大丈夫」
よく聞く言葉ですが、担当者は永遠にはいません。退職、異動、病気、定年。どの企業でも起こります。しかも属人化したシステムほど、そのリスクは大きくなります。担当者が去ったあとに初めて「誰も全体を把握していない」と気づくケースが後を絶ちません。
特に、長年同じ担当者が保守してきたスクラッチシステムやAS/400環境では、ドキュメントが存在しないまま属人的な運用が続いているケースが多くあります。その担当者が離れた瞬間、システムはブラックボックス化し、改修もできず、移行もできないという状況に陥ります。
「障害が出ていないから大丈夫」
これも危険な判断です。刷新を検討すべきタイミングは、障害が発生した時ではありません。障害が発生した時には、既に選択肢が減っています。「動いているうちに動く」ことが、基幹システム刷新における最大の原則です。
障害が起きた後では、「早急に何とかしなければならない」という制約のもとで意思決定を迫られます。十分な比較検討も、段階的な移行計画も描けないまま、コストと時間を浪費するリスクが高まります。
「予算が取れないから仕方ない」
予算不足は確かに現実です。しかし構想策定は開発よりはるかに小さな投資です。むしろ、方向性を決めないまま開発予算を組む方が大きなリスクになります。何を作るかが曖昧なまま進むプロジェクトほど、後から費用が膨らみます。
構想策定フェーズで明確にすべきことは、「何を刷新するか」ではなく「なぜ刷新するのか、何を実現したいのか」です。この問いに答えが出ていない状態で開発を発注することが、ITプロジェクト失敗の最大の要因のひとつです。
こんな状態なら刷新の検討を始めるべきかもしれません
次の項目に3つ以上当てはまる場合、少なくとも構想策定フェーズに着手する価値があります。
システム面
- SAP ECCやAS/400を利用している
- ベンダが実質1社しか対応できない
- 全体構造を理解している人が限られている
- ドキュメントが不足している
- 改修見積りが高騰している
業務面
- 新しい要望への対応に時間がかかる
- Excelや手作業が増えている
- 部門ごとにデータが分断されている
- システムが業務改善の足かせになっている
経営面
- 中期経営計画の見直しを進めている
- M&Aや事業再編を検討している
- DX推進を掲げている
- 役員会で刷新の議論が始まっている
当てはまる項目が多いほど、「今すぐ始める理由」は揃っています。
基幹システム刷新で最も重要なのは「何を導入するか」ではない
多くの企業は、ERP選定から始めようとします。しかし本来最初に整理すべきなのはERPではありません。整理すべきなのは次のことです。
- どの業務を変えるのか
- どの業務を残すのか
- 何を標準化するのか
- 何を競争力として維持するのか
製品選定の前に、経営判断が必要なのです。「どのERPにするか」は、経営の方向性が定まって初めて意味を持つ問いです。順序を間違えると、製品に業務を合わせるという本末転倒な状況が生まれます。
ERPのベンダ各社はそれぞれの強みを持っており、自社の業務特性・規模・将来戦略によって最適解は変わります。製品ありきで進めるのではなく、「自社が何を実現したいか」を言語化することが、成功するプロジェクトの出発点になります。
刷新に成功する企業が最初にやること
私たちがご支援してきた事例の中で、刷新を成功に導いた企業に共通しているのは、「検討の入口」が明確だったことです。製品選定でもベンダ探しでもなく、まず自社の現状と将来像を丁寧に整理することから始めていました。
具体的には、次のような問いを経営レベルで議論することが第一歩になります。
- 3〜5年後、自社のビジネスはどう変わっているか
- 現在のシステムで、その変化に対応できるか
- 刷新しない場合のリスクは何か、コストはいくらか
- 刷新する場合、どの業務から変えるべきか
- 社内に必要な体制・人材はそろっているか
これらの問いに答えを持たないまま開発会社に相談しても、相手は「要件を教えてください」と言うだけです。発注者自身が何を求めているかを整理していなければ、良い提案は引き出せません。
構想策定フェーズでやるべき3つのこと
基幹システム刷新における構想策定フェーズは、プロジェクト全体の土台となる最も重要な工程です。ここで整理すべきことは、大きく3つに整理できます。
1. 現状の整理と課題の言語化
現在のシステムが抱える問題を、「感覚」ではなく「事実」として整理します。改修コストの推移、対応リードタイム、属人化のリスク箇所、法改正対応の負荷など、データと事実をもとに課題を可視化することが出発点です。この作業なしに「刷新が必要」と言っても、社内の合意形成は難しくなります。
2. 将来像の設計
刷新後に「どうなりたいか」を描きます。新規事業への対応力、データ活用の基盤整備、業務標準化の範囲、グループ会社との連携など、経営戦略と連動した将来像を言語化することが求められます。この将来像が、製品選定やベンダ評価の軸になります。
3. 選択肢の比較と意思決定
「ERP統合」「段階移行」「現行維持・延命」「スクラッチ再構築」など、複数の選択肢をコスト・リスク・実現性の観点で比較します。正解を探すのではなく、自社として「納得できる判断」をすることが目的です。この比較なしに一つの方向性に決め打ちすることは、大きなリスクを伴います。
私たちがご支援しているのは「刷新」ではなく「判断」です
オーシャン・アンド・パートナーズは、特定のERPや開発手法を前提としません。SAP継続、AS/400延命、ERP統合、段階移行。どの選択肢が正解かは、企業によって異なります。私たちの役割は、経営として納得できる判断ができるよう、選択肢を整理し、比較し、意思決定を支援することです。
基幹システム刷新は「システムの更新」ではありません
基幹システム刷新は「システムの更新」ではありません。会社の将来像を決める経営プロジェクトです。だからこそ私たちは、開発会社を探す前の構想策定フェーズからご支援しています。
よくあるご質問
Q. 構想策定だけ依頼することはできますか？
はい、可能です。オーシャン・アンド・パートナーズでは、構想策定フェーズのみのご支援も承っています。「まだ開発に踏み切る段階ではないが、方向性を整理したい」というご相談が多く、そのような段階からお手伝いしています。
Q. 構想策定にはどのくらいの期間・費用がかかりますか？
企業規模や検討範囲によって異なりますが、一般的には3〜6ヶ月程度が目安です。費用は開発フェーズと比較すると大幅に小さく、まず着手しやすい投資規模で進めることができます。詳細はご相談の上、個別にご提案しています。
Q. 特定のERPやベンダを前提に支援しますか？
いいえ。私たちは特定製品・特定ベンダに依存しない第三者の立場で支援しています。SAP、Oracle、国産ERP、スクラッチ開発など、すべての選択肢をフラットに比較・評価し、発注企業の利益を最優先に考えます。
Q. 社内にIT部門がなくても相談できますか？
はい。IT部門が存在しない、あるいは体制が薄い企業からのご相談も多くいただいています。経営層・業務部門の方々と直接対話しながら、発注者としての視点で整理・支援することが私たちの強みです。
この記事のまとめ
- 基幹システム刷新は「問題が起きてから」では遅い。障害が出る前に、判断の自由度が失われていく
- SAPやAS/400が問題なのではなく、「自社の将来に適応できるか」が本質的な問い
- サポート終了はきっかけに過ぎない。問題は、その時点から動き始めることにある
- 属人化・障害なし・予算不足——どれも「後回しにする理由」にはならない
- 刷新の第一歩はERP選定ではなく、経営として「何を実現したいか」を整理すること
- 構想策定フェーズでやるべきことは、現状整理・将来像設計・選択肢の比較の3つ
- 成功するプロジェクトは「正解を探す」のではなく「納得できる判断をする」ことを目指している
【関連コラム】基幹システム刷新を検討し始めた方へ
システム刷新は、製品選定や開発会社探しから始まるものではありません。まずは、なぜ失敗するのか、何を判断すべきなのかを理解することが重要です。
「設計図のない街は作れない」──アーキテクチャとは何か
基幹システム刷新で最初に考えるべきは、製品ではなく全体構想です。システムアーキテクチャの役割と、なぜ構想段階が重要なのかを解説しています。
ITプロジェクトに正解はない──必要なのは納得できる判断である
基幹システム刷新では、ERP統合、段階移行、現行維持など複数の選択肢が存在します。重要なのは正解探しではなく、経営として納得できる判断を行うことです。
なぜ基幹システム再構築は失敗するのか
多額の投資を行ったにもかかわらず、稼働しない、使われない、現場に定着しない。失敗事例から学ぶ再構築プロジェクトの落とし穴を解説しています。
【サービス案内】基幹システム刷新の構想からベンダ選定まで伴走します
オーシャン・アンド・パートナーズは、特定のERPやベンダーを前提とせず、発注企業の立場から構想策定・RFP作成・ベンダ選定・プロジェクト推進を支援しています。
システム構想策定支援
業務整理、課題分析、将来像の設計を行い、基幹システム刷新の土台となる構想を策定します。
基幹システム再構築支援
構想策定後のRFP作成、ベンダ選定、要件定義、プロジェクト推進まで一貫して支援します。
RFP作成・ベンダ選定支援
比較可能性を担保したRFP作成と、提案評価・ベンダ選定を支援します。
【参考資料】基幹システム刷新の前に、判断材料を整理しませんか
システム刷新は、ERP選定や開発会社選定から始めるものではありません。まずは発注者として何を考え、何を整理し、何を判断すべきかを理解することが重要です。
IT投資の価格はなぜ見えないのか
システム投資の見積りが数倍変わる理由や、適正価格を判断するための考え方をまとめています。
「予算を示せないRFPは意思を示せない」
ベンダ選定が失敗する理由と、発注者として意思を示すためのRFP設計について解説しています。
ITプロジェクト失敗統計と投資対効果分析
国内外の統計データをもとに、なぜITプロジェクトが失敗するのか、どうすれば成功確率を高められるのかを整理しています。
システム刷新の前に、まず「何を判断すべきか」を整理しませんか
SAP ECC、AS/400、レガシーシステム、スクラッチ開発システムなど、多くの企業が「何に刷新するか」ではなく、「どう判断するか」で悩んでいます。オーシャン・アンド・パートナーズは、特定製品や特定ベンダーに依存しない第三者の立場で、構想策定からベンダ選定までご支援します。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
