ERP選定前の業務要件整理｜必須条件と優先順位を明確にする
KXSfourthERP選定前の要件整理は、現行画面をすべて再現する仕様書を作る作業ではありません。業務の目的と制約を明らかにし、候補製品を比較できる条件に整える作業です。本記事では、担当部門から集めた要望を整理し、必須条件と優先順位を決める方法を説明します。
この記事の要点
- 要望の背景と業務上の目的を確認してから要件にする
- 必須・優先・将来希望を分け、必須とする理由を記録する
- 選定時は実現性を比較できる粒度にし、詳細化は導入時へつなぐ
Agenda（この記事の内容）
選定要件と導入時の詳細要件を分ける
選定要件は、候補が自社の主要業務や制約に対応できるかを判断するために作ります。画面項目、帳票の細かなレイアウト、設定値のすべてを最初に決める必要はありません。一方、製品の適合性や費用に大きく影響する条件は省略できません。
例えば「請求書を発行できる」だけでは比較が困難です。締め単位、通貨、明細量、訂正方法、取引先別の条件など、採否に影響する違いを示します。詳しい設定方法までは決めず、どの業務を成立させたいかを書きます。
選定後は、確認できた実現方法と未確認事項を導入チームへ渡します。選定要件と要件定義はつながっていますが、目的と粒度が違います。提案で「対応可能」と回答されたことを、そのまま完成した仕様と扱わないようにします。
要望の背景を聞く
ヒアリングでは「何が欲しいか」に加え、「誰が、いつ、なぜ必要か」を確認します。現行の操作が習慣になっているだけなのか、取引条件や管理上の理由があるのかを分けます。目的がわかると、別の実現方法を検討できます。
例えば「取引先別のExcelを出したい」という要望では、用途が回収状況の確認なら、一覧画面や通知で代替できるかもしれません。一方、外部へ提出する指定形式なら、出力条件の確認が必要です。見た目の要求と業務上の義務を混同しないことが重要です。
ヒアリングには実務を知る担当者と判断できる責任者の両方が必要です。担当者は例外と実態を示し、責任者は業務変更の可否を判断します。日常業務だけでなく、月末、年度末、訂正、返品などの頻度が低い処理も確認します。
| 要件の項目 | 記載例 |
|---|---|
| 業務の目的 | 得意先ごとの請求を正確に行う |
| 条件 | 締め日・通貨・訂正方法 |
| 優先度 | 必須／優先／将来 |
| 確認方法 | 共通デモ・資料・検証 |
| ベンダー回答 | 実現方法・制約・費用 |
業務の流れと例外を整理する
要件一覧の前に、取引の開始から終了までを簡単に図示します。関係部門、使うデータ、承認、外部とのやり取りがわかれば十分です。部門ごとの断片的な要求をつなぎ、途中で誰も担当していない作業を探せます。
通常の流れができたら、取消、返品、分割、締め後訂正、外貨などの例外を加えます。すべてを同じ深さで書かず、頻度と影響で優先度を付けます。年に一度でも決算や出荷が止まる条件なら、選定中に確認する価値があります。
処理量や時間の要件も具体化します。「大量に処理できる」ではなく、想定件数、集中する時間帯、完了が必要な時刻を記載します。数値が未測定なら仮定と明記し、検証前に測定する計画を置きます。
必須条件を増やし過ぎない
必須条件は、満たさなければ採用できない条件です。すべてを必須にすると比較が成立せず、追加開発を増やす方向へ進みやすくなります。必須とする理由、代替手段の可否、変更できる範囲を一緒に記録します。
優先条件は、効果や負担に差が出るものの、代替案を含めて判断できる条件です。将来希望は、初期稼働には不要でも設計や拡張性に影響する場合があります。分類は部門任せにせず、全体の目的と対象範囲に照らして調整します。
例えば入力順序の好みと、監査上必要な承認記録は同じ扱いにしません。ただし「監査上必要」という言葉だけで決めず、社内の管理方針や担当者に必要な状態を確認します。条件の根拠が見えると、後のFit&Gapでも議論がぶれにくくなります。
比較可能な要件一覧にまとめる
要件には識別番号、業務、目的、条件、優先度、確認方法、責任者を持たせます。ベンダーの回答欄には、実現方法、制約、追加費用、前提を設けます。「可能・不可」の二択だけでは、標準機能と個別開発の違いがわかりません。
要件の文章は、一つの判断単位に分けます。「多通貨で受注・請求・入金・分析できる」を一行にすると、一部だけ対応している場合の評価が曖昧になります。関連付けを残しながら、確認する範囲を分割します。
完成した一覧は、業務責任者と情報システム部門で確認します。抜けをなくすことだけを目的にせず、重要な条件が目立つかを見ます。RFP、デモ、評価表で同じ番号を使うと、どの根拠で候補を評価したかを追跡できます。
一つの要望を確認可能な要件へ変える
「月次の数字をすぐ見たい」という要望を例にすると、まず数字が売上、利益、資金のどれかを確認します。対象会社、管理単位、通貨、速報か確定か、必要な時刻を決めます。次に、元データの入力と承認がいつ終わるかを調べます。画面の集計が速くても、元の取引が未入力なら目的は達成できません。
要件には「国内二社の部門別売上を、締めた取引を対象として確認する」など、対象と条件を記載します。必要な管理項目をどの取引で持つか、誰が入力するかも論点として残します。具体的な画面や配置は製品の標準を見てから検討できます。
このように、望む結果、データの前提、責任者、確認方法を分けると、ベンダーへ丸投げする質問から、自社も判断できる要件へ変わります。優先順位を決める際も、その要件が導入目的のどこへ効くかを説明できるようにします。
回答を受けた後も要件一覧を維持します。質問で条件が変わった項目は版を更新し、古い条件による回答と混ぜずに比較します。
よくある質問
現行の機能一覧をそのまま要件にできますか？
出発点には使えますが、目的、使用実態、将来も必要かを確認します。使っていない機能や別の方法で解決できる操作まで引き継ぐ必要はありません。
業務部門が忙しく参加できない場合は？
資料から仮説を作ることはできますが、主要業務と例外の確認、業務変更の判断には部門の関与が必要です。選定計画に参加時間を含めます。
次に確認すること
重要な業務を一つ選び、通常処理と例外処理について、目的・条件・確認方法を一組で記載してみましょう。
- ERPの導入範囲をどう決めるか｜対象業務・拠点と段階導入の考え方
- ERPのRFPとは？提案依頼書に必要な項目と作成の進め方
- ERPのデモで何を確認するか｜業務シナリオと質問の作り方
- ERPの要件定義とは？選定時の要件を具体化する進め方
参考情報・編集方針
本文の手順・評価例はERP選定ラボによる整理です。事例・数値例は説明用の仮定です。製品固有の機能・条件は各社の最新資料で確認してください。
参考情報の確認日：2026年10月28日。運営方針・プロフィール
