経営管理システムのRFP/要件定義書/提案依頼書について

経営管理システムの要件定義は、業務と差分を整理してRFP(提案依頼書)にまとめると、提案を比べやすくなります。

要件定義書やRFPは、Fit&Gap表や法令・移行・連携の要件を積み上げて作ります。RFPには、背景と目的、予算とスケジュール、評価基準を盛り込みます。全体像は経営管理システムの完全ガイドもご覧ください。

▼全体ガイドの記事
・経営管理システムの完全ガイド

Fit to Standardを前提とした要件定義の考え方

AsIs業務の確認から集計・入力・承認の見直しを経てToBe業務を設計する流れの図解
現状把握を起点に、業務の見直しを導入後の設計へつなげます。

近年の経営管理システム導入では、自社の業務をシステムに合わせるFit to Standardが主流になりつつあります。Fit to Standardは、システムを作り込むより、業務を標準機能に合わせて変える考え方です。どこまで取り入れるかが、費用と期間を左右します。

標準適合とカスタマイズのバランス

要件定義では、まず標準機能で使える業務を最大限に広げます。そのうえで、譲れない部分だけをカスタマイズの候補に残します。

  • 初期費用:カスタマイズを減らすほど、費用を抑えられます。
  • 導入期間:作り込みを減らすほど、稼働までの時間を短くできます。
  • 保守と更新:標準機能を使うと、将来の更新や保守が容易になります。

カスタマイズ費用は、最小で100万〜300万円、標準的な作り込みで500万〜1,000万円です。大規模になると、1,000万〜3,000万円以上に達する場合もあります。

ただし、会社固有のルールや得意先独自の運用は、標準機能と衝突することがあります。そこで、競争力の源泉として維持する業務と、標準に合わせる業務を見極めます。

すべてを標準に寄せると、現場が回らないおそれがあります。一方で、何でもカスタマイズすると、費用と保守負担が増えます。

そのため、標準適合とカスタマイズのバランスは、意図して設計する必要があります。要件定義で最初に大きく判断する点です。

AsIs業務の可視化とToBe業務の設計

要件定義では、まず現状の業務(AsIs)を把握し、そのうえであるべき業務(ToBe)を設計します。把握の際は、経営管理に関わる業務フローを書き出し、誰がどのデータをいつ集め、どう加工し、誰に報告するかを確認します。

また、Excelファイル同士のつながりも追っておく必要があります。この把握を省くと、システム化する対象があいまいになり、要件が固まりません。

AsIsを確認したら、導入後の業務を描きます。ここで大切なのは、現状の非効率な業務をそのままシステム化せず、業務そのものを見直すことです。

  • 集計:手作業で数字をまとめる作業をなくす
  • 入力:同じデータを二重に打ち込む手間の解消
  • 承認:決裁の流れの簡素化

ToBeを描くことで、要件は現状の焼き直しではなく、改善後の業務を実現するものになります。

riplaはフルスクラッチ受託と業務伴走の立場から、AsIsからToBeを描く工程を重視しています。要件定義は、機能一覧ではなく、業務改革の設計図として扱っています。

ポイント

迷ったときは、競争力の源泉として維持する業務だけをカスタマイズの候補に残し、それ以外は標準機能に合わせて業務を見直すと判断しやすくなります。

Fit&Gap表の作り方と活用

Gapへの3つの対応方針を並べた図解
差分ごとに選ぶ方法が、作り込みの範囲を左右します。

要件定義の実務で中心的な役割を果たすのが、Fit&Gap表です。自社の業務要件を並べ、標準機能で満たせるものをFit、差分があるものをGapとして示します。

この表によって、Fit to Standardを具体的な作業に落とし込めます。さらに、製品比較やベンダーへの依頼にも使う基礎資料になります。

業務要件の洗い出しと優先度づけ

Fit&Gap表の作成では、まず業務要件を網羅的に洗い出します。経営企画や経理、各部門へのヒアリングを通じて、予算編成や予実差異の見方を確認します。レポート形式や連携システム、権限設計も併せて確認します。

  • 必須:満たさないと業務が回らない要件
  • 推奨:望ましいが、代替手段で補える要件
  • 任意:将来的に必要になる要件

要件に優先度を付けると、製品選定やカスタマイズの判断の拠り所になります。すべてを同じ重みで扱うと、不要な機能まで備えた高額製品を選ぶおそれがあります。

必須要件を満たさない製品は、候補から外します。そのうえで、推奨要件で製品を比較し、任意要件は将来の拡張余地として扱います。この優先順位によって、限られた予算の使いどころがはっきりします。

関係者を巻き込むと、要件の抜けによる手戻りを減らせます。経営層、情シス、現場の視点を取り込んでおきます。

Gapへの対応方針の3分類

Fit&Gap表で見つかったGapへの対応方針は、大きく3つに分けられます。選んだ方針を記録しておくと、カスタマイズの総量から費用と期間を見積もれます。

  • 業務を変える:標準機能に合わせた業務への組み替え
  • システムを変える:カスタマイズや追加開発で対応
  • 運用で補う:手作業や別ツールを使う

すべてをカスタマイズで解決すると、費用が膨らみます。一方で、すべて業務変更にすると、現場が反発することがあります。

そこで、一つひとつのGapについて、カスタマイズする価値があるか、運用で補えるかを冷静に議論します。

Fit&Gap表は、議論を関係者全員で共有し、合意形成するための土台になります。ベンダーにも表を渡すと、各社が同じ前提で見積もれ、提案を比較しやすくなります。

会社ルールと得意先要求のギャップの見極め

会社固有のルールや得意先独自の運用に関わるGapは、効率だけでなく事業上の必要性から評価します。

  • 取引・統制への影響:大口取引先の締めや請求サイクル、決裁規程に関わる承認段階は、標準化で支障が出る場合があります。
  • 事業上の必要性:競争力や取引維持に直結するルールは、費用がかかってもカスタマイズや運用で守ります。
  • 慣習の見直し:標準に寄せて簡素化し、表で守る業務と変える業務を洗い出します。

見極めが甘いと、不要なカスタマイズで費用がかさむか、必要な運用を壊して現場や取引先の不満を招くおそれがあります。

ポイント

Gapごとに、業務で変えるか、システムを変えるか、運用で補うかを表に記録しておくと、カスタマイズの総量から費用と期間を見積もれます。

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

データ移行と連携で確認する移行範囲・データ整備・連携先や方式の図解
範囲と方式をそろえると、ベンダーが見積もる前提が明確になります。

機能要件のほかに、法令対応、データ移行、連携などの周辺要件も確認します。これらが要件定義から漏れると、導入後のトラブルにつながります。そのため、RFPに明記し、ベンダーに対応可否と方法を提案してもらいます。

インボイス制度・電子帳簿保存法への対応要件

会計・請求データを扱う経営管理システムでは、インボイス制度と電子帳簿保存法への対応が必須です。法対応のコストは形態によって違い、選定方針にも影響します。そこで、提供形態ごとに法対応の負担がどう違うか、RFPでどう確かめるかを見ておきます。

  • 標準機能と将来対応:現在の法令に対応し、将来の改正に追随できるかどうか
  • クラウド・サブスク型:頻繁な法改正の影響を抑えたい場合に有利で、定額保守費の範囲で法対応が無償提供される場合もあります。
  • オンプレミス型:法改正のたびに高額な追加開発が発生しやすいとされています。
  • RFPでの確認:対応の負担者と方法を問い、回答を比べることで、想定外コストを防ぎ、長く使える製品を選びやすくなります。

データ移行・クレンジングと連携の要件

データ移行とクレンジングは、見積もりから漏れやすい要件です。そのため、移行年数と対象システム数を具体的に書いておきます。

  • 移行範囲:何年分をいくつのシステムから移すか
  • データ整備:勘定科目の統廃合や、重複データの名寄せが必要かどうか
  • 品質基準と費用:範囲と基準を決め、想定外の出費や期間を防ぐ
  • 連携先・方式:会計ソフトや販売管理、ネットバンキング、人事給与などを洗い出し、APIかCSVかを明記する
  • 連携頻度・方向:「会計ソフトから日次でCSV取り込み」のように、具体的に示す

たとえば、20年分のデータが3システムに分散した商社では、統合だけで4ヶ月・数百万円を要しました。

要件を具体化しておくと、ベンダーは正確に見積もれます。移行と連携は数字の信頼性を支えるため、範囲を固めることが「数字が合わない」トラブルを避ける決め手になります。

ポイント

法改正への備えは、クラウド型かオンプレミス型かで費用の出方が変わります。データ移行と連携も、範囲と方式を書いておくと、ベンダーが見積もる前提が明確になります。

RFP(提案依頼書)に盛り込むべき項目

RFP(提案依頼書)は、整理した要件をベンダーに伝え、提案を引き出す文書です。完成度が提案の質と比較しやすさを左右します。

各社の前提が異なると、提案を比べられません。RFPで前提と評価軸をそろえておく必要があります。そこで、最低限盛り込む項目を、背景と体制、予算と評価基準、教育と定着支援に分けて示します。

背景・目的とプロジェクト体制

RFPでは、経営管理システムを導入する背景と目的を明確にします。背景は課題ごとに分け、それぞれが何を目指すのかを組にして書きます。

  • 月次決算:決算の早期化
  • Excel:属人化の解消
  • グループ:全体の可視化

導入の狙いが分かれば、ベンダーは目的に沿って提案できます。反対に、背景が曖昧だと、的外れな提案や過剰な機能を含む高額な提案が集まる場合があります。

自社の体制も併せて伝えます。統括担当、現場窓口、経営層の関与方法を示します。

体制を曖昧にしたまま進めると、失敗につながります。情シスだけで選定して現場が反発した例や、経営層の関与不足で意思決定が遅れた例があります。

体制を示すことは、社内の推進体制を固めるきっかけにもなります。経営層を巻き込み、PMO的な推進役を立てることが、導入成功の前提になります。

予算・スケジュール・評価基準の明示

RFPには、想定予算とスケジュールを示します。予算を伏せると、提案の規模がばらつき、比べにくくなります。

自社規模に合う予算レンジを示せば、現実的な提案が集まります。規模別の相場は、年商と従業員数の区分ごとに示します。併せて、評価基準と費用内訳も求めます。

  • 小規模の相場:年商10億・20名規模は、初期数十万〜数百万円、月数万〜数十万円です。
  • 中小規模の相場:年商10〜50億・100名規模は、初期数百万〜1,000万円、月数十万〜100万円超です。
  • 評価基準:価格、機能適合、サポート体制、導入実績、将来の拡張性への重みづけ
  • 費用内訳:主要サービスの多くは価格を公開していないため、初期費用、ライセンス、カスタマイズ、保守の内訳を求める

評価軸を事前に示しておくと、ベンダーは自社の強みを、その軸に沿って提案できます。RFPは、自社要件と評価軸を明文化し、複数のベンダーを同じ条件で比べるための重要な発注文書です。

教育・定着支援の要件

RFPには、導入後の教育と定着支援も盛り込みます。現場が使いこなせず、Excelに戻ってしまうと、導入は失敗につながります。

  • 教育:導入後の研修やトレーニングの内容
  • 運用資料:マニュアルや手順書の整備範囲
  • 伴走支援:導入直後のサポートの有無

各社に提案を求めて比べると、定着まで支援するベンダーを選びやすくなります。納品で終えるベンダーと、現場の定着まで伴走するベンダーとでは、導入の成否が分かれます。RFPで支援要件を明示すれば、各社の姿勢も見極められます。

riplaはフルスクラッチ受託と業務伴走の立場から、構築だけでなく現場で使えるようになるまでの支援を重視しています。

要件定義とRFPで定着支援を明確にしておけば、使われないシステムになるリスクを抑えられます。

ポイント

背景や体制、予算を書いておくと、ベンダーの提案を同じ前提で比べられます。評価基準と定着支援まで示すと、比べる観点もはっきりします。

まとめ

要件定義では、Fit to Standardの方針を決め、現状の業務(AsIs)を洗い出して、あるべき業務(ToBe)を設計します。そのうえで、Fit&Gap表で差分への対応を分類し、法令・移行・連携の要件も明記します。

カスタマイズ費用は、標準的な作り込みで500万〜1,000万円です。また、20年分のデータが分散していた事例では、統合だけで4ヶ月・数百万円を要しました。

RFPで大切なのは、機能を網羅することよりも、自社の目的と評価軸を正確に伝え、提案を同じ前提で比べられる状態を作ることです。そのため、背景・体制・予算・評価基準を明示し、Fit&Gap表も添えます。

riplaはフルスクラッチ受託と国内開発を組み合わせ、AsIsからToBeの要件整理と定着するシステムづくりを伴走支援します。全体像は完全ガイドをご覧ください。

会社紹介

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

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

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

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

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

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