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

財務システムの要件定義は、現状業務(AsIs)の把握、あるべき業務(ToBe)の設計、標準機能との差(Fit&Gap)の整理を経て、RFP(提案依頼書)にまとめます。

RFPの中身がそろっているほど、各社の提案を同じ条件で比べやすくなります。全体像は財務システムの完全ガイドでも確認できます。

▼全体ガイドの記事
・財務システムの完全ガイド

Fit to Standardを前提とした要件定義

近年の財務システム導入では、Fit to Standardが主流です。自社業務を標準化してシステムに合わせ、カスタマイズはできるだけ避けます。

カスタマイズを多用すると、導入費が膨らみます。さらに、法改正やバージョンアップのたびに改修が必要になり、そのぶん保守費も増えます。

要件定義では、まず標準機能でできることを把握します。自社の業務をそこへ寄せる検討が、コストを管理するうえでの基本になります。

現状業務(AsIs)の把握とヒアリング

要件定義の第一歩は、現状の財務業務(AsIs)を把握することです。業務の範囲は広く、仕訳の起票から月次決算までを含みます。債権消込、支払、予算管理も、一つずつ洗い出します。

  • 担当と手順:誰がいつ、どの手順で業務を進めるか
  • 使用ツール:各業務で何のツールを使うか
  • 業務の背景:なぜその手順なのか、個別対応や暗黙のルールがあるか

経理担当者へのヒアリングでは、表面的なフローだけでなく、手順の背景まで確認します。長年の慣行や得意先・仕入先への個別対応など、Excelに埋もれた暗黙のルールも、Fit&Gapで扱う論点になります。

現状(AsIs)を把握しないまま進めると、要件定義が机上の理想論になり、現場の実態から離れてしまいます。導入の失敗には、経理部門の人員の手薄さやマニュアルの未整備、教育不足といった人的要因もあります。

業務フロー図に加えて、各工程の担当、所要時間、使用ツールを一覧にします。現場の実務を文書に残しておくことは、システムの定着を左右する土台になります。

ToBeモデルとガバナンスの組み込み

AsIsを把握したら、次はあるべき業務の姿(ToBe)を設計します。財務システムの標準機能を前提に、無駄な手作業や属人的な工程を見直します。

失敗事例では、標準を守る意識の薄さや、買掛金残高確定の人的統制の不足が致命傷になっています。そのため、業務をシステムに寄せたフローを描く際は、効率化と合わせて内部統制・ガバナンスも組み込みます。

ToBe設計では、不正やルール逸脱を防ぐ統制を、システムの権限設定や承認フローに落とし込みます。

  • 権限分離:入力者と承認者を分ける
  • 支払承認:一定金額以上の支払に複数承認を必須とする
  • 残高確定:確定手続きをシステム上に記録する

こうした統制を組み込むと、人の善意や注意力に頼っていた管理を、システムで担保できます。効率化と統制の両方が、導入後に経営を守る仕組みになります。

ポイント

標準機能でできることを先に把握し、業務を標準に寄せられるかを見極めます。その際は効率化だけでなく、内部統制も同時に組み込んでおきます。

Fit&Gap表の作り方と現場摩擦の調整

Fit&Gap表の標準準拠、カスタマイズ、運用対応を3枚のカードで示す図。
改修の前に、業務変更や運用で吸収できる範囲も見渡せます。

Fit to Standardを採っても、標準機能で全業務をまかなえるとは限りません。会社固有のルールや得意先からの要求など、標準に当てはまらない部分が残ります。

要件定義の核心は、標準(Fit)との乖離(Gap)を一覧にしたFit&Gap表です。この表があると、関係者が対応方針に合意しやすくなります。

Gapの分類:「標準準拠・カスタマイズ・運用対応」

Fit&Gap表では、標準とずれる項目ごとに、三つの対応方針のうちどれを取るかを決めます。一項目ずつ判断して、カスタマイズを本当に必要な部分に絞ります。

  • 標準準拠:自社のやり方を変えて標準機能に合わせる
  • カスタマイズ:システムを改修して自社の要求を満たす
  • 運用対応:システム外の手作業やルールで補う

判断では、その要求が業務上譲れないか、カスタマイズ費に見合うかを確かめます。カスタマイズ費の目安は、最小で100万〜300万円、標準的な範囲で500万〜1,000万円です。

大規模なカスタマイズでは、1,000万〜3,000万円以上になる目安もあります。一方で、「あれば便利」程度の要求なら、費用との釣り合いを慎重に見ます。

Gapを安易に改修で埋めず、標準準拠や運用対応で吸収できないかを検討します。TCO(総保有コスト)を抑えるうえでも、この検討は欠かせません。

標準化に伴う現場摩擦への向き合い方

業務を標準に寄せる項目では、現場との摩擦が生じます。長年慣れたやり方を変えることへの抵抗は、経理の現場で特に強く出ます。

  • 理由の説明:標準に合わせる理由と、変えると何が楽になるかを伝える
  • 自社で判断:Gapの対応をベンダー任せにせず、業務を理解する自社が決める
  • 外部の支援:業務とシステム、BPR(業務改革)の視点で調整できるパートナーを活用する

Fit&Gapの調整は、表を埋める作業であるとともに、現場の納得を得るための対話でもあります。現場の懸念に耳を傾けることが、導入後の定着を左右します。

riplaはフルスクラッチ受託と業務伴走の立場から、Fit&Gapの調整と現場摩擦の解消を支援します。Fit&Gap表は、社内の合意形成に使うツールでもあります。

ポイント

Gapは改修で埋める前に、標準準拠か運用対応で吸収できないかを検討します。改修の要否は、業務上譲れないか、カスタマイズ費に見合うかで判断し、現場の納得も得ながら決めます。

連携・データ移行・法対応の要件化

データ移行・法対応の要件を、移行範囲、クレンジング、法対応、取引と改正の4パネルで示す図。
見積り前に範囲をそろえると、検討漏れを見つけやすくなります。

機能要件と並んで見落とせないのが、連携、データ移行、法対応です。これらは見積りに大きく影響する一方で、要件定義では曖昧になりやすい領域です。

RFPの段階でこれらを明確に要件化することが、想定外コストを防ぐ最善策です。

ネットバンキング・会計ソフトとの連携要件

連携要件では、外部システムごとに、データの方向・頻度・方式を決めます。方式は、APIかCSVかまで具体化します。

  • ネットバンキング:入出金明細を取り込む
  • 会計・販売管理:既存システムとデータを連携する
  • 給与計算:仕訳を連携する

「連携できればよい」といった曖昧な要件のままだと、ベンダーは連携の範囲を狭く見積もり、後から追加開発費を請求されるおそれがあります。

対象システムごとに、データ項目、連携方向、タイミングを定義し、想定件数も書き添えます。たとえば、ネットバンキングなら、入金明細を日次でCSVから取り込み、月間約500件と記します。

移行データや連携の品質は、API・CSV連携の検討に比べて手薄になりがちです。想定が甘いと、消込の自動化精度が落ち、導入効果が目減りします。このため、連携要件も機能要件と同じ重みで詰めます。

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

データ移行要件は、見積りの隠れた負担になりやすい領域です。RFPでは、次の内容を整理します。

  • 移行範囲:対象年数・移行元・科目や取引先コードの統合・移行後の検証方法
  • クレンジング:重複の名寄せ、科目の統廃合、不要データの判別
  • 法対応:インボイス制度・電子帳簿保存法をどこまでシステムで満たすか
  • 取引と改正:取引形態に応じた適格請求書の発行・保存のほか、税率別経理、電子取引保存、将来の法改正への追従

反面教師となる事例では、20年分のデータが3システムに分散しており、移行に4ヶ月・数百万円かかりました。

移行やクレンジングの工数は、初期の段階から見積もっておくことが欠かせません。要件が曖昧なままだと、後から工数が増えるおそれがあります。

クラウド・サブスク型には、定額保守の範囲内で無償対応する製品があります。これに対して、オンプレ型は、都度高額な追加開発が発生しがちです。この違いをRFPの評価に含めると、長期的なコストを判断しやすくなります。

ポイント

連携やデータ移行は、範囲が曖昧なままだと後から費用が膨らみやすい領域です。RFPの段階で、連携の項目や方向、移行範囲、法対応の範囲まで具体化して、想定外の費用を防ぎます。

RFPに盛り込むべき項目と見積り評価

中央のRFPから背景と自社概要、業務と機能、システム要件、進行と契約へつながる図。
4領域がそろうことで、各社の提案を同じ条件に置けます。

要件が固まったら、RFP(提案依頼書)にまとめて、複数のベンダーに提案を依頼します。RFPは、各社の提案を同じ条件で比べるための文書です。

要件が曖昧なままだと、ベンダーごとに前提が異なり、価格も機能も比べられません。RFPの完成度が、ベンダー選定の精度を左右します。

RFPに必ず盛り込むべき項目

財務システムのRFPには、プロジェクトの前提と要求をまとめます。次の情報を揃えておくと、ベンダーは共通の前提で提案できます。

  • 背景と自社概要:目的、業種・規模・拠点数・利用ユーザー数
  • 業務と機能:AsIs・ToBe、必須・優先・将来の優先度つき機能要件、Fit&Gap表
  • システム要件:連携、データ移行、法対応、性能・セキュリティ・可用性
  • 進行と契約:想定スケジュール・予算感、契約・保守条件

特に機能要件には、優先度を付けておきます。すべてを必須にすると、ベンダーは全要求を満たす必要があるため、見積りが高止まりします。そこで、必須・優先・将来に分けておくと、ベンダーは必須を満たしたうえで、残りをオプションとして段階的に提案できます。

RFPに評価基準と配点を明記すると、提案を客観的に採点でき、選定の公平性と説得力が高まります。RFPは、要求を正しく伝えつつ、公正な選定を進めるためのものです。

見積りの妥当性を判断する観点

提案と見積りを受け取ったら、3〜5年のTCO(総保有コスト)と、要件への対応状況から妥当性を見極めます。

  • 総額:月額や保守も含めた3〜5年のTCOでの比較
  • 費用内訳:カスタマイズ・データ移行・連携開発費の計上の有無
  • 要件との対応:見積り項目と自社要件の対応関係

オンプレ型は、導入サポートが費用構成の約50%を占めます。保守はライセンス費の年15〜22%が目安です。

クラウド型は、費用構成の約80%をサブスクが占めます。初期費用が安くても、月額や保守を積み上げると、総額が逆転することがあります。

財務・基幹システムは価格の透明性が低く、主要19サービスのうち15社が価格非公開だという調査もあります。

相場観を持ってRFPに要件を明記し、見積りを総額で比べることが、適正なコストでの導入につながります。

ポイント

RFPには、必須・優先・将来の区別を付けた機能要件と、評価基準・配点を明記します。見積りは、3〜5年のTCOと要件への対応で妥当性を見極めます。

非機能要件と体制・スケジュールの要件化

ここまでの項目に加えて、非機能要件と体制・スケジュールも明確にします。これらは曖昧になりやすく、システムの信頼性とプロジェクトの成否を左右します。そのため、RFPに盛り込んで、ベンダーの提案を実態に即したものにします。

性能・セキュリティ・可用性の非機能要件

非機能要件では、性能・セキュリティ・可用性を具体化します。RFPには、次の観点を示します。

  • 性能:同時利用者数、月次処理件数、締め処理時間の許容範囲
  • セキュリティ:暗号化、アクセス権限、操作ログ、外部脅威への対策
  • 可用性:必要な稼働率と、障害時の復旧目標時間

財務情報は、企業にとって最も重要なデータです。要件が曖昧なままだと、稼働後にセキュリティの穴や性能の不足が明らかになるおそれがあります。

可用性は、月末の締め処理や支払業務など、停止すると業務が滞る場面を想定して定めます。

クラウド型では、ベンダーが示すサービス品質の保証水準を、要件と照らし合わせます。「速い」「安全」といった言葉も、比べられる形の要件に直す必要があります。

たとえば、同時50ユーザーで月5万件を処理する、といった形で数値にします。稼働率の目安も具体化しておくと、ベンダー間で比較できます。

体制・スケジュールとチェンジマネジメントの要件

体制とスケジュールも、見落とせない論点です。導入後の定着支援(チェンジマネジメント)を含めて、RFPには次の項目を盛り込みます。

  • 推進体制:自社側の担当、ベンダーのPMや業務に精通した担当者
  • 進行計画:意思決定プロセス、稼働時期、マイルストーン
  • 定着支援:操作研修、マニュアル整備、稼働後の伴走サポート

失敗事例には、情シス単独で選定して現場が反発するケースや、経営層の関与が足りず意思決定が遅れるケースがあります。こうした事態を避けるため、要件定義の段階で推進体制を明確にします。

導入失敗の原因には、教育不足やExcelへの固執といった人的要因があります。riplaはフルスクラッチ受託と業務伴走の立場から、体制と定着支援を要件定義に織り込みます。

非機能と体制の要件を詰めることが、機能だけでは測れないプロジェクトの成功確率を高めます。

ポイント

性能・セキュリティ・可用性は数値で、体制・スケジュールは役割と時期で具体化します。曖昧なまま進めると、稼働後の不具合や導入の失敗につながるおそれがあります。

まとめ

財務システムの要件定義とRFPは、AsIsの把握、ToBeの設計、Fit&Gapの分類、連携・移行・法対応の明文化を経て進めます。そのうえで、RFPを仕上げ、TCOで見積りを評価します。

カスタマイズ費は100万〜3,000万円以上と幅があります。そこで、Gapを改修で埋めず、標準準拠や運用対応で吸収できないかを検討することが、TCOを抑える鍵です。

連携とデータ移行の要件が曖昧だと、後から費用が膨らむことがあります。また、要件定義では、効率化と内部統制・ガバナンスを両立させます。

Fit&Gapの調整は、現場の合意を得ながら進めます。曖昧なRFPは、比べられない提案と想定外のコストを招きます。

riplaはフルスクラッチ受託と業務伴走の立場から、AsIsの把握、ToBe設計、Fit&Gapの調整、RFPの整備を支援します。全体像は、財務システムの完全ガイドをご活用ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。