基幹システム/ERP改修のPoC・プロトタイプ・モックアップ開発について

基幹システム/ERP改修とは、会計・人事給与・生産管理・販売管理・在庫管理といった企業の背骨となる基幹システムについて、システム全体を作り替えるのではなく、特定の機能や特定モジュールのみを対象にした部分的・小規模な修正を指します。同じ基幹システム/ERPというテーマを扱いながらも、記事「基幹システム/ERPのモダナイゼーション」は5つの技術手法を横断的に扱う総論（HOW）、記事「基幹システム/ERP刷新」は経営層の投資判断（WHY/WHEN）、記事「基幹システム/ERP更改」は契約起点の期限（外圧型WHEN）、記事「基幹システム/ERPリニューアル」は現場ユーザーの体験起点、記事「基幹システム/ERPリアーキテクチャ」はアーキテクチャそのものの技術深掘り、記事「基幹システム/ERPリプレイス」は製品・ベンダー選定の意思決定を、それぞれ主軸に据えています。これらに対し本記事群が扱う基幹システム/ERP改修は、全面刷新に踏み切るほどの予算を確保できない企業が、法改正対応や特定モジュールの改善だけを低予算・短期間で完結させるという「部分最適」の選択肢に焦点を当てます。予算も期間も限られる改修だからこそ、PoC・プロトタイプ・モックアップといった検証工程をどこまで実施すべきかという判断が、他の6波以上にシビアに問われます。

本記事では、基幹システム/ERP改修におけるPoC・プロトタイプ・モックアップ開発に焦点を当て、改修前に不可欠な影響範囲調査と現行仕様の可視化、モックアップ・プロトタイプによる関係者間の認識合わせ、小規模改修においてPoCを省略してよいかの判断基準、そして低予算・短期間で検証を進める実務までを体系的に解説します。開発期間や費用そのものの詳細は基幹システム/ERP改修の開発期間・スケジュール・納期、保守・運用費用・ランニングコストの各記事に譲り、本記事では「限られた予算の中で、どこまで検証してから改修に着手すべきか」という実務に焦点を当てます。

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

▼全体ガイドの記事
・基幹システム/ERP改修の完全ガイド

小規模改修でも検証工程が欠かせない理由

「小規模な改修なのだから検証は不要ではないか」という考え方は、基幹システムの改修においては必ずしも正しくありません。基幹システムは企業の屋台骨であり、改修に失敗した場合は業務停止や手戻りコストといったダメージが甚大になりやすいためです。まずは、改修という文脈における検証工程の位置づけを整理します。

本格的な改修に多額の投資を行う前に、小さく試作品を作って検証することで、技術的な実現性（作れるか）や現場の業務適合性（使えるか）を最小限のリスクとコストで確かめ、本開発へ進むべきか（Go/No-Go）を客観的に判断することが、検証工程の最大の目的です。この目的自体は全面刷新でもリプレイスでも共通ですが、改修の場合はプロジェクトの規模自体が小さいため、検証工程にかけられる予算と期間も自ずと限られます。だからこそ「何を、どこまで検証するか」の見極めが、他の6波以上に重要になります。

検証したい「不確実性」の種類によって、3つの手法を使い分けます。モックアップは、内部のデータ処理を持たず画面レイアウトのみを作成するもので、新しい画面の情報配置について関係者間で完成イメージをすり合わせるために用います。プロトタイプは、画面遷移を伴う触れる試作品を作成するもので、実際の業務フローに沿って現場担当者が迷わず操作できるかを検証し、仕様の認識ズレをなくします。PoC（概念実証）は、新技術や外部ツールが既存の基幹環境で意図通りに動作するかを実証するもので、見た目や使い勝手は問わず、最小限のコードで技術的なGo/No-Goを判断します。改修プロジェクトでは、この3つのうちどれが本当に必要かを見極めることが、限られた予算を無駄にしないための第一歩です。

改修前に不可欠な影響範囲調査と現行仕様の可視化

改修に特有の検証として、新規開発にはない「既存システムの現行仕様をどう可視化するか」という工程があります。

基幹システムの派生開発における不具合分析では、「変更の影響範囲を正しく洗い出せなかった」ことに起因する手戻り工数が287時間で最大の要因となっています。レガシー化した基幹システムは仕様がブラックボックス化していることが多く、現行仕様が分からないまま改修に進むと、認識のズレや手戻りで費用が大きく膨らみます。そのため、いきなりソースコードを変更するのではなく、まず現状のシステムを「読める化（可視化）」し、影響範囲を漏れなく特定する事前調査が不可欠です。進め方としては、調査を「事前調査」「変更箇所調査」「影響調査」の3ステージに分ける標準調査プロセスが有効とされています。事前調査では変更箇所を探すことはせず、処理の構造を把握するための構造図作成に徹し、この構造図作成は1関数あたり約1分を目安として、使用できる工数から調査範囲を事前に計算して決定します。

可視化の具体的な事例として、作成者が退職し誰も改修できなくなったAccessの受発注システム（ブラックボックス状態）に対し、AIを用いて全機能を解析・仕様書化し、現行の挙動を完全に把握した上でWebシステムへ移行し、約4ヶ月で3拠点での利用を開始したケースがあります。この事例が示すように、可視化にかける工数は決して無駄なコストではなく、後工程の改修そのものをスムーズに進めるための先行投資です。小規模改修だからといってこの工程を省略すると、かえって手戻りによる追加コストと納期遅延を招くリスクが高まります。

モックアップ・プロトタイプによる関係者間の認識合わせ

改修において、関係者間での完成イメージの認識のズレを防ぐことは、本番実装後の大幅な修正（手戻り）を減らす上で重要な役割を果たします。

モックアップは、アニメーションや動作の実装を行わず、画面の色使いやレイアウトなどのビジュアルデザインのみを確認するための静的なサンプルであり、デザインツールで非常に簡易に作成できます。一方、プロトタイプは、画面遷移やボタンアクションなど一部の機能を実装し、ユーザー体験や操作性をテストするための動的なサンプルであり、モックアップよりも作成の難易度が高くなります。進め方としては、まずワイヤーフレームをもとにモックアップを作成してビジュアルデザインを固め、その後にプロトタイプを作成してユーザーに実際に操作してもらい、不要な機能や使いづらい箇所を検証・改善していくのが一般的です。改修対象が特定の画面や帳票に限定される場合は、この工程自体もごく短期間・低コストで完結させやすいという利点があります。

改修対象のモジュールが、既存の基幹システムや周辺システムと連携している場合、モックアップやプロトタイプの検証範囲には、その連携部分の見え方や操作フローも含めておく必要があります。改修は既存システムの一部だけを変更するため、変更箇所と変更しない箇所の境目で操作感に違和感が生じやすく、この境目を現場担当者に実際に確認してもらうことが、稼働後の混乱を防ぐポイントになります。特に、既存システムのアーキテクチャやセキュリティ制約の中で外部システムとの連携が正常に行えるか、大量データ処理時に要件を満たすパフォーマンスが出せるかといった技術的な論点は、モックアップやプロトタイプではなく次に述べるPoCで確認すべき領域です。

小規模改修においてPoCを省略してよいかの判断基準

限られた予算の中でPoCまで実施すべきかどうかは、改修プロジェクトの担当者が最も悩みやすい論点の一つです。判断基準を整理します。

PoCは、モックアップやプロトタイプとは目的が異なり、「新しい技術が自社の環境で実際に機能するか」という技術的な実現可能性や投資対効果を検証するための手法です。中小企業のPoCにかかる費用相場は30万〜300万円、期間は2〜8週間であり、本開発の10〜20%程度の予算を目安とします。既存システムの軽微なレイアウト変更や、既存ルールの範囲内での業務フロー変更など、「技術的な不確実性が低い（すでに実現できることが分かっている）」小規模改修においては、PoCを省略し、モックアップやプロトタイプによるUI/UXの検証に留めるべきです。改修の多くはこのケースに該当し、検証コストを最小限に抑えられます。

一方で、AI-OCRなどの新技術の組み込みや、未知の外部システムとの新たなAPI連携など、「本当にその精度や速度で動くのか」という技術的リスクが高い要素を含む改修であれば、小規模であってもPoCは必要になります。ただし、限られた予算の小規模改修でPoCを実施する場合は、検証対象の業務を1つに極小化し、明確な成功基準（KPI）や不合格時の撤退ライン（Go/No-Go判定）を事前に合意した上で短期間で実施することが、検証だけで予算が尽きる「PoC貧乏」を防ぐための鉄則です。改修の規模に見合わない大がかりなPoCを組んでしまうと、本末転倒になる点に注意が必要です。

低予算・短期間で検証を進める実務

ここまでの整理を踏まえ、改修における検証工程を実務としてどう進めるべきかをまとめます。

改修プロジェクトにおける検証工程は、対象を絞り込むほど費用対効果が高まります。改修対象の中でも「本当に不確実性が高い部分」だけをPoCの対象とし、それ以外はモックアップ・プロトタイプによる簡易な確認に留めるという線引きを、プロジェクト開始時点で発注者・開発会社の双方が合意しておくことが重要です。あわせて、何を確認できればGo（本開発着手）とし、何が確認できなければNo-Go（中止・再検討）とするのかという基準を、検証開始前に具体的な数値や条件で定義しておくことで、検証結果の解釈をめぐる後戻りを防げます。

検証工程を依頼する相手を選ぶ際は、モックアップ・プロトタイプ・PoCという3つの手法を使い分けた提案ができるか、そして改修対象となる既存システムの現行仕様を可視化する調査プロセスに慣れているかを確認することが重要です。小規模改修の検証工程は予算も期間も限られるため、過剰な検証プロセスを提案してくる相手よりも、必要最小限の検証で確実にリスクを潰す提案ができる相手を選ぶことが、結果的にプロジェクト全体のコストパフォーマンスを高めます。

まとめ

本記事では、基幹システム/ERP改修におけるPoC・プロトタイプ・モックアップ開発について、小規模改修でも検証工程が欠かせない理由、改修前に不可欠な影響範囲調査と現行仕様の可視化、モックアップ・プロトタイプによる関係者間の認識合わせ、小規模改修においてPoCを省略してよいかの判断基準、そして低予算・短期間で検証を進める実務を体系的に解説しました。技術的不確実性が低い改修であればPoCを省略しモックアップ・プロトタイプに留めることができ、費用相場30万〜300万円・期間2〜8週間を要するPoCが必要になるのは新技術や新たな外部連携を含む場合に限られます。開発期間や費用そのものの詳細は基幹システム/ERP改修の開発期間・スケジュール・納期、保守・運用費用・ランニングコストの各記事に譲るとして、本記事で強調したいのは、改修前の現行仕様の可視化こそが最も投資対効果の高い検証であり、これを省略しないことが、限られた予算を無駄にしないための最大のポイントだという点です。改修に慣れた検証プロセスを持つパートナーに、早めに相談することをお勧めします。

▼全体ガイドの記事
・基幹システム/ERP改修の完全ガイド

株式会社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を創業。