基幹システム/ERP刷新を経営会議で承認してもらうには、フルスクラッチで作り直すのか、標準パッケージやクラウドERPに乗り換えるのか、それとも両者を組み合わせるのかという方向性を示すだけでは不十分です。人月単価や多重下請け構造を踏まえたベンダー選定、J-SOXなどの内部統制対応コストを含めた投資判断まで見通した比較軸をそろえて初めて、稟議は前に進みます。
本記事では、選定前に整理すべき自社の課題、刷新アプローチの3つの種類、ベンダー/SIer選定で比較すべき評価軸、稟議・投資判断のための評価軸、RFI/RFPからデモ・PoCまでの進め方、そして選定の失敗を避ける方法を解説します。経営層への説明を任される担当者の方が、比較検討を始める前の論点を漏れなく押さえられる内容です。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・基幹システム/ERP刷新の完全ガイド
選定前に整理すべき自社の課題
刷新アプローチを比較する前に、まず自社がどこで刷新を停滞させているのかを特定する必要があります。技術的な機能比較から入ってしまうと、経営層と現場の間にある本当の対立点を見落としたまま候補を絞り込むことになりかねません。
決裁フローと調達プロセスの停滞箇所を可視化します
多くの企業では、経営層の「安く早く」志向と現場の「安全確実」志向がかみ合わないまま、ベンダーや手法選定のフェーズだけで1〜2ヶ月を費やしています。この停滞が、複数階層の決裁フローによるものなのか、コスト・効果シミュレーションの材料不足によるものなのかを切り分けることが、選定方針を決める前提になります。CxOが数年単位で交代する企業文化では、中長期投資の判断が先送りされやすい傾向もあわせて確認しておくとよいでしょう。
実務では、稟議書のドラフトを作成する前に、過去の類似投資案件がどの段階でどれだけの時間を要したかを振り返ると、自社の決裁構造の癖が見えてきます。障害が発生してから受動的に刷新を検討する展開が繰り返されているのか、それとも自律的な投資判断がそもそも例外的なのかによって、経営層への説明資料の作り方は変わります。前者であれば期限プレッシャーを可視化する資料が、後者であれば競合や業界動向を踏まえた説明が効果的になります。
現行踏襲の要望がどの業務領域に集中しているかを把握します
現場からの「今までと同じ操作性にしてほしい」という現行踏襲の要望は、多くの場合すべての業務に均等に出るわけではありません。帳票や承認経路に強いこだわりが出る部門もあれば、標準化に前向きな部門もあります。どの業務領域で現行踏襲の圧力が強いかを事前に把握しておけば、Fit to Standardをどこまで推進できるアプローチなのかという観点から刷新方式を選びやすくなります。あわせて、J-SOXなどの内部統制やグループガバナンスが費用構造に与える影響、多重下請け構造による人月単価の開きといった費用面の論点も、この段階で整理しておくと後工程の比較が具体的になります。
課題を洗い出す際には、部門ヒアリングを個別に行うだけでなく、決裁フロー・現行踏襲・費用構造・監査対応という4つの観点を横断する一枚のシートに整理すると、経営層への説明が一貫します。グループ会社を抱える企業では、親会社と子会社で温度差が生じやすいため、どの子会社がどの観点で最も抵抗が強いかも、この段階で把握しておくと選定方式の絞り込みが早まります。
刷新アプローチの3つの種類
主な刷新アプローチは、標準パッケージやクラウドERPに合わせるFit to Standard型、独自要件をゼロから作り込むフルスクラッチ型、そして共通業務をパッケージに任せ独自業務のみ個別開発するハイブリッド型の3つです。名称よりも、自社の独自業務がどこにあり、その独自性に投資し続ける事業上の理由があるかを見極めることが重要です。
Fit to Standard型は法改正対応と標準化の速さが強みです
標準パッケージやクラウドERPの機能に業務を合わせるFit to Standard型は、ベンダー側の継続的な更新によって法改正や制度変更への追随がしやすく、複数拠点・複数グループ会社の業務を標準化しやすい点が強みです。ただし、現場の現行踏襲要求が強い企業では、標準化の推進そのものが社内政治的な難所になりやすく、経営層のリーダーシップとBPRの推進体制が伴わなければ十分な効果を発揮しません。
Fit to Standard型を選ぶ場合でも、標準機能への統一をどの範囲まで求めるかは業種・業態によって濃淡が出ます。会計・人事のように業界横断で共通化しやすい業務は標準化の効果が出やすい一方、受発注や生産管理のように自社独自の商流を反映してきた業務は、標準機能に寄せることで現場の実務が回らなくなるリスクもあります。選定段階で、標準化を徹底する業務と、当面は現行を維持する業務を切り分けておくと、後の要件定義がスムーズになります。
フルスクラッチ型とコア・サテライト型ハイブリッドの判断基準
フルスクラッチ型は、事業の競争力に直結する独自の業務ロジックや、標準機能では対応しきれない基幹連携を作り込める一方、要件定義から保守、法改正への継続対応まで自社側で担う範囲が大きくなります。日本のSIビジネスには「低リスク・長期安定ビジネス」という商習慣が根強く、ユーザー企業側のIT自律性が低下して丸投げ体質に陥ると、必要以上にフルスクラッチへ寄ってしまう組織的な傾向があることにも注意が必要です。共通化しやすい契約・会計処理などのフロント業務をパッケージやクラウドに任せ、確定したデータを既存の基幹システムへ渡す部分だけを個別開発するコア・サテライト型のハイブリッドは、大企業や複数事業を持つ企業で現実的な折衷案になります。どちらを正のデータとするか、再送・取消時の処理をどちらが担うかを事前に決めておくことが、ハイブリッド構成を機能させる鍵です。
ベンダー/SIer選定で比較すべき評価軸
刷新アプローチの方向性が定まったら、実際に発注するベンダー・SIerを比較します。機能の提案力だけでなく、契約構造や責任範囲まで含めて評価することが、後工程のトラブルを防ぎます。
多重下請け構造と人月単価の妥当性を確認します
国内のSIer業界では、元請けから複数の下請けへ再委託される多重下請け構造が一般的で、人月単価は発注先によって大きく異なります。おおまかな目安として、大手SIerでは150万〜200万円程度、中小のSI企業では80万〜120万円程度、フリーランスエンジニアでは50万〜80万円程度とされ、再委託が重なるほど中間マージンが積み上がり、コストパフォーマンスが悪化しやすくなります。提案段階で、どこまでを元請けが直接担当し、どこから再委託になるのかを開示してもらい、品質基準・検査・秘密保持・知的財産権・損害賠償を元請け責任として整合できるかを確認します。
統制対応の実績と並行運用の設計力を確認します
J-SOXなどの内部統制やセキュリティ監査への対応が求められる企業では、要件定義段階から権限設計・監査証跡の実装を含めた提案ができるかどうかが評価軸になります。あわせて、ビッグバン方式を避け、新旧システムの並行運用や段階移行をどう設計するかという提案の具体性も重要な判断材料です。事業価値のまとまりごとに分割発注・段階承認を進めるトランシェ方式のような進め方の提案経験があるかどうかも、大規模刷新では確認しておきたい点です。
提案書の内容だけでなく、実際に手を動かす担当者のレベル感も評価対象にする必要があります。提案フェーズには経験豊富なメンバーが登場し、実行フェーズになると経験の浅いメンバーに入れ替わるという体制上のギャップは、多重下請け構造のもとで起こりやすい問題です。契約前に、要件定義から稼働までの主要フェーズごとに、どのような役割の担当者が何名関与するのかを確認しておくと、後工程での品質低下を予防しやすくなります。
稟議・投資判断のための評価軸
技術的な適合度だけでは、経営層の投資判断は通りません。稟議に持ち込む際には、費用対効果を定量的に示す評価軸を用意しておく必要があります。
コスト・効果シミュレーションで経営層と現場の乖離を埋めます
経営層の「安く早く」という志向と、現場の「安全確実」という志向の乖離を埋めるには、初期投資額、段階移行のスケジュール、運用コスト削減見込みを定量的に示すコスト・効果シミュレーションが欠かせません。コンサルタントやPMOには、現場の「現行踏襲したい」という要望をそのまま受け入れるのではなく、こうした定量データを提示して経営層のトップダウン判断を後押しする役割が求められます。
内部統制・監査対応コストを投資対効果に組み込みます
大企業向けの統合管理を含む初期費用は数千万円から1億円を超えることもあり、マスタデータクレンジングだけで数百万円以上の追加コストが発生することもあります。年間の保守運用費用は初期導入費のおおむね15〜20%程度が目安とされ、内部統制部門の新設や国内外子会社への往査、監査法人への外部委託といった監査対応コストが稼働後も継続的に発生します。これらを投資判断のシミュレーションに含めずに稟議を通そうとすると、稼働後の追加予算申請という形で経営層の不信を招きかねません。
RFI/RFPからデモ・PoCまでの進め方
比較軸が定まったら、実際の選定プロセスに落とし込みます。RFI・RFPで候補を絞り、デモとPoCで実現性を確かめるという段階を踏むことで、選定活動そのものが社内合意形成の材料にもなります。
RFI/RFPで2〜3社にショートリスト化します
RFI・RFPを通じた提案評価では、対象範囲、現行システムの規模、想定する刷新アプローチ、統制要件を提示し、机上検証によって2〜3社程度にショートリスト化します。この段階では、多重下請け構造の開示や実績確認も含め、机上の情報だけで判断できる範囲を絞り込むことに注力します。
実機デモ・サンドボックスPoC・パイロット試行の順に進めます
ショートリスト化した候補には、実機デモンストレーションとFit&Gap検証を依頼し、標準機能ではカバーできない差分を特定します。次に、サンドボックス環境での試験導入PoCを数週間から1ヶ月程度かけて実施し、非機能要件を含めて実証します。最後に、パイロット拠点や特定部門での試行によってリスクを分散させ、他部門への展開に備えます。このプロセス全体の目的は、技術確認以上に「組織の意思決定を円滑にすること」にある点を、選定担当者は意識しておく必要があります。
選定の失敗を避ける方法
よくある選定の失敗は、機能一覧やベンダーの提案力だけで判断し、検証範囲や責任分界を軽視することです。実際の事例から得られる教訓を踏まえ、選定プロセスに検証と責任の観点を組み込むことが重要です。
検証範囲を予算・期間の都合で安易に絞り込まないようにします
ある製造業の海外子会社でのERP導入では、期間10ヶ月・人員20名・予算200万ドルという体制のなかで、Fit&Gap検証をサンプリング方式に留めた結果、勘定科目データの重複が見過ごされ、最終的に決算訂正にまで発展した事例があります。この教訓は、時間や予算が限られているという理由で検証範囲を安易に絞り込むことの危険性を示しています。選定段階のRFPには、検証範囲を全数とするか一部サンプリングとするかを明記し、発注側が主体となってユーザー受入テストに関与する体制を条件として盛り込むことが有効です。
丸投げを避け発注側が責任分界を主導します
多重下請け構造のもとでは、引継ぎ不足や品質管理の不一致、契約条件の不整合が、伝言ゲームのような情報伝達の齟齬を生み、属人化やベンダーロックインにつながりやすくなります。発注側がプロジェクト全体を丸投げせず、契約書やNDAで再委託の可否・範囲・責任の所在を明確にし、当事者意識を持って進行管理に関与することが、選定後のトラブルを防ぐ最も基本的な方法です。具体的な製品を比較したい場合は、基幹システム/ERP刷新のパッケージ・クラウド製品一覧もあわせてご確認ください。
選定に着手する前に確認しておきたいポイント
候補を比較し始める前に、自社の体制と評価プロセスそのものを点検しておくことで、選定が長期化したり、決定後に社内で蒸し返されたりする事態を防げます。
最終判断の権限者と評価基準の統一方法を決めておきます
評価担当者ごとに自由採点すると、営業説明の分かりやすさに評価が引っ張られやすくなります。「デモで確認」「仕様書で確認」「契約条項で確認」のように確認方法を統一し、未確認の項目は点数を付けず保留にするルールを、比較を始める前に決めておきます。あわせて、最終的にどの役職が投資判断を下すのか、稟議の承認ルートも事前に確認しておくと、選定完了後の停滞を防げます。
刷新の全体像と用語の整理も先に済ませておきます
刷新、モダナイゼーション、新規のERP導入といった言葉の違いを社内で統一できていないと、比較検討の途中で議論が噛み合わなくなることがあります。基幹システム/ERP刷新の基本的な考え方や、経営判断としてなぜ・いつ刷新するのかという論点は、基幹システム/ERP刷新とはで整理していますので、選定作業に入る前に関係者間で認識をそろえておくことをおすすめします。
まとめ
基幹システム/ERP刷新の選定では、決裁フローの停滞箇所や現行踏襲の圧力といった自社課題を特定したうえで、Fit to Standard型、フルスクラッチ型、コア・サテライト型ハイブリッドという方向性を選びます。そのうえで、多重下請け構造や人月単価、統制対応の実績というベンダー評価軸と、コスト・効果シミュレーションや監査対応コストという投資判断の評価軸をそろえ、RFI/RFPからデモ・PoCまでの段階を踏んで候補を絞り込むことが重要です。
検証を軽視せず段階的に確度を高めます
時間や予算が限られているからといって検証範囲を安易に絞り込むと、稼働後の決算訂正のような重大な手戻りにつながりかねません。RFI/RFPによる机上検証、実機デモ、サンドボックスPoC、パイロット試行という段階を丁寧に踏み、発注側が主体となって検証に関与する体制を確保することが、選定の確度を高めます。
自社の評価軸を整えてから候補製品の比較に進みます
まずは自社の決裁フローの停滞箇所、現行踏襲の圧力が強い業務領域、投資判断に必要な統制対応コストを整理してください。評価軸が明確になれば、具体的な候補製品の比較にも進みやすくなります。標準パッケージやクラウドERPでは吸収しきれない独自業務や、既存の基幹システムとの複雑な連携が必要な場合には、フルスクラッチ開発やハイブリッド構成も有力な選択肢です。riplaはフルスクラッチ開発の立場から、選定前の要件整理、既製パッケージと基幹システムをつなぐ連携設計、独自業務に合わせた個別開発まで支援しています。
▼全体ガイドの記事
・基幹システム/ERP刷新の完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。