SFAの要件定義の進め方｜現状分析・課題整理・営業プロセス標準化・機能要件抽出から優先順位づけまで

SFAの導入プロジェクトで「ツールを選んだが現場に定着しなかった」「期待した効果が出なかった」という失敗の多くは、要件定義の段階で課題の整理が不十分だったことに原因があるケースが多いです。要件定義とは、自社の営業プロセスや課題を整理し、「何のためにSFAを使うか」「どの機能が必要か」を関係者間で認識を統一する工程です。この記事では、現状分析・課題整理から、機能要件の抽出方法・優先順位づけまで、担当者が実際に使える手順を解説します。

SFA導入全体の体系的な流れはSFA導入の進め方と手順で整理していますので、全体像を先に把握したい方はあわせてご覧ください。

SFA導入における要件定義とは

SFA導入における要件定義は「どんな課題を解決するためにどんな機能が必要か」を定義する工程であり、ツール選定・ベンダー交渉・導入後の運用すべての土台になります。ここを省略したり表面的に済ませたりすると、高機能なツールを入れても、現場が使わない、必要な情報が集まらないという事態が起きます。

要件定義の「完成条件」は、現場・マネージャー・経営層・情報システム担当の全員が「これで合っている」と言えるレベルの合意文書が存在することです。導入担当者のみで仕上げた文書を最後に承認してもらうだけでは、後工程で想定外の変更が発生しやすくなります。

要件定義が必要な理由

適切な要件定義は次の4つの場面で役立ちます。

• ベンダー選定や費用算出の根拠になる：「この機能が必須」「このプランで足りる」という判断を、感覚ではなく文書で説明できます。
• 導入後の「期待外れ」リスクを事前に排除できる：「こんなはずではなかった」という事態が発生する場合、要件として整理・合意されていなかった機能や運用ルールに一因があることが少なくありません。
• 現場への説明・稟議資料の裏付けになる：「なぜこのツールが必要か」を具体的な課題と機能の対応関係で示せます。SFAの社内稟議の進め方についてはSFA導入の社内稟議の通し方もあわせてご覧ください。
• カスタマイズ範囲を事前に確定し、費用が想定を超えることを防ぐ：要件が曖昧なまま進むと、後から追加要件が発生するたびに費用が膨らみます。

要件定義が不十分なときに起きること

「とりあえず触ってみてから考える」という進め方でよく起きるのが、次のようなケースです。

入力項目が多すぎて入力が複雑になったケース

SFAでの入力項目を「とりあえず全項目を有効にした」ために現場担当者の入力負荷が上がり、週次の入力率が低いままで、定着しないという結果になります。どの項目を必須にするかを事前に合意していなかったことが原因です。

連携先システムを後から追加しようとするケース

既存のシステムを連携しようとした際に、「API連携が必要だった」と判明し、プランをアップグレードするために追加費用が発生するケースです。API連携は追加機能である場合が多いため、要件定義段階で確認しておけばプラン選定に反映できます。

どの情報をSFAで管理するかが定まっていないケース

SFAと既存のExcelやスプレッドシートとの並行運用が続き、「どちらに入力されている情報が正しいか」という混乱が生じます。情報の一元化という導入目的が達成されにくくなります。

要件定義の完成した状態

要件定義が完成した状態とは、以下の4点が揃っている状態です。

• As-Is/To-Beの業務フロー図：現状の営業フローと、SFA導入後に目指すフローを対比した図
• 機能要件一覧（優先度付き）：「必須」「あると良い」「将来対応」に分類した機能リスト
• 非機能要件チェックリスト：セキュリティ・連携・運用サポートに関する確認済み要件
• 合意議事録：関係者が要件に合意した日付と承認者の記録

この4点が揃っていれば、ベンダー比較・稟議・現場説明・導入後の振り返りに活用できます。

ステップ1：現状分析と課題整理

まず要件定義ですることは「今の営業活動の課題」を把握することです。ヒアリングを行わずに「たぶんこうだろう」という推測で進めると、後になって現場から「そんな課題は意識していなかった」という声が出るため、事実を把握することが重要です。

現状分析では、ツールの問題（Excelやスプレッドシートのバラバラなファイルなどによる情報の分散）だけでなく、プロセスの問題（担当者ごとに商談の進め方が異なる）と人の問題（引き継ぎができない・ノウハウが個人に留まっている）の3軸で整理することが有効です。この3軸のうちどこに大きな課題があるかが、後の機能要件の優先順位に影響します。

ヒアリングの進め方：誰に・何を聞くか

営業活動の課題はそれぞれの立場によって異なるため、同じ質問を使い回すと、それぞれの立場の問題が見えにくくなります。立場別に確認すべき項目を整理しましょう。

• 経営層：売上予測の精度（現状のヨミ管理の精度と根拠）・パイプライン全体の可視化・部門や担当者別のKPI確認
• 営業マネージャー：メンバーの行動量と受注確度の把握方法・進捗報告に費やしている時間・リスク案件の検知タイミング
• 現場担当者（フィールドセールス・インサイドセールス）：日報・報告業務の時間・引き継ぎ時の情報共有のしやすさ・移動中や外出先での情報の確認のしやすさ
• 情報システム担当：既存システム（基幹・会計・MAなど）との連携要件・社内のセキュリティポリシー・ID管理・シングルサインオンの要否

ヒアリングは個別実施でも構いませんが、後で「言ったはずが伝わっていなかった」というトラブルを防ぐために、主な確認事項は書面（ヒアリングシート）で記録し、認識を揃えましょう。

As-Is業務フロー図の作り方

現状のフローを可視化するには、次の3ステップで進めましょう。

まず、商談発生から受注・失注までの主要なタッチポイントを書き出します。「リード獲得」「初回接触」「ヒアリング」「提案」「見積」「クロージング」といった区切りを、自社の実態に合わせて洗い出します。

次に、各タッチポイントで「誰が・何を・どのツールで」やっているかを付箋またはスプレッドシートで整理します。「Aさんは独自のExcelで管理しているが、Bさんは別の形式を使っている」といった担当者間のバラツキもこの段階で記録します。

最後に、課題・ムダ・リスクが発生している箇所に印をつけます。「ここで情報が抜け落ちる」「ここで確認に時間がかかる」「ここで引き継ぎが失敗しやすい」という箇所を可視化することで、To-Be業務フロー図が作りやすくなり、必要な機能要件との照合もしやすくなります。

課題を「営業生産性の方程式」で整理する

課題を並べるだけでなく、「商談数・受注率・単価・工数」のどこに当てはまるかを分類すると、後に機能要件と対応させて確認しやすくなります。

たとえば「初回商談から見積提出まで時間がかかりすぎている」という課題は、受注率とリードタイムの問題です。この場合、案件フェーズ管理・フェーズ滞留日数の可視化・アクションテンプレートが機能要件の候補になります。「現場担当者が退職するたびに顧客情報やデータが失われる」という課題は、工数と属人化の問題であり、コンタクト管理・アクション履歴の一元化の機能が必要になります。このように課題を分類しておくと、優先順位づけの際に「どの課題がKPIにつながるか」を判断しやすくなります。営業生産性の改善アプローチについては営業効率化の4つの方法も参考にご覧ください。

お役立ち資料

選定前の準備でSFA導入は決まる

要件整理から比較・稟議までの検討ステップを抜粋版で解説。導入後に使われないツールを避けたい方へ。

資料をダウンロードする

ステップ2：営業プロセスの標準化と要件への反映

現状分析で「担当者ごとに営業の進め方がバラバラ」という課題が出てきた場合、SFAを導入する前にTo-Beの標準プロセスをある程度決めておく必要があります。なぜならば、SFAは営業プロセスを実行・記録するシステムであり、プロセス自体を自動で決めるものではないからです。

「どのフェーズを経て受注に至るか」「各フェーズの完了条件は何か」「どんな情報を記録するか」を先に合意しておくことで、SFAに設定すべきフェーズ・必須入力項目・案件ボードの構成が決まります。標準化の作業はSFA導入の担当者だけで進めるのではなく、営業マネージャーと現場担当者が参加すると、後の定着率の向上につながります。SFA推進体制とロール分担で解説しているように、推進体制を整えてから導入することで、営業プロセスの標準化が円滑に進むようになります。

To-Be業務フロー図の作り方：フェーズの定義

標準的なフェーズの例として「リード→アポイント→ヒアリング→提案→見積→クロージング→受注/失注」があります。ただし、このまま転用するのではなく、自社の商談の実態に合わせて調整することが重要です。フェーズの数が多すぎると管理が煩雑になり、逆に少なすぎると進捗状況を細かく把握しにくくなります。目安としては5〜7フェーズ程度が運用しやすいケースが多いです。

各フェーズについて、以下の3点を決めておきましょう。

• 前提条件（このフェーズに入る条件）：たとえば「ヒアリング」フェーズに入る条件は「初回アポの実施が完了していること」など
• 完了条件（次のフェーズに進む条件）：「提案書を提出した」「見積金額に合意した」など、明確な事実で判断できる条件
• 記録すべき情報：そのフェーズで確認・更新が必要な項目（競合状況・意思決定者・予算感など）

この3点が決まると、SFAの必須入力項目とフェーズ滞留日数のアラート設定が自然に導き出されます。決めたフェーズを左から順に並べ、各フェーズの完了条件と記録する情報を下に書き添えたものがTo-Beの業務フロー図になります。

案件タイプ別の設定が必要なケース

新規開拓と既存拡販など営業プロセスが異なる場合、またはBtoB直販・代理店経由などチャネルごとに商談の進め方が違う場合は、フェーズ構成を分けましょう。たとえば新規開拓では「ニーズヒアリング」フェーズが重要ですが、既存顧客へのアップセルではそのフェーズが不要なことがあります。

たとえばMazrica SalesのようなSFAでは、Growthプラン以上で案件タイプ機能（複数営業プロセス管理）が利用可能であり、プロセスごとに異なるフェーズ構成を設定できます。こうした要件を要件定義段階で確認しておくと、プラン選定の判断材料になります。

標準化で「捨てる」決断をする

標準化は「全員の現行業務をSFAに移す」ことではなく、「チームとして共通化すべき情報・進め方を決める」ことです。入力項目を増やしすぎると定着率が下がります。「この情報はSFAではなく別のシステムで管理する」「この項目は任意入力にする」という判断を、この段階で関係者と合意しておくことが重要です。

「全部入れれば後で役立つかもしれない」という発想で項目を増やしていくと、現場の入力負荷が上がり、結果としてどの項目も埋まらないという状況を招きます。

ステップ3：機能要件の抽出

機能要件の抽出では、前ステップで整理した課題・To-Beプロセスと機能の対応関係を一覧化します。「欲しい機能を全部書き出す」のではなく「この課題を解決するためにこの機能が必要」という対応づけで整理することで、後の優先順位づけと費用対効果の検討がしやすくなります。

機能要件は「今すぐ必要」「あると良い」「将来対応で良い」の3段階に分けておくことが、選定での比較精度を高めるポイントです。特に、プランによって利用できる機能に差があるSFAでは、「この機能は必須かどうか」という判断がプランの選定と費用につながるため、要件を段階に分けておくと選びやすくなります。

機能カテゴリ別の確認項目

カテゴリごとに、確認すべき要件を整理します。

• 取引先・コンタクト管理 企業情報の自動補完（企業データベース内蔵かどうか）・ニュースやプレスリリースの自動収集・階層管理（親子会社の紐づけ）の要否
• 案件管理 フェーズ設定の柔軟性・複数営業プロセス対応（案件タイプ機能）・フェーズ滞留日数の可視化・案件ボードでのカンバン管理
• アクション管理 活動履歴の記録粒度・テンプレートの利用・モバイルアプリからの入力対応（名刺OCRスキャン・手書きメモOCRの要否）
• レポート・分析 標準レポート（売上予測・売上推移・売上実績・ファネル分析・アクション予測・アクション分析・アクション推移・フェーズ進捗など）で足りるか・カスタムレポートやダッシュボードの必要性・セールスメトリクスによる担当者別強弱分析の要否
• AI機能 AIによる活動要約・更新サジェスト・案件リスク可視化・売上予測・名寄せ
• 外部連携 メール（Gmail・Outlook）・チャット（Slack・Chatwork・LINE）・MA（Marketoなど）・名刺管理（Sansan）・会計（MFクラウド・freee）・iPaaS対応の要否

AIと自動化の要件はプランに直結する

要件定義の段階でAI機能の利用範囲を決めておくと、プラン選定の根拠になります。「AI機能を積極的に活用してマネージャーの案件フォローを効率化したい」という要件があるなら、対応するAI機能があるかを確認したうえでプランを選ぶことになります。逆に「まずは情報の一元化だけできれば十分」という段階であれば、データが蓄積されてから機能を追加するという判断もあります。

たとえばMazrica Salesでは、AIアシスタント（活動の要約・更新サジェスト）はStarterプランから利用可能ですが、利用回数はStarterプラン50回/月、Growthプラン1,000回/月、Unlimitedプラン無制限と異なります。AIインサイト（案件のリスク可視化・類似案件参照）・AI名寄せ・セールスメトリクスはGrowthプラン以上でのみ利用できます。

入力項目の決め方：現場が続けられる粒度に絞る

入力項目は「この情報がないと経営判断できない」ものだけを必須にすることが基本です。全項目を必須にすると現場の入力負荷が上がり、定着しないというのが要件定義のよくある失敗です。

必須項目はフェーズごとに「そのフェーズを進めるために最低限必要な情報」に絞りましょう。たとえば「ヒアリング」フェーズ完了時の必須入力は「意思決定者の確認」「予算感の把握」の2項目だけにして、それ以外は任意にする、というルールにします。フェーズが進むにつれて必要な情報が自然と蓄積されるようにすれば、現場の負荷を上げずに必要なデータが集まります。

ステップ4：非機能要件の整理

機能要件と並んで見落とされやすいのが、セキュリティ・運用・連携に関する非機能要件です。特にセキュリティ要件は情報システム部門担当や法務担当との合意が必要なことが多く、後から確認すると「このプランでは対応できない」となるケースがあります。

要件定義の段階で「誰が・どのデータに・どこからアクセスできるか」「操作ログをどれくらい保持すべきか」を確認しておくことで、プランやベンダー選定の判断基準になります。機能要件の議論が先行しがちですが、非機能要件は後から変更しにくい制約になることが多いため、並行して確認を進めましょう。

セキュリティ要件

セキュリティの観点で確認すべき点は以下のとおりです。

• IPアドレス制限の要否 特定のIPアドレスからのみアクセスを許可する設定が利用可能か確認します。社内ネットワーク外からのアクセスを制限するポリシーがある場合は、この要件をプラン選定に反映します。
• 権限管理の粒度 ユーザーごとのデータ閲覧範囲・操作権限・カスタム権限（ロール・プロファイルの独自設定）の設定は利用可能か確認します。「部門をまたいだデータの閲覧制限が必要か」「特定のメンバーには案件の編集だけ許可したいか」という要件を確認しておきます。
• 監査ログの保持期間 ユーザーの操作履歴（データ登録・更新・削除・CSVダウンロードなど）の保持期間はどのくらいか確認します。コンプライアンス上「操作ログを一定期間保持すること」が求められる場合は、この条件を要件として確認しておきます。
• SSO・多要素認証の対応 Google/Microsoft認証連携などによるシングルサインオンと多要素認証に対応しているか確認します。各サービス側で多要素認証を設定することで適用可能です。
• 第三者認証の取得状況 ISO 27001（ISMS認証）・ISO 27017（クラウドセキュリティ認証）・プライバシーマークの取得有無を、自社のベンダー選定基準と照らし合わせます。

連携要件

連携の観点で確認すべき点は以下のとおりです。

• 基幹システム・既存CRMとのデータ連携 API連携が利用できるかを確認します。既存システムとの双方向連携が必要な場合は、対応範囲もあわせて調べます。
• 利用中のツールとの連携要否 MA（Marketo等）・会計（MFクラウド請求書・freee会計）・名刺管理（Sansan）などの利用中のツールが標準連携対象かどうかを確認します。
• 標準連携にないツールへの対応 iPaaS（Workato・BizteX・Yoom）経由で接続が可能か確認します。標準連携にないツールが必須の場合は、iPaaSを経由した連携要件として記録しておきます。

SFAベンダーの選定段階での連携要件の確認方法については、SFA導入のベンダー選定の考え方で詳しく解説しています。

運用・サポート要件

運用・サポートの観点で確認すべき点は以下のとおりです。

• 導入支援の範囲 初期設定・データ移行（既存ExcelやCRMからのデータ取り込み）・マスタ設定（フェーズ設定・入力項目設定）のサポートがどこまで含まれるかを確認します。
• 定着フォローの有無 導入直後だけでなく、活用状況のレビューや改善提案を継続的に行うサポート体制があるかを確認します。SFA定着のための社内推進体制の整備についてはSFA推進体制とロール分担も参考になります。
• ユーザートレーニングの提供方法 オンライン・オンサイトでのトレーニングの有無、マニュアル・ヘルプコンテンツの充実度を確認します。特に現場担当者の入力操作に関するサポートは、定着率につながります。

ステップ5：要件の優先順位づけ

機能・非機能の要件が出揃ったら、「全部入り」を前提にするのではなく「何を今回実現し、何を後回しにするか」という優先順位を明確にします。要件を全部同列に扱うと、ベンダー選定でどのツールも微妙に合わないという結果になりやすく、判断が遅れます。

優先順位づけの目的は「このリストで優先度の高い課題から解決する構成を選ぶ」ことです。要件の優先順位が明確になると、「このプランのこの機能で十分」という判断ができるようになり、費用と効果のバランスを整理しやすくなります。

MoSCoW分析で4段階に分類する

要件をMoSCoW分析の4段階に分類することが有効です。

• Must（必須） 「これがないと導入した意味がない」という要件です。最初から対応が必須です。「案件の進捗が可視化できること」「担当者の活動履歴が一元管理できること」など、現状の課題を解決するための機能がここに入ります。
• Should（重要） 「できれば対応したいが、なくても運用は回る」という要件です。「カスタムレポートで任意の集計ができること」「AIによる案件リスクの自動検知」など、あると便利だが初期段階では標準レポートで代替できるものです。
• Could（あると良い） 「将来フェーズで対応可能」という要件です。今後の検討候補として記録しておきます。「MA連携による自動ナーチャリング」「iPaaSを使った基幹システムとの双方向連携」などが該当することがあります。
• Won't（今回は対応しない） 「このプロジェクトのスコープ外として明示的に除外」という要件です。「除外しない」のではなく「除外する」という判断を記録することが重要です。

各要件をこの4段階にマッピングする作業を、関係者全員が揃った場で行うことで、要件整理と合意形成を同時に進められます。

優先順位づけの判断基準

優先順位を決める際の判断基準は大きく3つあります。

1つ目は「KPIへの直接貢献度」です。この機能があれば商談数・受注率・リードタイム・入力工数のどれが改善するかを考え、改善幅が大きいものを上位に置きます。「フェーズ滞留日数の可視化によってリードタイムを短縮できる」という対応関係が明確な機能は優先度が上がります。

2つ目は「現場の入力負荷とのバランス」です。入力必須項目が増えるほど定着率が下がります。入力の負担に対して得られる情報が多い要件を優先し、入力の負担に対して得られる情報が少ない要件は後回しにします。

3つ目は「プランによる実現可否」です。上位プランでないと使えない機能（AI機能・カスタムレポート・案件タイプ・API連携など）が要件に含まれる場合、プランアップ分の費用を費用対効果で評価します。「この機能のためにプランを上げることが正当化できるか」という問いに答える材料が要件定義の段階で揃っていると、プラン選定の決断が速くなります。

要件の「捨て方」：除外判断の基準

「将来使うかもしれないから残す」という判断が積み重なると要件が膨らみ、全体の費用と手間が増え、選定に複雑さが増します。除外判断の目安として「12か月以内に実際に使うシナリオを具体的に言えない要件は、今回のスコープに入れない」というルールを設けることが有効です。「いつか使う」「あれば便利かも」という理由だけで要件に残すのではなく、「誰が・いつ・どのデータを使って・何の判断をするか」を具体的に言えない要件はCould（将来対応）またはWon't（除外）に分類します。

要件定義書のまとめ方と合意形成

要件定義の結果を文書化することで、ベンダー比較・稟議・現場への説明・導入後の振り返りすべてに使える「判断の基準」が生まれます。完璧な文書を作ることが目的ではなく、「この文書があれば誰でも判断できる」状態にすることが目標です。

要件が整理されていても合意の進め方が不十分だと、後工程でスコープの再交渉が発生します。合意形成と要件定義書の両方がそろって、要件定義は完了です。

要件定義書に含める項目

最低限、以下の7点が揃っていることが目安です。

• プロジェクトの背景と導入目的（解決したい課題と期待効果）
• As-Is/To-Beの業務フロー図
• 機能要件一覧（優先度付き・MoSCoW分類）
• 非機能要件チェックリスト（セキュリティ・連携・運用サポート）
• 制約条件（予算・スケジュール・既存システム）
• 対象外事項（今回のスコープ外として明示した要件）
• 承認者・合意日

「対象外事項」を文書に明示することは、後工程での「あれはどうなっているか」という問い合わせを防ぐ役割があります。合意した内容だけでなく「合意して除外した内容」を記録しておくことが、プロジェクトを途中で止めることなく推進させるポイントです。

関係者合意のポイント

要件定義は「担当者が完成させて経営層に提出する」だけでは不十分です。現場・マネージャー・経営層が各自の立場でレビューし「合意した」記録を残すことが、後のスコープ変更を防ぎます。

合意形成の場では、機能要件の一覧を全員で確認するだけでなく、「対象外事項」への合意をとることが重要です。「この要件は今回対応しない」という合意がないまま進むと、後になって「あの機能はどうなったか」という確認が発生し、プロジェクトが止まります。

レビューの負荷を下げるために、経営層・マネージャー・現場担当者・情報システム担当で確認してほしい箇所を分けて提示する工夫も有効です。全員が全項目を読む必要はなく、立場ごとに関係する部分を明確にすることで、合意形成のスピードが上がります。

要件定義でよくある失敗パターン

要件定義の失敗は「情報が足りなかった」より「合意が不十分だった」ケースが少なくありません。よくある失敗を把握しておくことで、自社の要件定義の進め方の抜け漏れを事前にチェックできます。SFA導入における失敗要因の全体像についてはSFA導入の失敗事例と原因で詳しく解説しています。

現場ヒアリングを省略して担当者だけで決める

経営層・マネージャーの要望だけで要件を固めると、現場担当者が使いにくいツールになります。「入力項目を絞ってほしい」「モバイルから入力できることが必須」「既存のメールと連携してほしい」といった現場の声を要件に反映しないと、定着率が上がりません。現場担当者にヒアリングに参加してもらうことは、後の「自分たちが決めたシステム」という当事者意識にもつながります。

機能要件に絞って非機能要件を後回しにする

セキュリティや連携要件は「後で確認すればいい」と後回しにしがちですが、プラン差や追加費用に直結します。たとえばAPI連携が必要と後から判明した場合、プランアップが必要になる場合があります。監査ログの保持期間についても、コンプライアンス要件として「3か月以上の記録が必要」という社内ポリシーがある場合は、上位のプランを選択する必要が生じる可能性があります。要件定義の段階でこれらを確認しておかないと、ベンダー選定後に「このプランでは対応できない」と判明するリスクがあります。

優先順位をつけずに「全部対応」を求める

全要件を必須にすると、想定を超える費用の発生・設定工数の増大・現場への展開遅延が起きます。MoSCoW分析で「今回のスコープに入れないもの」を合意しておくことが、プロジェクト全体のスピードを保つために重要です。ベンダーへのRFP（提案依頼）でも、要件の優先度が明示されていると提案の精度が上がります。

他社の導入事例をそのまま転用する

他社のSFA設定や要件定義書を参考にすること自体は有効ですが、「他社がそうしていたから」という理由だけで要件に加えると、自社の営業プロセスと合わない機能を抱えることになります。参考にするのは「設問の観点」や「フォーマット」に限定し、具体的な要件は自社のヒアリング結果から導き出しましょう。SFA導入に関する一般的な誤解についてはSFA導入でよくある誤解も参考になります。

まとめ

SFAの要件定義は「どんな機能を使うか」を決める工程ではなく、「自社の営業課題を解決するために何が必要か」を関係者全員で合意する工程です。現状分析・課題整理・プロセス標準化・機能要件の抽出・優先順位づけという5つのステップを順を追って進めることで、ベンダー選定・稟議・現場展開の土台が固まります。

要件定義の完成条件は、機能要件・非機能要件・対象外事項について関係者の合意が取れ、要件定義に関する文書が作成されている状態になることです。「担当者が作って提出した」だけでは不十分であり、現場・マネージャー・経営層・情報システム担当がそれぞれの立場でレビューし合意した記録が残っている状態を目指しましょう。

SFA導入プロジェクト全体のスケジュールの立て方についてはSFA導入スケジュールの立て方、ベンダー選定での比較・評価の進め方についてはSFA導入のベンダー選定の考え方で詳しく解説しています。また、導入プロジェクト全体の体系的な流れはSFA導入の進め方と手順で整理しています。

要件定義書が完成したタイミングで、具体的なSFAの機能・プランと照らし合わせると良いでしょう。たとえばMazrica SalesのようなSFA/CRMでは、案件ボード・AIアシスタント・カスタムレポートなどの機能をプランに応じて選択できます。自社の要件定義で優先度「Must」に分類した機能がどのプランで利用可能かを確認することで、コストと機能のバランスを整理した選定が可能になります。

よくある質問

Q SFAの要件定義にはどのくらいの期間が必要ですか？

A

規模にもよりますが、ヒアリング・フロー決め・合意形成まで含めて2〜4週間が目安です。営業部門の人数が多い・事業部ごとに営業の進め方が異なる・既存システムとの連携が複雑、などの条件があると1〜2か月かかるケースもあります。「完璧な要件定義」を追求して長期化させるよりも、主要要件を固めて動き始め、パイロット導入の結果を反映する方が早く進む場合も多いです。

Q SFAとCRMはどちらを先に導入すべきですか？

A

多くの場合、営業プロセス管理に強いSFA寄りの機能から始めるのが一般的です。どちらを優先すべきかは、入力負荷・案件の可視化ニーズ・既存ツール連携の3点で判断します。現在では両方の機能を兼ね備えたSFA/CRM製品が主流なため、機能の分離を意識しすぎず「自社の課題に合う機能構成」で選ぶことが重要です。

Q 要件定義書に含めるべき項目は何ですか？

A

最低限、①導入目的と解決したい課題、②As-Is/To-Beの業務フロー図、③機能要件一覧（優先度付き）、④非機能要件チェックリスト（セキュリティ・連携・運用）、⑤制約条件（予算・スケジュール）、⑥対象外事項、⑦承認者と合意日、の7点を揃えましょう。

Q SFAの問題点（デメリット）は何ですか？

A

主なデメリットは3点です。①コスト（月額ライセンス費用）が継続的に発生する、②入力業務の負荷が増える可能性がある（特に現場担当者）、③導入から定着まで一定の期間と社内工数がかかる、です。要件定義の段階で「必須入力項目を絞る」「現場が使いやすいUIのツールを選ぶ」「定着支援の体制を確保する」という対策を盛り込んでおくことで、これらのリスクを軽減できます。

Q 営業メンバーがSFAを使ってくれない場合の対処法は？

A

SFAが使われない原因は大きく「入力が面倒」「使い方がわからない」「使う意味が実感できない」の3つに分かれます。要件定義の段階からできる対策は、①現場担当者にヒアリングに参加してもらい「自分たちが決めたシステム」と実感してもらうこと、②入力必須項目を最小限に絞ること、③「入力した情報が自分のアクション判断に役立つ」ことを体験できる機能（AIアシスタントによる活動要約・案件ボードのフェーズ別色分けなど）を要件に含めること、が有効です。

Q 無料のSFAツールでも要件定義は必要ですか？

A

無料プランであっても要件定義は必要です。無料ツールで始めて「足りなくなったから有料プランへ」という移行のタイミングに、データ移行・設定変更の費用や手間が発生するケースが多くあります。最初から「いずれどのような機能が必要になるか」を見越した要件定義をしておくことで、ツール選定・プラン選定の精度が上がります。