BtoB EC要件定義の進め方6段｜成果物と3層の要件

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

B2B EC-COLUMN

BtoB EC要件定義とは、業務・システム・非機能・制度の要求を「決めた」と合意する工程である

BtoB EC要件定義とは、業務要件・システム化要件・非機能要件・制度要件を洗い出し、関係部門が「これを作る」と合意できる状態にする工程です。独立行政法人情報処理推進機構（IPA、経済産業省所管）は、この工程を4つの領域に整理しています^*1。

この工程を理解するうえで先に押さえたいのが、「要求」と「要件」の違いです。要求とは、現場が「したい」と考えていること。要件とは、その要求を検討したうえで「作る」と決めたことを指します。両者を区別しないまま進めると、出てきた要望がそのまま積み上がり、どこまで作るのかが誰にも分からなくなってしまいます。

IPAが公開する「ユーザのための要件定義ガイド 第2版」は、副題に示された128の勘どころとして要点を整理し、2019年9月12日に公開されました^*1。同ガイドは要件定義を4つの領域に分けています^*1。ビジネス要求定義（BR）、システム化要求定義（SR）、要件定義マネジメント（RM）、主要ドキュメント作成（DD）の4つです。本記事の6段は、この4領域を実務で扱いやすい順序へ組み替えたものです。

要件定義は、BtoB EC導入の全6工程のうち2番目に位置します。現状整理から移行・定着までの全体像は本記事の範囲外とし、ここでは要件定義の内部工程だけを掘り下げていきます。

共通フレーム2013とモデル取引・契約書が要件定義の標準化を裏づける

共通フレーム2013は、国際規格ISO/IEC/IEEE 29148のエッセンスを要件定義プロセスへ導入した枠組みです。ベースとなる国際規格をJIS X 0160:2012に変更し、2013年3月4日に公開されました^*4。情報システム・モデル取引・契約書（第二版）も、ユーザ企業とITベンダーいずれかにメリットが偏らない中立的な立場から、2020年12月22日に公開されています^*5。いずれも公的機関が整備した枠組みであり、要件定義を各社の裁量に委ねず、標準化された工程として扱う考え方が土台にあります。

要件定義は6段で進める

要件定義は、準備・現状把握・業務要件・システム化要件・非機能と制度要件・合意という6段で進めます。この区分は、IPAが示すBR・SR・RM・DDという4領域を、実務で扱いやすい順序に組み替えた整理です^*1。

6段の決めること・参加部門・成果物を一覧にする

各段で決めること、参加部門、成果物を1つの表にまとめます。期間はプロジェクトごとに異なるため、目安の日数ではなく、期間を左右する要因を示します。

第1段：準備 — 目的・スコープ・体制を要件定義マネジメント（RM）として先に決める

第1段では、要件定義の目的・対象範囲・体制・進め方を決めます。IPAはこれを要件定義マネジメント（RM）と呼び、要件定義そのものを管理する活動として独立させています^*1。体制を曖昧にしたまま現状把握へ進むと、後の段で参加すべき部門が抜け落ちる要因になります。

第2段：現状把握 — 受発注を手段別の件数で数える

第2段では、現状の受発注を電話・FAX・メール・EDIなど手段別の件数で数えます。感覚的な多い・少ないではなく、件数として可視化することで、次の段で検討する業務要件の土台になります。

第3段：業務要件（BR）を決める — EC化する業務と残す業務を切り分ける

第3段は、IPAのビジネス要求定義（BR）にあたる工程です^*1。どの業務をEC化し、どの業務を電話や営業担当者の対応として残すかを決めます。残す業務をここで明確にしておくと、次の段のシステム化要件が無理に肥大化しません。

第4段：システム化要件（SR）を決める — 機能一覧・画面一覧・連携先へ落とす

第4段は、システム化要求定義（SR）にあたります^*1。業務要件を、具体的な機能一覧・画面一覧・外部システムとの連携一覧に落とし込みます。基幹システムとの連携仕様をこの段で後回しにすると、構築の段階で仕様の手戻りが発生しやすくなります。

第5段：非機能要件と制度要件を決める — 競合記事が扱っていない層

第5段で決めるのは、非機能要件と制度要件の2つです。非機能要件はIPAの非機能要求グレードを物差しにして、発注者と開発者の認識を合わせます^*3。グレードの具体的な使い方は、後段の「機能要件だけでは足りない」で改めて扱います。制度要件で論点になるのは、電子取引データの保存とデジタルインボイスへの対応方針でしょう。

第6段：合意する — 優先度づけと完了条件を確認する

第6段では、洗い出した要件に必須・推奨・見送りの優先度をつけたうえで、責任者が合意します。ここで合意すべき対象は、要件の一覧そのものではなく「どこまで作り、どこから作らないか」の線引きです。優先度のつけ方と完了条件の具体は、後段の「要件定義の成果物と、完了と言える条件」で扱います。

BtoB EC要件定義で欠かせない「商習慣まわりの要件」

BtoB ECの要件定義では、一般的なEC構築のテンプレートに出てこない商習慣の要件を拾う必要があります。価格・取引・組織という3つの切り口で整理します。

価格：取引先別単価・数量帯別価格・オープン価格の扱いを要件に含める

価格まわりの要件では、取引先ごとに異なる単価、数量帯によって変わる価格、公開する価格（オープン価格）の範囲を決めます。取引先によって価格体系が異なる場合、第4段のシステム化要件でマスタ設計へ反映しなければなりません。

取引：掛売・与信限度・締め支払い・分割納品・ロットと入数を要件に含める

取引まわりの要件では、掛売による後払い、取引先ごとの与信限度、締め日と支払サイト、注文の分割納品、ロットと入数の単位を扱います。これらは受注確定の可否や在庫引当のロジックに直結するため、第3段の業務要件の段階で洗い出しておく必要があります。

組織：取引先側の複数担当・承認フロー・代理店階層、自社側の稟議を要件に含める

組織まわりの要件では、取引先側で発注担当と承認担当が分かれている場合の承認フロー、代理店を経由する階層構造、自社側で稟議が必要な取引条件を扱います。個人向けの一般的なEC購入フローには存在しない要件です。

BtoB固有の要件と一般的なEC要件を比較する

機能要件だけでは足りない — 要件の3層で抜けを潰す

要件定義でつまずく典型は、機能要件だけを書いて非機能要件と制度要件を落とすパターンです。要件を機能要件・非機能要件・制度要件の3層で整理すると、抜けを防ぎやすくなります。

3層の全体像 — 機能要件・非機能要件・制度要件

機能要件は、システムが何をするかという仕様のこと。非機能要件は、性能・可用性・セキュリティなど、機能を支える品質側の要件を指します。そして制度要件が、法令や業界標準への対応です。要件定義の解説では機能要件に説明が集中しがちですが、公開後に問題が表面化しやすいのはむしろ残る2層のほうだといえます。

非機能要件：IPAの非機能要求グレードを認識合わせのチェックリストとして使う

非機能要件を検討する際は、IPAが公開する非機能要求グレードを使います。このグレードは、非機能要求項目を網羅的にリストアップして分類するとともに、要求レベルを段階的に示したものです^*3。項目は6つの大項目ごとに樹系図で示され、3つの典型モデルシステムに対応するグレード表で確認できます^*2*3。個々の項目名を暗記する必要はなく、この樹系図とグレード表を使って発注者と開発者の認識を合わせる、という使い方が要点です。

制度要件：電子取引データの保存とデジタルインボイスを要件表に載せる

制度要件として要件表に立てる欄は、大きく2つです。1つは電子的に受け取った取引データの保存で、保存方式・保存期間・検索要件の3点を欄として起こしておきます。具体的な要件と義務の時期は制度所管の公式情報で確認するものとし、本記事では値を断定しません。もう1つがデジタルインボイスへの対応方針です。日本の標準仕様であるJP PINTは、デジタル庁がJapan Peppol Authorityとして管理しています^*6。仕様は3種類が提供されており、直近のバージョンは1.1.3、2026年6月8日の更新です^*6。請求書の電子化を進めるなら、この標準に合わせるかどうかを第5段で決めておきましょう。

標準への準拠：既存EDI・流通BMSとの関係をどこで決めるか

すでに取引先とEDIを使っている場合、新システムが既存のEDIや流通BMSとどう連携するかを、第4段のシステム化要件で決める必要があります。流通BMSは、消費財流通業界の標準を目指して策定されている、メッセージと通信プロトコルに関するEDI標準仕様です^*7。標準に準拠した連携か、個別のカスタム連携かによって、構築工程の見通しが変わります。

要件定義の成果物と、完了と言える条件

要件定義は、話し合いだけで終わらせるものではありません。文書として残る成果物が揃って、初めて次の工程へ進めるものです。

成果物一覧

優先度づけ：必須・推奨・見送りの3段で切り、「運用でカバー」を明文化する

洗い出した要件の優先度は、必須・推奨・見送りの3段階で切るのが扱いやすいでしょう。見送った要件のうち、システム化せず人の運用で対応する範囲は「運用でカバー」として明文化しておきましょう。この線引きを曖昧なまま持ち越すと、現場側は「ベンダーが対応してくれるはず」、ベンダー側は「運用で吸収されるはず」と考えたまま稼働日を迎えることになります。

なお、費用は要件の量と実現方式によって大きく変わります。優先度づけの結果がそのまま見積金額に響くと考えておいてください。

完了条件：誰が何に合意したら次工程へ進めるのか

要件定義の完了条件は、成果物一覧の各文書に責任者が合意し、必須要件と運用でカバーする範囲の線引きが確定した時点です。合意を口頭で済ませず要件定義書として残すことが、後の工程での言った言わないを防ぎます。

要件定義でつまずく5つの箇所と、どの段で潰すか

要件定義でよく見られるつまずきを5つ挙げ、どの段で対処すべきかを示します。

現場を呼ばずに情報システム部門だけで要件を書くと、机上の要件になる（第2・3段）

情報システム部門だけで要件を確定すると、現場が電話やFAXで行っている例外対応が要件に反映されません。第2段の現状把握と第3段の業務要件には、現場の担当者を欠かさず加えてください。

要求と要件を分けず、出てきた要望をすべて載せると優先度づけができなくなる（第6段）

要求（したいこと）と要件（作ると決めたこと）を区別しないまま進めると、要望がそのまま積み上がり、第6段の優先度づけで収拾がつかなくなります。要望が出た時点で必須・推奨・見送りのどれに近いかを仮に置いておくと、第6段の作業が軽くなります。

非機能要件を書かず、稼働後に性能や権限で揉める（第5段）

非機能要件を明文化しないまま構築を進めると、稼働後にレスポンスの遅さやアクセス権限の不足が判明し、追加の改修が必要になります。第5段でIPAの非機能要求グレードを使い、性能・可用性・セキュリティなどの要求レベルを事前に確認しておく必要があります^*3。

基幹システムとの連携仕様を後回しにすると、構築工程で手戻りが起きる（第4段）

連携仕様を後回しにすると、構築が進んだ段階でデータ形式の不一致が発覚し、設計のやり直しにつながりやすくなります。第4段のシステム化要件で、連携先と連携方式を明示しておく必要があります。

取引先が使えるかを検証しないまま要件を確定する（第3段）

社内の都合だけで要件を確定し、取引先が実際に使えるかを検証しないと、稼働後になっても取引先からの移行が進みません。第3段の業務要件を固める前に、主要な取引先数社に画面イメージと発注手順を見せて反応を確かめておきましょう。

そのまま使える要件定義チェックリスト

要件定義の各段で確認する項目を、番号付きリストにまとめました。読了後に別のチェックリストを探す必要がないよう、本文の要点をそのまま使える形にしています。

段別チェックリスト

1. 準備：目的・対象範囲・体制・進め方を文書で確認したか
2. 現状把握：受発注を手段別の件数で数えたか
3. 業務要件：EC化する業務と残す業務を切り分けたか
4. システム化要件：機能一覧・画面一覧・連携一覧を作成したか
5. 非機能・制度要件：非機能要求グレードで認識を合わせ、制度要件を要件表に載せたか
6. 合意：必須・推奨・見送りの優先度をつけ、責任者が合意したか

ベンダーに渡す前の最終確認

要件定義書をベンダーに渡す前に確認したいのは2点です。1つは商習慣の要件（掛売・与信・取引先別単価など）が漏れていないか。もう1つは、非機能要求グレードと制度要件の欄が空欄のままになっていないかです。

この2点を自力で埋めきれるかどうかが、体制の分かれ目です。BR・SR・RM・DDという公的な枠組みも、非機能要求グレードの読み方も、情報システム部門だけで抱え込める範囲を超えています。営業・経理・法務がそれぞれの制度動向を持ち寄って参加する体制が要ります。

商習慣の要件を洗い出す論点や非機能要求グレードの読み方に慣れた外部の知見を借りると、自社単独で進める場合に比べて、抜けの発見を要件定義の早い段階に前倒しできます。自社の商習慣をどう要件に落とすか相談したい場合は、無料相談で要件を整理するという選択肢もご検討ください。

まとめ：要件定義の成否を分ける2つの軸

本稿では、BtoB EC要件定義の進め方を6段として整理しました。要点は3つに集約できます。第一に、要件定義はBR・SR・RM・DDという公的な4領域を、準備・現状把握・業務要件・システム化要件・非機能と制度要件・合意という実務の6段に組み替えて進めます^*1。第二に、機能要件だけでなく非機能要件・制度要件を含めた3層で整理すると、稼働後のトラブルにつながりやすい抜けを防げます^*2*3。第三に、要件定義は成果物と合意条件が揃った時点で完了したと言えます。掛売や取引先別単価などの商習慣要件を早い段階で拾えるかどうかが、要件定義全体の成否を分けます。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

BtoB EC要件定義はどれくらいの期間がかかりますか。

期間は対象業務の数・連携先システムの数・取引先数によって変わるため、一律の月数では示せません。第2段の現状把握で対象業務を数え、第4段で連携先を確定させると、期間の見通しが立てやすくなります。本記事の6段のうち、時間がかかりやすいのは部署横断の合意が必要な第3段と第6段です。

要件定義は自社とベンダーのどちらが主導しますか。

要件定義マネジメント（RM）と合意形成は自社が主導し、システム化要件（SR）の技術的な実現方法はベンダー候補と一緒に検討する進め方が基本です^*1。自社の商習慣（掛売・与信・取引先別単価など）は、社外の担当者だけでは拾いきれないため、現場を交えて自社側が言語化する必要があります。

要件定義書は誰が書きますか。

情報システム部門または要件定義の責任者が取りまとめ、業務要件は現場の担当者、非機能要件と制度要件は情報システムと法務・経理が内容を確認します。1人が単独で書き上げるのではなく、各段の参加部門が確認した内容を積み上げる形で作成しましょう。

非機能要件は何から手をつければよいですか。

IPAの非機能要求グレードの樹系図とグレード表から始めます。樹系図は非機能要求項目を6つの大項目ごとに階層的に示し、グレード表は3つの典型モデルシステムに対応する要求レベルを示します^*2*3。この枠組みを使うと、担当者の経験だけに頼らず、発注者と開発者の認識を合わせやすくなります。

要件が膨らんで予算に収まらないときはどうしますか。

第6段で必須・推奨・見送りの3段階に優先度をつけ、見送った範囲のうち人の運用で対応できるものを「運用でカバー」として明文化します。すべての要望を機能として実装しようとせず、業務要件（第3段）に立ち返って本当にEC化が必要な範囲かを見直すことも有効です。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版 ― 要件定義を成功に導く128の勘どころ」（2019年9月12日公開）
2. *2　出典：独立行政法人情報処理推進機構（IPA）「システム構築の上流工程強化（非機能要求グレード）」（2019年3月28日改訂）
3. *3　出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレードについて」
4. *4　出典：独立行政法人情報処理推進機構（IPA）「SEC BOOKS：共通フレーム2013」（2013年3月4日）
5. *5　出典：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（2020年12月22日）
6. *6　出典：デジタル庁「デジタルインボイス（電子インボイス）」（2026年6月8日更新）
7. *7　出典：一般財団法人流通システム開発センター（流通システム標準普及推進協議会）「流通BMS」