得意先が関わるシステム導入の要件定義、社内だけの場合と何が違うか

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

B2B EC-COLUMN

得意先が関わる導入で、要件定義のどこにつまずきやすいか

得意先に使ってもらう受発注の仕組みを入れることになり、社内の業務要件までは書き出せたものの、得意先側の事情をどこまで聞けばよいのかで手が止まる。
この段階で効くのは、対象が「得意先に新しく使ってもらう画面と機能」なのか、「得意先がすでに使っているシステムとの接続」なのかを先に切り分けることです。
前者なら自社の商品データと得意先ごとの取引条件をどう持っているかが要件の中心になり、後者はやり取りする文書の形式と通信の取り決めが中心になります。
聞く相手も、確認する項目も、この分岐で変わります。
得意先への聞き取りに広く確立された手順があるわけではないため、確認できた標準規格と導入事例を手がかりに、判断の順序から整理します。

社内で完結するシステムなら、要件が固まらないときに聞きに行く先は社内にあります。
経理の担当者に処理の実態を確かめ、現場に画面の使い勝手を聞き、決まらなければ上長を交えて決める、という段取りが取れます。
ところが得意先が使う仕組みや、得意先のシステムとつなぐ仕組みになると、この前提が崩れます。
要件を左右する情報が社外にあり、聞ける時間も、答えてもらえる範囲も、こちらの都合だけでは決められないからです。

要件定義そのものの進め方については、公的な手引きが公開されています。
情報処理推進機構(IPA)は2019年に『ユーザのための要件定義ガイド 第2版』を公開し、要件定義を成功に導く勘どころを128個にまとめています¹。
目的の確認、関係者の洗い出し、業務要件と機能要件の書き分けといった作業の骨格は、こうした資料で確かめられます。
ただし公式の案内ページで確認できた範囲では、得意先のような社外の取引先に固有の聞き取り方法までは示されていません(ガイド本体は分量が大きいため、本記事では案内ページで確認できた範囲にとどめています)。

言い換えると、要件定義の型そのものは既存の手引きを流用でき、自分たちで埋めなければならないのは得意先に関わる部分だ、という状態になります。
社内だけの導入と比べたとき、具体的にどこが変わるのかを先に見ておきます。

この中でとくに扱いにくいのは、得意先の要望が純粋な機能の要望としてではなく、取引の条件や社内事情と絡んで出てくることです。
「この画面がないと発注できない」という話と、「この形でないと社内の承認が通らない」という話と、「今までのやり方を変えたくない」という話は、どれも同じ相手から同じ調子で出てきます。
しかし応じ方は別で、前の二つは要件として受け止める必要がある一方、最後の一つは移行の段取りや説明のしかたで扱える場合があります。
この仕分けの精度は、要望を聞く前に対象をどう捉えているかで変わります。

そこで最初に決めておきたいのが、いま進めている導入が、得意先に新しく使ってもらう仕組みを作る話なのか、得意先がすでに使っているシステムと接続する話なのか、という点です。
同じ「得意先が関わる要件定義」でも、この二つは確認する相手も項目も別物になります。

得意先向けに新規構築するか、既存システムと連携するかで確認軸を分ける

同じ受発注システムの導入でも、得意先の側に何が起きるかで話が分かれます。
得意先の発注担当者が新しい画面を開いて注文を入れるようになるなら、要件の中心は画面と機能です。
一方、得意先の購買システムが自動で発注データを送ってくるようになるなら、得意先の担当者は画面を見ません。
このとき要件の中心は、やり取りするデータの形式と、送受信の取り決めに移ります。

見極めの手がかりは、得意先が今どうやって注文を出しているかを確かめることです。
電話・FAX・メールの添付ファイルで注文が来ているなら、新しく画面を用意する余地があります。
すでに伝票のフォーマットや通信手順を先方から指定されているなら、接続の話が中心になります。
得意先ごとに事情は違い、同じ会社の中でも部署によって違うこともあるため、全体を一つの型に決めつけないほうが安全です。

得意先向けに新規構築する場合

得意先に使ってもらう受発注サイトを新しく作る場合、画面や機能の一覧は比較的早く書き出せます。
止まるのはその次で、その画面に何を表示するのかを決める段になると、自社の商品データの状態が問われます。
社内の担当者なら略称や旧品番を見ても察しがつきますが、得意先の発注担当者は画面に出ている情報だけで注文する商品を選びます。

欧州を中心としたスポーツ自転車部品の輸入・卸売りを手がける株式会社ポディウムは、受発注システムの導入にあたって、2万点ほどあった商品登録を精査したと述べています³。
これは特定の製品(EC-Rider B2B)の導入事例1件で語られた作業であり、どの会社でも同じ量になるという話ではありません。
ただ、得意先に見せる画面を作るということは、社内でしか見ていなかった商品マスタを社外の目に晒すということでもあります。
廃番のまま残っている品番、社内でしか通じない略称、単位や入数の表記揺れ、画像の有無といったものが、そこで一度に表に出てきます。

得意先ごとに掛率や取引条件が違う卸売では、誰にどの価格を見せるかが要件の中心に来ます。
全得意先に同じ表示価格を出して注文後に社内で引き直すのか、ログインした得意先ごとの価格を画面に出すのか。
後者にするなら、得意先別の価格が現在どこに、どの精度で保持されているかを先に確かめる必要があります。
表計算ファイルや営業担当者の記憶に残っている条件は、そのままでは画面に出せません。
ここは得意先に聞いても答えが出ない、自社側の宿題です。

一方で、得意先に聞かなければ決められないこともあります。
発注の単位(バラか、ケースか、その両方か)、希望納期をどう指定したいか、注文時に先方の伝票番号や工事番号を入れる欄が要るか、納品先を注文ごとに指定するか。
それに、誰がログインするのかという運用の話もあります。
本社の購買部門だけなのか、支店や店舗ごとに担当者がいるのか、権限を分けて発注できる人と見るだけの人を区別したいのか。
これらは先方の業務の形そのものなので、社内で想像して決めると高い確率で作り直しになります。

この順で見ると、得意先に聞くことと社内で先に決めることが分かれます。
得意先に聞くのは、発注のしかたと、注文時に必ず入れたい情報と、誰が使うかという運用の話です。
商品データをどう整えるかは自社側の作業で、これを得意先との打ち合わせに持ち込んでも答えは返ってきません。
打ち合わせの回数が限られる相手だからこそ、聞くことを絞っておく意味があります。

得意先の既存システムと連携する場合

得意先がすでに自社の購買システムやEDIを使っている場合、要件定義の会話は画面の話から離れます。
決めるのは、どの文書を、どの形式で、どの経路でやり取りするかです。
得意先の担当者が新しい操作を覚える必要はないかわりに、少しでも形式が合わなければデータそのものが通りません。

消費財の流通業界では、この取り決めを業界共通の仕様として定めた流通BMSがあります。
これは発注者と受注者の間でやり取りするメッセージ(電子取引文書)と、通信プロトコル、セキュリティに関するEDIの標準仕様で、卸・メーカーの導入企業数は2025年6月1日時点で21,600社以上と推計されています⁴。
この推計は消費財流通業界を対象にしたもので、他の業界の取引にそのまま当てはまる数字ではありません。
また標準仕様そのものには、要件定義をどう進めるかという手順は書かれていないため、あくまで連携の方式を検討するときの選択肢の一つとして押さえるものです。

それでも、得意先が標準仕様に沿っているかどうかを最初に確かめる意味は小さくありません。
標準に沿えるなら、項目の定義も通信手順も仕様書を見れば分かり、こちら側の作業は自社のデータをその形に合わせることに集中できます。
逆に得意先ごとの独自フォーマットを指定される場合は、得意先の数だけ変換の仕様を抱えることになります。
要件定義の段階でこの見通しを立てておかないと、後から連携する得意先が増えるたびに、同じ設計と試験をやり直すことになります。

実務で詰まりやすいのは、文書の種類よりも項目の対応関係です。
自社では一つの商品コードで管理しているものが、得意先側では先方専用の品番で発注されてくる。
納品先も、自社の得意先マスタでは一社でも、先方は店舗や倉庫ごとのコードで送ってくる。
この対応表をどこで保持し、誰が更新するのかは、機能の要件であると同時に運用の要件です。
要件定義書に項目の一覧だけ書いて対応表の維持を誰も引き受けないまま進むと、稼働後に品番が一致しない注文が人手の確認待ちで滞ります。

切り替えの段取りも要件のうちです。
既存のやり取りをいつ止めるか、両方を並行して動かす期間を置くか、テストデータをいつ送り合うか。
これは得意先側の作業予定を押さえないと決められないため、要件定義の終盤ではなく、連携の方式が固まった時点で早めに相談しておくほうが動きやすくなります。
先方にとっては自社都合の予定であり、こちらの希望日にそのまま乗ってもらえるとは限らないためです。

得意先の要望をどう聞き取り、整理・合意していくか

ここまでで、確認すべき項目の見当はつきます。
残るのは、それを誰にどう聞き、どう決着させるかという部分です。
この点について、得意先向けの聞き取り手順として広く確立された手法を、今回の調査では一次情報として確認できませんでした。
以下は、得意先が自社の指揮下にない相手であるという前提から、編集部として現実的だと考える進め方です。
効果を数字で裏づけたものではないため、自社の得意先との関係に合うかどうかは、営業部門と事実関係を確かめたうえで使ってください。

聞き取る窓口の整理

得意先に「要件を教えてください」と聞いても、答えられる人は限られます。
日々の発注のしかたを知っているのは現場の購買担当者で、社内の承認ルールを知っているのはその上長、データ形式や通信手順を答えられるのは情報システム部門、という具合に分かれているためです。
一人にすべてを聞こうとすると、その人が答えられない部分が推測で埋まり、後から覆ります。
聞きたいことを項目ごとに分け、誰なら答えられるかを先方に確かめるところから始めるほうが、往復は少なく済みます。

自社側でも窓口を整理しておきます。
得意先との接点を持っているのは、多くの場合は営業担当者です。
要件定義の担当者が直接連絡を取ると、営業が把握していない約束が生まれ、後で取引条件の話とかみ合わなくなることがあります。
聞く内容は要件定義側が用意し、渡し方と日程は営業を通す、という分担にしておくと、双方の説明が食い違いにくくなります。

得意先が複数いる場合、全社に同じ聞き取りをするのは現実的ではありません。
取引量の大きい得意先、発注の形が特殊な得意先、システム化に前向きな得意先というように、性格の違う数社を選んで聞き、残りには決まった内容を案内する形にすると、幅を保ちながら回数を抑えられます。
ここで気をつけたいのは、選んだ数社の要望がそのまま全体の仕様になってしまうことです。
聞いた要望は「どの得意先が言ったことか」を添えて記録し、全得意先に共通で必要なものと、その得意先だけの事情を分けておきます。
この区別があると、後から別の得意先に同じ機能を求められたときに、仕様を広げるか個別対応にするかを判断できます。

聞き取った内容の記録と合意確認

聞き取った内容は、その場のメモで終わらせず、相手に返せる形に整えます。
返す相手が社外にいるという点が、社内だけの要件定義との一番の違いです。
社内であれば後から口頭で修正できることも、得意先が相手だと、認識の違いが取引の話に発展しかねません。

要望は、受ける・受けない・条件付きで受けるに仕分けます。
受けないものについては、結論だけでなく、なぜ受けないのかを書き添えます。
「現行の基幹システムが対応していないため」「他の得意先と共通の画面のため個別の項目を追加できない」といった理由が分かれば、得意先の側も代替案を出しやすくなります。
理由を書かずに対応する機能の一覧だけを返すと、次の打ち合わせで同じ要望がもう一度出てきます。

合意の確認は、口頭のやり取りではなく、文書を渡して返事をもらう形にします。
得意先の担当者が社内に持ち帰れる状態にしておくと、先方の上長や情報システム部門の目が入り、担当者一人の理解で進んでいた部分が見つかります。
この確認には時間がかかりますが、稼働直前や稼働後に指摘を受けるより、直す範囲は狭くて済むと考えられます。
どこまでを合意事項とするか——画面の項目まで含めるのか、業務の流れの合意にとどめるのか——は、相手との関係や案件の規模で変わるため、先に自社側で決めておくと迷いません。

決めた内容が後から変わることも前提に入れておきます。
先方の担当者が替わる、発注の運用が変わる、得意先側のシステム更新が重なる、といった事情はこちらでは止められません。
要件を確定させたあとの変更を誰が受け付け、影響をどう見積もり、どこまでを今回の範囲に入れるか。
この扱いを要件定義の終わりに一度決めておくと、変更が出るたびに判断が揺れることを避けられます。

事例に見る期間感とつまずきやすいポイント

進め方の見当がついても、どれくらいの時間を見ておけばよいかが分からなければ、社内の計画は引けません。
公開されている導入事例には、期間や作業量が記されているものがあります。
いずれも特定の製品の事例で、しかも導入した側の視点で書かれているため、得意先への聞き取りにどれだけかかったかまでは分かりません。
それでも、全体の桁を掴む手がかりにはなります。

各種工業用粘着テープやテープ貼り機器を中心に約3,800品種の製品の提案・販売を手がける日東電工CSシステム株式会社は、得意先向けの受発注サイトについて、要件定義からテストサイト開設までを約10カ月で進めたとしています²。
ここでいう10カ月は、要件を固める期間だけでなく、構築してテスト環境を開くところまでを含んだ期間です。
要件定義に何カ月かかったかという内訳は事例に書かれておらず、また特定の製品(EC-Rider B2B)の導入1件の実績なので、そのまま自社の見積もりに置き換えられる数字ではありません。
それでも、得意先に見せられる状態になるまでに年単位に近い時間がかかることは、社内に日程を説明する際の目安になります。

日程を引くときに落ちやすいのは、この期間の中に得意先の都合が二度入ってくることです。
一度目は要件を聞くとき、二度目はテスト環境を触ってもらうときです。
どちらも先方の業務の合間に時間をもらうことになるため、決算期や繁忙期に当たると、こちらの作業が止まっていなくても日程は後ろにずれます。
先方の繁忙期をあらかじめ聞いておくだけでも、無理な日程を社内に約束せずに済みます。

先に触れた商品登録の精査も、この期間の中に収まる作業です³。
2万点規模のデータを見直すとなると、どの品番を残すかは情報システム部門だけでは決められず、営業や商品担当の判断が必要になります。
要件定義の打ち合わせと並行して、この判断を誰がいつ行うかを決めておかないと、画面はできているのに載せるデータが揃わない、という止まり方をします。
この作業量は事例1件から分かることであり、商品点数が同じなら同じ手間になるという性質のものではありません。
自社の商品マスタが今どの程度整っているかを、早い段階で一度覗いておく意味はあります。

二つの事例から読み取れるのは、期間を左右するのが機能の多さよりも、データの状態と社外の相手の都合だという点です。
機能の増減は見積もりに反映しやすい一方、商品データの精査にどれだけかかるかも、得意先から返事が来る時期も、要件定義を始める時点では見えにくいためです。
この二つの輪郭を早めに掴んでおくと、後から日程を組み直す幅が小さくなります。

得意先向けの受発注の仕組みは、画面の機能よりも、自社の商品データと得意先ごとの取引条件をどう持っているかで難しさが変わります。この見立ては、社内の資料を眺めているだけでは立てにくいところです。

現在の商品マスタや価格の持ち方をもとに、新規構築と既存システムとの連携のどちらが現実的か、要件定義のどこに時間がかかりそうかを一緒に整理できます。無料相談で要件を整理する

この導入がどちらの型かを見分けるための確認事項

得意先の側で誰が何を操作するようになるか、という観点で挙げた確認事項です。

• 得意先は今、どの手段で注文を出しているか(電話・FAX・メールの添付ファイル・指定の伝票フォーマット・システム間の送信)

• 新しい仕組みでは、得意先の担当者が画面を操作するのか、先方のシステムが自動でデータを送ってくるのか

• 得意先から形式や通信手順の指定があるか、あるとすればそれは業界の標準仕様か、その得意先だけの独自形式か

• 得意先ごとに価格や取引条件が異なり、画面やデータで出し分ける必要があるか

• 注文に、先方の伝票番号や納品先コードなど、得意先の業務で欠かせない項目が含まれるか

• 既存のやり取りを止める時期と、新旧を並行して動かす期間を、得意先と一緒に決められるか

画面の操作が中心なら新規構築型として商品データと得意先別条件の整備へ、データの送受信が中心なら連携型として形式と項目の対応へ、確認する項目を切り替えます。

要点の整理

軸	基準
型の見極め	得意先の担当者が画面を操作するのか、先方のシステムがデータを送ってくるのか
新規構築型の要件の中心	画面と機能に加えて、商品データの整備状況と得意先ごとの価格・条件の持ち方
連携型の要件の中心	文書の種類・データ形式・通信手順に加えて、品番や納品先の対応表を誰が維持するか
聞き取りの窓口	得意先側は項目ごとに答えられる人が分かれる。自社側は営業を通して日程を取る
合意の残し方	受ける・受けない・条件付きに仕分け、断る理由を添えた文書で先方の確認をもらう
期間の見方	要件定義からテストサイト開設まで約10カ月という導入事例がある(特定製品の1件)

得意先ごとに発注のしかたが分かれている場合、どこまでを共通の仕様にして、どこから個別対応にするかの線引きは、社内の議論だけでは決めきれないことが多い部分です。 実際の受発注サイトの画面や、導入時に必要になったデータ整備の進め方を見ながら、自社の要件定義で先に決めておくべき項目を確かめられます。

よくある質問

得意先が複数いる場合、要件定義の窓口は誰にすればよいか

全社に同じ聞き取りをするのは現実的ではないため、性格の違う数社を選んで聞くのが現実的です。
取引量の大きい得意先、発注のしかたが特殊な得意先、システム化に前向きな得意先というように、要望の出方が違いそうな相手を選びます。
得意先側の窓口は一人に絞らず、発注の実務は購買担当者、承認ルールは上長、データ形式は情報システム部門というように、項目ごとに答えられる人を確かめてください。
自社側は営業担当者を通して日程と渡し方を決め、要件定義の担当者が単独で約束を作らないようにしておくと、取引条件の話とかみ合わなくなることを避けられます。

得意先向けシステムの要件定義に、得意先の担当者をどこまで巻き込むべきか

得意先に聞かなければ決まらないことと、社内で決めるべきことを分けるのが出発点です。
発注の単位、希望納期の指定方法、注文時に必ず入れたい項目、誰がログインするかといった先方の業務の形は、社内で想像すると作り直しになりやすい部分です。
一方、商品データの整備や画面構成の細部は自社側の作業で、打ち合わせに持ち込んでも答えは返ってきません。
加えて、テスト環境を触ってもらう場面を日程に入れておくと、文書のやり取りだけでは見えない認識の食い違いが稼働前に出てきます。
ただし相手の業務時間をもらうことになるため、依頼する回数と内容は絞ってください。

流通BMS以外に、得意先システムとの連携で確認すべき標準規格はあるか

本記事で一次情報として確認できたのは、消費財流通業界のEDI標準仕様である流通BMSだけです⁴。
他の業界にも業界団体が定めた仕様が存在する場合はありますが、今回は確認していないため、ここで名前を挙げて推奨することはしません。
実務上は、規格の一覧を探すより先に、得意先が現在どの方式でデータをやり取りしているかを直接確かめるほうが確実です。
先方の情報システム部門に、使っている仕様の名称と版、通信手順、送受信している文書の種類を聞けば、標準に沿えるのか個社独自の対応になるのかが判断できます。

得意先と合意した要件が後で変わった場合、どう対応すればよいか

得意先側の担当者交代、発注運用の見直し、先方のシステム更新といった事情はこちらでは止められないため、変わることを前提に扱い方を先に決めておきます。
変更の申し出を誰が受け付けるか、影響と追加の手間を誰が見積もるか、今回の範囲に入れるか次の改修に回すかを誰が判断するか。
この三点を要件定義の終わりに決めておくと、変更が出るたびに社内の判断が揺れることを避けられます。
また、合意した内容を文書で残し、断った要望についても理由を書き添えておくと、変更の相談が来たときに、以前どういう前提で決めたのかを双方で確認できます。

1. 1　出典：独立行政法人情報処理推進機構(IPA)「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年）
2. 2　出典：株式会社フライトソリューションズ「EC-Rider B2B 導入事例（日東電工CSシステム株式会社様）」（事例掲載時点）
3. 3　出典：株式会社フライトソリューションズ「EC-Rider B2B 導入事例（株式会社ポディウム様）」（2025年）
4. 4　出典：一般財団法人流通システム開発センター(GS1 Japan・流通システム標準普及推進協議会)「第28回 卸・メーカーの流通BMS導入企業数推計」（2025年）