売上管理システムの開発・導入を成功させられるかどうかは、要件定義の質でほぼ決まると言っても過言ではありません。リサーチによれば、ERP導入の75%が進行中に何らかの失敗を経験し、在庫管理システム導入企業の約75%が不満を抱えているという厳しい統計があります。その多くは、技術力や予算の問題ではなく、要件定義の段階で自社の業務や例外処理を詰め切れなかったことに起因します。逆に、コンサルを活用して要件をしっかり固めたERP導入は85%が成功しているというデータもあり、要件定義こそが成否を分ける分水嶺だと分かります。
本記事は、売上管理システムのRFP（提案依頼書）や要件定義書をどう作り込むかを、発注企業の視点で解説する「要件定義特化」の記事です。返品・値引・分納といった例外処理の三分類による整理、マスタの名寄せ要件、ECや基幹システムとの連携アーキテクチャ、インボイス・電帳法といった法制度の数値要件、そしてRFPに盛り込むべき項目まで、具体的に踏み込みます。ベンダーに丸投げせず、自社が主導して要件を固めるための実践的な指針を提供します。なお、売上管理システムの全体像をまだ把握していない方は、まず売上管理システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・売上管理システムの完全ガイド
業務フローの棚卸とToBe設計の進め方
要件定義の出発点は、現状（AsIs）の業務フローを徹底的に棚卸しすることです。誰が、いつ、どんな手順で売上を計上し、集計し、請求しているのか。その過程にどんな例外や手戻りがあるのか。これを可視化せずにシステムの要件を考え始めると、必ず後から「実はこういう処理もあった」という抜けが発覚します。
AsIs業務フローの棚卸と関係者ヒアリング
AsIsの棚卸では、経理・営業・各拠点の担当者といった売上に関わるすべての関係者にヒアリングを行います。机上で想像した業務フローと、現場の実際の運用には、必ずギャップがあります。とくに、マニュアルに書かれていない「暗黙の運用ルール」や「特定の取引先だけの特別対応」を洗い出すことが重要です。これらは担当者の頭の中にしかないことが多く、ヒアリングで引き出さなければ要件から漏れてしまいます。
ヒアリングでは、「通常の流れ」だけでなく「うまくいかないとき」「例外が起きたとき」をしつこく聞くことがコツです。返品が来たらどうするか、値引きの決裁は誰がするか、締めた後に修正が入ったらどう処理するか。こうした例外こそが、後でシステムが対応できずに現場が混乱する原因になります。リサーチでも、現場の巻き込みと、例外処理のシステム化判断が導入失敗の分かれ目だと指摘されています。AsIsの可視化は、要件定義の精度を決める最初の、そして最も重要な工程です。
ToBeモデルで「あるべき業務」を描き直す
AsIsを可視化したら、次は「あるべき業務の姿（ToBeモデル）」を描きます。ここで陥りがちな失敗が、現状の非効率な業務をそのままシステムに置き換えてしまうことです。Excelでやっていた煩雑な手順を、そっくりそのままシステムで再現しても、効果は限定的です。ToBe設計では、「そもそもこの作業は必要か」「システム化を機にこの運用ルールを変えられないか」という視点で、業務そのものを見直すことが大切です。
ToBeモデルを描く際は、システムで実現したいことに優先順位をつけます。すべてを一度に実現しようとすると、要件が膨らみ、開発費も期間も膨張します。「まず売上集計の自動化という効果の大きい部分から着手し、リベート計算やERP連携は次のフェーズで」といった段階的な計画を、ToBeの中で描いておくことが、現実的で成功率の高い進め方です。riplaも、現場の業務から逆算してToBeを描き、段階的に定着させる進め方を一貫して重視しています。AsIsとToBeを文書として残すことが、後のRFPと要件定義書の骨格になります。
返品・値引・分納など例外処理の三分類による整理
売上管理システムの要件定義で、もっとも差がつくのが例外処理の扱いです。リサーチでも、定型フロー（見積→受注→出荷→請求）は語られても、業務の3〜4割を占める返品・値引・バックオーダー・分納といった例外処理をどう仕分けるかのノウハウが、競合の解説では欠落していると指摘されています。この例外処理を「すべて自動化」「すべて手動」のどちらかに振り切るのではなく、三つに仕分けることが要件定義の肝になります。
「自動化・手動・運用ルール」の三分類で仕分ける
例外処理を整理する有効な手法が、(1)システムで自動化する、(2)システム上で手動入力する、(3)システム化せず運用ルールで対応する、の三分類に仕分けることです。発生頻度が高く、ルールが明確な例外（定型的な返品など）は自動化の対象にします。発生はするがルールが固まっていない例外は、システム上で手動入力できるようにします。年に数回しか起きない極めてまれな例外は、無理にシステム化せず、運用ルールとマニュアルで対応すると割り切ります。
この三分類が重要なのは、すべての例外を自動化しようとすると開発費が際限なく膨らみ、逆にすべてを手動・運用に回すと現場の負担とミスが増えるからです。発生頻度と影響度のバランスで、どこまでをシステムに任せるかの線引きを、要件定義書に明記します。リサーチでも、例外処理を自動化・手動・運用ルールの三つに仕分ける要件定義ノウハウが、競合に欠けている差別化の主戦場だと位置づけられています。この線引きを発注側が主導できると、見積もりの精度も上がり、開発後の手戻りも激減します。
情物一致とバックオーダー・分納の要件化
例外処理の中でも特に注意したいのが、システム上の数字と現物のズレ（情物一致）を、いつ・どう合わせるかという要件です。出荷したのに計上が漏れている、返品が現物だけ戻ってきてシステムに反映されていない、といったズレは、売上データの信頼性を直接損ないます。要件定義では、棚卸や突合のタイミングと方法、ズレが見つかったときの修正フローを明確に定義する必要があります。
あわせて、在庫が足りずに後から納品するバックオーダーや、一つの注文を複数回に分けて納品する分納の扱いも、要件として詰めておく必要があります。これらは「いつ売上を計上するか」「どの時点で請求するか」に直結し、会計処理にも影響します。分納のたびに部分的に売上計上するのか、全数納品時にまとめて計上するのか、といった方針を要件定義書で確定させておかないと、開発の途中で仕様が二転三転します。情物一致と分納・バックオーダーの要件化は、売上管理システムの実務的な完成度を左右する核心部分です。
連携アーキテクチャとマスタ名寄せの要件
売上管理システムは単独で完結することは少なく、会計・EC・POS・WMS・EDIといった周辺システムと連携して初めて真価を発揮します。この連携をどう設計するかは、要件定義の重要な柱です。とくにシステム間でコード体系が異なる場合の名寄せは、リサーチでも連携要件の整理だけで数週間を要する最大の関門だと指摘されています。
取引先・商品コードの名寄せ要件を先に固める
名寄せとは、システムごとにバラバラの取引先コードや商品コード（SKU）を、共通の体系に統一する作業です。たとえば会計システムでは「T001」という取引先コードが、EC側では別の番号で管理されている、商品コードも倉庫と販売で異なる、という状態は珍しくありません。これを放置したまま連携すると、データが正しく突き合わせられず、集計が狂います。要件定義では、どのコードを基準（マスタ）とし、他システムのコードとどう紐づけるかを、開発に入る前に確定させる必要があります。
リサーチによれば、この名寄せはBtoB連携における最大の関門であり、連携要件の整理だけで数週間を要します。さらに、後付けの連動開発費は数十万〜100万円の隠れコストになるリスクがあり、見積もり時に見落とすと予算オーバーの原因になります。要件定義書では、移行前のデータクレンジング（重複・誤記の整理）と、コード体系の統一ルールを明記し、これにかかる工数と費用をベンダーに見積もらせることが重要です。名寄せを軽視した連携は、必ずどこかで破綻します。
連携方式とリアルタイム性の数値要件
連携アーキテクチャの要件では、各システムと「どの方式で」「どのタイミングで」データをやり取りするかを定義します。リアルタイムにAPIで連携するのか、1日1回のバッチ処理でまとめて連携するのか。たとえばECと在庫を連携する場合、同期にタイムラグがあると「売り越し（欠品）」が発生するため、リアルタイム連携が求められます。一方、会計への仕訳連携は日次バッチで足りることも多く、要件に応じて方式を使い分けます。
要件定義書には、これらを数値で明記することが大切です。「在庫の同期は◯分以内」「日次バッチは何時に実行し、何時までに完了する」「連携が失敗したときのリトライとアラートの仕組み」といった非機能要件を具体的に書きます。インボイス・電帳法といった法制度対応も、「適格返還請求書を発行できること」「電子取引データを◯年保存すること」のように、対応の有無ではなく具体的な要件として落とし込みます。曖昧な言葉ではなく、検収時に合否を判定できる粒度で書くことが、要件定義書の品質を決めます。
RFP（提案依頼書）に盛り込むべき項目
これまで整理したAsIs/ToBe、例外処理の三分類、連携・名寄せの要件を、ベンダーに提示する形にまとめたものがRFP（提案依頼書）です。RFPの質が高いほど、ベンダーからの提案と見積もりの精度が上がり、複数社を同じ土俵で比較できるようになります。逆に曖昧なRFPでは、各社の提案がバラバラで比較できず、後の認識違いやトラブルの原因になります。
背景・目的・スコープと必須要件の記載
RFPの冒頭には、なぜ売上管理システムを導入するのかという背景と目的を明確に書きます。「月次締めの短縮」「複数チャネルの売上一元化」「掛率・リベート計算の自動化」など、解決したい課題を具体的に示すことで、ベンダーは的を射た提案ができます。次に、対象範囲（スコープ）を明記します。どの業務をシステム化し、どこは対象外とするのかを区切ることで、見積もりの前提が揃います。
機能要件は、「必須」「あると望ましい」「不要」に分けて一覧化します。掛率管理・リベート計算・債権管理・インボイス対応・各システム連携といった機能を列挙し、それぞれの優先度と、自社の具体的な業務パターンを添えます。とくに前述した例外処理の三分類は、RFPの中で「この例外は自動化を求める」「これは手動入力でよい」と明示すると、見積もりのブレが大幅に減ります。要件を曖昧にせず、優先順位とともに具体的に書くことが、良いRFPの条件です。
非機能要件・予算・保守体制とサポートの明記
RFPでは、機能だけでなく非機能要件も明記します。同時アクセスするユーザー数、想定するデータ量、レスポンス速度、セキュリティ要件、可用性（障害時にどれだけ業務を止められるか）といった項目です。リサーチでも、トラブル時に業務が停止しないサポート体制が選定基準の一つとして挙げられています。365日サポートが必要なのか、平日日中で足りるのか、障害時の復旧目標時間はどれくらいか、を要件として書き込みます。
予算感とスケジュール、そして導入後の保守・運用体制についても、RFPに記載します。費用の目安として、リサーチではクラウド型が初期0〜10万円・月額3,000〜70,000円、セミオーダーが100万円以上、スクラッチが500万〜数千万円とされており、自社の予算がどのレンジにあるかを示すことで、現実的な提案を引き出せます。これらを揃えたRFPを複数社に提示し、提案内容・見積もり・保守体制を同じ基準で比較することが、失敗しない売上管理システム選定の王道です。要件定義に時間をかけることこそが、最大のリスクヘッジになります。
データ移行とベンダー選定の要件
要件定義書とRFPが固まっても、見落としやすいのがデータ移行の要件と、提案を受けたベンダーをどう選ぶかという観点です。この二つは、システムの稼働品質とプロジェクトの成否を左右する、要件定義の仕上げにあたる重要な工程です。
データ移行とクレンジングの要件を明記する
新システムへの移行では、既存のExcelや旧システムに蓄積された取引先・商品・売上履歴のデータを移し替える必要があります。このとき問題になるのが、データの品質です。重複した取引先、表記が揺れた商品名、誤入力された数値といった「汚れたデータ」をそのまま移行すると、新システムでも集計や連携が正しく動きません。リサーチでも、データ移行前のクレンジングが重要な論点として挙げられています。
要件定義書には、どのデータを、どの範囲（過去何年分か）で移行するのか、移行前にどんなクレンジング（重複削除・表記統一・コード整理）を行うのかを明記します。あわせて、SKUを基準にした商品コードの付与ルールや、移行データの検証方法も定義します。このデータ移行・クレンジングの工数は見積もりに含まれていないことがあるため、RFPで明示的にベンダーに見積もらせることが、後の予算超過を防ぐポイントです。きれいなデータで稼働を始めることが、システムの信頼性の出発点になります。
提案・見積もりを同じ基準で評価する
RFPを複数のベンダーに提示したら、返ってきた提案と見積もりを同じ基準で評価します。評価軸は、機能要件をどこまで標準で満たせるか、自社の例外処理や商慣行への理解度、見積もりの内訳の妥当性（とくに連携開発費やデータ移行費が含まれているか）、そして導入後の保守・サポート体制です。価格の安さだけで選ぶと、後から追加費用が膨らんだり、サポートが不十分でトラブル時に業務が止まったりするリスクがあります。
とくに重視したいのが、ベンダーが自社の業務をどれだけ理解しようとしているかです。リサーチでも、コンサルを活用したERP導入は85%が成功しているとされ、業務に踏み込んで要件を一緒に固められるパートナーの価値が示されています。提案の場で、自社の例外処理や商慣行について的確な質問が返ってくるか、ToBeの実現方法を具体的に提示できるかを見極めます。riplaはフルスクラッチ受託と国内開発の立場から、要件定義からデータ移行、開発、定着までを伴走し、自社固有の業務に適合したシステムづくりを支援します。ベンダー選定は、要件定義の質を実装へとつなぐ最後の関門です。
デモ・トライアルで要件の実現性を検証する
要件定義書とRFPで要件を固めても、それが実際に動くかどうかは、デモやトライアルで検証することが欠かせません。リサーチでも、無料トライアルやデモ、見積依頼チェックリストの活用が意思決定段階のポイントとして挙げられています。製品デモでは、ベンダーの用意したサンプルデータを眺めるだけでなく、自社の実際の取引パターン・例外処理・帳票様式を当てはめて、要件をどこまで再現できるかを試すことが重要です。
とくに、掛率・リベートの計算、返品時の適格返還請求書の発行、複数チャネルの売上一元化といった、要件定義で重視した難所を、デモの場で実演してもらいます。「できます」という口頭の回答ではなく、実際に画面上で動くことを確認することで、認識のズレを早期に潰せます。トライアル期間があれば、現場の担当者に実際に操作してもらい、定着の見込みを確かめることも有効です。要件の実現性を稼働前に検証することが、開発後の手戻りと現場非定着のリスクを大きく減らします。
まとめ
売上管理システムの要件定義は、AsIs業務フローの棚卸とToBe設計から始まり、返品・値引・分納といった例外処理を「自動化・手動・運用ルール」の三つに仕分け、取引先・商品コードの名寄せと連携アーキテクチャを数値要件まで落とし込み、それらをRFPとして優先順位つきでまとめる、という一連の流れで進めます。ERP導入の75%が何らかの失敗を経験する一方、要件をしっかり固めた導入は85%が成功するというデータが示すとおり、成否は要件定義の質でほぼ決まります。とくに例外処理の三分類と名寄せ要件は、競合の解説でも空白になりがちな、差がつく核心部分です。
要件定義をベンダー任せにせず、発注側が現場の業務と例外から逆算して主導することが、現場に定着するシステムへの最短ルートです。riplaはフルスクラッチ受託と国内開発の立場から、AsIs/ToBeの可視化、例外処理の三分類、名寄せ要件の整理を含む要件定義の支援を一貫して行っています。全体像の確認には、あらためて売上管理システムの完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。