BtoB卸売業のEC要件定義｜卸価格切替と掛け売り対応で決めるべきこと

◆監修・編集責任者　小園 将隆　2026年9月17日

B2B EC-COLUMN

要件定義では何を決めるのですか

紙やFAXの受発注をECへ移すとき、最初に手が止まるのは「何から決めれば要件定義になるのか」という点です。要件定義は、システムの機能を並べる作業ではありません。いまの業務のうち、どこをシステムに載せ、どこを人の運用として続けるかを決め、その決め事を文書に残す作業です。

BtoB卸売業の場合、その線引きが最も難しくなるのが卸価格の切替と掛け売りです。取引先ごとに違う価格、支店や部門ごとに違う条件、締め日ごとの請求、入金の消込。これらは長年の商習慣として運用で吸収されてきたため、担当者の頭の中にしか残っていないことが少なくありません。要件定義とは、その暗黙の条件を書き出し、システムで受ける範囲を決める場です。

進め方は、①要件定義で決める対象を確かめる、②自社の取引条件を洗い出す、③システムと運用の線引きを決める、④文書にして発注先へ示す、⑤期間を見積もって社内日程に落とす、という順番になります。以下、この順に見ていきます。

要件定義は業務の決め事を文書にする作業です

要件定義は、システム会社に渡す仕様書を書く作業と思われがちですが、実際にはその前段にあたります。いまの受発注業務を洗い出し、EC化したあとに業務がどう変わるかを自社で決める。その決め事を、発注先が読んで作れる形に書き直したものが要件定義書です。

逆に言えば、自社で決めていないことは要件になりません。「取引先ごとに価格が違う」という事実だけでは要件にならず、「どの単位で、誰が、いつ価格を登録し、変更するのか」まで決めて初めて要件になります。要件定義が進まない原因の多くは、システムの知識不足ではなく、この社内の決め事が未確定なことにあります。

決める対象は業務・機能・非機能の三つに分かれます

決める対象は、大きく三つに分けると整理しやすくなります。一つ目は業務要件で、誰がどの順番で何をするかという業務の流れそのものです。受注から出荷指示、請求までの流れを、EC化後の姿で書きます。

二つ目は機能要件で、その業務を成り立たせるためにシステムが持つべき働きです。卸価格の切替や与信枠の照合はここに入ります。三つ目は非機能要件で、同時に使う人数、応答の速さ、データの保持期間、既存の基幹システムとの連携方式などです。

情報システム担当が抜かしがちなのは三つ目です。既存の基幹システムと何を、どの頻度で、どちらの向きにやり取りするか。ここが決まっていないと、開発の終盤で手戻りが起きます。

進め方に迷うときは公開されたガイドを物差しにします

自社だけで項目を考えると、抜けに気づけません。発注する側の立場で書かれた公開ガイドがあり、要件定義を進めるうえでの勘どころが128個にまとめられています¹。

すべてを読み込む必要はありません。自社が決めた項目を並べたうえで、ガイドの目次と突き合わせ、書かれていない項目がないかを確かめる使い方が現実的です。社内の合意を取るときにも、外部のガイドに沿っていると説明できる点は効きます。

洗い出した条件のすべてをシステムで受ける必要はありません。次に決めるのは、その切り分けです。

卸価格の切替はどこまで洗い出せば良いですか

価格が変わる条件を四つの軸で並べます

卸価格の洗い出しは、取引先の一覧を作るところから始めがちですが、先に「何によって価格が変わるのか」という軸を並べたほうが早く済みます。軸は主に四つです。取引先そのもの、商品や商品分類、注文数量、そして期間です。

四つの軸のうち、自社で実際に使っているのはどれか。すべての軸を使っていると思い込んでいても、確かめると数量による変動はごく一部の商品だけ、というケースがあります。使っていない軸を要件から外せば、それだけ仕組みは簡単になります。

取引先の組織階層をどこまで見るかを決めます

卸売業で見落とされやすいのが、取引先の中の階層です。本社と支店で価格が違う、同じ支店でも部門によって条件が違う、帳合先を挟んでいる、といった構造は珍しくありません。

この組織階層に応じた卸価格の切替は、5階層までを対応の上限として想定しておくと、多くの取引形態を受けられます²。自社の取引先のうち最も階層が深いのは何段か。そこを数えておくと、発注先に条件を伝えるときの共通言語になります。

階層を決めるときは、価格の継承の向きも合わせて決めます。上位に設定した価格を下位が引き継ぐのか、下位の設定が優先されるのか。ここを決めずに進めると、登録作業のたびに判断が必要になり、運用の負担として残ります。

例外の特価は件数を数えてから扱いを決めます

どの卸売業にも、規則で説明しきれない特価があります。長年の取引で決まった値段、案件ごとのスポット価格などです。これらをすべて仕組みで受けようとすると、要件は急に複雑になります。

判断の材料になるのは件数です。年間で何件あるのか、どの取引先に集中しているのかを数えます。件数が少なく特定の取引先に偏っているなら、その分は運用で個別に対応すると決めてしまったほうが、全体としては早く安く仕上がります。

線引きが決まったら、それを他の人が読める形に直します。ここからが文書化の段です。

システム任せと自社運用の線引きはどう決めますか

件数と頻度で線を引きます

線引きの基準は、担当者の感覚ではなく件数と頻度に置きます。毎日発生して件数も多い処理はシステムに載せる価値があります。年に数回しか起きない処理は、仕組みにする手間と効果が見合いません。

洗い出した条件の一つひとつに、発生件数と頻度を書き添えていきます。この二列を足すだけで、どこを機能で受け、どこを運用に残すかの議論が具体的になります。

掛け売りは機能側に寄せます

掛け売りは、運用に残すと負担が積み上がる領域です。BtoB ECで掛け売りに対応するために必要な機能要件は、与信枠・締め請求・入金消込の3つに整理されます⁶。この3つは毎月必ず発生し、件数も受注の数だけ増えるため、機能側に寄せる判断になりやすい部分です。

与信枠は、取引先ごとに上限を持ち、受注のたびに残枠と照らす働きです。締め請求は、締め日ごとに期間内の取引をまとめて請求書にする働きです。入金消込は、入金と請求を突き合わせて残高を確定する働きです。この三語を要件定義書に書いておくだけでも、発注先との話は通じやすくなります。

運用に残すものは手順書に書き出します

運用に残すと決めた処理は、決めた時点で手順書の形にしておきます。「システムでは受けない」とだけ書かれた要件は、稼働後に誰も担当しない仕事になりがちです。

誰が、いつ、どの画面や帳票を見て、何をするのか。この粒度で書いておくと、稼働前の教育にもそのまま使えます。要件定義の成果物は要件定義書だけではない、と考えておくと安全です。

要件は誰にどう見せれば伝わりますか

読み手は社内決裁・現場・発注先の三者です

要件定義書は一つでも、読む人は三者います。予算を承認する社内の決裁者、実際に使う営業や出荷の現場、そして開発する発注先です。三者は知りたいことが違います。

決裁者が見るのは、投じる費用に対して何が変わるかです。現場が見るのは、自分の仕事の手順がどう変わるかです。発注先が見るのは、作るべき対象の範囲と条件です。同じ文書でも、冒頭に業務の変化を書き、後半に条件を詳述する構成にすると、三者それぞれが必要な箇所を読めます。

要件定義書に載せる項目をそろえます

記載項目は、業務の流れ図、機能の一覧、卸価格の条件表、取引先の階層の定義、掛け売りに関する取り決め、既存システムとの連携、非機能の条件、運用に残す処理の一覧、といった構成が基本形になります。

このうち卸価格の条件表は、表の形にしておくと効果が大きい部分です。軸ごとに条件を並べ、優先順位を添える。文章で書かれた価格条件は読み手ごとに解釈が分かれますが、表であれば解釈の幅が狭まります。

合意した内容と保留の項目を分けて記録します

要件定義の途中では、社内で結論が出ない項目が必ず残ります。これを空欄のままにせず、「保留」として理由と決定予定時期を書き添えます。

保留項目を明示した文書は、発注先にとっても扱いやすくなります。見積もりの前提が分かるためです。逆に、決まっていない部分を曖昧な表現で埋めると、後から範囲の解釈をめぐって揉める原因になります。

要件定義から稼働まではどれくらいかかりますか

期間は決める範囲の広さで変わります

期間の目安は、一律には言えません。既存の基幹システムとの連携をどこまで行うか、卸価格の条件がどれだけ複雑か、対象とする取引先の数がどれくらいかで大きく変わります。公開されている導入事例を見ると、その幅が分かります。

短い例では、導入までの期間が約2か月というケースがあります⁵。実質的な開発期間が約4か月というケース⁴、要件定義からテストサイトの開設までに約10か月をかけたケース³もあります。差を生むのは、連携の範囲と決めるべき条件の量です。

社内のスケジュールを引くときは、この幅を前提にします。最短の事例だけを見て日程を組むと、要件の洗い出しに時間がかかった段階で計画全体が崩れます。

社内の確認に使う時間を先に確保します

期間が延びる原因は、開発そのものより社内の確認にあることが多い領域です。卸価格の条件は営業部門に、掛け売りの条件は経理部門に確かめる必要があり、どちらも日常業務の合間の作業になります。

そのため、要件定義の日程を引くときは、各部門への確認に使う時間を最初から工程に入れておきます。発注前の社内調整でここを見込んでおくと、発注後の日程が現実的になります。

要件定義は、システムの知識より自社の取引条件の把握が先に立つ作業です。卸価格の軸と階層、掛け売りの3つの働き、そして運用に残す処理。この三点を書き出せた時点で、発注先と具体的な話ができる状態になります。

卸価格の軸と階層を自社だけで書き出すと、どこまでが一般的な範囲でどこからが自社固有の事情なのかが分かりません。BtoB ECの構築を手がけてきた側は、他社がどの条件までを機能で受けているかを知っています。

自社の取引条件をそのまま伝えれば、どの条件が標準の設定で受けられ、どこからが追加の開発になるのかを、発注前の段階で切り分けて確かめられます。無料相談で要件を整理する

与信管理を整えるために決める5つの項目

順位は公表された調査に依ります⁷。

掛け売りを機能側に寄せると決めたら、与信管理をどう回すかまで踏み込む必要があります。BtoB ECにおける与信管理の導入手順は5つのステップに整理されています⁷。要件定義の段階で決めておくのは、次の5点です。

要点の整理

軸	基準
卸価格の条件	取引先・商品・数量・期間の四軸で洗い出し、使っていない軸は要件から外す
取引先の階層	組織階層は5階層までを想定し、価格を継承する向きも合わせて決める
例外の特価	年間の件数を数え、少数かつ偏っていれば運用で受けると決めてしまう
掛け売り	与信枠・締め請求・入金消込の3つを機能要件として明記する
与信管理	判断材料・枠・照合・超過時の扱い・見直し周期の5点を決めておく
機能と運用の線引き	件数と頻度の二列を条件表に足し、多いものを機能側に置く
文書化	業務の変化を先に、条件の詳細を後に置き、保留項目は理由とともに残す
期間	事例には約2か月から約10か月までの幅がある。連携の範囲と条件の量で決まる

要件定義書を書き上げてから相談すると、前提が合わずに書き直しになることがあります。書き上げる前に、決め事の粒度と抜けの有無を実務を知る相手と突き合わせておくほうが、結果的に早く進みます。 手元の条件表を見せながら相談すれば、要件として不足している項目、期間に影響する要素、運用に残したほうが良い処理の見当を、社内の日程を引く前に確かめられます。

よくある質問

要件定義はシステム会社に手伝ってもらっても良いのですか

問題ありません。ただし、自社の業務をどう変えるかという判断は自社で持つ必要があります。手伝ってもらうのは、業務の洗い出しの進め方や、決め事を文書の形に整える部分です。判断まで委ねると、稼働後に「思っていたものと違う」という事態になりやすくなります。

卸価格の条件が多すぎて洗い出しが終わりません

すべてを一度に洗い出そうとせず、取引先の数と取引金額の大きい順に着手します。上位の取引先で使われている条件を先に固めると、多くの場合は残りの取引先も同じ型に収まります。収まらない例外だけを別に扱えば、洗い出しは終わります。

既存の基幹システムは残したままEC化できますか

できます。その場合、要件定義で決めるべきは連携の範囲です。取引先マスタと商品マスタをどちらで管理するか、受注データをどの頻度でどちら向きに渡すか、卸価格の登録をどちらで行うか。この三点を先に決めると、以降の要件が組み立てやすくなります。

要件定義書はどれくらいの分量が必要ですか

分量より、決め事が漏れなく書かれているかが重要です。公開されている要件定義のガイドには勘どころが128個にまとめられているため¹、自社の文書と照らして抜けを確かめる使い方が現実的です。

1. 1　出典：独立行政法人情報処理推進機構（IPA）社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年）　経路
2. 2　出典：株式会社フライトソリューションズ「EC-Riderお役立ちコラム「BtoB向けECサイトで取引先ごとに卸価格を切り替える」」（2026年）　経路
3. 3　出典：株式会社フライトソリューションズ（EC-Rider B2B）「導入事例 日東電工CSシステム株式会社様」（2020年）　経路
4. 4　出典：株式会社フライトソリューションズ「EC-Rider B2B 導入事例（フーヅフリッジ株式会社様）」（2017年）　経路
5. 5　出典：株式会社イーシー・ライダー「EC-Rider B2B 導入事例（フリュー株式会社様）」（2016年）　経路
6. 6　出典：株式会社フライトソリューションズ「BtoB EC掛売り決済の対応方法｜2026年取適法と要件（EC-Rider B2B Ⅱ 公式サイト）」（2026年）　経路
7. 7　出典：株式会社フライトソリューションズ「BtoB ECの与信管理の進め方｜取適法対応の手順（EC-Rider B2B 公式サイト）」（2026年）　経路