基幹システム/ERP更改でフルスクラッチを選ぶかどうかは、保守契約やハードウェアリースの満了までに完成できるかを先に見極めて決めます。間に合わない場合は、延長保守や段階移行も比べます。判断では、長期開発のリスクと、期限を過ぎても業務を止めずに続けられる移行計画を合わせて評価します。
- 更改の期限と判断条件の確認
- 必要な工程と検証範囲の整理
- 依頼先と実行体制の比較
このテーマ全体を扱った完全ガイドは、次の記事で読めます。
▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
基幹システム/ERP更改におけるフルスクラッチという選択肢の位置づけ
フルスクラッチを検討する前に、更改特有の制約と、この記事群で扱う範囲を押さえておく必要があります。
基幹システム/ERP更改とは、会計・人事給与・生産管理・販売管理・在庫管理といった企業の背骨となる全社基盤システムについて、そのまま延長するか作り替えるかを判断し、実行する取り組みです。
そのきっかけは、保守サポート契約の満了、ハードウェア（オンプレミスサーバー）のリース満了、ERPパッケージのバージョンアップサイクルの節目です。これらは「契約・ライフサイクル起点の期限」にあたります。
「基幹システム開発」「ERP導入」のように、ゼロから基幹システムを構築する取り組みとも異なります。また、既存の老朽化した基幹システムの契約更新という制約の中で下す判断である点も、本記事群に共通する前提です。
モダナイゼーション・刷新のフルスクラッチ論との違い（契約期限内に収まるかという制約軸）
「基幹システム/ERPのモダナイゼーション」が扱うフルスクラッチは、コア業務領域への適用範囲やパッケージとのハイブリッド構成といった技術的な設計が中心です。一方、「基幹システム/ERP刷新」が扱うフルスクラッチは、なぜ数多くの日本企業が合理的とは言えないフルスクラッチを選んでしまうのかという、組織文化・商習慣の構造分析が中心です。
これに対し本記事が扱うのは、保守契約やハードウェアリースの満了という動かせない期限までに、長期のプロジェクトが物理的に間に合うかという、極めて実務的な制約です。フルスクラッチが技術的・経営的に望ましい選択だとしても、期限に間に合わなければ、老朽化したシステムを保守切れのまま使い続けるという最悪の事態を招きかねません。
契約更新のタイミングでフルスクラッチを選ぶことの是非（期間・リスクの観点）
契約更新のタイミングは、フルスクラッチという抜本的な選択肢を検討する好機です。一方で、限られた時間の中で意思決定を迫られるという難しさもあります。
パッケージ更改であれば、標準機能への移行が中心となり、比較的短い期間で完了します。これに対しフルスクラッチは、要件定義から設計、開発、テストまでを一から積み上げる必要があります。そのため、契約更新までの残り期間が短い場合は、現実的な選択肢になりにくいという制約があります。
更改のタイミングでフルスクラッチを検討する際は、まず契約満了までに残された期間を正確に把握することが出発点です。そのうえで、その期間内にフルスクラッチを完了できるかを冷静に見極めます。
保守契約満了までにフルスクラッチが間に合うかという現実的な制約
フルスクラッチという選択肢の是非を論じる前に、まず期間の面で「間に合うかどうか」を冷静に見極める必要があります。
フルスクラッチの標準期間と契約更新サイクルのミスマッチ
基幹ERPのフルスクラッチ（リビルド）は、期間の目安が約12〜30ヶ月とされ、マイクロサービス化を限定範囲で行う場合でも8〜18ヶ月程度を要します。
一方、保守サポート契約は1年単位の自動更新、ハードウェアのリースは4年または5年周期で到来します。満了までの残り期間が1〜2年程度しかない場合は、フルスクラッチの標準期間との間に大きなミスマッチが生じます。
特に、契約更新通知が届く満了の3〜6ヶ月前になって更改を検討し始めると、フルスクラッチは事実上取り得なくなります。フルスクラッチを現実的な候補として俎上に載せられるのは、契約満了の1〜2年以上前から検討を始めていた場合に限られると考えておくべきです。
間に合わない場合の暫定策（延長保守のブリッジ活用）
残り期間がフルスクラッチの標準期間に満たない場合は、延長保守（または再リース）を、開発期間を確保するための一時的なブリッジとして位置づけて契約するのが現実的です。
たとえば、SAP ECC6.0であれば、条件を満たすと2030年末まで延長保守を受けられます。その延長期間を使って、フルスクラッチのプロジェクトを計画的に進めるという段取りも選択肢になります。
ただし、延長保守の追加費用（基準保守料金への2%上乗せなど）は、延長を続ける限り発生し続けます。そのため、ブリッジ期間をいたずらに長くせず、あらかじめ確定させた期限内に開発を完了させる、強いプロジェクトマネジメントが求められます。
更改のタイミングでフルスクラッチを検討すべきケース・避けるべきケース
期間の見込みが立ったとしても、フルスクラッチを選ぶかどうかは業務領域ごとに見極める必要があります。
コア業務領域への該当性という判断基準（ポートフォリオマトリクス）
フルスクラッチを選ぶべきなのは、自社の競争優位に直結し、改修の難易度も高いコア業務領域に限られます。
ビジネス価値の高さと改修の難易度という2軸でポートフォリオマトリクスを作成します。コア領域はスクラッチを検討し、一方、総務・人事・一般会計といった非競争（コモディティ）領域では、更改のタイミングでパッケージの標準機能への移行（Fit to Standard）を優先すべきです。
更改は契約期限という制約がある分、判断に使える時間が限られています。だからこそ、感情論や「今までと同じものが欲しい」という現場の要望だけでフルスクラッチに流れないよう、この4象限の判断基準を事前に用意しておくことが、合理的な結論につながります。
「とりあえず延命」で終わらせず、戦略的にフルスクラッチへ踏み切る判断材料
更改のタイミングは、単なる「延命」で終わらせず、戦略的にフルスクラッチへ踏み切るかを見極める貴重な機会でもあります。
受注生産の仕組みなど、自社の柔軟性が競争力の源泉になっている業務領域では、パッケージの標準機能だけでは対応しきれないことがあります。その際は、フルスクラッチかハイブリッド構成が現実的な解になります。ハイブリッド構成とは、共通基幹部分はパッケージの標準機能を使い、独自性が求められる領域だけをスクラッチで開発する形です。
契約更新という外圧をきっかけに、コア業務領域の技術的負債を根本から解消できるかどうかで、次の契約更新サイクル（4〜5年後）に同じ課題を抱えたまま迎えるかが分かれます。
フルスクラッチを選ぶ場合のベンダー選定と契約設計
フルスクラッチを選ぶなら、契約期限を踏まえたベンダー選定と契約設計が欠かせません。
開発ベンダーと既存保守ベンダーの契約関係整理・多重下請け構造への対処
フルスクラッチでは、これまで保守を委託してきたベンダーと、新システムを開発するベンダーが別になるケースが一般的です。
開発ベンダーを選ぶ際は、基幹システムやERPパッケージとの連携実績と、大規模プロジェクトのマネジメント実績を確認します。そのうえで、2〜3社以上から相見積もりを取るのが基本です。
大規模案件では、元請けが実作業を二次請け・三次請けへ再委託する多重下請け構造が生じやすくなります。人月単価も、大手SIerで150万〜200万円、中小規模の開発会社で80万〜120万円と、2〜3倍の開きがあります。こうした構造を踏まえ、契約書とNDAで再委託の可否と範囲、責任の所在を明確に定めます。そのうえで、発注者自身がプロジェクト全体を統制できる体制を保つことが重要です。
保守契約の解約・移行期間を織り込んだ契約スケジューリング
フルスクラッチを選ぶなら、開発ベンダーとの契約だけでなく、既存の保守契約の解約時期も合わせて設計する必要があります。
開発が終わる前に既存の保守契約を解約すると、開発が遅れたときに保守切れの空白期間が生じるおそれがあります。そのため、新システムの本番稼働と並行稼働期間の完了を確認してから、既存の保守契約とハードウェアリースを解約する流れを組むのが安全です。
さらに、契約更新通知が届く時期と、フルスクラッチの完了予定時期はずれやすいものです。必要に応じて保守ベンダーと短期間の延長契約を個別に交渉し、開発完了までの空白期間を作らない調整も、契約設計の欠かせない一部です。
フルスクラッチ判断を誤らないためのガバナンスと注意点
契約期限に追われるなかでこそ、フルスクラッチという重い投資判断を誤らないためのガバナンスが欠かせません。
契約期限のプレッシャーによる拙速な意思決定を避けるステアリングコミッティ運営
契約更新期限が迫ると、「時間がないから」という理由で十分な検討をせずフルスクラッチに踏み切ってしまうことがあります。逆に、検討を先送りにした結果、延長保守を選ばざるを得なくなることもあります。どちらも、拙速な意思決定に陥りやすい形です。
これを避けるには、経営層を含むステアリングコミッティを早期に設置し、契約期限から逆算したマイルストーンごとに、「このタイミングまでにこの判断を下す」という意思決定ログを残すことが大切です。そのうえで、期限のプレッシャーに流されない冷静な議論の場を確保します。
フルスクラッチを選ぶ理由を「競争優位に直結する業務領域だから」という言葉で明確に言語化し、全社で共有しておくことは、後々の判断に一貫性を保つ土台になります。
変更管理・予備費確保による費用超過防止
フルスクラッチ開発で費用が超過する最大の原因は、要件定義の後に発生する仕様変更や追加要件です。契約期限に追われると、要件定義に十分な時間をかけられないまま開発に着手しがちで、その結果、スコープクリープを招き、費用超過につながります。
仕様変更が起きたら、口頭での「ちょっとした追加」で済ませず、必ず変更要求として起票します。そのうえで、影響範囲の調査と工数見積もり、ステアリングコミッティでの承認を経てから実施するルールを徹底します。
予備費として全体予算の10〜20%を確保しておくことが、契約期限の制約のなかでもプロジェクトの費用と品質をコントロールし続けるための実務的な備えになります。
まとめ
ここまで、更改におけるフルスクラッチの位置づけと、契約期限との関係を見てきました。さらに、期限に間に合うかという現実的な制約と、検討すべきケース・避けるべきケース、ベンダー契約、ガバナンスの要点も取り上げました。
フルスクラッチは期間の目安が12〜30ヶ月と長期に及ぶため、契約満了の1〜2年以上前から検討を始めていなければ、現実的な選択肢として俎上に載せることすら難しくなります。
技術的な実装方法やカスタマイズ率と費用の関係は、基幹システム/ERPのモダナイゼーションの記事で扱っています。なぜフルスクラッチを選んでしまうのかという組織文化の分析は、基幹システム/ERP刷新の記事で扱っています。
一方、本記事で強調したいのは、契約更新という期限のプレッシャーがあるからこそ、フルスクラッチという重い投資判断は、早期の着手と冷静なガバナンスがそろって初めて成功するという点です。契約満了が近づいてから慌てないよう、早い段階で専門家に相談し、期間と選択肢を見極めることをお勧めします。
▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。