フルスクラッチ・オーダーメイド開発は、独自業務ロジックの継承と経営層の継続的な意思決定を一体で進める投資で、期間も費用も最大規模になる選択肢です。経営企画や財務など直接の発注者でなくても投資承認に関わる方にとって、レガシー刷新特有の事情を理解しておくことは審査を的確に進めるうえで有用です。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
COBOLやメインフレームの「塩漬け」システムほど、独自業務ロジックが積み重なり、単純なリプレースでは吸収しきれません。フルスクラッチにするかどうかは、次の観点から見極めます。
- 独自業務ロジック：標準機能や自動変換で吸収できない要件
- 投資規模：期間と費用の大きさを支えられる体制
- 継承要件：会計基準、商習慣、帳票など、引き継ぐべき要件
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム刷新でフルスクラッチが選ばれる背景
長年にわたり継ぎ足し開発を繰り返してきたレガシーシステムでは、業種や企業に特有の複雑な業務ロジックが、標準的なパッケージ製品の機能では吸収しきれないほど積み重なっているケースが多く見られます。
そのため、既存コードを自動変換ツールで移行するリビルドや、パッケージへの単純なリプレースでは対応しきれない場合があります。そうした場合、ゼロから設計・開発するフルスクラッチが唯一の現実的な選択肢として残ります。
さらに、経営判断としてフルスクラッチを選ぶことは、期間も費用も最大規模の投資を、最も不確実性の高いレガシーシステムに対して行うことを意味します。経営層の理解と強いコミットメントがなければ、到底実現できません。
とりわけCOBOLやメインフレーム上で稼働してきたシステムは、長年の運用の中で、会計基準の改正や業界特有の商習慣、独自の帳票フォーマットといった、外部からは見えにくい要件が幾重にも折り重なっています。これらを正確に引き継ぎながら新しい技術基盤の上に再構築する作業は、単純なコード変換では代替できません。
コア領域への集中投資という経営判断
フルスクラッチを選ぶべきかどうかの根底にあるのは、対象システムが自社の「コア領域」、すなわち競合他社との差別化要因である中核業務を担っているかどうかという判断です。取るべき道は、この違いで次のように分かれます。
- 周辺業務：SaaS標準機能で代替できるなら、パッケージ移行やSaaS化でコストを抑えるべきです。
- コア領域：自社の強みそのものを支えるシステムなら、標準機能への合わせ込みは競争力の喪失に直結します。
経営層は、ポートフォリオ管理の発想で、コスト削減を優先する領域と戦略的投資を集中させる領域を明確に切り分ける必要があります。そのうえで、後者に限ってフルスクラッチという最大投資を許容するという判断の観点を持つことが求められます。
この切り分けが曖昧なまま「重要そうだから」という感覚的な理由でフルスクラッチを選ぶと、投資額に見合う効果が得られず、後になって稟議そのものの妥当性が問われかねません。逆に、コア領域であるにもかかわらずコスト削減を優先してパッケージの標準機能に無理に合わせると、自社の強みが失われ、刷新したのに競争力が低下するという本末転倒な結果を招くこともあります。
したがって、この見極めには経営層自身が事業戦略の観点から関与することが欠かせません。
手法の技術的な比較と姉妹記事
フルスクラッチ・パッケージ/SaaS移行・自動変換ツール利用という3つの手法は、どう比較して選ぶかが問われます。技術的・実務的な観点は、「レガシーシステムのモダナイゼーション」のフルスクラッチ・オーダーメイド開発に関する記事で詳しく解説しています。
この観点を踏まえ、本記事は大型投資として承認を得るための経営プロセスとガバナンスに絞って解説します。手法選定にまだ迷いがある方は、あわせてご参照いただくとよいでしょう。
なお、フルスクラッチとリビルドは類似した文脈で語られることもありますが、既存コードの資産をどこまで活用するか、要件定義をゼロから行うかどうかという点で、実務上のアプローチが異なります。そこで、社内での用語の使い方をベンダーとの間で早い段階から揃えておくと、見積もり比較の際の認識のずれを防げます。
経営層・取締役会の投資承認を得る進め方
フルスクラッチの費用感は、期間12〜30ヶ月、費用3,000万円〜2億円程度が目安とされています。さらに、実質総費用は当初見積もりの1.3〜1.5倍に膨らむこともあるとされています。
このため、部門決裁では完結せず、取締役会クラスでの投資承認が必要になるのが一般的です。
取締役会での承認プロセスには、稟議書の作成から役員会での審議、必要に応じた差し戻しや再審議までが含まれます。想定以上の期間がかかることも珍しくないため、開発スケジュールを検討する段階から、この承認プロセスに要する期間を明示的に織り込んでおくことが望ましいといえます。
複数年度予算化と投資回収シミュレーション
フルスクラッチのように投資規模が大きく、開発期間も長期にわたるプロジェクトでは、単年度予算での承認ではなく、複数年度にわたる予算計画として提示することが現実的です。初年度はアセスメントとPoCに絞った予算枠を確保し、その結果を踏まえて2年目以降の本開発の予算を段階的に承認してもらうとよいでしょう。この進め方なら、経営層もリスクを段階的に見極められます。
あわせて、初期構築費用だけでなく運用保守費用まで含めた総所有コスト（TCO）で、現状維持のシナリオと刷新のシナリオを比較します。何年で投資を回収できるかというシミュレーションを提示することが、取締役会での承認を得るための基本的な資料構成になります。
フェーズごとの完了基準と次フェーズへの移行判断基準をあらかじめ合意しておけば、途中の年度で経営環境が変わっても、プロジェクト全体を白紙に戻さず、計画の一部を見直せます。この柔軟さも、複数年度予算化のメリットです。
先送りのリスクを訴求するナラティブの組み立て方
投資対効果の提示だけでは、先送りした場合に何が起きるかが取締役会に伝わりにくいものです。その危機感を裏づける材料になるのが、自社の判断とは別に迫る外部のリミットです。
- 2025年の崖：経済産業省の「DXレポート」は、放置した場合に年間最大12兆円の経済損失が生じる可能性を警告しています。
- 2027年問題：世界的な基幹業務システムであるSAP ERPの保守サポートが2027年末に終了します。
- 人材の確保：COBOLやメインフレームに対応できる技術者の高齢化・退職が進んでいます。
これらの外部リミットは、自社固有の判断とは独立した「先送りできない理由」として、取締役会の危機感を醸成する有効な材料になります。加えて、「今なら実現できるが、数年後には実現困難になる可能性がある」という時間的制約も、明確に伝えておく必要があります。
稟議資料には、定量的な損失予測に加えて、障害や重大インシデントが実際に起きた競合他社・同業他社の事例を添えるとよいでしょう。そうすることで、抽象的なリスクを具体的な経営課題として実感してもらえます。数字だけを並べた資料よりも、「もし自社で同様の事態が起きたらどうなるか」を想像させるストーリー仕立ての説明のほうが、取締役会の議論を前に進める力を持つことも少なくありません。
大型投資を成功させるプロジェクト体制とベンダー選定
投資承認を得た後は、その予算を実際の成果に結びつけるプロジェクト体制の構築が問われます。体制の設計の巧拙が、フルスクラッチという大型投資の成否を大きく左右します。
予算が承認されたことに安心して体制構築を開発ベンダー任せにすると、発注者側の意思決定が追いつかず、プロジェクトが停滞しがちです。現場の反発によって計画が形骸化することもあります。そのため、体制の設計は発注者側が主体的に担うべき工程だという認識を持つことが大切です。
10億円規模の基幹システム刷新に学ぶ体制構築
ある企業の10億円規模の基幹システム刷新は、導入から約20年が経過した旧システムが過剰な個別カスタマイズでブラックボックス化しており、一度頓挫しかけた末に再スタートを切ってリリースにこぎつけた事例です。体制面では、次のように役割が分かれました。
- 経営層（専務）：プロジェクト責任者として方針を示し、旗振りを担いました。
- 情報システム部長：プロジェクトマネージャーを務めました。
- 三位一体の体制：業務部門・開発ベンダー・外部コンサルタントが参画する構成です。
特に注目すべきは、コンペで最も見積金額が高かったコンサルタントをあえて選んだ点です。他社が責任問題を恐れて詳細な現状分析を避けるなか、「旧システムの構成を全部洗い出す」と明言したことが決め手になりました。また、機能追加要望には、専務が費用対効果を厳しく査定して現場業務を新システムに合わせる「標準化」を徹底し、スコープの肥大化を防ぎました。
この事例が示すのは、大型投資であるほど、経営層自身がプロジェクトの当事者として細部の意思決定に関与する必要があるということです。逆に、予算だけを承認して後を現場に任せると、途中の無数の判断が現場レベルで先送りされ、スケジュールと予算の両方が膨らむリスクが高まります。
ベンダー選定基準と業務標準化の徹底
フルスクラッチのベンダー選定では、初期費用の安さだけで判断しないことが基本です。同業種・類似規模での導入実績とデータ移行の経験、プロジェクト管理とコミュニケーション能力、運用保守・アフターサポート体制という3つの基準で、複数社を比較検討します。
開発ベンダーを再選定する際は、担当者のレジュメでパッケージ製品や対象領域への理解度を確認します。可能であれば、「開発を担うベンダーと運用保守を担うベンダーが同一であること」を重視すると、稼働後の一貫したサポート体制を確保しやすくなります。あわせて、業務の標準化を大前提とすることも欠かせません。
現場の要望をすべて盛り込もうとすると、過剰なカスタマイズを招き、旧システムと同様のブラックボックス化（技術的負債の再生産）に陥りかねません。このため、不必要な業務は廃止するという経営判断が必要です。業務標準化では、現場の反発を単なる抵抗として切り捨てず、業務フローが今の形になっている背景を丁寧にヒアリングしたうえで、必要な例外対応と単なる慣習を切り分けるプロセスが実効性を高めます。
失敗を避けるためのリスク管理と教訓
投資規模が大きいフルスクラッチほど、失敗した際の経営へのインパクトも甚大です。過去の失敗事例から共通する教訓を学び、稟議の段階からリスク管理策を織り込んでおくことが欠かせません。
フルスクラッチはやり直しの利かない意思決定だからこそ、成功事例だけでなく失敗事例を直視し、同じ失敗を繰り返さないための具体的な対策を稟議書に盛り込んでおくことが大切です。そうすれば、承認者の安心感にもつながります。
数千万〜数十億円規模の失敗事例に共通する要因
海外の事例では、テストや移行計画が不十分なまま新システムへ移行した結果、在庫情報が混乱しました。わずか3ヶ月で、数億円規模の損失と100万ドルを超える修正コストが発生したケースが報告されています。国内でも、業務要件に合わないパッケージ選定と要件定義の甘さからプロジェクトが白紙撤回され、ベンダー側に数十億円規模の賠償命令が下された事例があります。
これらの失敗に共通する主な要因は、現場ニーズや業務フローの軽視と、要件定義や計画の不備です。ほかにも、ベンダー選定と契約管理のミスマッチ、従業員教育やチェンジマネジメントの不足、プロジェクト管理体制の不備があり、合わせて5点に整理できます。フルスクラッチはやり直しが容易でない投資だからこそ、着手前にこれらのリスクをどう抑えるかを、具体的な計画に落とし込んでおく必要があります。
特にレガシーシステム刷新では、要件定義の甘さが表面化するのが着手から相当期間を経た後になりがちです。発覚した時点で多額の予算がすでに投じられているケースが多いため、要件定義フェーズに十分な期間と専門人材を割り当てることが、最も優先すべきリスク管理策といえます。
放置のリスクを示す警鐘としてのガバナンス教訓
2021年に発生したある大手金融機関のシステム障害の調査報告書では、過去に発生していた同種の予兆事象が特段の検討もされないまま放置され、重大な顧客被害に直結したことが指摘されています。報告書は、根本原因として「積極的に声を上げて責任問題となるリスクを取るよりも、自らの持ち場だけ対応するほうが合理的」という組織風土を挙げ、失点を恐れて自発的に動かない傾向にも言及しています。
この教訓は、フルスクラッチという大型投資の意思決定にも当てはまります。現場や担当部門が問題を察知していても声を上げにくい組織風土のままでは、どれだけ優れた投資計画を立てても、実行段階でリスクが顕在化しやすくなります。PMOを設置し、問題が起きた際に軌道修正する勇気を経営層自身が持つことに加えて、次の取り組みも欠かせません。
- 目的の定量化：経営ビジョンと導入目的を、定量的に「言語化」しておくこと。
- パイロット導入：現場を巻き込んだ段階的な導入を徹底すること。
- 節目ごとの議論：進捗の節目で「このまま続けるべきか、計画を修正すべきか」を率直に話し合うこと。
フルスクラッチは一度着手すると数年単位で後戻りが難しいため、こうした場を経営層自身が設けることが、結果として投資全体を守ることにつながります。
まとめ
ここまで、レガシーシステム刷新のフルスクラッチ・オーダーメイド開発について、選ばれる背景から、投資承認の進め方、プロジェクト体制とベンダー選定、リスク管理と教訓までを見てきました。
フルスクラッチは期間12〜30ヶ月、費用3,000万円〜2億円規模に達することもある最大級の投資です。そのため、承認プロセスには、複数年度予算化や投資回収シミュレーション、先送りリスクのナラティブといった、通常のシステム導入とは異なる経営レベルの合意形成が求められます。
10億円規模の刷新を成功させた事例が示すように、体制構築、ベンダー選定、業務標準化の徹底は、投資を成果に結びつけるうえで欠かせません。一方で、過去の失敗事例が示すように、現場ニーズの軽視や組織風土の問題は、投資規模にかかわらずプロジェクトを頓挫させます。
技術手法そのものの詳細は、姉妹記事の「レガシーシステムのモダナイゼーション」もあわせて参照してください。そのうえで、まずは自社にとってのコア領域を見極め、経営層を巻き込んだ投資判断のプロセスを設計することから始めるとよいでしょう。
フルスクラッチは、技術基盤の刷新であると同時に、企業が今後何年も事業をどう支えていくかという経営の意思決定です。だからこそ、目先の予算承認を通すことだけを目的にせず、投資後の運用・成長まで見据えた計画を、経営層と現場が一体となって描くことが、プロジェクトを成功へ導く最も確実な方法です。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。