ERPの要件定義とは？選定時の要件を具体化する進め方
KXSfourthERPの要件定義は、選定時の要件一覧を詳しく書き直すだけではありません。採用した製品の標準機能を踏まえ、業務の流れ、データ、権限、連携、受入条件を具体化する活動です。本記事では、選定要件との違いと、構築・テストへつながる要件のまとめ方を説明します。
この記事の要点
- 要件は業務目的・実現方法・受入条件をつなげて具体化する
- 通常処理だけでなく、例外・締め・権限・運用も扱う
- 未確定事項は担当者と期限を置き、設定や開発へ黙って流さない
Agenda（この記事の内容）
選定要件から何を具体化するか
選定要件では、候補製品の適合性と費用を比較する条件を整理します。導入時の要件定義では、実際に使う製品と方式を踏まえて、誰が何を行い、何をもって成立とするかを決めます。
例えば「請求書を発行できる」という条件は、対象伝票、締め条件、税や通貨、訂正、送付、承認、会計への反映に分かれます。必要な業務と制約を具体化し、標準設定でどう実現するかを確認します。細部を増やすことだけが目的ではありません。
選定時の要件番号と提案回答を引き継ぎ、どこが確認済みで、どこが仮定かを明らかにします。営業説明と確定した要件を混ぜず、実現方法と条件を導入チームで再確認します。
業務の流れとデータを揃える
業務の開始から完了まで、関係者、入力、承認、出力を整理します。部門ごとの画面ではなく、受注から入金などの流れで確認すると、受け渡しの抜けを見つけやすくなります。
データについては、マスタの定義、管理項目、登録と変更の担当、利用するタイミングを決めます。同じ「部門」「取引先」でも、部門によって意味が違うことがあります。用語の定義を揃えないまま項目だけ作らないことが大切です。
架空の例で、受注時の営業部門と計上時の管理部門が異なるなら、どの値をどの帳票で使うかを分けます。数字が違って見える原因を事前に説明できる設計が必要です。分析用の項目も、データが発生する時点で取得できるかを確認します。
| 要件の構成 | 確認する内容 |
|---|---|
| 目的 | なぜ必要か |
| 業務条件 | 誰がいつ何を行うか |
| 実現方法 | 設定・業務変更・追加対応 |
| 受入条件 | 何が確認できれば完成か |
| 判断記録 | 理由・影響・承認・保留 |
例外と非機能の条件を具体化する
通常の取引が流れても、取消、返品、分割、締め後訂正ができなければ業務が止まります。頻度が低い処理も、影響が大きいものを優先して扱います。誰がどの権限で実行し、履歴をどう確認するかまで整理します。
性能、停止許容、運用、セキュリティなどは、非機能要件として確認します。「速い」「安全」では受入ができないため、対象の処理量、利用状況、完了条件、確認方法を置きます。測定できていない値は仮定と明示します。
連携では、データ項目だけでなく、頻度、失敗時の処理、再実行、重複防止、照合を決めます。接続が成功することと、障害時も業務を継続できることは別です。技術担当と運用担当の両方で確認します。
標準機能との関係と判断を残す
要件を確認しながら、標準機能で対応できる範囲と差分を整理します。差分は個別開発の依頼へ直結させず、業務変更、設定、外部サービスなどの選択肢を比較します。Fit&Gapと要件定義は相互に進む活動です。
判断記録には、目的、選択肢、採用方法、理由、影響、承認者を残します。現行の方法を残す場合にも、なぜ必要かを明らかにします。設計時の背景がわかると、後の変更や保守で判断しやすくなります。
保留事項には責任者、期限、次の工程への影響を付けます。重要な要件が未確定なら、先に進める部分と止める部分を分けます。確定していない設定値を、担当者の推測で補ってしまわないようにします。
受入条件と変更管理へつなぐ
要件には、完成したと判断できる受入条件を付けます。例えば「承認済みの請求だけを出力し、対象件数と合計額が一致する」など、確認できる状態で書きます。実現方法の説明だけではテストの合否を決められません。
要件、設定・開発、テストケースを対応させると、変更の影響と確認の抜けが見えます。一つの要件に複数の試験が必要な場合や、共通の設定が複数業務へ影響する場合も記録します。
要件定義の終了は、すべての将来の変更を止めることではありません。合意した範囲を基準にし、追加や変更の必要性と影響を判断できる状態を作ることです。版、承認日、保留事項を管理し、実務担当者と責任者が同じ前提を持てるようにします。
受入条件から要件の不足を探す
例として「請求書を正しく発行できる」を受入条件にしようとしても、何を正しいとするかが曖昧です。対象となる取引、承認状態、締め日、通貨、税の計算、明細と合計、訂正後の扱いへ分解します。それぞれで期待する結果と確認者がわかれば、設定と試験へつなげられます。
この過程で、「返品が締め後に届く場合を決めていなかった」などの不足が見つかります。試験の準備を最後まで待たず、要件定義の段階で簡単な受入例を作ると、判断が必要な条件を早く発見できます。細かなテストケースをすべて作る必要はなく、重要な通常処理と例外から始めます。
業務責任者が、実現方法の技術説明を理解できなくても、期待する業務結果なら確認できる場合があります。逆に結果を説明できない要件は、目的か条件が曖昧な可能性があります。仕様の記述量を増やす前に、誰に何が確認できれば完成なのかを話し合いましょう。
承認の記録には、確認した文書の版を付けます。「会議で了承した」だけでは、後からどの条件を認めたかが不明になる場合があります。変更があったら影響する要件と試験を明らかにし、必要な担当者が更新内容を確認できるようにします。
受入条件も同じ版で共有します。
よくある質問
要件定義をパートナーに任せられますか？
整理や製品への具体化は支援を受けられますが、業務の目的、変更の可否、データの意味、受入条件は自社側の確認と判断が必要です。
すべてを文書化する必要がありますか？
判断や引継ぎに必要な情報を残します。細部を無制限に増やすより、重要な業務・例外・前提・受入条件を追跡できることを重視します。
次に確認すること
選定時の重要要件を一つ取り出し、業務の流れ・実現方法・受入条件・未確定事項に分けてください。
- ERP選定前の業務要件整理｜必須条件と優先順位を明確にする
- Fit&GapとFit to Standardの進め方｜標準機能と業務の差を判断する
- ERPのカスタマイズはどこまで必要か｜業務変更・設定・追加開発の判断
- ERPのテストと受入判定｜業務シナリオ・合否基準・残る問題の扱い
参考情報・編集方針
本文の手順・評価例はERP選定ラボによる整理です。事例・数値例は説明用の仮定です。製品固有の機能・条件は各社の最新資料で確認してください。
参考情報の確認日：2026年10月28日。運営方針・プロフィール
