販売管理システムの要件定義は何を決める？受注・出荷・請求の流れと確認項目

要件定義で、発注側と開発側が決めること

要件定義は、仕事上の困りごとを集め、実現したい業務とシステムに求める条件を関係者でそろえる工程です。「販売管理を入れたい」という要望から、対象となる仕事、必要な情報、担当の判断、確認できる結果へ具体化します。要件の文章を作成した段階と、関係者が内容を確認して採用した段階も区別します。

発注側の営業・倉庫・経理は、現行資料と実際の例外、次の担当が困る状態を説明します。発注責任者は、部門の希望がぶつかったときの優先度と対象範囲を決められる体制を用意します。開発側や製品提供側には、実現方法、既存機能で扱える範囲、追加作業、費用・日程への影響を確認します。製品名や機能名を先に決めても、業務上の未回答は残ります。

IPAの要件定義の解説は、利用者の要求を整理し、関係者と合意する考え方を示しています。ここでの資料や数値は本記事の独自の架空例であり、IPAの導入事例を再現したものではありません。

一件の販売を、資料と担当でたどる

検討するのは、架空の包装資材卸が架空の飲食店へ包装箱（説明用）を販売するという例です。自社で作る要件定義では、最近の一件を選び、顧客情報などを扱える範囲で伏せて、最初の依頼から後工程まで使った資料を並べます。現在使っている資料と、これから作りたい資料案を区別してください。

この例では、次の資料をつなぐ案を置きます。見積の提示、注文の受付、出荷の指示、請求対象の判断は、それぞれ確認する内容が違います。

図は確認する関係の案です。見積書を作ったことだけで注文が確定したり、出荷指示を作ったことだけで実際に出荷できたりするわけではありません。資料にある数量が、注文数量・引当数量・出荷数量のどれなのかを、その資料を使う担当へ尋ねます。

資料ごとに、元・担当・状態・渡す条件を確かめる

1. 入力元をたどる。顧客からの注文、営業の受注票、倉庫への指示など、どの資料から転記したかを確かめます。見積の途中案と、顧客から受けた注文を同じ確定情報にしません。
2. 誰が記録し、誰が使うかを聞く。作成する人、訂正する人、次に読む人を区別します。部署名だけで終えず、困ったときに内容を答えられる担当を決めます。
3. 状態と、次へ渡す条件を確かめる。受付中、内容確認中、出荷指示の準備、出荷した数量の確認など、自社で区別する状態を選びます。伝票が存在することと、次工程へ進めてよいことは分けて説明します。
4. 戻る仕事を探す。数量変更、納期の相談、出荷できない品目がある場合に、誰へ情報が戻るかを確認します。通常の一方向の矢印に収まらない仕事も、要件の候補です。

IPAの要件定義の成果物事例集には、受注・出荷・請求の情報の流れ、担当や手順、入力・処理・出力を整理する資料の例があります。過去の事例の様式をそのまま必須にせず、今回の仕事を説明するために必要な資料と対応を選びます。

通常出荷と一部出荷を、別の条件で比べる

同じ商品の注文数量を使い、すべて出荷する案と、一部だけ出荷する別条件を比べます。次の値は説明用の案で、実際の受注・引当・出荷記録ではありません。一部出荷案は、通常案を修正して成功した結果でもありません。

引当は、注文へ在庫を割り当てる扱いです。通常案に引当12を置いたことは、実在庫が確保できた証拠ではありません。一部出荷案の引当数量は未確認です。出荷7という例から、在庫が7しかないことや、残分の入荷日を補ってはいけません。

すべて出荷する案で、後工程へ渡す内容を読む

通常の一件では、受注票から出荷指示・請求対象へ何を渡すか

同じ注文の数量12を、出荷数量の確認と請求対象の判断へつなぐ（未承認の要件案）

受注票の12と出荷指示の12が、同じ商品・同じ注文の情報として読めるかを確認する案です。残数量0という記入例だけで、請求書の発行や入金まで終わったとは扱いません。経理が請求対象を判断するには、取引条件と出荷の記録をどう結び付けるかの回答が必要です。

次の確認：営業・倉庫・経理が同じ受注票を指して入力元と引継ぎ条件を決める

一部だけ出荷する別案で、残分の扱いを決める

別条件として一部だけ出荷した場合、残数と請求対象をどう保留するか

出荷7と残5を別状態で保ち、請求対象と残分の扱いは営業・倉庫・経理の回答後に決める（未承認の要件案）

注文12・出荷7・残5は、この架空条件で置いた値です。残数量5は分かっている値で、まだ分からないのは残分をどう扱うかです。残りを後日出荷するのか、注文内容を見直すのか、顧客への連絡と判断を誰が行うのかを確認します。

次の確認：残分の扱い、顧客への連絡、請求条件、決定者を確認し未回答は保留する

図で確かめる問い：営業・倉庫・経理へ同じ注文を渡すとき、出荷7と残5をどこで分け、どの判断を回答待ちにするでしょうか。

この解説図を原寸で見る

図の読み方：注文数量から出荷数量と残数量を分けて読み、請求対象の決定と結び付ける質問を探します。数量の例と、未確認の業務条件を一つの「不明」にまとめず、答えられる担当へ渡します。

MicrosoftのDynamics 365 Salesの解説は、見積の改訂や受注・請求を製品内の状態として説明しています。また、Business Centralの販売業務の解説には、一部出荷や複数の出荷をまとめた請求などの機能が紹介されています。これらは製品ごとの例です。自社が採用する業務や製品で何を使えるかは、条件を示して提供側へ確認します。

今回の対象と期待結果を、一つの要件案へ結ぶ

資料を並べたら、今回変えたい困りごとと対応させて範囲を選びます。この例では「営業が受けた注文を、倉庫と経理が別々に読み直している」仕事を検討の入口にします。新しい機能を広く集める前に、同じ注文について必要な情報を次の担当へ渡せる条件を具体化します。

この範囲は本記事の未承認の検討案です。自社で入金消込、返品、配送予約などが必須なら、その資料と担当を追加します。記事で取り上げた仕事だけを、会社の販売管理全体の必要機能にしないでください。

機能名から、業務と期待結果が読める文章へ進める

1. 困りごとを書く。たとえば「出荷が一部になったとき、経理が何を請求対象にしてよいか分からない」と具体化します。実際の困りごとは、自社の担当へ確認してください。
2. 資料・担当・操作を結ぶ。「営業の受注票と、倉庫が確認した出荷数量・残数量を、経理が同じ注文として参照できる」という案へ変えます。資料の対応が取れない箇所は、入力元や識別方法の質問にします。
3. 条件と期待結果を添える。通常案なら注文12・出荷12・残0、一部出荷の別案なら注文12・出荷7・残5を区別できることを、確認候補にします。請求の確定条件は未回答なので、ここでは確認済みの結果に置き換えません。
4. 確認担当と資料を決める。営業が注文内容、倉庫が出荷・残数量、経理が請求対象の条件を同じ資料で読み合わせる案です。採用判断をする責任者と、説明が食い違った際の確認先も残します。

要件案の書き方の例：営業が受け付けた同じ注文について、倉庫が出荷数量と残数量を記録し、経理が両方を区別して請求対象の判断に使えるようにする。一部出荷を認める条件・請求の基準・決定者は、営業・倉庫・経理の回答と発注責任者の判断を受けて確定する。

この文章を読んで、画面や資料のどこで何を見ればよいか説明できなければ、要件はまだ粗い状態です。必要な表示・入力元・記録のつながりを開発会社へ示し、実現方法と不足条件を回答してもらいます。ここで示した文章は、実装済みの機能や実テストの合格記録ではありません。

合意した条件を、後の確認へつなげる

採用した条件、対象の資料、担当、確認方法を同じ版へまとめます。自社で扱う通常と例外のうち、どの条件を誰が確認するかを選びます。入力エラーや権限を含む詳しい受入条件への落とし込みは、同じ注文の入力と結果から受入条件を決める方法で確認できます。

未回答と周辺条件を、確認先へ戻す

業務の範囲を決めるときは、価格や納期などの条件、現在使うシステム、会計との接続も見ます。以下は通常案と一部出荷案に共通する未確認事項です。空欄を埋めるために、都合のよい値や自動処理を補わないようにします。

取引条件は、元の注文と見積へ戻す

この例の顧客価格は未確認、納期も未確認です。営業に、どの提示条件と注文を対応させるか、条件変更を誰が確認するかを聞きます。現在の単価表があることだけで、その注文へ適用する価格が決まるとは限りません。金額や納期を確定する業務が必要なら、参照する資料と判断する担当を要件へ追加します。

記録先と在庫の扱いは、現行の管理担当へ聞く

受注の正本システムは未確認、在庫の正本システムも未確認です。営業・倉庫・IT担当に、どこで正式な注文と在庫を管理し、どの情報を他へ渡しているかを確認します。引当、出荷指示、実際の出荷を同じ状態名にまとめず、自社で必要な区別を選びます。

同時注文や途中の保存失敗に対して注文と在庫をどう確定するかは、受注と在庫の確定条件へつながる別の詳しい検討です。既存・新規システムを並行利用する場合の記録先と訂正の判断は、新旧システムで注文をどちらへ記録するかも確認してください。

会計との接続と取扱は、経理の業務条件から決める

会計との連携方法は未確認、この例の税・会計上の取扱も未確認です。経理と現行システムの管理担当へ、渡す項目、渡すタイミング、訂正時の対応、渡せなかったときの確認先を尋ねます。請求書案を作れることだけでは、会計側で正しく処理できる条件まで決まりません。実際の取引へ適用する取扱は、経理や必要な専門家へ具体条件を示して確認します。

業務を動かすための条件も、今回の範囲へ含める

利用する部署・人数・時間帯、情報を見たり変更したりする役割、止まると困る仕事、既存データや運用の引継ぎを確認します。必要な応答時間や復旧条件を未確認の数値で埋めず、困る場面と確認担当を整理して開発先へ伝えます。部門間の引継ぎが機能しても、現場で使える時間帯や担当者の操作条件が抜けていれば、業務で使える要件になりません。

回答が出たら、対象・優先度・期待結果を一緒に見直す

• 一部出荷を認める回答なら：残分の管理、顧客への連絡、請求対象の条件と決定者を具体化し、その条件で期待する表示・記録を更新します。
• 一部出荷を認めない回答なら：7だけを先に進める案を採用せず、注文の保留や数量・納期の相談をどう扱うかへ要件案を変えます。すでに出荷した結果として読まないでください。
• 回答がまだなければ：確認先と返答の目安を残し、回答が必要な判断を保留します。並行して進められる資料の整理や担当の確認は続け、未回答を採用済みの仕様へ混ぜません。

変更理由と判断した担当を残し、影響する資料と後工程を読み直します。依頼した文章だけ直して、倉庫の指示や経理の判断条件が以前のままにならないよう、同じ一件の流れで確認してください。

まとめ：同じ受注票を、営業・倉庫・経理で読む

販売管理システムの要件定義は、機能の一覧を埋めるだけでなく、自社の販売一件について、資料・担当・状態・次工程へ渡す条件をそろえる仕事です。通常の一件から始め、一部出荷などの例外でどの判断が増えるかを確かめると、今回の対象と回答待ちを分けて説明できます。

この架空例では注文12に対する出荷12・残0と、別条件の出荷7・残5を比べました。残5という数量と、残分の扱い・請求条件・決定者の未確認を区別しています。要件案に期待結果と確認担当を添え、回答が変わったら、範囲と後工程も同じ版へ戻して見直してください。

参照資料と、この架空例の範囲

• IPA DX SQUARE：要件定義とは？ — 業務とシステムに求める条件、利用者と関係者の関与・合意の考え方を参照。リンク先ガイド全章や旧調査を精読した認定、成功率や法的責任の結論は置いていません。
• IPA：超上流から攻めるIT化の事例集・要件定義 — 業務機能の流れ、担当、入力・処理・出力、画面・帳票や接続の整理例を参照。アーカイブの事例であり、個別のサンプルや標準の最新版をすべて検証したものではありません。
• Microsoft：Dynamics 365 Salesの見積・受注・請求／Business Centralの販売業務 — 状態や一部出荷などを製品固有の例として参照。自社へそのまま当てはまる仕様、製品の採用判断、日本の税・会計の結論として使っていません。
• 卸売の注文・請求・配送連絡の分断を相談した本人投稿 — 本人の主文から困りごとの参考にしたものです。本記事の会社・数量・二つの要件案は独立した架空例で、日本の需要量や投稿者の導入成果を示しません。