レガシーシステム刷新のPoC・プロトタイプ・モックアップ開発について

レガシーシステム刷新におけるPoC（概念実証）・プロトタイプ・モックアップ開発は、単なる技術検証の一工程ではなく、経営層が「本当にこの投資を実行してよいのか」を判断するための意思決定ゲートとして機能します。COBOLで書かれたメインフレームや、長年の改修で属人化した「塩漬け」システムを対象とする刷新プロジェクトは投資規模が大きくなりやすく、いきなり本開発の稟議を通そうとしても、経営層は「本当に実現できるのか」「投資に見合う効果があるのか」という不確実性を理由に判断を先送りしがちです。「レガシーシステムのモダナイゼーション」記事がPoCを現場・経営層双方の合意形成の”見せ方”として扱うのに対し、本記事はPoCを予算承認プロセスに組み込む実務、すなわちPoC自体の予算をどう稟議で通し、その結果をどう次フェーズの投資判断に接続するかという切り口を中心に解説します。数千万円から数億円規模の投資を一度に承認してもらうことが難しい大企業ほど、PoCという小さな投資判断の積み重ねが、結果的に本開発着手までの最短ルートになるケースが少なくありません。

本記事では、レガシーシステム刷新においてPoCが投資判断のゲートとして果たす役割から、PoCが必要になる背景、稟議を通すためのPoCの予算とスコープ設定、ベンダー選定とPoCを組み合わせる「コンペ型PoC」という進め方、そしてPoC結果を次の投資判断につなげる意思決定基準までを体系的に解説します。刷新の必要性は感じているものの本予算の稟議に踏み切れずにいる方はもちろん、これからPoCの計画を立てようとしている方にとっても、投資判断を前に進めるための実践的な視点が身に付く内容です。ブラックボックス化したシステムほど「やってみないとわからない」領域が多いからこそ、PoCの設計そのものが投資判断のスピードを左右します。情報システム部門の担当者だけでなく、稟議を最終的に承認する経営企画部門や財務部門の関係者にとっても、PoCがどのような役割を持つ工程なのかをあらかじめ理解しておくことは、審査時間の短縮につながります。

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

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

PoCが投資判断のゲートとして果たす役割

レガシーシステム刷新における投資規模は、対象がCOBOLやメインフレームであるほど数千万円から数億円に達することが珍しくありません。これほどの投資を一度の稟議でいきなり承認してもらうのは、どれだけリスクを丁寧に説明しても経営層にとって現実的ではありません。そこでPoCは、本開発への投資を小さく分割し、「まず小さな予算で実現可能性とリスクを見極め、その結果を踏まえて本予算を判断する」という段階的な意思決定を可能にするゲートの役割を果たします。PoCという言葉を単なる技術検証の枠組みとして捉えるのではなく、投資委員会や経営会議における「Go/No-Go判断のための小さな投資」として位置づけることが、レガシー案件特有の大規模投資を前に進める鍵になります。特にCOBOLやメインフレームのように対応可能な技術者が希少な領域では、経営層自身が技術的な実現可能性を直感的に判断できないケースがほとんどであり、PoCという客観的な検証結果を挟むことでしか、投資判断に必要な確信を得られない場面が多くあります。逆に言えば、PoCという工程を省略して本開発をいきなり発注してしまうと、経営層は不確実性を抱えたまま巨額の意思決定を迫られることになり、稟議が長期間停滞する、あるいは十分な検討がないまま見切り発車で承認され後になって問題が噴出する、といったどちらの結末にも転びやすくなります。

PoCが果たす機能は大きく2つに分けられます。1つ目は技術検証としての機能で、自動変換ツールの変換率・正確性・パフォーマンスの検証、新旧システムの「機能等価性（回帰検証）」の証明など、本当にその移行手法でレガシーシステムを刷新できるのかを技術的に確認します。2つ目は合意形成ツールとしての機能で、現場の抵抗感を払拭し、経営層の投資判断を後押しする役割です。現場担当者にプロトタイプを実際に操作してもらうことで「今のやり方を変えたくない」という心理的抵抗を緩和し、経営層に対しては小規模な成果を実証することで投資対効果を可視化し、初期の成功体験を次の投資判断への推進力に変えていきます。本記事では、この2つの機能のうち、特に投資判断・予算承認との接続に重心を置いて掘り下げます。技術検証と合意形成は別々に進めるものではなく、同じPoCの中で並行して積み上げていくべき成果であり、どちらか一方が欠けると次フェーズの稟議で必ずと言っていいほど厳しい質問が返ってくる点も押さえておく必要があります。

現状アセスメントからパイロット選定、自動変換ツールによる技術検証、機能等価性の回帰検証、並行稼働による最終検証という一連の技術的なプロセスは、対象システムの言語や基盤によって検証内容が大きく異なるため、実務上は専門のエンジニアやアーキテクトを交えて計画することが不可欠です。こうした詳しい進め方については、「レガシーシステムのモダナイゼーション」のPoC・プロトタイプ・モックアップ開発に関する記事で詳しく解説しています。本記事では技術検証の実務プロセスは最小限にとどめ、そのPoCを社内でどう稟議にかけ、どうベンダー選定や本予算化に接続していくかという、意思決定プロセスとしての側面に絞って解説を進めます。技術検証の内容そのものを深く知りたい担当者と、稟議・予算承認の実務を知りたい担当者とでは求める情報が異なるため、社内で複数の役割の担当者が関わる場合は、両方の記事をあわせて共有しておくと認識合わせがスムーズです。

PoCが必要になる背景（なぜ投資判断にPoCが不可欠なのか）

新規のWebサービス開発であれば、要件定義と設計を丁寧に行うことで開発着手前にある程度の確実性を確保できます。しかしレガシーシステム刷新の場合、対象システムそのものの全体像が正確に把握できていないという前提から出発するため、要件定義書だけを見て投資を判断すること自体に無理があり、事情が大きく異なります。

長年の継ぎ足し開発による技術的負債、ドキュメントと実態が乖離するブラックボックス化、担当者しか仕様がわからない属人化を抱えたシステムでは、事前の要件定義だけでは「本当に移行できるのか」という不確実性を払拭できません。経営層としては、この不確実性が解消されないまま数千万円から数億円規模の投資を承認することはリスクが大きすぎます。だからこそ、本開発の前段階で小規模なPoCを実施し、想定していたリスクが実際にどの程度顕在化するのかを確認するプロセスが、投資判断において必須のステップとなります。株主や取締役会に対する説明責任を負う経営層にとっては、「なぜその投資を実行したのか」を後から問われた際に、客観的な検証プロセスを経ていたという事実そのものがガバナンス上の裏付けになるという側面も見逃せません。PoCを経ずに本開発の稟議だけを求めても、経営層から「まず検証してから」という差し戻しを受けるのが一般的です。差し戻しを受けてから慌ててPoCを企画すると、結果的にプロジェクト全体のスケジュールが後ろ倒しになるため、稟議を出す前の段階からPoCの実施を織り込んだ計画を立てておくことが、遠回りに見えて最も早く本開発にたどり着く進め方になります。

レガシーシステム刷新は、システムを入れ替えるだけでなく業務プロセスと組織文化を変革する取り組みであるがゆえに、現場には「これまでのやり方を変えたくない」という心理的抵抗、いわゆる「チェンジモンスター」が必ず発生します。これを放置するとシステムの形骸化に直結するため、稟議を通した後の定着フェーズで苦労することになります。PoCの段階で現場のキーパーソンを巻き込み、新しいシステムによって残業が減る、入力ミスが減るといった具体的なメリットを実際に体感してもらうことで、稟議を通す前の段階からチェンジマネジメントを先取りして進めることができます。長年同じ業務フローに慣れ親しんだ現場ほど変化への抵抗は強くなりがちですが、PoCという「まだ本決定ではない、試しに触ってみる段階」だからこそ、現場担当者も比較的率直な意見を出しやすく、本開発着手前に潜在的な懸念を洗い出せるという副次的な効果も期待できます。経営層にとっても、現場の反応を伴ったPoCの結果は、投資判断の材料として説得力を増します。稟議の場で「技術的には実現可能」という報告だけを提示するよりも、「実際に現場が使ってみて業務時間が短縮された」という定性的な声を添えることで、投資対効果の説明に人間味と具体性が加わり、意思決定者の腹落ちを早める効果も見込めます。PoCの実施結果を社内報告会や社内報で共有し、対象部門以外の従業員にも刷新の意義を伝えておくことも、後続フェーズでの全社的な協力を得やすくする地道ながら効果的な工夫です。

稟議を通すためのPoCの予算とスコープ設定

PoC自体にも予算が必要である以上、PoCの実施そのものを稟議にかける必要があります。ここでのポイントは、本開発の稟議とは異なる、小さく通しやすい稟議として設計することです。本開発と同じ粒度・同じ承認フローでPoCの稟議を申請してしまうと、せっかく段階的に投資判断を進めようとした意図が失われ、結局は本開発と同等の審査時間がかかってしまう点に注意が必要です。

PoCの稟議を通しやすくするためには、対象範囲をシステム全体ではなく、最もリスクが大きい、あるいは最も効果が見えやすい一部の機能に絞り込むことが有効です。範囲を絞ることで予算規模を小さく抑えられるため、部門決裁レベルで承認が完結し、取締役会クラスの承認を待たずに着手できるケースも少なくありません。稟議書には、PoCの目的（何を明らかにするための検証か）、検証項目、期間、費用、そしてPoC終了時にどのような結果が出れば本開発に進むのかという判断基準をあらかじめ明記しておくことで、承認者が「小さな投資でリスクを見極められる」と判断しやすくなります。あわせて、PoCで得られる知見が本開発のどの工程・どの予算項目に直結するのかを稟議書の中で明示しておくと、承認者は「単発の実験費用」ではなく「本開発コストを引き下げるための先行投資」として評価しやすくなり、承認のハードルが下がります。目的が曖昧なまま「とりあえず試してみたい」という稟議は、承認者に不安を与え差し戻しの原因になります。逆に、対象範囲を絞りすぎて検証の意味が薄れてしまうケースもあるため、コアとなる業務ロジックのうち技術的難易度が最も高い部分、あるいは事業インパクトが最も大きい部分を選ぶという基準を持っておくと、スコープ設定の判断に迷いにくくなります。

レガシーシステム刷新のように依頼先の実績が期間・成果を大きく左右する領域では、複数の候補ベンダーに同一条件で小規模なPoCを実施してもらい、その結果を比較した上で本契約の相手先を決定する「コンペ型PoC」という進め方が有効です。提案書の内容や過去実績だけでは見極めにくい「実際に自社の対象システムを解析させたときの精度・スピード・報告の分かりやすさ」を、複数社を横並びで比較できるため、ベンダー選定の説得力が格段に高まります。コンペ型PoCを実施する場合は、参加ベンダーごとに一定の謝礼を用意する、あるいは本契約時に費用を還元するといった条件を事前に取り決めておくことで、質の高い提案を集めやすくなります。参加ベンダー数が多すぎると社内の評価工数が膨らみ、逆に稟議までのスケジュールを圧迫してしまうため、事前のRFIや実績確認である程度候補を絞り込んだ上で、2〜3社程度でコンペ型PoCを実施するのが現実的なバランスといえます。稟議資料に「複数社を実際に比較検討した上での選定である」という事実を盛り込めることも、経営層への説明材料として大きな価値を持ちます。特に監査や内部統制の観点から相見積もりの実施が求められる企業では、コンペ型PoCの実施記録自体がガバナンス上のエビデンスとしても機能するため、稟議承認だけでなく事後の説明責任という面でも有効な進め方といえます。

PoC結果を次の投資判断につなげる意思決定基準

PoCを実施して終わりにせず、その結果を確実に次の投資判断へと接続することが、稟議プロセス全体を停滞させないための最後の要です。PoCの実施自体が目的化してしまい、結果の評価と次の意思決定への橋渡しが曖昧なまま時間だけが過ぎてしまうケースは、レガシーシステム刷新のプロジェクトで実際によく見られる停滞パターンの一つです。

PoC終了後の判断は、変換率・正確性・パフォーマンスといった定量的な技術検証結果と、現場の受容度や経営層の懸念解消度といった定性的な材料の両方をもとに下します。定量結果が良好でも、現場の抵抗が強いまま本開発に進めば、稼働後の定着に苦労するリスクが残ります。逆に現場の反応が良くても、技術的な実現可能性に致命的な懸念が残る場合は、手法の見直しを検討すべきです。あらかじめ「この項目がこの水準を満たせば本開発に進む」という判断基準をPoC計画の段階で合意しておくことで、結果が出た後の解釈をめぐる社内議論を最小限に抑え、意思決定のスピードを落とさずに次のフェーズへ進むことができます。判断基準を数値だけで固めすぎると、想定外の好材料や懸念点を見落とすこともあるため、最終判断の場には定量基準に加えて、プロジェクトオーナーや現場責任者の総合所見を述べる時間を設けておくことも実務上有効です。

PoCで得られた具体的な数値やスクリーンショット、現場担当者のコメントは、本開発の稟議資料において最も説得力のある材料になります。「机上のシミュレーションではなく、実際に自社のシステムで検証した結果」として提示することで、経営会議での質疑応答にも具体的な根拠をもって答えられるようになります。PoCの段階でコンペ型の比較検討を行っていれば、ベンダー選定の妥当性についても同じ資料の中で説明でき、稟議のプロセスを一つにまとめてスムーズに進めることができます。PoCから本開発への移行に時間が空きすぎると、せっかく醸成した現場や経営層の機運が薄れてしまうため、PoC計画の段階から本予算化までのスケジュールをあらかじめ描いておくことが望ましいです。理想的には、PoCの結果報告会と次年度予算の編成タイミングを合わせて設計しておくことで、承認された投資判断がそのまま予算計画に反映され、着手までの空白期間を最小限に抑えることができます。

まとめ

本記事では、レガシーシステム刷新のPoC・プロトタイプ・モックアップ開発について、投資判断のゲートとして果たす役割から、PoCが必要になる背景、稟議を通すための予算とスコープ設定、ベンダー選定と組み合わせる「コンペ型PoC」、PoC結果を次の投資判断につなげる意思決定基準までを体系的に解説しました。レガシーシステム刷新は投資規模が大きいからこそ、いきなり本開発の稟議を通そうとするのではなく、PoCという小さな投資判断を経由することで、経営層・現場双方の合意形成を段階的に積み上げていくことが現実的な進め方です。技術検証の具体的な進め方は姉妹記事の「レガシーシステムのモダナイゼーション」もあわせてご参照いただきつつ、まずは通しやすいスコープでPoCの稟議を設計することから始めることをお勧めします。レガシーシステム刷新は着手前の不確実性が大きいほど経営層の意思決定が慎重になりやすいものですが、裏を返せば、PoCという小さな成功体験を丁寧に積み上げることさえできれば、本開発への投資判断は驚くほどスムーズに進むこともあります。PoCの企画段階から「この検証結果がどのような形で稟議資料に使われるのか」を逆算して設計しておくことこそが、レガシーシステム刷新における意思決定のスピードを左右する最も実務的なポイントです。

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

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