基幹システム刷新のRFPで失敗しないための要件定義 — 経営が握る3つの設計点

基幹システム刷新プロジェクトの失敗は、技術や予算よりもRFP（提案依頼書）段階の要件定義で決まることが多い。IPAは「上流工程の作業不備に起因した開発プロジェクトの失敗や運用後のシステムトラブルは、10年以上強調され続けても無くなっていない」と明言しています。経営層がRFPを情報システム部門とベンダーに任せきりにした結果、見積もりの比較だけで選定が進み、開発が始まった後から要件の抜け漏れが次々と表面化する——この構図は、業種を問わず繰り返されています。

経済産業省が2025年5月に公表したレガシーシステムモダン化委員会の総括レポートは、ユーザー企業の61%がレガシーシステムを抱えていることを示しました。大企業ほどその割合は高く、モダン化計画を立てても着手後に問題が顕在化して遅延するケースが相次いでいます。その遅延の根本には技術的な困難よりも、刷新前の要件整理の甘さがあります。長年の運用で現行システムがブラックボックス化するほど、「何を要件として書けばよいか」がわからなくなり、それがRFP作成を困難にさせ、選定後のトラブルの温床となります。

最初の失敗パターンは、現行踏襲型の要件定義です。「現行システムと同じ機能を新システムで実現する」という要件は、一見合理的に見えて業務改革の機会を完全に潰します。基幹システムの刷新は、単なるハードウェアの入れ替えではなく、業務プロセスそのものを設計し直す機会です。現行踏襲のまま新システムを入れると、旧来の非効率が新技術の上に温存され、投資効果が著しく低下します。IPAの「システム再構築を成功に導くユーザガイド」も、業務仕様の理解不足と現行踏襲が再構築固有の最大リスクであると指摘しています。

第二のパターンは、非機能要件の設計が後回しになることです。RFPに記載される要件は機能要件が中心になりがちですが、性能・可用性・セキュリティ・データ移行・保守運用体制といった非機能要件こそが、刷新後のランニングコストとシステム品質を左右します。これらを詳細に定義せずに提案を受けると、ベンダーの解釈や仮定によって見積もりに大きな差が生じ、「最安提案を選んだら後から追加費用が膨らんだ」という結果を招きます。IPAは「非機能要求グレード」という体系的な整理手法を公開しており、RFPの設計に組み込む企業とそうでない企業では、選定後の混乱に明確な差があります。

第三のパターンは、RFP自体をベンダーに依存して作成することです。要件定義の工数と専門性を理由に、情報収集段階から特定のベンダーに依拠すると、そのベンダーに有利な要件がRFPに組み込まれ、実質的な競争が成立しなくなります。前述のモダン化委員会レポートも、IT人材がITベンダー企業に過度に偏在し、ユーザー企業がベンダーに強く依存する「低位安定構造」が固定化していると指摘しました。RFPを書く能力はベンダーを選ぶ能力そのものです。この力をユーザー企業が持てるかどうかが、刷新プロジェクト全体の主導権の分岐点となります。

三つの失敗パターンを回避するには、RFP作成の前段として「As-IsとTo-Beの業務設計」を経営レベルで完了させることが必要です。現在の業務フローを可視化し、刷新後に何をどう変えるかを明確にした上でRFPを書く——この順序が守られれば、現行踏襲の罠は避けられます。非機能要件はTo-Beの業務設計から逆算して定義できます。そしてRFPの質が上がれば、ベンダーの提案の質が上がり、比較評価の基準が明確になります。経営がこの上流工程に関与することが、技術的な問題より先に解決すべき意思決定です。

私たちがRFP設計の支援で重視するのは、「何を書くか」より「何を決めてからRFPを書くか」という問いの立て方です。当研究所はヘルスケア経営の現場で、稼働中の基幹業務を止めずに業務設計を再構築する方法論を培ってきました。現場で検証済みのことしか提案しない——その姿勢から言えば、RFPの前段に業務設計を置くことは、刷新プロジェクトのリスクを最も低減する実装済みのアプローチです。情報システム部門が単独で抱える前に、経営が論点を整理することでプロジェクト全体の質が変わります。

基幹システム刷新の成否は、選んだベンダーよりも、RFPを書く前に何を決めたかで決まります。現行踏襲の排除・非機能要件の先行設計・ベンダー依存の脱却——この三点を経営が主導すれば、刷新プロジェクトは制御可能なものになります。自社のRFP設計や要件定義の論点整理についてご相談のある経営層の方は、ブリーフィング（https://fujii-consulting.jp/contact）でお声がけください。