基幹システムのRFP/要件定義書/提案依頼書について

基幹システムの導入プロジェクトを動かそうとするとき、最初の大きな関門になるのが「RFP（提案依頼書）や要件定義書を、どう作ればよいのか」という問題です。基幹システムは会計・販売・購買・在庫といった会社の根幹に関わるため、要件が曖昧なまま開発や製品選定に進むと、後から「想定していた業務に合わない」「追加開発で費用が膨らんだ」という事態を招きます。逆に、RFPと要件定義をしっかり作り込めば、ベンダーから的確な提案を引き出せ、見積の精度も上がり、プロジェクト全体のリスクを大きく下げられます。

本記事は、基幹システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から体系的に解説する「要件定義特化」の記事です。Fit to Standard（標準適合）を前提とした要件定義の進め方、現状業務とのギャップを洗い出すFit&Gap表の作り方、インボイス・電子帳簿保存法といった法対応要件、データ移行・クレンジング要件、そして連携要件まで、リサーチで得た知見とあわせて具体的に解説します。読み終えるころには、自社のRFPに盛り込むべき項目と、その優先順位が見えてくるはずです。なお、基幹システムの全体像をまだ把握していない方は、まず基幹システムの完全ガイドから読むことをおすすめします。

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

Fit to Standardを前提とした要件定義の進め方

基幹システムの要件定義で、近年とりわけ重視されるのがFit to Standard（標準適合）の考え方です。これは、自社の現行業務にシステムを合わせるのではなく、パッケージの標準機能に業務を合わせていくという発想です。カスタマイズを最小限に抑えることで、導入コストと将来の保守負担を下げ、法改正対応もベンダーのアップデートで吸収できるようになります。

要件定義の出発点は、現状の業務フロー（AsIs）を可視化することです。受注・在庫・出荷・請求・入金・仕入・支払といった一連の業務を、誰が・いつ・どんな手順で・何を使って行っているかを書き出します。このとき、現行業務をそのまま正解とせず、「なぜこの手順なのか」「本当に必要か」を問い直す姿勢が大切です。長年の慣行で続いているだけの非効率な手順は、システム導入を機に見直す対象になります。

次に、システム導入後にあるべき業務の姿（ToBe）を描きます。標準機能を前提に、どの作業が自動化され、どの帳票が不要になり、どこに人の判断が残るのかを整理します。ToBeを描くことで、現行業務を惰性で引き継ぐのではなく、業務改革（BPR）の視点で要件を組み立てられます。Fit to Standardは「標準に合わせて妥協する」のではなく、「標準を活用して業務を改善する」前向きな取り組みだと捉えることが、成功の分かれ目です。

要件定義を進めるうえで見落とされがちなのが、推進体制の明確化です。基幹システムは複数の部門にまたがるため、情報システム部門だけで要件をまとめると、現場の実態と乖離し、後で反発を招きます。要件定義の段階から、経理・営業・購買・倉庫といった各部門の代表を巻き込み、経営層がプロジェクトにコミットする体制を作ることが、Fit to Standardを成立させる前提になります。

標準適合の判断には、しばしば部門間の利害調整が伴います。「この業務は標準に合わせる」という決定には、現場の抵抗がつきものです。だからこそ、意思決定を担うPMO（プロジェクト管理組織）と、経営層の後ろ盾が必要になります。RFPには、自社側の推進体制と意思決定の仕組みを明記し、ベンダーにも体制面での支援を求めるとよいでしょう。要件定義書は機能要件の集まりであると同時に、プロジェクトを推進する合意形成の記録でもあるのです。

Fit&Gap表の作り方とギャップの埋め方

Fit to Standardを実務に落とし込むための中心ツールが、Fit&Gap表です。これは、自社が必要とする業務要件を一覧化し、各要件がパッケージの標準機能で満たせるか（Fit）、満たせずギャップがあるか（Gap）を整理する表です。ギャップが見つかった要件について、どう対応するかを決めることが、要件定義の核心になります。

Fit&Gap表は、業務プロセス単位で要件を細分化し、それぞれに判定を付けていきます。基本的な列構成は、業務カテゴリ、具体的な要件、標準機能での対応可否（Fit／Gap）、ギャップ時の対応方針、優先度、概算工数です。たとえば「得意先別の単価表を出し分けたい」という要件に対し、標準機能で対応できればFit、できなければGapと判定し、Gapなら「運用で回避」「設定で対応」「追加開発」のいずれかを記入します。

判定を付ける際に重要なのが、要件ごとの優先度です。すべてのギャップを追加開発で埋めようとすると、カスタマイズ費が最小100万〜300万円、標準的でも500万〜1,000万円、大規模では1,000万〜3,000万円以上と膨らんでいきます。そこで、「必須・推奨・任意」といった優先度を付け、本当に必須のギャップだけを追加開発の対象とします。任意の要件は標準機能や運用での回避に寄せることで、コストを抑えられます。Fit&Gap表は、こうした取捨選択を可視化する意思決定のツールなのです。

Fit&Gapで難しいのは、標準に合わせたくても合わせられない要件への対処です。維持が必須の会社ルールや、得意先から求められる特定の帳票・運用は、簡単に標準へ寄せられません。たとえば、特定の大口得意先が独自の納品書フォーマットを要求している場合、それを無視すると取引そのものに影響します。こうした「譲れないギャップ」をどう扱うかが、要件定義の腕の見せどころです。

解決の方向性は、まず「本当に譲れないのか」を業務部門と詰め直すこと、次に標準機能の設定の範囲で代替できないかを探ること、それでも残るギャップだけを追加開発の対象とすることです。この調整には、業務とシステムの両方を理解した上で現場と対話できる力が求められます。RFPの段階で、こうしたギャップ調整をベンダーがどう支援してくれるかを問うことも有効です。標準適合の理想と現場の現実の間を、誰がどう埋めるのか。ここを曖昧にしないことが、プロジェクト後半の混乱を防ぎます。

法対応要件とデータ移行・クレンジング要件

機能要件と並んで、RFPに必ず盛り込むべきなのが、法対応要件とデータ移行要件です。とりわけデータ移行は、機能の検討に比べて軽視されがちでありながら、プロジェクトの遅延と追加コストの最大の発生源になりやすい領域です。要件定義の段階で、ここを具体的に詰めておくことが、後の予期せぬ事態を防ぎます。

法対応要件では、インボイス制度と電子帳簿保存法への対応を具体的に書き出します。インボイスについては、登録番号・適用税率・税率別の消費税額を満たした適格請求書を発行できること、受領した請求書の登録番号を管理できることなどを要件化します。電子帳簿保存法については、電子取引データをタイムスタンプ付きで保存できること、日付・金額・取引先で検索できることといった保存要件を明記します。

あわせて要件化したいのが、将来の法改正への追随方針です。税制や会計基準は定期的に改正されるため、その対応がベンダーのアップデートで無償提供されるのか、都度個別開発で追加費用が発生するのかは、長期コストを大きく左右します。クラウド型やサブスクリプション型では保守費の範囲で法改正対応が提供される傾向があり、オンプレミス型では都度の改修費がかかりやすい点を踏まえ、RFPで「法改正対応の費用負担はどうなるか」を明確に問うことが賢明です。

データ移行要件は、RFPでもっとも軽視されやすく、しかしもっとも危険な領域です。実際に、20年分のデータが3つのシステムに分散していた商社では、統合に約4ヶ月、移行費用が数百万円規模に膨らんだ事例があります。要件定義では、移行対象のデータ範囲、各データの量、データの品質状態、クレンジングに必要な工数を具体的に見積もります。何年分の取引履歴を移すのか、どこまでをマスタとして引き継ぐのかを明確にすることが起点です。

クレンジングの要件では、勘定科目の統廃合による重複、得意先・商品マスタの表記揺れ、コード体系の不統一といった、品質上の問題への対処方針を定めます。安易に古いデータを削除して移行を急ぐと、後で過去の取引履歴が参照できないリスクが生じるため、何を残し何を捨てるかの基準づくりも要件に含めます。RFPでデータ移行を曖昧にすると、ベンダーの見積もそこを薄く見積もり、後から追加費用として跳ね返ってきます。移行要件を機能要件と同じ重みで書き込むことが、プロジェクトの安定運営の鍵です。

連携要件と非機能要件のRFPへの落とし込み

RFPを完成度の高いものにする最後の要素が、連携要件と非機能要件です。機能要件が「何ができるか」を定めるのに対し、これらは「どのように外部とつながり、どんな品質で動くか」を定めます。ここを書き込むかどうかで、ベンダーから引き出せる提案と見積の精度が大きく変わります。

連携要件では、どの外部システムと、どんなデータを、どの方式・頻度で連携するかを明記します。ネットバンキングからの入金明細の取り込み、既存会計ソフトへの仕訳連携、ECサイトやPOSとの受注連携などが典型例です。連携方式はAPIによるリアルタイム連携か、CSVによるバッチ連携かを示し、求める即時性を伝えます。連携するデータ項目を具体的に列挙することで、ベンダーは連携開発の規模を正確に見積もれます。

注意したいのは、「連携できる」という回答だけで安心しないことです。CSV連携でも出力フォーマットが固定で自社の会計ソフトの取込形式と合わなければ、手作業の変換が残ります。RFPでは、自社の既存システムの仕様を提示し、連携の現実性をベンダーに検証してもらうことが有効です。連携要件の作り込み不足は、リリース後に「データがつながらず手入力が残った」という不満に直結する、見逃せない論点です。

非機能要件には、セキュリティ、可用性、性能、サポート体制などが含まれます。基幹システムは会社の機微なデータを扱うため、アクセス権限の制御、操作ログの取得、データのバックアップ体制といったセキュリティ要件を明記します。また、どの程度の同時アクセスや取引量に耐える必要があるか、月末月初の高負荷時にも安定して動くかといった性能要件も、自社の取引規模に応じて示すことが大切です。

見落とされやすいのが、導入後のサポート体制と定着支援に関する要件です。基幹システムの失敗原因の多くは、技術ではなく現場の教育不足やマニュアル未整備にあります。だからこそ、操作研修の実施、業務マニュアルの整備支援、稼働後の問い合わせ対応といった伴走の要件をRFPに含めるべきです。riplaはフルスクラッチ受託と国内開発の立場から、機能要件だけでなく、データ移行・連携・定着支援までを見据えた要件定義を一貫して支援します。RFPの完成度が、プロジェクト全体の成否を左右することを忘れないでください。

RFP配布からベンダー選定までの進め方

要件定義書とRFPが完成したら、次はそれをベンダーに配布し、提案を受けて選定する工程に進みます。せっかく作り込んだRFPも、配布と評価の進め方を誤ると、的確な提案を引き出せません。RFPは作って終わりではなく、ベンダーとの対話を通じて要件を磨き上げ、最適なパートナーを選ぶためのコミュニケーションツールです。

RFPには、機能要件や非機能要件だけでなく、自社の事業背景やプロジェクトの目的を盛り込むことが大切です。なぜ基幹システムを導入するのか、どんな課題を解決したいのか、3年後にどんな状態を目指すのかといった背景があれば、ベンダーは表面的な機能対応だけでなく、目的に沿った提案をしてくれます。あわせて、自社の規模・取引量・既存システムの構成といった前提情報を提示することで、提案と見積の精度が上がります。

また、RFPには評価基準をあらかじめ明示することが有効です。機能の充足度、費用、導入実績、サポート体制、データ移行の支援力など、何を重視して選ぶのかを示せば、ベンダーはその観点に沿って提案を組み立てます。評価基準を社内で先に固めておくと、複数の提案を公平に比較でき、「価格だけで選んで後悔した」という事態を避けられます。RFPは、自社が何を求めているかを正確に伝える文書であると同時に、選定を公正に進めるための基準でもあるのです。

ベンダーから提案を受けたら、見積金額の比較だけでなく、要件への対応方針を丁寧に確認します。とくに注目したいのが、Fit&Gap表で挙げたギャップに対し、各ベンダーがどう対応すると提案しているかです。標準機能で吸収できるとするのか、設定で対応するのか、追加開発を要するのか。同じ要件でも、製品やベンダーによって対応方法とコストが大きく異なるため、ここを見比べることで、自社に適したパートナーが見えてきます。

提案書だけで判断せず、実際の画面を見るデモを依頼することも重要です。デモでは、自社の代表的な業務シナリオを提示し、それがどう実現されるかを確認します。とくに、消込のイレギュラー処理や、自社固有の帳票、連携の動きといった、要件定義で論点になった部分を重点的に見ます。実物を見ると、提案書では分からなかった操作性や制約が明らかになります。データ移行や定着支援の進め方についても、具体的な実績を聞いて確認しましょう。riplaはフルスクラッチ受託と国内開発の立場から、RFP作成だけでなく、提案評価やデモ確認の観点づくりまで、発注側の視点に立った支援を行っています。

RFPと要件定義書の役割は、ベンダー選定が終わったら終わりではありません。むしろ、契約後の開発フェーズで、認識のズレを防ぐ基準として活き続けます。何を作るかを文書で合意しておけば、開発の途中で「言った・言わない」の食い違いが起きたとき、立ち返るべき拠り所になります。要件定義書は、発注側とベンダーの双方を守る、共通の約束事なのです。

とはいえ、要件は開発の過程で変化することもあります。実際に手を動かす中で、当初の想定が現実に合わないと判明したり、より良い方法が見つかったりします。重要なのは、こうした変更を口頭で済ませず、要件定義書を更新して合意し直すことです。変更の経緯と理由を記録に残せば、後で振り返ったときに判断の根拠が分かります。要件定義書を「作って終わりの書類」ではなく、プロジェクト全体を通じて育てていく生きた文書として扱うことが、認識のズレによる失敗を防ぐ最後の鍵になります。

まとめ

基幹システムのRFP・要件定義書づくりを振り返ると、その要諦は「Fit to Standardを前提に現状とあるべき姿を整理し、Fit&Gap表でギャップの取捨選択を可視化し、法対応・データ移行・連携・非機能の各要件を具体的に書き込む」という一連の作業に集約されます。AsIs/ToBeの整理と経営層の巻き込みが標準適合の土台を作り、Fit&Gap表が追加開発の範囲を見極め、データ移行・クレンジング要件が予期せぬコストの発生源を抑え、連携・非機能要件がベンダーの見積精度を高めます。要件を曖昧にしたまま進めると、追加開発の膨張やデータ移行の遅延という形で、必ず後から跳ね返ってきます。

RFPを作るときに大切なのは、機能の網羅性だけでなく、標準に寄せる発想と、譲れない要件の見極めを両立させることです。すべてを現行業務に合わせようとせず、本当に必須のギャップだけを追加開発の対象とすることが、過剰投資を防ぎます。riplaはフルスクラッチ受託と国内開発の立場から、業務から逆算した要件整理、Fit&Gapの調整、データ移行の品質担保、現場定着の支援までを一貫してお手伝いします。全体像の確認には、あらためて完全ガイドをご活用ください。

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