レガシーシステム刷新の選定ポイント/選び方/種類

レガシーシステム刷新は、パッケージ導入・クラウド移行・フルスクラッチ開発のいずれを選ぶかで、投資額もプロジェクトの進め方も大きく変わります。刷新の必要性は理解していても、いざ検討を始めると、稟議に何を書けばよいのか、ベンダーをどう比較すればよいのか、PoCで何を確認すればよいのかが分からず、検討が停滞してしまう情報システム部門は少なくありません。特にレガシー資産の刷新は、通常のシステム入れ替えよりも移行対象のデータ量が多く、稼働年数が長いほど比較検討に必要な情報も集めにくくなります。

本記事では、レガシーシステム刷新の選定に入る前に整理すべき自社課題、パッケージ移行型・クラウド移行型・フルスクラッチ型という3つの進め方、比較すべき7つの評価軸、RFP作成とベンダー選定の進め方、PoCを投資判断のゲートとして使う方法、そしてプロジェクトの推進体制とガバナンスを解説します。これから候補の絞り込みに入る担当者の方が、稟議に耐えられる比較の材料をそろえられる内容を目指しています。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド

レガシーシステム刷新の選定前に整理すべき自社課題

レガシーシステム刷新の選定は、製品カタログやベンダーの提案を集めることから始めるものではありません。まず、自社のどの基幹システムが、どのような理由でどこまで深刻化しているかを切り分けることが出発点になります。

軽微な仕様変更でも見積りが高額になる、そもそも見積りを出せるベンダーが限られている、という状態は、ブラックボックス化がかなり進んでいるサインです。保守費用の推移を過去3〜5年分さかのぼって確認し、どの程度のペースで増加しているかを数値で示せるようにしておくと、後の稟議説明でも説得力のある資料になります。あわせて、現行システムの設計書や仕様書がどこまで最新化されているかも、選定方式を左右する重要な材料です。

事業戦略に既存システムが追従できていないのか、サポート切れの環境でセキュリティ上の不安を抱えているのか、それとも中身を理解できる人材が社内にごく一部しかいない属人化が問題なのかによって、優先すべき進め方は変わります。複数の課題が重なっている場合でも、どれが最も経営インパクトが大きいかを一つ決めてから比較を始めると、機能の多さだけで判断してしまう失敗を避けやすくなります。あわせて、現行システムを理解している担当者があと何年在籍する見込みか、退職・異動が重なった場合に業務が止まるリスクがどの程度あるかも、優先度を判断する材料になります。

レガシーシステム刷新の3つの進め方

レガシーシステム刷新の進め方は、大きく分けるとパッケージ移行型、クラウド移行型、フルスクラッチ型の3つに整理できます。どれか一つが常に正解というわけではなく、自社の業務がどこまで標準化に適しているかで選び方が変わります。

パッケージ移行型は、ERPなどの業務パッケージが持つ標準機能に合わせて自社の業務フローを標準化していく進め方です。過剰なカスタマイズを避け、パッケージの標準機能に業務を合わせる「Fit to Standard」を徹底できれば導入後の保守性は高まりますが、業界特有の商習慣や独自の承認フローが多い企業では、標準機能とのギャップをどこまで許容できるかが選定の分かれ目になります。ギャップが大きい業務については、パッケージ側にアドオン開発を追加するのか、それとも自社の運用ルールを変えるのかを、機能ごとに個別判断していく作業が必要になります。

クラウド移行型は、既存のオンプレミス環境をクラウド基盤へ移す進め方で、現行構成を保ったまま移行するリホストのような方法から、クラウドサービスの機能を活用しやすいよう作り替えるリアーキテクトまで幅があります。フルスクラッチ型は、独自の業務要件や既存システムとの複雑な連携をそのまま再現したい場合に選ばれる進め方で、期間はおおむね12〜30ヶ月、費用は3,000万円から2億円程度が目安とされます。投資規模が大きくなる分、自由度も高くなるため、既製品では吸収しきれない要件がどこまであるかを見極めることが重要です。

刷新プロジェクトを比較する7つの評価軸

進め方の方向性が定まったら、候補となるパッケージ・クラウドサービス・開発ベンダーを7つの評価軸で比較します。同じ質問をそろえて提示すれば、営業説明の巧拙ではなく適合度で判断しやすくなります。評価軸ごとに担当部門を割り振っておくと、情報システム部門だけで判断がつかない項目についても、法務・経理・現場からの視点を漏れなく集められます。

第一に、自社の主要な業務フローが標準機能でどこまでカバーされ、どこからが追加開発扱いになるかを確認します。第二に、現行システムに蓄積された膨大なデータをどのように移行できるか、移行ツールの有無や移行リハーサルの実施可否を確認します。第三に、初期構築費用だけでなく保守運用まで含めたTCO(総保有コスト)で比較し、クラウド移行であれば1.5〜4年程度での投資回収を見込めるかを確認します。

第四に、同業種・類似規模での導入実績とデータ移行経験を確認します。第五に、権限管理、操作ログ、障害時の対応体制などセキュリティ面を確認します。第六に、本稼働時のダウンタイムや切り戻し手順など移行リスクへの備えを確認します。第七に、稼働後の運用保守体制とSLA(サービス品質保証)が明確にされているかを確認します。これらは「デモで確認」「仕様書で確認」「契約条項で確認」のように確認方法まで記録し、未確認事項は点数を付けず保留にすると、選定後の認識違いを防げます。

RFP作成とベンダー選定の進め方

候補を絞り込んだら、RFP(提案依頼書)を作成してベンダーへ提示し、正式な選定プロセスに進みます。ここでの文書化の精度が、後工程の予算超過やスケジュール遅延を防ぐ鍵になります。口頭説明やヒアリングだけで進めてしまうと、後になって「言った・言わない」の水掛け論が生じやすいため、要求事項は必ず文書として残しておくことが前提になります。

RFPには、対象システムの範囲、現状の課題、削減したい保守費用や工数といった定量目標、希望納期、評価基準を明記します。曖昧な要件定義は予算超過やスケジュール遅延の温床になるため、必須要件と希望要件を分けて優先順位を示すと、実現可能な提案を引き出しやすくなります。RFI(情報提供依頼書)を先に発行し、技術的な実現可能性を事前にすり合わせておく方法も有効です。

ベンダー選定では、同業種・類似規模での導入実績とデータ移行経験、プロジェクト管理・コミュニケーション能力、運用保守・アフターサポート体制という3つの基準が重視されます。プロジェクト失敗の多くはベンダー選定のミスマッチが一因になっているとも指摘されており、提案書の見栄えだけでなく、既存クライアントへの直接ヒアリング(リファレンスチェック)を行うと、実際の対応力を見極めやすくなります。

PoCを投資判断のゲートとして使う方法

レガシー案件のPoCは、技術的な検証だけを目的にするものではありません。次フェーズの本予算化を判断する投資判断のゲートとして位置づけると、稟議の説得力が高まります。

現状アセスメントで洗い出した課題の中からパイロット対象を選び、技術検証と、旧システムと同じ処理結果が得られるかを確かめる機能等価性の回帰検証を行います。ここで得られる変換率、正確性、パフォーマンスといった定量結果を経営会議の意思決定資料に落とし込み、次フェーズである本開発の予算化を稟議にかけるという流れにすると、PoCが単なる技術デモで終わらず、投資判断の材料として機能します。

複数のベンダーに小規模なPoCを競わせる「コンペ型PoC」も有効な進め方です。提案書の説明だけでは分かりにくい技術力や実績を、実際の小規模な検証を通じて見極められるため、本契約前の判断材料が増えます。ただし、PoCにも一定の費用と社内工数がかかるため、あらかじめ評価基準と合格ラインを決めておかないと、比較のための比較に終わってしまう点には注意が必要です。参加ベンダーの数を絞りすぎると比較の意味が薄れ、広げすぎると社内の評価工数が追いつかなくなるため、2〜3社程度を目安に呼びかけるケースが多く見られます。

プロジェクトの推進体制と失敗を避ける方法

選定プロセスを整えても、社内の推進体制が整わなければプロジェクトは頓挫しかねません。ここでは、体制づくりと、よくある失敗要因を選定段階でどう潰しておくかを整理します。

キングジムでは、導入から約20年が経過し過剰な個別カスタマイズでブラックボックス化した販売・物流システムの刷新に、10億円規模の予算でプロジェクトを始動させています。専務がプロジェクト責任者として方針を示し、情報システム部長がプロジェクトマネジメントを担い、業務部門と開発ベンダー、外部コンサルタントが参画する三位一体の体制を組んだ結果、一度頓挫しかけたプロジェクトを再スタートさせ、2024年末に無事リリースしています。この事例では、他社が避けがちな「最も見積金額が高い」コンサルタントを、旧システムの構成を全部洗い出すと明言したことを理由にあえて選定した点も特徴的です。

レガシー案件の失敗には共通したパターンがあります。現場の業務ニーズを軽視したまま要件定義を進めてしまう、ベンダー選定と契約管理が甘くリスクが契約書に反映されない、教育やチェンジマネジメントを後回しにしてしまう、といった要因です。実際に、業務要件に合わないパッケージを選定し要件定義も甘いままプロジェクトを進めた結果、契約が白紙撤回に至り多額の賠償問題に発展した事例も報告されています。海外の事例でも、テストや移行計画が不十分なままERPへ移行した結果、在庫管理が混乱し、短期間で数億円規模の損失と大幅な修正コストが生じたケースが報告されています。選定段階で経営ビジョンと導入目的を定量的に言語化し、現場を巻き込んだ段階的な導入計画を立てておくことが、こうした失敗を避ける前提になります。

レガシーシステム刷新導入前に確認しておきたいポイント

候補の絞り込みが進むと、具体的な進め方や予算の切り分け方について、現場からさまざまな疑問が出てきます。ここでは、選定段階でよく生じる疑問を整理します。

一言では言えません。標準的な業務フローが多く、法改正や機能更新への継続的な追随を重視するならパッケージ移行型やクラウド移行型が第一候補になります。独自の承認フローや基幹システムとの深い連携が事業競争力に直結するならフルスクラッチ型が適しています。両者の中間として、標準化できる業務はクラウドサービスに任せ、独自性の高い部分だけを開発するハイブリッドな組み合わせも選択肢になります。

本開発の予算とは別に、PoC専用の予算枠をあらかじめ確保しておくことをおすすめします。PoCの結果次第で本開発を見送るという判断もあり得るため、本予算に組み込んでしまうと、途中で後戻りしにくくなります。PoCの合格条件とあわせて、上限予算と実施期間も事前に決めておくと、検証が長期化してしまう事態を防げます。稟議の段階で「PoCで何が確認できれば本開発に進むか」という基準まで明記しておくと、経営層の承認も得やすくなります。

必要です。現行ベンダーは経緯を理解している安心感がありますが、その安心感だけで比較を省略すると、本来もっと適した進め方や製品を見落とすおそれがあります。現行ベンダーにも他候補と同じRFPを提示し、同じ評価軸で比較したうえで、結果として継続を選ぶ分には問題ありません。長年の付き合いがある相手だからこそ、あらためて第三者的な視点で見積りと提案内容を確認しておくと、稟議の場でも説明がしやすくなります。

まとめ

レガシーシステム刷新の選定では、保守費用の増加や属人化といった自社課題を切り分け、パッケージ移行型・クラウド移行型・フルスクラッチ型のどれが適するかを見極めることが出発点になります。そのうえで、業務適合度、データ移行、投資対効果、ベンダー体制、セキュリティ、移行リスク、運用保守体制という7つの評価軸で候補を比較し、RFPとPoCを通じて稟議に耐えられる材料をそろえることが重要です。

三位一体の推進体制を早期に組み、経営層への説明では投資対効果とリスクの両面を示すことが、稟議を通すうえで欠かせません。PoCを技術検証で終わらせず、次フェーズの予算化を判断するゲートとして位置づければ、経営会議での意思決定もスムーズになります。あわせて、選定段階で洗い出した失敗要因を防止策としてプロジェクト計画に落とし込んでおくと、稟議の場で懸念点を先回りして説明でき、承認までの往復を減らせます。

レガシーシステム刷新の基本的な考え方や、経営判断としての着手タイミングについては、レガシーシステム刷新とは？｜考え方・特徴・仕組み・目的を解説で解説しています。具体的な候補製品を確認したい場合は、レガシーシステム刷新のパッケージ・クラウド製品一覧を参照すると、共通軸で比較しやすくなります。既製パッケージやクラウドサービスでは対応しきれない独自要件がある場合、riplaはフルスクラッチ開発の立場から、要件整理からベンダー横断の連携構築まで支援しています。

▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。