保守期限が迫るERP、担当者しか仕様を知らない独自システム、部門ごとに分かれたマスタ。基幹システムの刷新を任された情報システム部門やPMOの方は、こうした課題を抱えながら、経営層への稟議と事業部門との合意形成を並行して進めることになります。

その中で最初の大きな分岐点になるのが、どの開発会社をパートナーに選ぶかです。この記事では、大企業の基幹システム刷新に強い開発会社8社をタイプ別に紹介し、選び方、発注形態、進め方、費用の考え方までを解説します。

この記事を読むと理解できること

• 基幹システムの開発会社を探す前に整理しておくべき刷新の前提

• 大企業の基幹システム刷新に強い開発会社8社の特徴

• 大手SIer、ERPパートナー、上流から伴走する会社の違い

• 大企業が基幹システムの開発会社を選ぶときの5つのポイント

• 請負契約と準委任契約の使い分けと発注形態の考え方

• 構想策定から定着化までの基幹システム刷新の進め方

• 基幹システム開発の費用が決まる構造と予算化の考え方

基幹システムの開発会社を探す前に整理したい刷新の前提

基幹システムは、会計、販売、購買、在庫、生産、人事給与など、企業活動の根幹を記録するシステムです。止まれば受注も出荷も請求も止まるため、業務システム全般と比べても求められる信頼性の水準が高くなります。両者の範囲の違いは業務システムと基幹システムの違いで詳しく整理しています。

大企業の刷新では、開発会社に声をかける前に社内で整理しておきたい前提が3つあります。1つ目は刷新の目的です。保守切れへの対応なのか、データを一元化して経営判断を速くしたいのか、業務プロセスそのものを変えたいのかによって、相性の良い開発会社は変わります。

2つ目は対象範囲です。会計だけを入れ替えるのか、販売・購買・生産までを含めて全社展開するのか、周辺の業務システムや既存基幹システムとの連携をどこまで含めるのかを決めておくと、提案の比較がしやすくなります。3つ目は体制で、情報システム部門、事業部門、経営層のうち誰が意思決定者で、PMOをどこに置くのかを明確にしておく必要があります。

この3点が曖昧なまま開発会社を選ぶと、各社の提案がばらばらの前提で出てきてしまい、比較そのものが成り立ちません。刷新全体の考え方は基幹システム刷新の進め方もあわせて参考にしてください。

大企業の基幹システム刷新に強い開発会社8選

ここからは、大企業の基幹システム刷新で候補になりやすい開発会社を紹介します。各社の情報は、それぞれの公式サイトで確認できた内容に限定して記載しています。

株式会社FAKE

株式会社FAKEは、東京・恵比寿に拠点を置き、UI/UXデザイン、業務システムの戦略からUI/UXデザイン、システム開発、新規事業支援、FDE支援、AI開発を提供する会社です。「デザインドリブン®」を掲げ、デザインとビジネスと技術を一体で扱う点に特徴があります。

FDE支援では、大企業DXの上流工程に入り込み、プロトタイプとヒアリングを反復しながら抽象的な議論を具体化します。AIでドキュメント作成も並行して進めるため、関係者の認識合わせと要件定義書の作成を一つのフローで完結できます。基幹システム刷新が失敗する原因を「現場に使われないシステム」と「要件定義や合意形成に時間がかかりすぎること」の2つと捉え、UX起点の業務再設計とプロトタイピングで両方を同時に解決します。

パッケージ導入を前提にせず、AI駆動開発によってスクラッチ開発を低コストで実現し、ベンダーロックインを避ける提案ができる点も強みです。システム開発では、ビジネス理解のあるPdMを中心にチームを組成し、Figmaで詳細を詰めてから実装することでドキュメント作業を短縮します。MVP開発から品質を重視した本開発、保守運用まで対応し、多言語や大規模開発の経験があるメンバーが参加します。

経営陣には、アクセンチュアで経営・デザインコンサルティングに携わったパートナー、米Apple本社でソフトウェアエンジニアからエンジニアマネージャーを務めたパートナー、製造業の基幹システムやAI導入に従事してきた執行役員が在籍しています。要件定義の段階で事業部門と情報システム部門の認識がそろわない、刷新後に現場で使われるか不安があるという場合は、FAKEへのお問い合わせからご相談ください。

確認元: FDE支援 / システム開発

株式会社NTTデータ

株式会社NTTデータは、東京都江東区豊洲に本社を置き、世界70ヵ国以上でITサービスを提供している大手SIerです。コンサルティング、業種別ソリューション、データ・AI、クラウドやネットワークなどのITインフラ・運用サービスまでを幅広く手がけています。

ERP領域では、SAPと自社製ERPの「Biz∫」を中核ソリューションとし、構想策定から導入、保守までを一貫して支援しています。Biz∫は日本の商習慣に合った機能を標準装備したクラウド対応の国産ERPパッケージで、年商500億円以上の大手企業向けと位置づけられています。グローバル展開を含む大規模な刷新で候補に入りやすい開発会社です。

確認元: 会社概要 / ERP(SAP/Biz∫)

株式会社野村総合研究所

株式会社野村総合研究所は、東京都千代田区大手町に本社を置き、コンサルティング、金融ITソリューション、産業ITソリューション、IT基盤サービスを事業としています。

コンサルティングとシステムの両方を事業の柱に持っているため、経営課題の整理から基幹システムの構築、IT基盤の運用までを同じグループ内で検討できる点が特徴です。金融と産業の双方にITソリューション事業を持つため、戦略とシステムを切り離さずに相談したい場合の選択肢になります。

確認元: 会社概要

SCSK株式会社

SCSK株式会社は、東京都江東区豊洲に本社を構え、コンサルティング、システム開発、ITインフラ構築、ITマネジメント、検証サービス、BPOなどを提供する開発会社です。システム開発では、信頼性が重視されるSoRからスピードが求められるSoEまで対応するとしています。

基幹システムの領域では、会計、人事給与、販売・生産管理までを対象とするERP「PROACTIVE」を提供しています。卸売・商社、製造、建設、サービス業向けのベストプラクティスも用意されており、業種別のテンプレートを持つERPを軸に刷新を検討する企業の候補になります。

確認元: 事業内容 / PROACTIVEとは / 豊洲本社

株式会社日立ソリューションズ

株式会社日立ソリューションズは、東京都品川区東品川に本社を置き、ソフトウェア・サービス事業と情報処理機器販売事業を手がけています。

SAP領域では、SAP Best Practices日本版をベースに独自の拡張を加えたSAP S/4HANA向けテンプレート「HITRY/Basic for SAP S/4HANA」を提供しています。販売、在庫、購買、生産、会計などの主要業務を対象に、日本企業向けにパラメータを事前設定した環境や業務フローのサンプルが含まれるため、S/4HANAへの移行を早期に具体化したい企業に向いています。医薬品製造業向けの専用ソリューションも用意されています。

確認元: 会社概要 / HITRY/Basic for SAP S/4HANA

株式会社電通総研

株式会社電通総研は、東京都港区港南に本社を置き、システムインテグレーション、コンサルティング、シンクタンクの機能連携によって企業変革を支援する会社です。

SAP ERPを1995年から取り扱い、上流のコンサルティングから導入、導入後の保守までを一貫して提供しています。S/4HANA移行を検討する企業向けには、ITロードマップ策定支援、アセスメント、コンバージョンを用意しており、影響分析ツール「Panaya」を使って既存環境の利用状況と移行影響度を分析します。SAP以外にもOracle E-Business Suiteを使ったグループ統合会計などを扱っています。

確認元: 会社概要 / SAPビジネスへの取り組み / ERPソリューション

アビームコンサルティング株式会社

アビームコンサルティング株式会社は、東京都中央区八重洲に本社を置き、マネジメントコンサルティング、ビジネスプロセスコンサルティング、ITコンサルティング、アウトソーシングを提供しています。ITコンサルティングには、IT戦略、企画立案、システム開発、パッケージ導入、保守が含まれます。

SAP領域ではSAP S/4HANA Cloud Public Editionの導入サービスを提供し、SAP Business Technology Platformを活用して大規模なコーディングを抑えながら要件に対応するとしています。業務改革とERP導入を一体で進めたい場合に、コンサルティング色の強い選択肢として検討できます。

確認元: 会社概要 / SAP S/4HANA Cloud Public Edition

ULSコンサルティング株式会社

ULSコンサルティング株式会社は、東京都中央区晴海に本社を置き、戦略、オペレーション、テクノロジーに関するコンサルティングを提供しています。ビジネスとテクノロジーの両方に精通した人材による「ダブルコア」と、顧客と同じ目線で価値を生み出す「一心共創」を掲げています。

公開されている大手小売業の基幹システム刷新事例では、基盤の入れ替えにとどまっていた計画のゴールを見直し、マイクロサービスアーキテクチャと、ベンダーロックイン回避を狙った独自フレームワークを提言しています。内製化組織の設置や顧客側技術者の教育も支援しており、上流から技術選定、内製化までを伴走してほしい企業の候補になります。

確認元: 会社概要 / ULSコンサルティングとは / 基幹システム構築事例

基幹システムの開発会社はタイプで得意領域が異なる

紹介した開発会社は、大きく3つのタイプに分けられます。どのタイプが優れているかではなく、自社の刷新の目的と社内体制に合うタイプを選ぶことが重要です。

大手SIerは、体制の厚さと運用まで含めた責任範囲の広さが強みです。一方で、要件が固まってから力を発揮する構造になりやすいため、構想段階の整理は発注側で進めておく必要があります。

ERPパートナーは、パッケージの標準機能とテンプレートを使って短期間で導入を進めることに長けています。ただし、パッケージに業務を合わせる前提が強くなるため、自社の競争力の源泉になっている業務まで標準化してよいかは慎重に判断したいところです。SAP ECCの保守期限への対応についてはSAP 2027年問題で整理しています。

上流から伴走する開発会社は、何を作るべきかが定まっていない段階から入り、関係者の認識をそろえる役割を担います。基幹システムの刷新では、要件定義の遅れや現場の反発が後工程の手戻りにつながりやすいため、このタイプを最初に入れ、実装や運用は別のタイプと組み合わせる進め方も有効です。

大企業が基幹システムの開発会社を選ぶ5つのポイント

ここでは、大企業が基幹システムの開発会社を比較するときに確認したいポイントを5つに整理します。

上流工程から認識を合わせられるか

基幹システム刷新でつまずきやすいのは、開発よりも前の構想策定と要件定義です。事業部門は業務の困りごとを語り、情報システム部門は既存システムとの整合を気にし、経営層は投資対効果を問うため、同じ言葉を使っていても想定がずれていることが少なくありません。

提案の段階で、開発会社が議論をどう具体化するのかを確認しましょう。文書だけで要件を固めるのか、画面や業務フローのプロトタイプを使って関係者に触ってもらいながら合意をつくるのかで、要件定義にかかる期間と精度は大きく変わります。

現場に使われる業務設計ができるか

基幹システムは全社員が日常的に使うものです。機能が要件どおりにそろっていても、入力が煩雑で現場が使いこなせなければ、Excelでの二重管理が残り、データの一元化という刷新の目的は果たせません。

現場の業務を観察し、操作のしやすさまで含めて業務を再設計できる開発会社かどうかは、提案書の画面イメージや過去の進め方から判断できます。UI/UXの専門性を持つ人材がプロジェクトに参加するかも確認したい点です。

パッケージに対してフラットな提案か

自社製品やパートナー契約のあるERPを持つ開発会社は、そのパッケージを軸に提案する傾向があります。それ自体は問題ではありませんが、スクラッチ開発、パッケージ導入、両者の組み合わせを比較したうえでの提案かどうかは確認が必要です。

特に、競争力の源泉になっている業務をパッケージの標準に合わせてよいのか、周辺システムとの連携をどう設計するのかは、開発会社の立場によって答えが変わりやすい論点です。複数の選択肢の長所と短所を説明できる開発会社を選ぶと、稟議の場でも判断の根拠を示しやすくなります。

ベンダーロックインを避ける設計か

基幹システムは10年以上使われることも多く、特定の開発会社にしか仕様がわからない状態になると、改修のたびに交渉力を失います。設計書やソースコードの扱い、技術スタックの選定、内製化への移行支援の有無は、契約前に確認しておきたい項目です。具体的な対策はベンダーロックインの解説記事で紹介しています。

大企業特有の進め方に対応できるか

大企業の基幹システム刷新では、セキュリティ審査、稟議、監査対応、段階移行といった手続きが必ず発生します。開発会社がこれらに慣れているか、PMOと連携して進捗やリスクを報告できる体制を持っているかは、プロジェクトの安定性に直結します。

あわせて、既存基幹システムや周辺システムとの連携をどこまで担えるか、移行期間中の並行稼働をどう設計するかも確認しましょう。全社展開を一度に行うのか、拠点や事業部ごとに段階的に展開するのかによって、必要な体制は変わります。

基幹システム開発会社への発注形態と契約の考え方

基幹システムの開発会社への発注では、工程ごとに契約形態を使い分けることが一般的です。成果物の完成に責任を負う請負契約と、専門家としての業務遂行に責任を負う準委任契約の違いを理解しておくと、契約交渉で迷いにくくなります。

構想策定や要件定義のように、何を作るかがまだ決まっていない工程は、成果物を事前に定義しにくいため準委任契約が向いています。一方、要件が確定した後の設計・開発・テストは、成果物と受入基準を明確にできるため請負契約を選びやすくなります。両者の違いは準委任と請負の違いで詳しく解説しています。

発注形態としては、1社に構想から運用までを一括で任せる方法と、上流工程と実装工程で開発会社を分ける方法があります。一括発注は窓口が一本化される反面、上流で決めた方針がその会社の得意な実装方法に寄りやすくなります。分割発注は各工程に適した開発会社を選べる一方で、工程間の引き継ぎと全体管理を発注側のPMOが担う必要があります。

大企業の場合、上流工程を担う開発会社に要件定義書とRFPの作成支援まで依頼し、その成果物をもとに実装を担う開発会社を選定する進め方も選択肢になります。要件が言語化された状態で複数社から提案を受けられるため、見積もりの比較精度も上がります。

基幹システム開発会社と進める刷新の進め方

基幹システムの刷新は、おおむね次の4つのフェーズで進みます。開発会社によって関与できるフェーズが異なるため、自社がどこからどこまでを依頼したいのかを先に決めておきましょう。

現状分析と構想策定

最初のフェーズでは、現行システムの機能、データ、業務フロー、運用上の課題を棚卸しし、刷新後のあるべき姿を描きます。経営層に投資判断を求めるのはこの段階で、刷新の目的、対象範囲、概算予算、スケジュールを稟議に耐える形で整理する必要があります。

要件定義と開発会社の選定

次に、業務要件とシステム要件を定義し、実装を担う開発会社を選定します。要件定義では、事業部門の担当者に参加してもらい、画面や業務フローのプロトタイプで具体的な使い方を確認しながら進めると、後工程での仕様変更を減らせます。

設計・開発・テスト・データ移行

設計と開発が始まった後は、PMOが進捗、課題、リスクを管理し、仕様変更の判断基準を運用します。基幹システムでは特にデータ移行の比重が大きく、移行リハーサルとユーザー受入テストに十分な期間を確保することが、本番切り替えの成否を分けます。

運用・定着化と継続改善

本番稼働後は、現場への定着支援と、不具合や改善要望への対応が続きます。刷新はゴールではなく、変化する事業に合わせてシステムを育てていく出発点です。保守体制や内製化の方針を、運用フェーズに入る前に開発会社と合意しておきましょう。

基幹システム開発会社に依頼する費用の考え方

基幹システム開発の費用は、対象範囲、ユーザー数、拠点数、連携するシステムの数、データ移行の難易度、パッケージかスクラッチかといった条件によって大きく変わります。そのため、他社の事例の金額をそのまま自社の予算の目安にすることはおすすめできません。

費用の大部分を占めるのは人件費で、関与する人数と期間で決まります。構想策定や要件定義の段階で範囲と優先順位が固まっていないと、開発会社は不確実性を見込んだ見積もりを出さざるを得ず、提示額の幅も大きくなります。逆に、要件が具体化されていれば各社の見積もり前提がそろい、比較しやすくなります。

予算化の際は、初期の開発費だけでなく、パッケージのライセンスやクラウドの利用料、保守運用費、将来の改修費を含めた総保有コストで比較することが大切です。見積もりが他社より明らかに低い場合は、どの作業が範囲外になっているのか、発注側に求められる作業は何かを事前に確認しましょう。

稟議を通すうえでは、最初から全体の金額を確定させるのではなく、構想策定と要件定義を先行して発注し、その成果をもとに開発フェーズの予算を精緻化する段階的な進め方も現実的です。上流工程の進め方や費用について相談したい場合は、FAKEへのお問い合わせをご利用ください。

まとめ

基幹システムの開発会社は、大手SIer、ERPパートナー、上流から伴走する会社というタイプによって得意な領域が異なります。自社の刷新の目的、対象範囲、社内体制を整理したうえで、どのフェーズをどのタイプの開発会社に任せるのかを決めることが、ベンダー選定の第一歩です。

選定では、上流工程で認識を合わせられるか、現場に使われる業務設計ができるか、パッケージに対してフラットか、ベンダーロックインを避けられるか、大企業特有の進め方に対応できるかの5点を確認しましょう。発注形態は工程ごとに請負と準委任を使い分け、費用は総保有コストと段階的な予算化の視点で考えるのが現実的です。

FAKEは、プロトタイプを使った上流工程の合意形成と、UX起点の業務再設計、パッケージを前提にしないAI駆動開発で、大企業の基幹システム刷新を支援しています。要件定義が進まない、刷新後の定着に不安があるといった課題をお持ちの方は、お問い合わせからお気軽にご相談ください。

基幹システムの開発会社に関するよくある質問

大手SIerとERPパートナーはどちらに依頼すべきですか

刷新の方針によって変わります。ERPパッケージの標準機能に業務を合わせる方針が固まっているならERPパートナー、インフラや運用まで含めた大規模な一括対応を求めるなら大手SIerが候補になります。方針自体が固まっていない場合は、まず上流から伴走できる開発会社と構想を整理するのがおすすめです。

上流工程と開発で開発会社を分けても問題ありませんか

問題ありません。上流工程で作成した要件定義書やプロトタイプを引き継げる形で残しておけば、実装を担う開発会社をRFPで公平に選定できます。ただし、工程間の引き継ぎと全体の進捗管理は発注側のPMOが担う必要があるため、社内体制とあわせて判断しましょう。

基幹システムの刷新にはどれくらいの期間がかかりますか

対象範囲や全社展開の方法によって大きく異なるため、一律の期間を示すことは難しいです。会計など一部の領域から段階的に移行するのか、全社一斉に切り替えるのかでも計画は変わります。構想策定の段階で、開発会社と移行方式を含めたスケジュールを検討することが大切です。

スクラッチ開発とパッケージ導入はどう選べばよいですか

競争力の源泉になっている業務はスクラッチ開発で自社に合わせ、会計や人事など標準化しやすい業務はパッケージを活用するといった組み合わせも選択肢です。どちらか一方を前提にせず、業務ごとに比較してくれる開発会社に相談すると、判断の根拠を社内に説明しやすくなります。

開発会社に相談する前に社内で準備しておくことはありますか

刷新の目的、対象範囲、意思決定者とPMOの体制、おおよその予算感とスケジュールを整理しておくと、開発会社からの提案の精度が上がります。現行システムの課題を事業部門と情報システム部門の双方からヒアリングしておくことも有効です。