基幹システムのRFP・要件定義では、現状とあるべき姿を整理し、標準機能との差を見極めることが出発点です。法対応や移行の要件も具体化すると、追加開発や移行のリスクを抑えられます。この記事は、発注する会社の担当者に向けて、RFP・要件定義書・提案依頼書の作り方を解説します。
▼全体ガイドの記事
・基幹システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Fit to Standardを前提とした要件定義の進め方
Fit to Standard（標準適合）は、自社の現行業務にシステムを合わせるのではなく、パッケージの標準機能に業務を合わせる考え方です。基幹システムの要件定義では、近年この考え方が重視されています。
標準機能に業務を寄せると、カスタマイズを抑えられ、導入コストと将来の保守負担を下げられます。さらに、法改正への対応も、ベンダーのアップデートで吸収しやすくなります。
現状業務（AsIs）とあるべき姿（ToBe）の整理
要件定義の出発点は、現在の業務をそのまま正解とせず、導入後に実現したい業務まで描くことです。
- 現状業務（AsIs）：受注から支払までの各業務について、担当者と時期、手順、使用物を洗い出す
- 現行手順の見直し：その理由と必要性を問い、慣行だけで続く非効率な業務を改める
- あるべき姿（ToBe）：標準機能を前提に、自動化する作業、不要になる帳票、人の判断が残る箇所を描く
- 業務改善：AsIsとToBeを基に、現行業務を惰性で引き継がず、BPRの視点で要件を組み立てる
- 標準機能の活用：標準に合わせることを目的にせず、標準機能を使って業務を改善する
経営層の巻き込みとPMO体制の明記
要件定義で見落とされがちなのが、推進体制の明確化です。情報システム部門だけで検討すると、現場とのずれや反発を招くため、推進体制は次のように組みます。
- 部門代表を加える：経理や営業、購買などの担当者が参加する
- 経営層が関与する：Fit to Standardを進める判断を支え、部門間の調整を後押しする
標準適合の判断では現場の抵抗も起こり得るため、意思決定を担うPMO（プロジェクト管理組織）と経営層の後ろ盾が必要です。
RFPには、自社の推進体制と意思決定の仕組みを記し、ベンダーにも体制面の支援を求めます。また、要件定義書は、機能要件と合意形成の記録を兼ねます。
Fit&Gap表の作り方とギャップの埋め方
Fit&Gap表は、Fit to Standardを実務に落とし込む中心的な手段です。自社の要件が標準機能で満たせるかを判定し、FitとGapを分けて対応を決めます。
Fit&Gap表の構成と判定の付け方
Fit/Gap表では、業務プロセスごとに要件を分け、標準機能で満たせるかと、Gapへの対応方針を見比べます。この表は、どの要件を追加開発で埋めるかの根拠を可視化する意思決定のツールです。
- 業務カテゴリ：要件が属する業務プロセス
- 具体的な要件：実現したい業務内容
- 標準機能の可否：FitかGapかの判定
- 対応方針：運用で回避するか、設定で対応するか、追加開発するかを決める
- 優先度・概算工数：重要度と対応規模
たとえば、「得意先別の単価表を出し分けたい」という要件は、標準機能でできればFit、できなければGapになります。
すべてのギャップを追加開発で埋めると、カスタマイズ費が膨らみます。費用は、最小で100万〜300万円、標準的には500万〜1,000万円、大規模では1,000万〜3,000万円以上です。
そこで、要件に「必須・推奨・任意」などの優先度を付け、必須のギャップだけを開発対象にします。任意の要件を標準機能や運用で回避できれば、コストを抑えられます。Fit&Gap表は、こうした取捨選択を一覧にして判断するための道具です。
会社ルールと得意先要求のギャップ調整
Fit&Gapで難しいのは、標準に合わせたくても合わせにくい要件の扱いです。維持が必須の会社ルールや、得意先指定の帳票・運用がこれに当たります。たとえば、大口得意先指定の納品書を無視すると、取引に影響する場合があります。
- 業務部門と、本当に譲れない要件かを再検討する
- 標準機能の設定で代わりにできないかを調べる
- 残るギャップだけを追加開発の対象にする
この調整では、業務とシステムの両方を理解したうえで、現場と対話する力が求められます。加えて、RFPでは、ベンダーがギャップ調整をどう支援するかも確認できます。
標準適合の理想と現場の現実の間を、誰がどう埋めるかを明確にしておきます。曖昧さを残すと、プロジェクト後半の混乱を招きます。
法対応要件とデータ移行・クレンジング要件
機能要件と並んで、RFPには法対応とデータ移行の要件も盛り込みます。特にデータ移行は、機能検討に比べて後回しにされがちですが、遅延や追加コストの大きな発生源になりやすい領域です。そこで、要件定義の段階で内容を具体化しておくと、後から起こる予期せぬ事態を防げます。
インボイス・電帳法の要件のRFPへの明記
法対応では、インボイス制度と電子帳簿保存法の要件を具体化します。RFPには、制度ごとに求める機能を書き込みます。
- インボイス：登録番号、適用税率、税率別消費税額を満たす適格請求書を発行し、受領書類の登録番号を管理する
- 電子帳簿保存法：電子取引データをタイムスタンプ付きで保存し、日付・金額・取引先で検索する
税制や会計基準は定期的に改正されるため、将来の法改正への追随方針も要件化します。また、ベンダーの更新で無償提供されるか、個別開発の追加費用がかかるかで、長期コストは変わります。
クラウド型やサブスクリプション型では、保守費の範囲で対応される傾向があります。一方で、オンプレミス型は都度の改修費がかかりやすいため、RFPで費用負担を問います。
データ移行・クレンジング要件の見積もり方
データ移行は、RFPで軽視されやすく、リスクの大きい領域です。たとえば、20年分のデータが3システムに分散した商社では、統合に約4ヶ月、移行費用は数百万円規模になりました。
要件定義では、移行範囲とクレンジングの対象を、次の観点から見積もります。
- 移行範囲：取引履歴を何年分移すか、どこまでのマスタを引き継ぐかを決める
- データ量・品質：各データの量と状態を確認し、クレンジングの工数を見積もる
- 品質上の課題：勘定科目の統廃合による重複、得意先・商品マスタの表記揺れ、コード体系の不統一を洗い出す
古いデータを急いで削除すると、過去の取引履歴を参照できない恐れがあります。そのため、何を残し、何を捨てるかの基準も要件に含めます。
移行要件が曖昧だと、ベンダーは見積もりを薄く組み、後から追加費用が発生することがあります。このため、移行要件も機能要件と同じ重みで記しておくと、安定した運営につながります。
連携要件と非機能要件のRFPへの落とし込み
RFPを完成度の高いものにする最後の要素が、連携要件と非機能要件です。連携は外部とのつなぎ方、非機能はシステムの品質を定めます。
機能要件は「何ができるか」を定めます。一方で、連携・非機能要件は「どうつながり、どんな品質で動くか」を示します。これらを具体化すると、ベンダーから得る提案と見積もりの精度が高まります。
ネットバンキング・会計ソフト連携の要件化
手作業を残さないために、会計や販売の外部システムとの接続条件を、RFPで明らかにします。
- 連携対象：ネットバンキングの入金明細、会計ソフトへの仕訳、ECサイトやPOSからの受注
- 連携方式：APIによるリアルタイム連携か、CSVによるバッチ連携かを示す
- 連携内容：頻度、即時性、データ項目を具体化し、ベンダーが開発規模を正確に見積もれるようにする
「連携できる」という回答の中身も、確認しておく必要があります。たとえば、CSVの出力形式が会計ソフトの取込形式と合わないと、手作業の変換が残ります。
RFPでは既存システムの仕様を提示し、連携の実現性を検証してもらいます。検証が不足すると、稼働後も手入力が残る不満につながります。
セキュリティ・サポート体制など非機能要件
非機能要件は、扱う機微なデータや取引規模に合わせて定めます。さらに、RFPには品質と支援の条件も示します。
- セキュリティ：アクセス権限の制御、操作ログの取得、データのバックアップ
- 性能・可用性：同時アクセスや取引量に対応し、月末月初の高負荷時も安定して動くこと
- 見落とされやすい導入後支援：操作研修、業務マニュアルの整備、稼働後の問い合わせ対応
技術面だけでなく、現場の教育不足やマニュアルの未整備も、失敗の原因になります。riplaは、フルスクラッチ受託と国内開発の立場から、要件定義を一貫して支援しています。
支援では、機能要件に加えて、データ移行・連携・定着まで見据えます。RFPの完成度は、プロジェクト全体の成否を左右します。
RFP配布からベンダー選定までの進め方
要件定義書とRFPが完成したら、ベンダーに配布して提案を受け、選定に進みます。配布や評価を誤ると、せっかく作り込んだRFPから的確な提案を引き出せません。RFPは作成後も、ベンダーとの対話で要件を磨き、適切なパートナーを選ぶための文書です。
RFPに盛り込むべき背景情報と評価基準
機能・非機能要件に加えて、事業背景と目的もRFPに記すと、業務背景を踏まえた提案を引き出しやすくなります。
- 事業背景と目的：導入理由、解決したい課題、3年後に目指す状態
- 自社の前提：規模、取引量、既存システムの構成など、提案と見積もりの精度に関わる
評価基準もあらかじめ示し、機能の充足度や費用、移行支援力など、重視する点を伝えます。
社内で基準を決めておけば、複数の提案を公平に比べられます。価格だけで選んで後悔する事態も防げます。加えて、RFPは自社の要望を伝えるだけでなく、公正な選定を進めるうえでも役立ちます。
提案評価とデモで確認すべきポイント
提案評価では、Fit/Gapで挙げた要件への対応方法と費用を比べます。製品やベンダーによって差が出るため、自社に合う相手を見極めます。
- 標準機能・設定・追加開発：ギャップごとの解決方法の違い
- 費用と適合性：同じ要件への対応の差を比べ、適したベンダーを判断する
提案書だけで決めずに、実際の画面を使ったデモを依頼します。特に、自社の代表的な業務シナリオがどう実現されるかを確かめます。
デモでは、消込の例外処理や自社固有の帳票、連携の動きなど、要件定義で論点になった部分を重点的に見ます。操作性や制約も、こうした場面で分かります。
データ移行や定着支援の進め方は、具体的な実績を聞いて確認します。また、riplaは発注側の視点から、RFP作成や提案評価、デモ確認の観点づくりを支援します。
契約後の基準としての要件定義書の活用
RFPと要件定義書は、選定後も役割が続きます。要件定義書は開発に合わせて育て、発注側とベンダーの双方を守る共通の約束事です。契約後も、この文書を基準に開発を進め、要件の扱いは文書で決めていきます。
- 契約後の共通基準：作るものを文書で合意し、食い違いが起きたときに双方が立ち返る
- 開発中の要件変更：実作業で想定とのずれが分かったり、より良い方法が見つかったりして、要件が変わることもある
- 変更の合意：要件変更を口頭で済ませず、文書を更新して双方で合意する
- 判断根拠の保存：変更の経緯と理由を記録し、後から根拠を確認できるようにする
まとめ
基幹システムのRFP・要件定義は、Fit to Standardを中心に進めます。そのうえで、AsIsとToBeを整理し、経営層を巻き込んでおくことが標準適合の前提になります。
Fit&Gap表で追加開発の範囲を見極め、法対応やデータ移行などの要件も具体化します。データ移行・クレンジング要件は予期せぬコストを抑え、連携・非機能要件はベンダーの見積もり精度を高めます。
要件が曖昧なままだと、追加開発が膨らみ、データ移行も遅れやすくなります。そのため、標準に寄せる範囲と譲れない要件を見極め、必須のギャップだけを開発対象にすれば、過剰な投資を防げます。
riplaは、フルスクラッチ受託と国内開発の立場から、業務から逆算して要件を整理し、Fit&Gapの調整から、データ移行の品質担保、現場定着まで一貫して支援します。
全体像を確認するには、あらためて完全ガイドをご活用ください。
▼全体ガイドの記事
・基幹システムの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。