SFA・CRM導入の要件定義で、「顧客情報を一元化したい」「案件を見える化したい」「活動履歴を残したい」という要望だけを集めると、現場には入力項目が増え、管理者にはレポートが増えます。それでも、どの案件へ支援を入れるか、どの顧客を優先するか、予測をどう修正するかが決められなければ、導入価値は生まれません。
画面や機能の要望を起点にせず、誰のどの判断を変えるかから、業務・データ・定着要件として具体化します。
要件定義の起点は画面ではなく、営業の意思決定です。誰が、どの場面で、どの問いに答え、どの行動を取るのかを明確にし、そこから業務プロセス、KPI、データ、アプリケーション、運用へ展開します。本稿では、ベンダー選定前にも、既存SFA・CRMの再設計にも使える手順を解説します。
この記事でわかること
- 画面要望を営業判断の要件へ変換する方法
- 要件定義で合意すべき業務・データ・ITの論点
- 顧客・商談データの正本と周辺システム連携の考え方
- EAとDMBOKを使った抜け漏れのないレビュー方法
「何を入力するか」より先に「何を判断するか」
同じ商談情報でも、営業担当者、マネジャー、営業企画、経営層では目的が違います。担当者は次の接点を決め、マネジャーは支援が必要な案件を選び、営業企画はボトルネックを特定し、経営層は着地見込みと資源配分を判断します。役割ごとの意思決定が曖昧なまま共通画面を作ると、誰にとっても情報量が多くなります。
| 利用者・場面 | 答えるべき問い | 必要な行動 | 代表データ |
|---|---|---|---|
| 営業担当・日次 | 次に誰へ何を働きかけるか | 接点設定、提案準備、社内支援依頼 | 顧客課題、関係者、次アクション、期限 |
| マネジャー・案件レビュー | どの案件へ介入すべきか | コーチング、リソース投入、中止判断 | ステージ根拠、滞留、競合、リスク |
| 営業企画・週次／月次 | どこがプロセスのボトルネックか | 施策、ルール、育成の改善 | 転換率、滞留日数、失注理由、活動 |
| 経営・予測会議 | 着地見込みと目標との差にどう対応するか | 重点案件への人員・予算配分、パイプライン創出、予測修正 | 金額、受注予定日、確度、予測区分 |
営業判断から逆算する7ステップ
1．経営目的と対象スコープを決める
導入目的を「顧客管理」ではなく、重点顧客の深耕、案件転換率、予測精度、営業生産性などの成果で定義します。対象事業、顧客、商材、チャネル、地域、利用者を明記し、初期リリースで扱わない領域も決めます。成功指標は導入前の基準値を確認できるものにします。
2．意思決定シナリオを記述する
「週次案件レビューでマネジャーが、当月受注見込み案件の根拠とリスクを確認し、支援・見直し・中止を決める」のように、場面、役割、問い、判断、行動を一文にします。The Open GroupのBusiness Scenariosは、業務課題、環境、人・システムのアクター、望ましい結果を関連づけて要求を導く考え方です。機能要望を業務目的へ戻す際に有効です。
3．営業プロセスと判断ゲートを定義する
リード、案件認定、課題把握、提案、評価、交渉、受注・失注などの流れを、顧客の購買プロセスに合わせて設計します。各段階に入口、次段階への移行条件（Exit Criteria）、必要データ、承認・例外、次アクションを置きます。製品標準のステージ名をそのまま採用せず、自社の判断に必要な最小限へ整理します。
4．KPIからデータ項目を導く
画面項目を直接議論せず、意思決定に使うKPIと判断根拠から必要なデータを逆算します。たとえば予測には金額と受注予定日だけでなく、ステージの根拠、次アクション、顧客側の意思決定プロセス、リスク更新時刻が必要です。各項目に利用目的、入力・生成方法、更新期限、品質責任を付けます。
5．正本・データモデル・履歴を設計する
顧客、担当者、案件、活動、商品、見積、契約、売上について、どのシステムを正本とするかを決めます。法人と拠点、個人と所属、案件と見積、案件と受注の関係を概念モデルで確認し、ID連携と重複判定を設計します。組織変更、担当変更、金額・予定日・ステージ変更をどこまで履歴として残すかも要件です。
6．機能・連携・非機能要件を具体化する
入力、検索、案件管理、活動、承認、通知、予測、分析などの機能を、意思決定シナリオと対応づけます。MA、ERP、見積、契約、問い合わせ、DWHとの連携は、同期対象、方向、頻度、整合性、再送、エラー発生時の対応責任を定義します。モバイル、応答時間、可用性、監査、最小権限、データ保持も後回しにできません。
7．運用・定着・変更を要件化する
データ責任者、プロセス責任者、システム責任者を分け、問い合わせ、品質是正、権限付与、機能変更、リリース、教育、棚卸しのRACIを決めます。Salesforce Well-Architectedも、業務価値、標準とカスタム、ガバナンス、データ整合性、利用者体験を健全な設計の重要論点として扱っています。稼働は終了ではなく改善サイクルの開始です。
要件を6層で整理する
| 層 | 主な要件 | レビュー質問 |
|---|---|---|
| 成果 | 事業目的、KPI、対象、期限 | どの経営成果が変われば成功か |
| 意思決定 | 利用者、場面、問い、判断、行動 | この情報で誰の行動がどう変わるか |
| 業務 | プロセス、役割、ゲート、例外、会議 | 顧客の購買プロセスと整合しているか |
| 情報・データ | 定義、正本、粒度、履歴、品質、権限 | 数字の根拠と更新責任を説明できるか |
| アプリケーション | 機能、画面、自動化、連携、分析 | 標準機能と変更の境界は妥当か |
| 運用・技術 | 性能、可用性、監査、変更、教育、廃止 | 稼働後に誰が維持・改善できるか |
データ要件で決めるべき項目
| データ領域 | 設計論点 | 品質ルールの例 |
|---|---|---|
| 顧客 | 法人・拠点・グループ、外部ID、名寄せ、担当 | 重複候補の確認責任と解消期限 |
| 担当者 | 所属、役割、同意、連絡先、異動履歴 | 退職・異動情報の反映期限 |
| 商談 | 金額、予定日、ステージ、確度、競合、失注理由 | ステージ変更時の必須根拠 |
| 活動 | 接点種別、相手、目的、結果、次アクション | 重要接点から一定期間内の記録 |
| 商品・価格 | 商品体系、価格表、通貨、有効期間 | ERP・見積システムとのコード一致 |
| 契約・売上 | 見積、受注、契約、請求、実績との対応 | 商談と受注実績を照合できること |
品質ルールは「必須入力」に置き換えないことが重要です。自動取得できるものは連携・計算し、人が判断すべきものだけを入力します。入力時点で分からない項目を必須にすると、仮値が増えてデータ品質を悪化させます。項目の追加時には、利用する判断、所有者、保持期間、機密性を確認し、使われない項目を廃止できるようにします。
EAとDMBOKを要件レビューに使う
EAでは、ビジネスアーキテクチャで営業能力・プロセス・役割を、データアーキテクチャで顧客・商談・商品・売上の正本と流れを、アプリケーションアーキテクチャでSFA・CRMと周辺システムの責任を整理します。これにより、CRMへすべてのデータを複製する、部門ごとに顧客マスタを作る、同じ承認を複数システムへ実装するといった重複を防げます。
DMBOKでは、データガバナンス、データ品質、メタデータ、マスターデータ、統合、セキュリティを横断します。ビジネス用語集に顧客・案件・受注の定義を置き、データリネージュでCRMからERP・DWHまでの流れを追い、データ責任者が変更を承認します。Salesforceの公式Integration Patternsも、連携方式の選定に際して、データ・プロセス・仮想統合、同期性、ボリューム、障害処理、トランザクションなどを考慮する枠組みを示しています。
構築・製品選定前のチェックリスト
- 導入目的が営業成果と期限で定義されている
- 主要利用者ごとに意思決定シナリオがある
- 営業プロセスと次段階への移行条件が顧客の購買プロセスに沿っている
- 各KPIの定義、比較基準、責任者が決まっている
- 顧客・商談・商品・契約・売上の正本が明確である
- 入力項目に利用目的、更新期限、品質責任がある
- 連携の方向、頻度、エラー時の再処理と責任者が決まっている
- 権限、監査、保持・廃棄を含む非機能要件がある
- 運用・教育・変更・廃止を担う体制がある
- 実案件を使ったプロトタイプで判断の改善を検証した
まとめ：要件定義書は「営業判断からデータまでの追跡表」
SFA・CRM要件は、機能一覧の多さではなく、経営成果、営業判断、プロセス、KPI、データ、機能、運用が追跡できるかで評価します。まず一つの重要会議や営業シーンを選び、誰が何を決め、どの情報が不足しているかを確認してください。その判断に不要な入力や画面は削り、必要なデータの正本と責任を先に決めることで、使われる仕組みへ近づきます。
高度設計：要件を「判断からテストまで」のグラフで管理する
要件一覧を機能別に並べるだけでは、なぜ必要か、削除すると何が困るか、どのデータで受入を判定するかが失われます。経営成果→意思決定→業務シナリオ→業務ルール→データ→機能・連携→非機能→テスト→運用KPIを一つの追跡関係として管理します。要件IDは文書の行番号ではなく、変更後も同じ目的をたどれる識別子にします。
| 要件オブジェクト | 最低限の属性 | 結び付ける対象 |
|---|---|---|
| 意思決定 | 判断者、頻度、選択肢、期限、誤判断による影響 | KGI、会議、業務シナリオ |
| 業務ルール | 条件、判定、例外、根拠、責任者 | プロセス、データ、テスト |
| データ要件 | 定義、粒度、時点、正本、品質、履歴 | KPI、項目、連携、権限 |
| 機能要件 | 利用者、事前条件、正常時・例外時のフロー、結果 | 画面、API、自動化、受入 |
| 非機能要件 | 測定値、負荷条件、測定場所、判定者 | アーキテクチャ、運用、試験 |
すべての重要判断に、必要データと受入シナリオがあるかを確認します。
同じ顧客、商談、売上が画面・連携・BIで同じ定義を参照するかを確認します。
項目やルールの変更から、下流レポート、教育、権限、テストへ影響をたどります。
Fit-to-Standardを「標準への強制」にしない
標準機能を優先する判断は保守性に有効ですが、顧客価値や法令・契約上必要な差まで消すものではありません。ギャップごとに、業務を標準へ合わせる、設定で対応する、周辺機能で補完する、拡張する、要件を撤回するという選択肢を比較します。
| 評価軸 | 確認する問い | 拡張を認める証拠 |
|---|---|---|
| 差別化 | 顧客が価値として認識する固有能力か | 戦略・顧客調査・受注要因 |
| 統制 | 法令、契約、監査で不可欠か | 条文・規程・統制責任者承認 |
| 頻度 | 主要シナリオか、まれな例外か | 実績件数・対象売上・利用者 |
| 保守性 | 更新、テスト、運用の継続費用は何か | 総保有コストと廃止条件 |
| 代替 | プロセス変更や教育で実現できるか | パイロット結果と利用者評価 |
非機能要件を営業影響へ翻訳する
| 観点 | 業務条件 | 測定可能な要件例 | 受入証拠 |
|---|---|---|---|
| 可用性 | 商談更新・見積が止められない時間帯 | 対象時間、許容停止、縮退手順 | 障害訓練・復旧記録 |
| 性能 | 会議で一覧を絞り込み、更新する | データ量、同時利用、応答時間 | 実データ相当の負荷試験 |
| 鮮度 | 受注・入金を営業が確認する | 基準時刻、最大遅延、遅延表示 | 連携ログと画面時刻 |
| セキュリティ | 担当外顧客・機密商談を制限する | 役割、行・項目、職務分離 | ペルソナ別権限試験 |
| 監査 | 金額・確度・同意の変更を説明する | 対象項目、履歴、保管、検索 | 監査シナリオ |
要件管理の成熟度と会議体
| 段階 | 状態 | 定例会議 | 次の改善 |
|---|---|---|---|
| 1 要望集約 | 画面・項目の要望が中心 | 要望確認会 | 意思決定シナリオを付与 |
| 2 追跡可能 | プロセス、データ、テストが要件IDで結合 | 要件レビュー | Fit-to-Standardと変更影響 |
| 3 統制運営 | 価値、リスク、保守性でバックログを判断 | デザインオーソリティ | 本番KPIとの検証 |
| 4 継続学習 | 利用・成果データから要件を再評価 | 四半期価値レビュー | 不要機能とデータの廃止 |
RACIの要点
営業プロセス責任者が業務ルールに最終責任を持ち、データ責任者が定義・品質・利用許可、プロダクト責任者がバックログとリリース、アーキテクトが全体整合、セキュリティ・法務が統制を協議します。実装パートナーに要件の最終責任を置かないことが重要です。
成果物テンプレートと段階導入
| 段階 | 成果物 | レビューゲート |
|---|---|---|
| 発見 | シナリオボード、判断台帳、現状課題の証拠 | 主要シナリオと対象外を合意 |
| 構想 | 将来プロセス、概念データモデル、原則 | 正本・責任・例外を合意 |
| 詳細化 | 追跡表、Fit-gap、非機能、受入テスト | 拡張の根拠と保守責任を承認 |
| パイロット | 利用ログ、品質、業務成果、改善バックログ | 展開・修正・中止を判断 |
用語解説
- Fit-to-Standard
- 標準業務・標準機能を起点に差分と対応方針を判断する方法。
- 要求トレーサビリティ
- 目的から要件、設計、テスト、運用成果までの関係を追跡できる状態。
- デザインオーソリティ
- 横断的な設計原則、例外、技術負債を審査する意思決定機能。
- 受入基準
- 利用者・業務責任者が要件達成を判定する観測可能な条件。
設計の参考にした公式資料
営業判断から始めるSFA・CRM要件定義を支援します
Version株式会社は、営業プロセス、KPI、顧客・商談データ、周辺システム連携、ガバナンスを一体で整理し、ベンダーを同一基準で比較できる要件とロードマップとして具体化します。既存要件のレビューや再構築の診断にも対応します。
参考資料
- Microsoft Learn：Plan a Dynamics 365 implementation strategy
- Salesforce Architects：Well-Architected — Easy
- Salesforce Help：Opportunity Fields
- Salesforce Architects：Integration Patterns
- The Open Group：TOGAF Series Guides
- DAMA International：What is Data Management?
営業改革・SFA・CRMテーマクラスター：営業組織改革の全体像 ／ SFA・CRM要件定義 ／ 営業プロセス標準化 ／ 営業KPI設計 ／ パイプライン・売上予測 ／ 顧客360・マスタデータ ／ SFA定着 ／ CRMデータ移行 ／ CRM・MA・ERP・DWH連携 ／ SFA・CRM刷新
関連するBI／DWHナレッジ：意思決定から逆算するBI要件定義 ／ セマンティックレイヤー ／ データ不一致とリネージュ
コメント