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

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

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

SFAの要件定義とは

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

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

要件定義が必要な理由

要件定義が適切にできていると、次の4つの場面で効いてきます。

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

要件定義を省略したときに起きること

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

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

連携先システムを後から追加しようとして対応できなかったケースでは、「API連携が必要だった」と判明した時点でプランをアップグレードしなければならず、追加コストが発生します。API連携はGrowth以上の機能であるため、要件定義段階で確認しておけばプラン選定に反映できます。

どの情報を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つの方法も参考になります。

ステップ2：営業プロセスの標準化と要件への落とし込み

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

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

To-Beフローの設計：フェーズの定義

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

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

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

この3点が決まると、SFAの必須入力項目とフェーズ滞留日数のアラート設定が自然に導き出されます。

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

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

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

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

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

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

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

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

機能要件は「今すぐ必要」「あると良い」「将来対応で良い」の3段階に分けておくことが、ベンダー選定での比較精度を高めるポイントです。特に、プランによって利用できる機能に差があるSFAでは、「この機能は必須かどうか」という判断がプランとコストに直結するため、要件の粒度を上げておく価値があります。

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

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

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

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

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

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

入力設計：現場が続けられる粒度に絞る

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

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

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

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

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

セキュリティ要件

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

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

連携要件

• 基幹システム・既存CRMとのデータ連携 API連携はGrowth以上で利用可能です。既存システムとの双方向連携が必要な場合は、Growth以上が前提になります。
• 利用中のツールとの連携要否 MA（Marketo等）・会計（MFクラウド請求書・freee会計）・名刺管理（Sansan）との標準連携が用意されています。利用中のツールが標準連携対象かどうかを確認します。
• 標準連携にないツールへの対応 iPaaS（Workato・BizteX・Yoom）経由でGrowth以上であれば国内外1,000以上のアプリケーションとの接続が可能です。標準連携にないツールが必須の場合は、iPaaSを経由した連携要件として記録しておきます。

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

運用・サポート要件

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

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

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

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

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

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

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

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

優先順位づけの判断軸

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

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

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

3つ目は「プランによる実現可否」です。Growth以上でないと使えない機能（AIインサイト・カスタムレポート・案件タイプ・API連携など）が要件に含まれる場合、プランアップ分のコストを費用対効果で評価します。「この機能のためにStarterからGrowthへプランを上げることが正当化できるか」という問いに答える材料が要件定義の段階で揃っていると、プラン選定の決断が速くなります。なお、各プランの1IDあたり月額単価（税別）はStarter6,500円〜・Growth12,500円〜（いずれも最低10IDから）です。

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

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

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

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

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

要件定義書に含める項目

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

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

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

ステークホルダー合意のポイント

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

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

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

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

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

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

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

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

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

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

全要件を必須にすると、コスト超過・設定工数の増大・現場への展開遅延が起きます。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か月かかるケースもあります。「完璧な要件定義」を追求して長期化させるよりも、主要要件を固めて動き始め、パイロット導入の結果を反映する形のほうが現実的な場合も多いです。SFAをスモールスタートで進める考え方についてはSFAのスモールスタートアプローチで解説しています。

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

A

優先すべきかは、入力負荷・案件の可視化ニーズ・既存ツール連携の3点で判断します。「商談の進捗が把握できない」「担当者ごとに管理方法がバラバラ」という課題が先にあるなら、営業プロセス管理に強いSFA寄りの機能から始めるのが一般的です。現在の市場では両者を統合して扱うSFA/CRM製品が主流であり、機能の分離を意識しすぎず「自社の課題に合う機能構成」で選ぶことが先決です。

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

A

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

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

A

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

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

A

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

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

A

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