大規模基幹では、独自業務や技術要件を見極め、コアは個別開発、周辺は標準機能やSaaSに分けます。安易な選択は「2025年の崖」に象徴されるレガシー化を招くおそれがあります。
大規模特有のリスクと制約から、選定の軸や費用、保守、構成を見ていきます。全体像は大規模システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・大規模システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
大規模基幹でフルスクラッチが選ばれる理由
フルスクラッチは、パッケージやSaaSより初期費用も期間も大きくなります。それでも大規模基幹で選ばれるのは、既製品では吸収しきれない要件があるためです。
小規模開発では、作らずに済ませればコストを抑えられます。一方、大規模基幹では、作らなければ競争力を保てない場合があります。選ばれる理由は、独自業務、技術要件、規制対応の観点から整理できます。
競争優位の源泉となる独自業務のシステム化
大規模基幹でフルスクラッチが選ばれる最大の理由は、長年培ってきた独自業務が競争力の源泉になる場合があるためです。
- 業務の独自性：他社が真似しにくいノウハウを支える
- 標準機能とのずれ：一般的な業務向けのパッケージでは吸収しきれない
- 投資の位置づけ：競争力を守り、伸ばすための戦略投資となる
製造業の独自生産工程や物流業の特殊な配送ルールは、固有ノウハウの例です。これらを標準フローに当てはめると、自社の強みが失われるおそれがあります。
パッケージは、多くの企業に共通する一般的な業務を効率化するために作られています。そのため、企業固有の特殊なやり方には対応できないことがあります。
競争優位に関わるコア業務は、費用がかさんでも自社の手順をシステム化します。反対に、競争力に関わらない一般業務まで作ると、過剰投資になり得ます。
大規模連携・超高可用性・厳格な法規制対応
独自業務以外にも、大規模特有の技術要件が開発方式を左右します。もう一つの理由は、厳格なセキュリティと法規制への対応です。
- 大規模連携：ERPなど多数の既存システムとリアルタイムに接続する
- 高負荷処理：大規模ECやIoTデータに対応する
- 可用性と性能：独自のデータベースやAPI設計が必要になる
- 規制対応：独自の制御や監査ログなど、法的要件を満たす
既製品では、大規模連携や超高負荷、超高可用性に対応しきれない場合があります。その場合は、システムの根幹から作り込む必要が生じます。
金融・医療・公共機関では、強固な個人情報保護が求められることがあります。不正防止のためのアクセス制御や詳細な監査ログが、法律で義務づけられる場合もあります。
規制要件のなかには、標準機能では満たせず、独自に構築が必要になるものもあります。大規模システムでは、一部停止や情報漏洩が社会に甚大な影響を及ぼします。そのため、非機能要件や法的要件への対応が、フルスクラッチを選ぶ根拠になります。
フルスクラッチとパッケージ・ERPの判断軸
方式の選択は、プロジェクトの成否と稼働後の運用を大きく左右します。独自要件だけを理由にフルスクラッチを選ぶと、後の保守負担に苦しむおそれがあります。
コストを理由にパッケージを選んでも、追加開発で高くつくことがあります。両者を選び分けるには、業務とシステムのどちらを合わせるかを見極める必要があります。
Fit to StandardとFit/Gapの選び分け
選択の基準は、自社業務にシステムを合わせるか、業務をシステムに合わせるかです。
- Fit/Gap：自社業務を起点にシステムを作り込む
- Fit to Standard：パッケージの標準業務に自社業務を合わせる
- 業務別に選択：コアと標準化された周辺業務を切り分ける
Fit/Gapは自社のやり方を変えずに済む一方、作り込みにはコストと期間がかかります。
会計や人事給与は、多くの企業で標準化されている業務です。パッケージなら初期費用を抑えられ、法改正やOS更新への対応もベンダーが行います。そのため、自社が担う維持負担を大幅に軽くできます。
判断の基準は、独自のやり方を維持する価値があるか、業界標準に合わせても支障がないかです。たとえば、競争優位に関わるコア業務では、自社独自の進め方を残す理由になります。
アドオン開発による技術的負債のリスク
パッケージやERPでは、アドオン開発による技術的負債に注意が必要です。
- アドオン：標準機能で足りない部分を追加開発する
- 更新への影響：独自機能との整合性を取る作業が発生する
- 判断の目安：標準機能を優先し、追加機能を最小限にする
独自要件を追加開発で組み込みたくなりますが、大きな落とし穴になり得ます。アドオンが増えるとシステムが複雑になり、定期アップデートに追随しにくくなります。
標準機能の更新ごとに、独自機能との整合性を取り直す必要があります。この負担が技術的負債となり、放置すると更新できず、古い版に固定されることがあります。
ドイツの小売大手Lidlは、レガシーシステムからSAPベースへの移行を試みました。独自要件に固執して追加開発を重ね、約7年間で約660億円（5億ユーロ）を投じましたが、その末にプロジェクトそのものが頓挫しています。
大量のアドオンが必要なら、コア業務をフルスクラッチにするほうが健全な場合もあります。
大規模フルスクラッチの費用・期間・体制の規模感
大規模フルスクラッチは、小規模開発とは桁違いの人員や資金を必要とします。数十万円・数ヶ月で立ち上がる小規模システムに対し、こちらは数億円・数年規模です。複数のベンダーが参加する大所帯になるため、規模感を正しく把握する必要があります。
費用や期間、体制を見誤らないために、各項目の目安を順に見ていきます。
数億円規模の費用と長期化する開発期間
大規模開発は高額で長期になりやすいため、事業価値との釣り合いを判断材料にします。
- 費用：数千万円から1億円以上がベースライン
- 全社基幹：数億円から数十億円に及ぶこともある
- 開発期間：12ヶ月から2年、さらに長引く場合もある
- 人月単価：大手SIerへの委託で150万円から200万円の場合がある
費用の約8割は人件費です。多数のエンジニアが長期間作業するため、労働集約的な開発になります。たとえば、数十名が2年間稼働すれば、それだけで費用が数億円に膨らむ計算です。
大規模開発ではウォーターフォールが主流で、要件定義に全体の約25%を要します。2年のプロジェクトなら、要件定義だけで約半年かかります。契約から稼働までには相当の時間を要するため、発注側は入口の段階から全体の大きさを把握しておく必要があります。
自由度の高さは、設計や実装を自前で行う費用と期間を伴います。独自要件の有無よりも、投資に見合う事業価値があるかを見極める必要があります。
マルチベンダー協働とPMO体制
大規模案件では複数ベンダーと部門を束ねる管理体制が、プロジェクトを左右します。
- 複数ベンダー：各社が得意領域を分担して開発する
- 部門間調整：部分最適の要求を全体最適の観点で裁定する
- PMO：発注側から全体を見渡して管理する組織を置く
単一ベンダーで完結することは稀で、複数社が一つの巨大なシステムを作ります。各社が並行して開発するため、調整しなければ統合段階で破綻しかねません。
多数の部門が関わると、全体最適と部分最適の対立、つまりサイロ化も起こりやすくなります。営業が自部門に都合のよい仕様を求め、経理が別の要求を出すこともあります。こうした対立を放置すれば、システム全体の整合性が崩れます。
PMO（Project Management Office）は、権限を持つ横断的なプロジェクト管理組織です。複数ベンダーの調整や部門間の裁定、全体日程とクリティカルパスの管理を担い、発注側の立場で全体最適を維持します。
技術力のあるベンダーを集めたあとは、発注側がPMOを構築し、マネジメントとガバナンスを整えられるかが問われます。
フルスクラッチの保守負担とレガシー化リスク
フルスクラッチの弱点は、構築後の運用フェーズに現れます。自由に作り込める分、保守を自社または委託先で担い続けなければなりません。
負担への対処を誤ると、システムがレガシー化し、経営上の問題につながります。長期のリスクは、保守負担とレガシー化の両面から見ておく必要があります。
ブラックボックス化・属人化とベンダーロックイン
設計を理解する人が限られると、改修先を替えにくくなり、保守の負担も続きます。
- ブラックボックス化：内部構造を把握する人が限られる
- ロックイン：機能追加や修正を特定ベンダーに頼らざるを得ない
- 継続費用：年間で初期開発費の15%から25%程度がかかる
- 予防策：設計思想や開発経緯を文書化する
独自設計の内部構造は、開発ベンダーや当時の社内担当者だけが知る状態になりやすいです。その結果、他社への移行や内製化が難しくなり、ベンダー主導で保守費が高止まりしても受け入れざるを得ないことがあります。
担当者の退職やベンダー契約の終了で、改修できなくなる事態も起こり得ます。数億円のシステムなら、年間の保守費は数千万円になります。
OS更新やインボイス制度などの法改正も、自社で対応します。フルスクラッチでは、パッケージならベンダーが担う更新対応も、自社の負担として続きます。こうした負担が経営を圧迫します。
担当者が替わっても改修を続けられるよう、設計の背景を残しておく必要があります。
レガシー化と「2025年の崖」
老朽化や複雑化を放置すれば、刷新も維持も難しくなり、経済損失につながるおそれがあります。
- レガシー化：改修の積み重ねで全体像が分からなくなる
- 2025年の崖：刷新できない場合の経済損失が試算されている
- 出口戦略：将来の刷新先まで含めた計画を持つ
属人化やブラックボックス化を放置して長年運用すると、徐々にレガシー化します。改修が継ぎ接ぎになり、全体像の把握や新技術との連携が難しくなります。
経済産業省が警鐘を鳴らしたのは、老朽化・複雑化・ブラックボックス化した基幹システムです。同省の試算では、刷新できなければ2025年以降に日本全体で年間最大12兆円の損失が生じます。
独自性の高い大規模基幹は、保守人材の減少や技術の陳腐化に直面しやすくなります。20年、30年使ったメインフレームの基幹を刷新できず、維持も難しい企業は少なくありません。
フルスクラッチを選ぶなら、長期的なレガシー化リスクと向き合い続ける必要があります。そのため、開発の初期から将来の保守や刷新の道筋を組み込んでおきます。さらに、開発したあとも、数十年にわたって維持・進化できる構造を意識します。
ハイブリッド構成による大規模最適化
現代の大規模開発では、すべてを一つのフルスクラッチで解決するのは現実的ではありません。強みを活かしながらレガシー化を抑える方法が、役割を分散するハイブリッド構成です。疎結合の考え方と、企業での活用事例も見ていきます。
コアと周辺の分離とAPI疎結合
コア業務と周辺業務を分け、それぞれに合った作り方を割り当てます。
- コア業務：フルスクラッチまたはERP標準機能で堅牢に作り込む
- 周辺業務：ローコードやSaaSで短期間かつ低コストに組み上げる
- システム間連携：明確なAPIを介して緩やかにつなぐ
コアには、競争優位に直結する基幹部分を置きます。一方、日報管理、ワークフロー、問い合わせ対応は、差別化が不要な周辺業務の例です。作り込む価値のある部分に集中投資すれば、全業務を抱え込まずに済みます。
疎結合とは、システム同士を密接に絡めず、APIという接点で緩やかにつなぐ設計です。障害や仕様変更が起きても、別システムへの影響を小さく抑えられます。周辺パッケージの更新や法改正にも、柔軟に追随できます。
コアは独自性と堅牢性を、周辺は柔軟性と保守性を受け持ちます。この分担により、独自性を保ったまま、大規模システムのレガシー化リスクを抑えられます。
ハイブリッド最適化の実例
企業事例では、標準機能と独自機能を分けて連携する構成が成果につながっています。
- インフラパーツ製造業：ERPは標準機能に限定し、独自機能を別システムに切り出して連携
- 静岡銀行：勘定系機能を部品化し、ハブ経由で連携する
- 共通する考え方：二者択一にせず疎結合で組み合わせる
あるインフラパーツ製造業では、法改正に対応できない老朽基幹を受けてERPを導入しました。大量のアドオンを避け、意思決定を速めて、システム管理も簡素化しました。
金融機関のミッションクリティカルな事例として、静岡銀行の次世代勘定系では記帳決済機能を部品化しました。また、周辺システムとはハブ経由で疎結合に連携するオープンテクノロジーを活用しました。
従来の勘定系は一体的に作り込まれ、レガシー化やブラックボックス化の温床でした。これに対し、機能を部品化して疎結合にしたことで、柔軟性と保守性が改善しました。
自社の競争力を踏まえてコア業務を切り分ける戦略が、大規模開発の成否を左右します。
まとめ
大規模基幹では、独自業務や技術要件、規制要件がフルスクラッチを選ぶ理由になります。連携や高可用性、法規制への対応は、パッケージでは吸収しきれない場合があります。そのうえで、業務ごとにFit/GapとFit to Standardを使い分け、アドオンを抑えます。
費用は数億円から数十億円、期間は数年に及ぶことがあり、約8割が人件費です。加えて、人月単価は150万円から200万円に達する場合があり、PMO体制も必要です。
運用では保守費用やロックイン、レガシー化のリスクを抱えます。また、「2025年の崖」では、日本全体で年間最大12兆円の損失が試算されています。
コアと周辺をAPIで疎結合につなぐ構成なら、独自性を保ちながら柔軟性を高められます。インフラパーツ製造業や静岡銀行の事例が、その成果を示しています。どの業務をコアとして握るかは、実績を持つパートナーと十分に議論することが大切です。
▼全体ガイドの記事
・大規模システム開発の完全ガイド
▼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を創業。