多拠点の得意先システム導入：要件定義で全社統一と拠点差を切り分ける進め方

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

B2B EC-COLUMN

得意先システムの要件定義で、拠点の要望が割れるときに最初に決めること

拠点の営業や事務の担当者から話を聞くほど、得意先の登録の仕方も請求先の書き方も拠点ごとに違うことが分かり、要件定義がまとまらなくなっていませんか。
ここで変えられるのは、要望を全部集めてから調整する進め方そのものです。
得意先の項目ごとに「全社で揃える」か「拠点差を許す」かを切り分けると、一度に決める範囲が小さくなります。
まず拠点横断で扱いを棚卸しします。
次に、請求先のように社外に出る項目から統一するかどうかを決めます。
残す差は理由とともに例外として合意し、要件書に記録します。

要望を集める作業と、項目を切り分ける作業は違う

拠点ごとにヒアリングを重ねると、要件は「A支店はこうしたい」「B営業所はこう使っている」という拠点単位の要望として集まります。
どの要望も、その拠点の業務の中では筋が通っています。
そのため、どれを採用してどれを外すかを比べる物差しがありません。
結果として調整は「どの拠点の言い分を通すか」という話になり、導入を進める担当者が板挟みのまま止まってしまいます。

そこで、決める単位を拠点から、得意先という対象の項目へ移します。
得意先コード、正式名称、請求先、納品先、取引条件、与信限度といった項目を縦に並べます。
そのうえで、項目ごとに全社で一つに揃えるのか、拠点ごとの差を残すのかを決めていきます。
同じ食い違いでも、「B営業所の要望を却下するか」ではなく「請求先の名称を全社で一つにするか」と問い直せば、議論の対象は拠点の立場から項目の性質へ移ります。

項目単位に分けると、すべての項目で拠点がぶつかっているわけではないことも見えてきます。
たとえば、得意先の住所や代表電話番号のように拠点間でほとんど違いが出ない項目もあります。
一方で、納品時の注意事項のように、拠点ごとに書き方がまちまちな項目もあります。
この二つでは、議論に必要な時間がまったく違います。
揉めている項目だけを取り出せれば、決めるための会議の数も参加者も絞れます。

要件定義の進め方には、公的な手引きもあります。
情報処理推進機構（IPA）の「ユーザのための要件定義ガイド 第2版」は、システム部門やITベンダが中心の進め方から、業務部門のユーザが主体的に関わる進め方への転換を支援する資料です¹。
要件定義で直面する問題を、解決の勘どころと組にして示しています¹。
掲載されている勘どころは128個です¹。
ただし、このガイドが扱うのは要件定義一般であり、多拠点の得意先管理に特化した資料ではありません。
ここで示す項目の切り分け方や判断軸は、ガイドの記述ではなく、この枠組みを入口にした編集上の整理です。

要件を出す人と決める人を分ける

もう一つ、先に決めておきたいのが、誰が要件を出し、誰が決めるかです。
拠点の営業担当や事務担当は、自分の拠点で得意先をどう扱っているかを一番よく知っています。
一方で、ある項目を全社で揃えるかどうかは、一つの拠点の業務だけを見て決められる話ではありません。
要件を出す役割と決める役割を同じ会議の中で混ぜると、発言力の強い拠点の扱いが、そのまま全社の要件になってしまうおそれがあります。

導入を進める担当者の仕事は、次の流れになります。
まず拠点の担当者から現在の扱いを聞き取ります。
次に、それを項目ごとに並べて論点を整理し、決める人へ渡します。
決める人には、拠点をまたいで責任を持てる立場の人が向いています。
たとえば営業本部の責任者や、導入プロジェクトの責任者として指名された役員などです。
誰を置くかは会社の組織によりますが、要件定義を始める前に名前を決めておけば、意見が割れたときに担当者が自分で裁く必要がなくなります。

IPAのガイドは、ビジネス要求定義、システム化要求定義、要件定義マネジメント、主要ドキュメント作成といった章立てで要件定義を整理しています²。
誰が何を決めるかを先に置くことは、このうち要件定義を管理する側の仕事にあたると考えられます。
ヒアリングの冒頭で、拠点の担当者に「今日は現状を教えてもらう場で、決めるのは別の場です」と伝えておくとよいでしょう。
それだけでも、自拠点のやり方を守ろうと身構える空気を和らげる助けになります。

拠点横断の棚卸し：誰の扱いを調べ、どの項目で食い違いを見るか

関係者を漏れなく挙げる

項目ごとに扱いを並べるには、まず誰の扱いを調べるかを決めます。
得意先の情報に触れているのは、営業担当だけではありません。
たとえば次のような人が、それぞれ別の項目を使っています。

• 新しい得意先を登録する事務担当
• 取引条件を決める営業の管理職
• 与信を見る経理や審査の担当
• 請求書を発行する担当
• 出荷や納品を手配する倉庫や工場の担当

IPAのガイドには、各ステークホルダ（要件に利害を持つ関係者）が意識すべきことを扱う節があります¹。
また、ステークホルダを漏れなく正確に記述するための勘どころも示されています¹。
拠点が複数ある会社では、この「漏れなく」が拠点の数だけ掛け算になります。
本社の経理には聞いたのに、工場の出荷担当には聞いていなかった、という抜けがあると、納品先の扱いの違いが導入直前まで見えません。

そこで、棚卸しの最初の成果物は関係者の一覧にします。
拠点を横に、役割を縦に置き、各欄に担当者の名前と、その人が触っている得意先の項目を書き込みます。
空欄が残ったら、その拠点にその役割がないのか、まだ聞けていないのかを区別して埋めます。
たとえば、ある営業所では与信を本社の経理が見ているため営業所側に担当がいない、と分かることがあります。
そうした事情も、それ自体が拠点差の一つとして記録に残ります。

項目別に拠点の扱いを並べる表

関係者が決まったら、項目別に拠点の扱いを並べる表を作ります。
行に得意先の項目、列に拠点を置き、各欄にはその拠点での実際の扱いを書きます。
たとえば「得意先コード：本社は連番、A支店は独自の英数字、B営業所はExcelの行番号で管理」のように書きます。
ルールだけでなく、実際に何を見て何を入力しているかまで書くのがこつです。

項目の候補には、次のようなものがあります。
ここでは編集上の整理として、得意先の登録から請求までの流れに沿って並べています。

• 登録：誰が、どの書類をもとに、どの時点で新しい得意先を登録するか
• 得意先コード：採番の規則と、同じ会社が複数のコードを持っていないか
• 取引条件：締め日、支払条件、単価の決め方
• 与信：限度額を誰が決め、どの単位で管理しているか
• 請求先：請求書の宛名に使う名称と送付先
• 納品先：届け先の住所、受け取りの条件、先方の担当者

聞き取りだけで表を埋めると、担当者が「本来のルール」として話した内容と、実際の扱いがずれることがあります。
各拠点で使っている得意先台帳のExcelや、発行済みの請求書の控え、納品書の宛先などを見せてもらえれば、その差が分かります。
同じ得意先の名称が台帳では正式名称、請求書の控えでは略称になっていれば、その拠点の中ですでに揺れが起きていることになります。

表ができたら、項目ごとに食い違いの数を数えます。
全拠点で同じ扱いの項目、二つの流儀に分かれている項目、拠点の数だけやり方がある項目、という程度の粗い分け方で十分です。
この数が、次に統一の要否を決める順番の手がかりになります。
食い違いが多い項目ほど揉めるとは限りません。
それでも、どの項目から話し合えば早く片付くかは、表の上で見えるようになります。

表を埋める段階では、善し悪しを書かないようにします。
「A支店のやり方は非効率」といった評価が混じると、拠点の担当者は次のヒアリングで実態を話しにくくなります。
棚卸しの表は事実を並べるためのもので、判断は次の段階で別に行います。
こう分けておけば、拠点の担当者も安心して現状を話せます。

▼ 図の内容を文字で読む

1. 新規登録を行う事務担当
2. 得意先コード
3. 正式名称と住所
4. 営業担当と営業の管理職
5. 取引条件

得意先コード・与信・請求先・納品先：全社で揃える項目と拠点差を残す項目の判断軸

判断軸の置き方

棚卸し表で食い違いが見えた項目について、全社で揃えるか、拠点差を残すかを決めます。
ここで使う判断軸は、公的な基準として定められたものではなく、編集上の提案です。
項目ごとに、次の三つの問いを順に当ててみます。

• 拠点をまたいで、同じ得意先を同じものとして特定する必要があるか
• その項目が、請求書など社外に出る書類の記載の出所になるか
• 与信のように、全社で合算して見る必要がある数字の単位になるか

一つでも当てはまる項目は、全社で揃える候補になります。
最初の問いに当てはまる代表が、得意先コードです。
同じ会社にA支店とB営業所が別々のコードを振っていると、その会社との取引額を全社で集計するとき、誰かが二つのコードを手で突き合わせなければなりません。
コードを揃えれば、この突き合わせの作業そのものが要らなくなります。

与信は三つ目の問いに関わります。
たとえば、ある得意先にA支店とB営業所の両方が販売していて、それぞれが自拠点の売掛金だけを見て限度額の内側に収めているとします。
拠点ごとには問題がなくても、会社全体ではその得意先への売掛金が想定より膨らんでいる、ということが起こり得ます。
与信を全社で合算して見るかどうかは、経営や経理の方針によります。
ただ、合算すると決めたなら、限度額の管理単位は拠点ではなく得意先に揃える必要があります。

反対に、三つの問いのどれにも当てはまらない項目は、拠点差を残しても全社の業務を止めにくい項目です。
納品先の細かな受け取り条件や、営業担当が残す訪問の記録などがこれにあたります。
これらはその拠点の担当者が一番よく分かっている情報で、全社で書式を揃えても使い勝手が上がらないことがあります。
ただし、納品先の住所そのものを複数の拠点が使う場合は、最初の問いに当てはまる可能性があります。
そのときは、項目をもう一段細かく分けて考えます。

請求書の記載事項から見る請求先の扱い

二つ目の問いについては、確認できる公的な手掛かりがあります。
国税庁のインボイス制度の概要によると、適格請求書には次の事項の記載が必要です³。
交付先の氏名または名称、売手の氏名または名称と登録番号、取引年月日、取引内容、税率ごとの対価の総額と適用税率、税額などです³。
得意先システムから請求書を出すなら、得意先マスタ（得意先の基本情報を集めた台帳）の請求先名称が、この「交付先の名称」の出所になります。

つまり、請求先の名称は請求書に必ず載る事項です。
拠点ごとに略称や旧社名が混じったまま管理していると、その揺れがそのまま請求書に出ます。
たとえば、A支店は正式名称で、B営業所は社内で通じる略称で登録していたとします。
すると、同じ得意先に届く請求書の宛名が、発行した拠点によって違うことになります。
宛名をどこまで正確に書けば足りるかは個別の判断が要る話です。
それでも、要件定義の場で「請求先名称は拠点ごとに自由に書いてよい」と決める理由は見つけにくいでしょう。

一方で、この資料が定めているのは請求書の記載事項です。
得意先マスタをどういう項目で組むかを定めたものではありません³。
請求書の送付方法や、請求書に添える社内の管理番号の付け方まで、ここから全社統一が必要だと導くことはできません。
また、記載事項に挙がっている登録番号は、売手、つまり請求書を発行する自社の側のものです。
請求先の名称は社外に出るので揃え、送付の手配は拠点の運用に残す余地がある、というように根拠が届く範囲で線を引けば、拠点への説明も通りやすくなります。

得意先コード、与信、納品先については、請求書の記載事項のような外部の決まりから、統一するかどうかを直接導くことはできません。
これらは前の三つの問いを使った自社の判断として扱います。
そのうえで、要件書にも全社で揃える理由を自社の言葉で書き残しておくのがよいでしょう。
理由が書いてあれば、後から拠点の担当者に「なぜ変えられないのか」と聞かれたときに、導入を担当した人が異動していても説明が残ります。

▼ 図の内容を文字で読む

1. 得意先コード
2. 全社で一つの採番規則
3. 請求先
4. 請求書の宛名に使う名称（揃える）
5. 請求書の送付の手配（拠点の運用に残す候補）

拠点間の差が大きいとき：共通要件と拠点別要件の切り分けと合意の取り方

共通を先に合意する順

拠点間の業務差が大きいと、項目ごとに判断しても、拠点別に残す部分が多くなります。
このとき全部の項目を一つの会議で決めようとすると、残す部分の議論に時間を取られ、揃える部分まで決まらなくなります。
ここでは、共通部分を先に合意し、拠点別の部分はその後に例外として扱う順を提案します。

共通部分を先にする理由は、共通部分が決まらないと例外の範囲も決まらないからです。
得意先コードの採番規則と請求先名称の扱いが全社で決まれば、各拠点は「その規則の上で、自拠点として残したい扱いは何か」を考えればよくなります。
逆に拠点別の要望から先に聞くと、各拠点がそれぞれの前提で要望を出してきます。
すると、一つ一つが共通部分とぶつかるかどうかを、後から見直す手間が増えます。

IPAのガイドの付録には機能要件の合意形成ガイドがあり、機能要件について合意を形成するためのコツがまとめられています¹。
拠点との合意の取り方を考えるときの参考資料になります。
ただし、共通部分を先にするという順序はガイドの記述ではなく、編集上の提案です。

共通部分の合意は、決める人と、各拠点から一人ずつ出てもらう代表者で行うのが一案です。
議題は、棚卸し表のうち全社で揃える候補になった項目に絞ります。
各拠点の代表者には、揃えたときに自拠点の作業で何が変わるかを事前に書き出してもらいます。
変わる作業が見えていれば、反対意見が出ても「何が困るのか」を具体的に話せます。
そうなれば、決める人も判断しやすくなります。

拠点別要件を例外として残す条件

共通部分が決まったら、拠点ごとに残したい扱いを例外として出してもらいます。
例外として認めるかどうかは、二つの点で見ると整理しやすくなります。
一つは、その扱いを残しても、全社で揃えると決めた項目を崩さないかどうかです。
もう一つは、残す理由がその拠点の取引先や商品、地域の事情などから具体的に説明できるかどうかです。

たとえば、工場に隣接する拠点だけが、得意先ごとに納品時の検品方法を細かく記録している場合を考えます。
この記録は納品先の運用に関する情報で、得意先コードや請求先名称を崩すものではありません。
理由も「その拠点が扱う品目では、検品方法の取り決めが取引ごとにある」と説明できます。
こうした扱いは、拠点別の項目として残す候補になります。

反対に、「慣れているから」「Excelのほうが早いから」という理由だけの扱いは、例外として記録しても、後で誰も説明できなくなります。
理由を説明できない扱いは、例外として認めるのではなく、どう置き換えるかを一緒に考える対象にします。
導入時の操作説明や移行の手順の中で、その拠点の担当者が困らない方法を探します。
目的は例外を減らすことではありません。
残す理由を書ける例外だけを残す、という線引きです。

段階導入を選ぶ場合

拠点の差が大きく、共通部分の合意に加われる拠点と加われない拠点が分かれることもあります。
その場合は、共通部分の合意が済んだ拠点から導入を始める段階導入が選択肢になります。

段階導入で気をつけたいのは、先に導入する拠点の都合で、共通部分を後から変えないことです。
先行した拠点の要望を取り込んで得意先コードの規則を変えると、後から加わる拠点は別の前提で移行の準備をし直すことになります。
段階導入を選ぶなら、共通部分は全拠点の合意として先に固め、拠点ごとに導入の時期だけをずらす形にしておきます。
そうすれば、後から加わる拠点の準備が無駄になりにくくなります。

また、段階導入の期間中は、導入済みの拠点と未導入の拠点とで、得意先の情報が二か所に分かれます。
同じ得意先に両方の拠点が販売している場合は、どちらの情報を正とするかを、移行期間の扱いとして要件書に書いておく必要があります。
全拠点一斉と段階導入のどちらがよいかは、拠点の数や業務差、移行するデータの量によって変わるため、一律には決められません。

▼ 図の内容を文字で読む

1. 共通部分を先に合意する
2. 拠点ごとに残したい扱いを例外として出す
3. 二つの点で例外を確かめる
4. 全社で揃えると決めた項目を崩さないか
5. 残す理由を具体的に説明できるか

要件書と合意記録に何を載せるか、導入後のマスタ管理をどう要件に組み込むか

要件書に載せる項目

決めた内容は要件書に残します。
IPAのガイドは、要件定義の主要ドキュメント作成の勘どころを一つの章として扱っています²。
得意先システムの要件書では、その中に、項目ごとの扱いを一覧で残す部分を設けることを提案します。

一覧の各行には、少なくとも次の内容を載せます。

• 得意先の項目名
• 全社で揃えるか、拠点差を残すか
• 揃える場合はその理由、残す場合は残す範囲
• 例外として残した拠点と、その理由
• 合意した拠点と日付

理由の欄は書くのを後回しにしやすい欄ですが、導入後に役立つのはこの欄です。
たとえば、新しく着任した拠点の事務担当が「なぜ請求先名称を略称で入れてはいけないのか」と疑問に思ったとします。
要件書に請求書の記載事項との関係が書いてあれば、その場で理由が分かります。
理由が書かれていない規則は、担当者が入れ替わるたびに「前のやり方に戻してよいか」という問い合わせを生みます。

合意記録の残し方

要件書とは別に、合意の経緯を残す記録を作っておくと、後で意見が割れ直したときに役立ちます。
記録に残すのは、議題にした項目、各拠点の代表者が出した懸念、決める人が下した結論、その結論に対して残った課題です。

特に残しておきたいのは、反対した拠点の懸念です。
たとえば、B営業所が「得意先コードを統一すると、既存の得意先台帳と照合できなくなる」と懸念を出し、それでも統一すると決めた場合を考えます。
この懸念は、移行時の作業として引き継ぐ必要があります。
記録しておけば、旧コードと新コードの対応表を移行の準備で作る、といった具体的な作業に落とし込めます。

合意記録は、決める人が確認した版を拠点の代表者に共有しておきます。
これは、各拠点の代表者が自拠点の担当者に決定を説明するときの資料にもなります。

マスタ管理の責任者と変更ルール

要件定義で揃えた項目も、導入後に各拠点が自由に得意先を登録できる状態のままだと、時間がたつにつれてまた揺れていきます。
同じ会社が別の拠点から別のコードで登録されたり、請求先名称が略称で入力されたりします。
こうした揺れは、誰が登録してよいか、誰が確かめるかが決まっていないと防ぎにくくなります。

そこで、導入後の得意先マスタの管理を、後から決める運用ではなく、要件として要件書に入れておくことを提案します。
具体的には、次のような内容です。

• 得意先マスタの管理責任者を誰にするか
• 新しい得意先を登録するときの申請と承認の流れ
• 全社で揃えた項目を変更するとき、誰の承認が要るか
• 拠点別に残した項目を、拠点の判断で変えてよい範囲
• 重複や表記の揺れを定期的に点検する担当と時期

申請と承認の流れを要件に入れておけば、システム側の設計を導入の前に検討できます。
たとえば、承認されるまで新しい得意先コードを使えないようにする画面や権限の設計が必要かどうか、です。
運用ルールとして後から決めると、システムがその流れを支えられない場合に、紙やメールでの承認が別に残ります。
その分、拠点の事務担当の手間が増えることがあります。

管理責任者を置いても、拠点の担当者が新しい得意先をすぐに登録したい場面はなくなりません。
承認を待つ間の仮登録を認めるか、認めるならいつまでに本登録へ切り替えるかも、変更ルールの中で決めておきます。
この取り決めがあれば、責任者が承認の時点で重複や表記を確かめることになり、後からまとめて名寄せ（同じ得意先の重複登録を一つにまとめる作業）をする手間を減らせます。

▼ 図の内容を文字で読む

1. 拠点の担当者が新しい得意先の登録を申請する
2. 管理責任者が重複と表記を確かめて承認する
3. 全社で揃えた規則に沿って本登録する
4. 点検の担当が重複や表記の揺れを定期的に調べる
5. 見つかった修正を拠点の担当者が申請する

棚卸し表ができても、どの項目を揃える側に置くかは自社の取引の実態によって変わります。拠点の立場から離れて線を引くことは、社内の担当者だけでは難しい場合があります。

棚卸し表をもとに、揃える候補の項目と例外として残す扱いの線引きを一緒に整理し、決める人へ渡す論点の形にできるかを確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
決める単位	拠点の要望ではなく、得意先の項目ごとに揃えるか残すかを決める
役割	拠点の担当者は現状を出し、決める人は要件定義の前に指名する
棚卸し	関係者一覧を先に作り、項目×拠点の表で食い違いの数を数える
揃える候補	拠点をまたいで特定する項目、社外の書類の出所になる項目、全社で合算する項目
例外	揃えた項目を崩さず、理由を具体的に説明できる扱いだけを残す
記録	項目ごとの扱い・理由・合意した拠点と日付、導入後の登録と変更のルール

導入後の登録や承認の流れを要件に入れるには、システム側で権限や承認をどう支えるかを検討する必要があります。 要件書に書いた得意先マスタの管理ルールが、導入予定のシステムの画面や権限でどこまで支えられ、どこが運用に残るかを確かめられます。

よくある質問

拠点の担当者が、自拠点のやり方を変えたくないと言う場合、どう進めればよいですか。

まず、拠点全体のやり方ではなく、どの項目を変えたくないのかを棚卸し表の上で特定します。
その項目が、拠点をまたいで同じ得意先を特定する、社外に出る書類の出所になる、全社で合算して見る、のいずれにも当てはまらなければ、例外として残す候補になります。
当てはまる場合は、変えると自拠点のどの作業が困るのかを具体的に書き出してもらい、決める人の判断材料にします。
出てきた懸念は合意記録に残し、移行や操作説明の作業として引き継ぎます。

得意先コードを統一せず、拠点別のまま導入するのはどんな場合に成り立ちますか。

同じ得意先に複数の拠点が販売しておらず、全社での取引額の集計や与信の合算も必要としない場合には、成り立つ余地があります。
ただし、後から全社集計が必要になったときには、拠点別のコードを突き合わせる対応表を作り直す手間が生じます。
拠点別のまま進めるなら、その判断の理由と前提を要件書に書いておくことをお勧めします。

既存の得意先データを移行するとき、重複や表記の揺れはいつ整理しますか。

棚卸しの段階で、どの項目にどれくらい揺れがあるかを把握しておきます。
実際の整理は、全社で揃える項目と規則が合意された後、移行の前に行うのが筋です。
統一の規則が決まる前に名寄せを始めると、何を基準に同じ得意先とみなすかが定まらず、やり直しが出やすくなるためです。

要件定義の途中で拠点の意見が割れたら、誰が最終判断をしますか。

要件定義を始める前に指名しておいた、拠点をまたいで責任を持てる立場の人が判断します。
導入を進める担当者は、割れている項目、各拠点の懸念、揃えた場合と残した場合に変わる作業を整理して渡す役割です。
決めた結論と残った課題は、合意記録として拠点の代表者に共有します。

導入後に拠点が勝手に得意先を登録しないようにするには、何を要件に入れればよいですか。

得意先マスタの管理責任者、新規登録の申請と承認の流れ、全社で揃えた項目を変更するときの承認者、拠点が自分の判断で変えてよい範囲、定期点検の担当と時期を要件書に入れます。
急ぎの登録に備えて、仮登録を認めるか、認めるなら本登録への切り替えの期限も決めておきます。
要件として先に書いておけば、承認や権限をシステムの画面でどこまで支えるかを導入前に検討できます。

1. 1　出典：独立行政法人情報処理推進機構（IPA）社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年）
2. 2　出典：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版」概要ページ（2019年）
3. 3　出典：国税庁「適格請求書等保存方式（インボイス制度）の概要」（2026年確認時点の公開版）