SFA導入における推進体制・役割分担｜プロジェクトオーナー・推進リーダー・現場担当の最適配置

SFAの導入を決めたものの、「社内で誰が何を担当するのか」が曖昧なまま進めようとしている担当者は少なくありません。ツール選定や要件定義と並行して早い段階で決めておきたいのが、推進体制の設計です。誰が判断し、誰が現場担当者に展開し、誰がルールを維持するかが決まっていない状態でSFAを動かし始めると、推進が停滞しやすくなります。

推進体制が整っていない状態で導入を進めると、どのフェーズでも同じ課題が繰り返されます。以下では、体制づくりの考え方を具体的に解説します。

SFA導入プロセスの全体像はSFA導入の進め方で整理していますので、体制設計と合わせてご覧ください。

推進体制の不在がSFA導入を止める理由

SFA導入が失敗する原因の多くは、ツールの機能不足ではなく推進体制が整っていないことがあります。「誰が決める権限を持つか」「誰が入力ルールを決めるか」が曖昧なまま始動することで、現場担当者への定着が止まりやすくなります。問題が判明するのは導入直後ではなく、全社展開から数か月が経過した時点であることが多く、そのタイミングでは手を打つのが難しくなっています。

「誰かがやるだろう」で始まる体制なし導入のリスク

SFA導入プロジェクトで「誰がやるか決まっていない」状態が放置されると、判断が必要な場面で進行が止まりやすくなります。止まりやすいポイントは主に3つです。

• 入力様式の変更：現場担当者から「この項目は不要」「この選択肢が足りない」という声が上がっても、変更を決定できる担当者がいない
• 運用ルールの更新：営業プロセスが変わったときに、SFA側の設定を誰が直すかが決まっていない
• ベンダーへの要望伝達：機能に不満があっても、窓口担当がいないためにベンダーへのフィードバックが止まる

これらは「ツールの問題」に見えますが、実際は「推進リーダーが不在」という推進体制の問題です。特に運用開始後の小さな課題が解決されないまま積み重なると、現場担当者の不満がSFAへの不信感に変わり、入力率の低下につながります。

推進リーダーが不在だと、「ルールの微修正」の場面で対応が止まりやすくなります。フェーズ名の変更、入力必須項目の見直し、承認フローの追加といった小さな運用変更が放置され、現場担当者が「このSFAは自分たちの仕事に合っていない」と感じ始めます。その結果として入力が形だけになり、データが蓄積されず、経営層にとっても活用しにくいシステムになっていきます。

推進体制が「ツール選定」より重要な理由

SFA導入を検討する際、ツール選定と推進体制を整えることを並行して進めようとするケースが多くあります。しかし本来の順序は、推進体制を整えることが先です。誰が何を担うか決まっていない状態で説明を受けたりデモを体験したりしても、「誰がどう使うか」という視点で要件を評価しにくくなります。

要件定義・ベンダー選定を適切に進めるには、業務要件を決定できる推進リーダーが存在し、その推進リーダーに必要な権限が付与されていることが重要です。詳細な要件の整理についてはSFA要件定義の進め方をご覧ください。

SFA推進体制の基本構造

SFA推進体制は、判断・推進・実行の3層で設計すると役割を整理しやすくなります。プロジェクトオーナー（経営・事業責任者）・推進リーダー（実務統括）・現場担当者（営業メンバー）が揃うことで体制が整います。どれか一つが欠けると、判断が止まるか、現場担当者への浸透が止まるか、いずれかの問題が発生します。

この3層は「役職名」ではなく「機能と権限」で定義するものであり、一人が複数の役割を兼ねるケースも組織規模によっては有効な選択肢です。

3層構造の概要と権限の明示

3層それぞれが「何を決める権限を持つか」を明確にしておかないと、役割が重複したり、逆に誰も決めない状態が生まれたりします。以下に各層の責任範囲と権限の一例を整理します。

プロジェクトオーナー

• 責任範囲：SFA導入プロジェクト全体の最終承認と予算管理、組織横断の判断
• 持つべき権限：予算執行権、入力義務化などの社内規定化権限、他部門との合意形成における決裁権
• 適切な役職目安：営業部長・事業部長・経営企画部長クラスなど

推進リーダー

• 責任範囲：要件定義・ベンダー折衝・展開計画・定着支援を含むプロジェクト実務の統括
• 持つべき権限：入力様式・営業プロセスのフェーズ区分の変更権、ベンダーへの一次問い合わせ権、現場担当者へのルール告知・徹底の権限
• 適切な役職目安：営業マネージャーまたは営業企画担当など

現場担当者

• 責任範囲：SFAへの日々の入力、実態に基づくフィードバックの提供、チーム内の横展開（キーマンの場合）
• 持つべき関与：入力ルール策定段階でのヒアリング参加、先行利用による課題の抽出

この3層の権限を明確にした「役割定義書」を作成しておくことで、フェーズが進んで担当者が変わった場合も引き継ぎができるようになります。

組織規模別の体制人数の目安

組織規模によって、3層のそれぞれに必要な人員数が変わります。

小規模（営業メンバー30名以下）の場合

推進リーダーがプロジェクトオーナーを兼ねるケースもありますが、兼務すると「自分が推進して自分が承認する」という体制になり、組織としての合意が曖昧になる可能性があります。可能であれば経営者または営業責任者にオーナーの役割だけでも担ってもらい、定期的な判断の場を設ける方法があります。

中規模（30〜200名）の場合

専任の推進リーダーを1名立てたうえで、チームや部門ごとに現場担当者キーマンを複数名配置する形が考えられます。推進リーダーが全体統括に集中できるよう、現場担当者キーマンにチーム内の展開・フィードバック収集を委ねる分業が有効です。

大規模（200名以上）の場合

部門横断のPMO（プロジェクトマネジメントオフィス）を設置しましょう。複数の営業部門・地域拠点がある場合、推進リーダーだけでは情報が届かない拠点が生まれます。情報システム部門との役割分担を明確にしたうえで、各部門に推進担当を置く体制が有効です。

お役立ち資料

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

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

資料をダウンロードする

プロジェクトオーナーの役割と必要な権限

プロジェクトオーナーは「SFA導入の最終責任者」です。推進リーダーへ権限を委譲しつつ、予算・組織変更・他部門調整など現場担当者では解決できない判断を担います。そのため、営業部長・事業部長・経営企画部長クラスなど必要な決裁権を持つ責任者をプロジェクトオーナーとする体制が有効です。プロジェクトオーナーに求められるのは細部への関与ではなく、決定が必要な場面で迅速に判断できる権限と、実際に判断を行うことです。

オーナーが担うべき具体的な判断

推進リーダーがプロジェクトの実務を担う一方、以下の判断はオーナーが担わなければ進みません。

• 予算確保・契約承認：SFAの契約費用、オプション追加、カスタマーサクセス費用などの承認
• 運用ルールの社内規定化：「入力を義務化する」「未入力案件は進捗会議で取り上げる」といったルールを現場担当者に浸透させるためには、必要に応じてオーナー名義で方針を示す
• 他部門との調整・合意形成：情報システム部門のセキュリティ審査、法務部門のデータ管理方針、人事部門の評価制度との連携など、推進リーダーの権限では動かせない調整
• エスカレーション受け：推進が止まったときに判断を下す

これらの判断を推進リーダーに集中させると、推進リーダーは実務と判断の両方を抱えることになり、いずれかが十分に実行できない状態に陥ります。

オーナーが「名前だけ」になるパターンと回避策

多いのは、多忙なマネジメント層をオーナーに据えたものの、実質的な関与がゼロになるパターンです。オーナーが関与しないまま推進が進むと、「現場担当者の抵抗にあった推進リーダーが孤立する」「ベンダーから求められる組織側の判断が止まる」「導入費用の追加が発生したときに判断が遅れる」といった問題が発生します。

回避策として有効なのは以下の2点です。

まず、定期的な報告の場を設けることです。推進リーダーが「オーナーに判断を求める事項リスト（判断リスト）」を毎回持参し、その場で決定を得る体制にします。報告を受けるだけでなく、判断を出すことをオーナーの役割として明確にします。

次に、判断リストをあらかじめ用意しておくことです。「このフェーズでオーナーが決定する項目」を事前に合意しておくことで、オーナー側も何を準備すればよいかが明確になり、関与のハードルが下がりやすくなります。

稟議・社内承認との関係

SFAの導入には、システム調達・クラウドサービス契約・情報セキュリティ審査など複数の社内承認フローが絡みます。これらの承認フローをオーナーが必要に応じて支援・主導することが重要で、推進リーダー単独では関係部門を動かしにくい場合があります。

SFA稟議の進め方では社内承認フローを詳しく解説しています。体制設計と並行して稟議フローを確認しておくことで、承認待ちによる遅延を防ぐことができます。

推進リーダーの役割と動き方

推進リーダーはSFA導入プロジェクトの実務統括者です。要件定義・ベンダー折衝・社内展開・定着支援まで、プロジェクトの幅広い実務を担います。「現場担当者の課題を理解し、経営の意図を翻訳できる」人材が適任で、営業マネージャーまたは営業企画担当が担うことが多いです。推進リーダーの能力よりも、推進リーダーに付与された権限の範囲がプロジェクトの推進力に影響します。権限のない推進リーダーは、何を決めるにも上位承認が必要になり、意思決定に時間がかかりやすくなります。

推進リーダーに付与すべき権限

推進リーダーが動くためには、以下の権限をどこまで付与するかを事前に決めておく必要があります。

• 入力様式・営業プロセスのフェーズ区分の変更権：現場担当者の声を受けてSFAの設定を変更できる権限。毎回オーナー承認が必要な状態では、小さな改善が進みにくくなる
• ベンダーへの問い合わせ・要望の一次窓口権：機能の確認、不具合の報告、追加要望の伝達を推進リーダーが主導できる状態
• 現場担当者ユーザーへのルール告知・徹底の権限：「この項目は必須入力とする」「このフェーズ以降はマネージャー承認が必要」といった運用ルールの決定と告知

SFAによっては、管理者権限の範囲が明確に定義されています。例えばMazrica Salesでは、CSVによる一括インポートはデフォルトで管理者ユーザーのみ利用可能であり、権限設定などの機能も管理者ユーザーに付与されます。そのため、推進リーダーを管理者ユーザーに設定することで権限の範囲が明確になります。このように、推進体制をSFAの設定に反映することを踏まえて、権限の割り当てを行いましょう。

推進リーダーが陥りやすい3つの罠

現場担当者の声を重視しすぎる

現場担当者の声を経営層に届ける役割は重要ですが、現場担当者の要望をすべて受け入れる立場になると、方針の一貫性が失われます。「現場担当者が嫌がるから必須入力をやめる」「現場担当者が使いにくいと言うから項目を減らす」を繰り返すと、SFAがデータの蓄積に足る運用にならなくなります。推進リーダーは「現場担当者の声を聞く」と「組織の目的に沿ったルールを維持する」の両方を担う立場であることを自覚する必要があります。

ベンダーとの調整と社内展開が同時になるとリソース不足に陥る

導入初期は、ベンダーとの設定調整・テスト・社内説明会・マニュアル作成・現場担当者からの問い合わせ対応が同時に発生します。推進リーダー1人でこれらを抱えると、どこかが対応しきれなくなる可能性があります。PoC（小規模検証）フェーズから現場担当者キーマンを巻き込み、社内対応の一部を分担してもらうことで、負荷を分散できます。

定着フェーズで役割が曖昧になる

全社展開が完了すると「プロジェクトは終わった」という認識が広がり、推進リーダーの役割が曖昧になるケースがあります。そのため、定着フェーズでは「誰が運用オーナーとして継続的に管理するか」を事前に決めておく必要があります。推進リーダーが継続するのか、運用担当者に引き継ぐのかを明確にしないと、誰も改善しない「放置された運用」に移行します。

情報システム部門・管理部門との役割分担

SFAは業務システムである以上、情報システム部門（以下、情シス）との関係が生じます。役割分担の例は以下のとおりです。

• 業務要件の決定（何を管理し、どのプロセスで使うか）：営業側（推進リーダー）が担う
• IT要件の管理（セキュリティ審査・既存システムとの連携・インフラ管理）：情シスが担う

摩擦が起きやすいのは「SFAの設定変更が、情シスの審査フローを通過しないと実行できない」という状況です。小さな運用変更のたびに情シスの承認が必要になると、改善のサイクルが遅くなる可能性があります。対策として、「業務設定の変更権は推進リーダーに委ねる」「セキュリティに関わる設定変更は情シスの事前承認を得る」という境界を明確にした役割定義書を作成することが有効です。

SFAベンダーの選び方では、ベンダー評価時に情シスが確認すべき観点も整理しています。ベンダー選定の段階で情シスとの役割分担を確認しておくことも重要です。

現場担当者の巻き込み方

現場担当者の関与設計を怠ると、ツールは導入されても使われないまま終わります。「使わされる側」ではなく「検討に加わる側」に営業メンバーを引き込むことで、定着率が大きく変わります。全員参加を目指すのではなく、キーマンを選定して役割を担ってもらうことが有効な手法です。キーマンが先に利用し、使いやすさの改善に貢献したという実績を持つことで、チーム内での展開にも納得感が生まれやすくなります。

現場担当者キーマン（チャンピオンユーザー）の選び方と役割

現場担当者キーマンの選定基準は主に3つです。

• チーム内での影響力：同僚がその人の言動を参考にする傾向があるか
• ツールへの抵抗感の低さ：新しいシステムや変化に比較的オープンな人材か
• チームへの発信力：感じたことを率直に共有でき、チームに伝播できるか

この3条件を満たす人材を、チームや部門ごとに1〜2名選定します。

キーマンに担ってもらう役割は以下のとおりです。

• 先行利用：全社展開前のPoCフェーズで実際に使い、問題点を洗い出す
• フィードバック収集：自分の経験だけでなく、周囲の意見も集約して推進リーダーに届ける
• チームへの横展開：導入後、同じチームのメンバーに使い方を伝え、最初の疑問に答えるサポート役を担う

キーマンは「管理者」ではなく「同じ現場担当者の先行者」として機能するため、同僚からの抵抗が比較的生じにくく、展開を進めやすくなる場合があります。

営業メンバーの「入力負荷」を下げる工夫

SFAの定着を阻む要因の一つが、入力の手間です。入力に時間がかかるほど、「SFAを使うより自分のメモで管理した方が速い」という判断が現場担当者で生まれやすくなります。

入力負荷を下げるためにまず取り組むべきは、入力項目の絞り込みです。「あれば便利」な項目をすべて必須にすると、入力の障壁が高くなります。初期段階では「特に必要なデータ」だけを必須項目とし、定着してから段階的に項目を拡張していくと、現場担当者の負担を抑えながら定着しやすくなります。この絞り込みの決定権を誰が持つかを運用体制を整える段階で明確にしておきましょう。

入力補助機能を持つSFAでは、この負荷をさらに下げることができます。例えばMazrica Salesのようなアクションテンプレートやアシスト機能を持つSFAでは、よく使う入力パターンをテンプレート化したり、AIが活動内容を要約して更新候補を提示したりすることで、入力工数を抑えられます。こうした機能を活用できることを踏まえながら、「どの項目をどのくらいの細かさで入力するか」のルールを整えることで、推進リーダーが現場担当者に求める基準を現実的な水準に保ちやすくなります。

また、「入力しないと損をする」という仕組みづくりも重要です。案件の進行状況がSFAに蓄積されることで、マネージャーからのアドバイスや類似案件の成功パターンを参照できるというメリットが現場担当者に実感される状態をつくることで、入力への意欲を高めやすくなります。この「使うと得をする」体験をどう作るかが、定着のポイントになります。

現場担当者抵抗を想定したコミュニケーション計画

「なぜSFAを導入するのか」を現場担当者に伝える責任は、推進リーダーにあります。ただし、伝える内容が「管理のため」「本社の方針」だけでは、現場担当者の納得を得にくくなります。「現場担当者にとってどんなメリットがあるか」を中心に据えたメッセージの工夫が必要です。

具体的なコミュニケーション計画として、以下の3点を体制設計の段階から準備しておきましょう。

• キックオフ・説明会の計画：導入の目的・背景・現場担当者へのメリット・使い方の概要を伝える場。推進リーダーが主導し、プロジェクトオーナーが冒頭で一言添えることで、組織としてのコミットメントを伝えやすくする
• FAQドキュメントの作成：「なぜ入力が必要か」「自分のデータはどう使われるか」「従来の管理方法とどう違うか」といった、現場担当者が最初に感じる疑問への回答をまとめた文書
• 現場担当者キーマンを通じた継続的なフィードバック収集：説明会だけで終わらせず、導入後も現場担当者の声が推進リーダーに届く経路を設けておく

フェーズ別の体制シフト

SFA導入は「全社展開すれば完了」ではありません。PoC・段階展開・全社定着の各フェーズで、求められる体制の機能が変わります。同じやり方のまま走り続けると、フェーズ移行時に推進力が失速します。フェーズが進むほど「推進プロジェクト」の性格から「継続的な運用管理」の性格に変化し、必要な人員・権限・コミュニケーション頻度も変わっていきます。

PoC（小規模検証）フェーズの体制

PoCフェーズでは、全社展開の前に限定的な範囲でSFAを試験的に運用し、運用上の課題と改善点を洗い出します。この段階の推進メンバーを必要な範囲に絞ることが重要です。

PoCフェーズでは、例えば推進リーダー1名と現場担当者キーマン2〜3名です。このメンバーが先行利用し、入力ルールの適切さ・操作の分かりやすさ・データ活用の可能性を検証します。

この段階で事前に合意しておくべきことが2点あります。まず、検証対象の絞り込みです。「すべての機能を試す」のではなく、「案件管理の入力・アクション記録・週次レポートの3点に絞る」のように範囲を限定します。次に、判断基準の合意です。「PoCの結果として何を確認できれば全社展開に進むか」を数値または条件で合意しておかないと、いつまでもPoCが終わらない、または課題を抱えたまま展開が進むという問題が起きる可能性があります。

詳細なアプローチについてはスモールスタートアプローチで具体的な進め方を解説しています。

全社展開フェーズの体制

全社展開フェーズでは、PoCで検証した内容を組織全体に広げていきます。この段階で必要な変化は2点です。

まず、部門別キーマンの増員と役割の再定義が必要です。PoCフェーズで3名だったキーマンを、部門ごとに1〜2名ずつ配置し、各部門のフォロー窓口として機能させます。キーマンに「部門内の質問に答える担当者」という公式な役割を与えることで、推進リーダーへの問い合わせ集中を防ぎます。

次に、ベンダーのカスタマーサクセスとの連携方法です。全社展開時には設定変更・トラブル対応・追加要望が集中する可能性があるため、ベンダー側の担当者との定期MTGを設け、課題を逐次共有できるようにします。SFA導入スケジュールの立て方では、導入スケジュールの全体像を整理しています。

定着・改善フェーズへの移行

全社展開が完了した時点でプロジェクトを解散すると、定着フェーズの担当者が不明確になる可能性があります。展開完了後も、以下の機能を担う「運用チーム」への移行が重要です。

• 入力率・活用率・レポート参照頻度などのKPIを確認する担当者の明確化
• 運用マニュアルの更新管理
• 新入社員・中途採用者へのオンボーディング対応
• 営業プロセスの変化に合わせたSFA設定の見直し

「推進プロジェクトのリーダー」を継続して「運用オーナー」にするか、別の担当者に引き継ぐかを、全社展開完了の前に決めておくことが重要です。

推進体制を維持するための運営の仕組み

体制を「図として作る」だけでは十分に活かせません。定例会議・レポーティング・判断の場を整えることで、体制が日常業務の中に組み込まれます。会議のルールとKPIの指標は、体制図と同時に作るべき「体制を動かすための仕組み」です。この仕組みがなければ、初期に設計した3層構造は数か月後に形骸化します。

定例会議のルール（頻度・参加者・アジェンダ）

週次：推進リーダー＋現場担当者キーマン

目的は、現場担当者から上がってくる課題の吸い上げと、入力状況の確認です。必要に応じて30分程度の時間を設け、アジェンダを固定化することで準備コストを下げます。固定アジェンダの例は以下のとおりです。

• 直近1週間の入力率・アクション登録状況の確認（数値共有）
• 現場担当者から寄せられた課題・疑問の整理
• 次の1週間で対処する事項の決定

月次：プロジェクトオーナー＋推進リーダー

目的は、KPIレビューと判断です。推進リーダーが「判断リスト」を持参し、必要な事項についてオーナーがその場で判断します。報告だけで終わる会議にしないことが重要で、「今月何を決めたか」の記録を残します。

アジェンダの固定化により、参加者が事前に準備すべき内容が明確になり、会議のコストが下がります。毎回ゼロから組み立てる会議は準備負荷が高くなるため、テンプレート化が有効です。

KPI設定と進捗管理の実務

運用がうまく回っているかを測るKPIとして、以下を設定できます。

• 案件入力率：対象期間内に発生した商談のうち、SFAに登録された割合
• アクション登録数：担当者ごとの週次・月次の登録件数（現場担当者の活用度合いを測る）
• レポート参照回数：マネージャーがSFAのレポートを参照している頻度（データ活用度合いを測る）

これらの数値を可視化することで、推進リーダーが「どこで入力が止まっているか」を特定し、対策を立てやすくなります。例えばMazrica Salesでは、全プランで利用できる標準レポート（8種）に加え、Growth以上で利用できるカスタムレポートのような機能を備えており、これらの指標を定期的に確認する仕組みを構築しやすくなります。「使われているか」が数値で分かる状態にすることで、推進リーダーが根拠を持って動けるようになります。

ベンダーのサポートを体制に組み込む

ベンダーのカスタマーサクセス担当者を推進チームの一部として活用することが、特に定着フェーズで重要になります。具体的には以下の方法が有効です。

• 月次または隔月のカスタマーサクセス定例MTGに推進リーダーが参加し、KPIの進捗と課題を共有する
• 社内の質問・不具合報告の一次窓口を推進リーダーに集約し、ベンダーへのエスカレーションを一本化する
• 新機能のリリース情報をベンダーから定期的に受け取り、現場担当者への展開要否を判断する

ベンダーに「丸投げ」するのではなく、自社の推進リーダーとベンダーの担当者が役割を明確に分担した状態で連携することが、長期的な運用品質を保つうえで重要です。

推進体制が機能しなくなる典型パターン

推進体制が崩れるのは、立ち上げ時ではなく展開後しばらく経過したタイミングであることが多いです。典型的なパターンを事前に知っておくことで、対策を体制設計に織り込めます。原因は、特定の人材の能力不足ではなく、体制を構築する段階で権限や引き継ぎの仕組みを決めていなかったことにある場合もあります。

パターン1：推進リーダーが孤立する

原因と症状

プロジェクトオーナーが実質的に関与せず、現場担当者からの抵抗（「入力が面倒」「なぜ必要なのか分からない」）を推進リーダーひとりが受け続ける状況です。推進リーダーが「説得できない」「決定できない」という状態が続くと、推進の負担が集中します。その結果、プロジェクトが停滞したり、SFAの活用が進まない状態になったりする可能性があります。

対策

エスカレーション先と判断の基準を明文化します。「現場担当者の合意が得られない場合はオーナーが方針を決定する」「入力ルールの変更や強化が必要な場合はオーナー名義で通達する」というルールを事前に合意しておくことで、推進リーダーが一人で抱え込まない構造を作ります。

パターン2：入力ルールが属人化する

原因と症状

推進リーダーが変わると、「この項目はなぜ必須なのか」「このフェーズはどういう状態で変更するのか」が分からなくなるパターンです。運用ルールが推進リーダーの頭の中にしかない状態で引き継ぎが発生すると、新しい担当者が前任者の意図を把握できず、独自のルール解釈で動き始めます。

対策

運用マニュアルの管理担当と更新ルールを体制図に明記します。「マニュアルの管理者は推進リーダー、更新は変更のたびに実施、保管場所は〇〇」という形で具体化しておきます。マニュアルは存在するだけでなく、「最新版を誰が管理するか」が明確になっていることが重要です。

パターン3：フェーズ完了後に体制が解散する

原因と症状

全社展開が完了すると、推進リーダーをはじめとした体制メンバーの多くが通常業務に戻ります。その結果、定着フェーズを担当する人員が不明確になり、入力率の低下・ルールの形骸化・新機能の未活用が放置される可能性があります。SFA導入失敗事例では、こうした体制上の課題を詳しく確認できます。

対策

定着フェーズの「運用オーナー」を事前に決めておきます。推進プロジェクトの完了基準と、運用フェーズへの移行タイミングを明確にしたうえで、移行後の担当者と役割を体制図に書き込んでおくことが有効です。

パターン4：情シスと営業で権限が宙ぶらりんになる

原因と症状

「IT要件は情シスが担当、業務要件は営業が担当」と原則的には合意しているものの、その境界が曖昧なため、両者が互いの判断を待ち続けるパターンです。例えば「ユーザー権限の設定変更は情シスの承認が必要か、推進リーダーが独断でできるか」という問いに対して、どちらも「相手が決める」と思っている状態が典型例です。

対策

「業務要件の決定権は営業側（推進リーダー）」など、役割の境界を明記した役割定義書を作成します。情シスの関与が必要な領域（セキュリティ設定・外部システム連携・インフラ管理）と、推進リーダーが独自に判断できる領域（入力項目・フェーズ区分・ユーザー権限の業務設定）を具体的な事例で区別して定義しておくことで、判断の空白地帯を減らせます。

まとめ：体制設計から始めるSFA導入

SFA導入における推進体制は、ツール選定・要件定義・展開・定着のすべてのフェーズに影響します。体制を早い段階で決めておくことで、要件定義の担い手が明確になり、展開の推進役を定め、定着後の運用も継続しやすくなります。役割分担が曖昧なまま進めると、どのフェーズでも「誰が決めるか」の問題が繰り返し発生しやすくなります。

組織の状況に応じた最初の一手を以下に整理します。

まずオーナーの特定から始める場合（SFA導入をこれから検討する段階）

予算権限と組織横断の調整権を持つ役職者をオーナーとして明確にし、推進リーダーの候補者との合意形成を進めます。ツール選定と並行して、誰が判断を担うかを明確にしておくことが重要です。

推進リーダーは決まっているがうまく動けていない場合（導入中・定着フェーズ）

推進リーダーの権限範囲を書面で明確化し、情シスとの役割境界を定義します。オーナーとの月次の判断MTGを設けることで、推進リーダーが判断できない事項を滞留させない構造を作ります。

全社展開後に入力率が下がってきた場合（定着フェーズ）

「運用オーナー」が明確に存在するかを確認します。不在であれば推進リーダーまたはその後継者をアサインし、KPIの確認と定例レビューを再開します。

推進体制は一度構築すれば終わりではなく、フェーズの移行に合わせて見直すものです。体制づくりを含むSFA導入の進め方では、導入プロセスの全体像を確認できます。

SFA選定や推進体制づくりに課題を感じている場合は、Mazrica Salesのような現場での使いやすさを重視したSFAの情報を参考に、現場担当者への定着を前提とした進め方を検討してみてください。

よくある質問

Q SFAを導入するとどんな効果があるの？

A

推進体制を整えてSFAを導入した場合の効果として、案件情報の一元管理による「引き継ぎ時の情報損失の抑制」、入力データの蓄積による「受注パターンの可視化と共有」、レポート機能を活用した「マネージャーによる案件状況の把握とフォロー」が挙げられます。一方で、推進体制が整っていない状態での導入は、入力が定着せずデータが蓄積されないため、これらの効果が得られません。体制設計と並行してSFAに何を期待するかを明確にしておくことが、効果測定の起点になります。

Q SFAの問題点は何ですか？

A

SFA導入において起こりやすい問題として、「現場担当者に使われない」「データが蓄積されない」といった定着の課題があります。この原因の多くは機能への不満ではなく、推進体制の不在と入力ルールの整備不足にあります。「誰が入力ルールを決めるか」「入力しないことへの対処を誰が担うか」が決まっていない組織では、SFAは導入しても形骸化します。その他の問題点としては、要件定義の甘さによる機能とのミスマッチ、複数部門間での権限分担の混乱なども見られます。

Q SFAの導入事例はありますか？

A

体制設計のパターンとして代表的なのは、推進リーダーに営業マネージャーなどの現場を理解する担当者を据え、情シスとの役割境界を明文化したうえで段階展開を進めたケースです。PoCフェーズでキーマンを先行利用させ、「PoCの結果として何を確認できれば全社展開に進むか」を数値または条件で事前に合意しておくことで、「いつ全社展開に踏み切るか」の判断をしやすくなります。具体的な企業事例については、各SFAベンダーの導入事例ページを参照することをお勧めします。

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

A

営業メンバーがSFAを使わない理由は大きく3つに分類されます。入力の手間が大きい、使うメリットが実感できない、なぜ必要なのかが理解されていない、などが考えられます。対処法としては、入力項目を絞り込んで必須項目を必要な範囲にすること、使った結果として得られる恩恵（過去の類似案件の参照・マネージャーからの的確なアドバイス）を現場担当者が体験できるようにすること、「なぜ導入するのか」を現場担当者メリットで伝えるコミュニケーション計画を推進リーダーが主導することが有効です。キーマンを先行利用させて実際の活用例をチーム内で共有することも、抵抗感を下げる方法の一つです。

Q SFA導入にはどのくらいの期間が必要ですか？

A

体制設計から定着までの全工程を含めると、組織規模・既存システムとの連携の複雑さ・現場担当者の習熟度によって大きく異なります。そのため、一律の期間を設定することはできません。体制設計・要件定義・ベンダー選定、設定・テスト・PoC、全社展開、定着支援・KPIの確認といったフェーズに分けてスケジュールを設計することが重要です。「とりあえず早く使い始める」ことだけを優先するのではなく、体制づくりと入力ルールの合意を事前に進めることで、導入後の手戻りを抑えやすくなります。

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

A

どちらを先にするかよりも、自組織がまず何を解決したいかを明確にすることが先決です。「案件の進捗管理と受注率の改善」が優先課題であればSFA的な機能、「顧客との長期的な関係管理とLTV向上」が優先課題であればCRM的な機能が起点になります。現在は両機能を統合して提供するSFA/CRMも多く、どちらか一方を単独で選ぶ必要はないケースも多くあります。体制設計の観点では、どちらの機能を先に活用するかによって最初に整備すべき入力ルールや推進の重点が変わります。目的を明確にしてから製品を選ぶ順序を守ることが重要です。