SFAの権限設計｜全社展開で失敗しない役割・組織変更・監査の進め方
SFAを全社・複数部門へ展開する際の権限設計を解説。営業担当・マネージャー・営業企画・管理者・連携アカウントの役割を分け、組織変更、例外付与、棚卸し、監査まで運用できる設計書の作り方を整理します。
この記事でわかること
対象：全社・複数部門でSFAの新規導入・刷新・展開を進める営業企画、情報システム、セキュリティ、営業管理者の担当者
- 画面ごとの権限ではなく、誰がどの顧客・案件・活動を、いつ、何の業務で扱うかから設計する
- 異動・兼務・代理・退職などの組織変更を例外処理にせず、申請・期限・承認・記録まで運用に組み込む
- 権限表、実機テスト、定期棚卸し、監査ログをつなげ、設定が業務要件どおりに維持されるか確認する
目次
SFAの権限設計は、営業担当者に案件を見せるかどうかだけの設定ではありません。顧客、案件、商談記録、メール、添付、集計、出力、管理設定のそれぞれについて、誰が閲覧・更新・承認・削除できるかを決める業務設計です。
利用者が100名を超える組織では、異動、兼務、代理対応、部門再編、退職、外部委託などが続きます。個別の設定依頼に都度対応するだけでは、見えてはいけない情報が残る、必要な引き継ぎができない、管理者が設定を説明できないという問題につながります。本記事では、導入前の役割整理から組織変更・監査まで、継続運用できる権限設計の進め方を解説します。
本記事は一般的な権限設計の進め方です。法令、顧客契約、労務上の取扱い、既存のID管理方針により追加の確認が必要です。実際の設定・監査は自社の情報システム・セキュリティ担当者と確認してください。
SFAの権限設計で最初に決める4つのこと
製品の権限名から考え始めると、設定はできても業務上の理由を説明できません。まず、扱う情報、利用者の役割、操作、判断責任を整理します。顧客・案件の閲覧範囲と、全社レポート・一括出力・設定変更の権限は分けて検討します。
| 整理対象 | 決めること | 成果物 |
|---|---|---|
| データ | 顧客・案件・活動・録音・添付の機微度と保持 | データ分類表 |
| 対象範囲 | 部門・拠点・商材・担当顧客・代理対応の範囲 | 閲覧範囲の原則 |
| 操作 | 閲覧・作成・更新・削除・出力・設定変更を誰が行うか | 権限マトリクス |
| 責任 | 申請・承認・設定・棚卸し・例外対応を誰が担うか | 運用責任表 |
役割ではなく業務シナリオから権限を作る
「営業」「管理者」のような大きな区分だけでは不足します。営業担当者が自分の案件を更新する、直属マネージャーがチームの案件を確認する、営業企画が定義を保守する、情報システムがアカウントを管理する、といった実際の操作へ分けます。同じ役職でも、担当顧客、兼務、地域、代理対応によって必要範囲が異なる場合は、役職名ではなく条件を記録します。
| 役割例 | 必要な操作 | 制限・確認点 |
|---|---|---|
| 営業担当者 | 担当顧客・案件・活動の閲覧と更新 | 他部門・退任者の情報は原則見せない |
| 営業マネージャー | 管轄チームの確認・支援・承認 | 閲覧範囲を組織・担当範囲と一致させる |
| 営業企画 | 項目・フェーズ・レポートの管理 | 本番変更の承認・影響確認を残す |
| 情報システム | アカウント・連携・権限グループの管理 | 業務データの通常閲覧は必要最小限にする |
| 監査・セキュリティ | ログ確認・調査 | 閲覧目的・期間・記録を定める |
| 連携アカウント | APIで必要なデータの送受信 | 用途別に分け、権限・鍵・失敗時の扱いを確認する |
全社展開で増える組織変更を標準運用にする
異動や退職を例外扱いにすると、前の組織の閲覧権限が残りやすくなります。人事・ID基盤・組織マスタのどれを基準にするか、反映のタイミング、手動介入が必要な例外を決めます。代理やプロジェクト横断の共有は、申請者、承認者、終了日を残し、恒久的な権限に変わらないようにします。
| 場面 | 事前に決めること | 完了確認 |
|---|---|---|
| 入社・配属 | 付与する標準ロールと教育完了の条件 | 初回ログインと必要範囲だけが見えること |
| 異動・組織変更 | 旧権限の削除、新組織・担当データの引き継ぎ | 旧組織の顧客・案件が見えないこと |
| 兼務・代理 | 対象範囲、承認者、開始・終了日 | 期限後に自動または確認して解除すること |
| 退職・委託終了 | 停止時刻、端末・API鍵・共有アカウントの扱い | ログイン不可と残権限がないこと |
| 緊急調査 | 閲覧理由、承認、対象期間、記録 | 調査後に一時権限を解除すること |
権限マトリクスは設定表ではなく合意文書にする
権限表には、ロール名と可否だけでなく、対象データ、操作、付与条件、承認者、設定者、証跡、見直し時期を入れます。これにより、製品を変更したときも、現在の設定が業務要件を満たすかを確認できます。閲覧可否を細かくしすぎる前に、共通ロールと例外ロールを分け、例外の期限を必ず決めます。
| 項目 | 記載例 |
|---|---|
| ロール | 東日本営業マネージャー |
| 対象データ | 管轄組織の顧客・案件・活動。ただし人事評価資料は対象外 |
| 操作 | 閲覧・更新・承認可。削除・一括出力・設定変更は不可 |
| 付与条件 | 組織マスタ上のマネージャー。兼務は承認済み期限付き申請 |
| 承認・設定 | 営業本部長が承認し、情報システムが設定 |
| 証跡・見直し | 申請記録、月次の例外一覧、半期のロール棚卸し |
導入前に実機で確認するテスト
設定画面やベンダー回答だけでは、実際に何が見えるかを判断できません。営業担当者、マネージャー、営業企画、情報システム、監査担当などのテストユーザーを用意し、閲覧だけでなく検索、添付のダウンロード、エクスポート、レポート、API、組織変更後の挙動を確かめます。見えるべき情報と見えてはいけない情報の両方をテストケースにします。
- 担当外の顧客・案件・商談記録を検索・一覧・レポート・添付から閲覧できないか
- マネージャーが管轄変更後の旧チーム情報を必要以上に見続けないか
- 営業企画が項目やレポートを変更したとき、影響範囲と履歴を確認できるか
- 一括出力・削除・権限変更を限られた管理者だけが実行できるか
- 連携アカウントが用途に必要な範囲を超えて取得・更新できないか
- 異動、代理終了、退職後にアクセスが確実に解除されるか
定期棚卸しと監査ログで設計を維持する
導入時に正しく設定しても、組織変更や例外付与で実態は変わります。標準ロール、期限付き権限、管理者、連携アカウントを対象に、組織・人事情報と照合して定期的に棚卸しします。大量出力、権限変更、設定変更などは監査ログで追えるようにし、誰がどの頻度で確認するかを運用手順に入れます。
参考：IT製品の調達におけるセキュリティ要件リスト活用ガイドブック（IPA）
SFAの権限設計でよくある失敗
- 全利用者へ同じ閲覧範囲を付け、顧客・案件の担当範囲を考慮しない
- マネージャーに全権限を与え、削除・出力・設定変更まで分離しない
- 兼務や代理の権限に終了日がなく、異動後も残り続ける
- 組織変更後に設定を直す前提で、反映責任者と確認手順を決めない
- 連携アカウントを共用し、用途・鍵・操作履歴を追えない
- 権限表だけで判断し、検索・添付・出力・APIを含む実機テストをしない
SFAの権限設計に関するよくある質問
営業マネージャーは部下のすべての情報を見られるようにすべきですか？
役割だけでは決まりません。支援・承認・予測に必要な顧客、案件、活動の範囲を定義し、人事評価資料や不要な添付まで広げないようにします。組織・担当範囲の変更後に閲覧範囲が更新されるかも確認してください。
権限は細かいほど安全ですか？
細かすぎる権限は、設定・問い合わせ・例外処理を増やし、必要な引き継ぎを妨げることがあります。共通ロールを基本にし、機微情報や一括出力など影響の大きい操作を分け、期限付きの例外運用を用意します。
SSOを導入すれば権限管理は十分ですか？
SSOは認証やアカウント統制に役立ちますが、SFA内でどの顧客・案件・操作を許可するかは別に設計が必要です。ID基盤の所属情報とSFAのロール・閲覧範囲がどう対応するかを確認します。
まとめ：権限設計を全社展開後も運用できる状態にする
全社・複数部門へ展開するSFAでは、権限は導入時の設定作業で終わりません。業務シナリオ、データ範囲、役割、組織変更、例外、実機テスト、棚卸し、監査ログをつなげることで、利用者が増えても必要な情報共有と統制を両立しやすくなります。
認証・権限・ログ・AI・契約終了の確認項目を使う
SFAセキュリティチェックリストを読む →自社の組織・権限・移行条件に合う進め方を相談する
大規模な営業組織の導入相談 →
執筆：小花 達也
新卒でソフトバンク株式会社に入社し、デジタルマーケティングを担当。その後、ベンチャー企業数社でBtoBマーケティング、データ基盤構築、営業などを担当した後、ELW株式会社に入社。DRIVE SFAでは導入支援とマーケティングを担当。
本記事は、DRIVE SFAの導入支援・営業運用に関する知見をもとに編集しています。