EN
JP
KRSalesforce要件定義に取り組むべき5つのサイン｜導入・再構築前に見直すべき重要ポイント
Salesforceは、営業活動、顧客情報管理、案件管理、活動履歴の記録、問い合わせ対応、売上予測、経営判断に必要な情報の可視化など、企業の顧客接点を支える中心的な仕組みとして活用できます。特に、営業部門だけでなく、販売促進部門、顧客支援部門、管理部門、経営層まで同じ情報を確認できるようになるため、正しく設計されていれば、社内の情報共有と意思決定の質を大きく高めることができます。
しかし、Salesforceは導入すれば自動的に成果が出るものではありません。自社の業務フロー、顧客情報の持ち方、営業担当者の入力習慣、管理者が確認したい指標、部門間の引き継ぎルールなどを整理しないまま導入すると、画面や項目は存在していても、実際には使われない状態になりやすくなります。導入後に改修を重ねている企業でも、最初の要件定義が曖昧だった場合、時間が経つほど運用が複雑になり、現場にとって負担の大きい仕組みになることがあります。
Salesforce要件定義とは、単に必要な機能を一覧化する作業ではありません。どの業務を改善したいのか、誰がどの情報を使うのか、どのタイミングで入力するのか、どのデータを正しい情報として扱うのか、どの指標を経営判断に使うのかを整理し、Salesforceを業務に合った形へ設計するための重要な工程です。特に既存環境の見直しや再構築を行う場合は、現在の課題を正しく把握したうえで要件を定義し直すことが欠かせません。
この記事では、企業がSalesforce要件定義に取り組むべき5つのサインを解説します。入力されない項目、信頼されないレポートやダッシュボード、部門ごとの運用差、複雑化した設定、現場に定着しない状態などをもとに、どのタイミングで要件定義を見直すべきかをわかりやすく整理します。
1. 入力されない項目が増えている
Salesforce要件定義に取り組むべき最もわかりやすいサインは、現場で入力されない項目が増えている状態です。画面上には多くの項目が用意されているにもかかわらず、実際には空欄が多い、更新されていない、古い情報のまま残っている、担当者によって入力の粒度が大きく違うといった状況が続いている場合、現在の設計が業務に合っていない可能性があります。
入力されない項目が増えると、Salesforceに蓄積される情報の信頼性が下がります。管理者や経営層がSalesforce上の情報を見ても、実際の営業状況や顧客状況を正しく判断できなくなり、結局は担当者への個別確認、表計算ファイル、会議での口頭報告に戻ってしまうことがあります。この状態では、Salesforceは顧客情報を集約する基盤ではなく、現場にとって追加の入力作業になってしまいます。
Salesforce要件定義では、まず現在の項目が本当に必要なのか、どの業務判断に使われているのか、現場が入力できるタイミングに配置されているのかを確認する必要があります。項目を増やすことが管理強化につながるとは限りません。むしろ、使われていない項目を整理し、必要な項目を適切なタイミングで入力できるようにすることが、データ品質と現場定着の両方を高めるために重要です。
1.1 現場にとって入力の意味が伝わっていない
入力されない原因の一つは、現場担当者がその項目をなぜ入力する必要があるのか理解できていないことです。管理者にとっては必要な情報でも、営業担当者から見ると「何に使われているのかわからない項目」「入力しても自分の業務に返ってこない項目」に見える場合があります。意味が伝わらない項目は、忙しい日常業務の中で後回しにされやすく、最終的には入力されなくなります。
たとえば、失注理由、競合情報、次回対応予定、顧客課題、見込み度合いなどは、営業管理や分析には重要な情報です。しかし、その情報が営業会議、提案改善、顧客フォロー、売上予測にどう使われるのかが現場に共有されていなければ、入力の優先度は下がります。Salesforce要件定義では、各項目の利用目的を明確にし、入力する人にとっても納得できる設計にすることが大切です。
また、入力した情報が実際に活用されていることを現場が実感できる導線も必要です。入力した次回対応予定がタスク管理に反映される、顧客課題が提案資料の準備に使われる、失注理由が営業改善の議論に使われるといった形で、入力と業務成果がつながっていれば、現場の協力を得やすくなります。要件定義では、項目そのものだけでなく、入力後に情報がどのように使われるかまで設計する必要があります。
1.2 入力タイミングが業務フローと合っていない
入力されないもう一つの大きな原因は、入力タイミングが実際の業務フローと合っていないことです。たとえば、初回接点の段階ではまだわからない情報が必須項目になっている、商談直後に大量の情報入力を求められる、受注前に契約後の詳細情報まで入力しなければならないといった設計では、現場担当者の負担が大きくなります。結果として、仮の情報を入れたり、後で入力しようとして忘れたりする状態が起きやすくなります。
Salesforce要件定義では、業務の流れに合わせて、どの段階でどの情報を入力するのかを整理する必要があります。初回登録では最低限の顧客情報だけを入力し、商談化した段階で課題や予算感を追加し、提案段階で競合や決裁者情報を整理し、受注後に契約や導入に関する情報を補完するといったように、段階的な入力設計にすることで、現場の負担を減らしながら必要な情報を集めやすくなります。
入力タイミングの設計では、必須項目の設定も慎重に考える必要があります。必須項目を増やしすぎると、入力完了のために不正確な情報が登録される可能性があります。一方で、重要な項目を任意入力にしたままだと、分析や管理に使えない状態になります。要件定義では、業務上本当に必要なタイミングと、現場が無理なく入力できるタイミングの両方を見ながら設計することが重要です。
2. レポートやダッシュボードの数字が信頼されていない
Salesforceのレポートやダッシュボードを見ても、現場や管理者が「実態と違う」「この数字はあまり信用できない」と感じている場合は、Salesforce要件定義を見直すべきサインです。数字が画面に表示されていても、その前提となるデータ定義、入力ルール、集計条件が曖昧であれば、意思決定に使える情報にはなりません。
特に、案件数、商談金額、受注見込み、活動件数、失注理由、顧客分類、契約更新予定などは、営業戦略や経営判断に直結しやすい情報です。これらの数字が信頼されていない場合、Salesforce上のデータではなく、担当者個人の感覚、別途作成された表計算ファイル、会議での口頭説明に頼る状態が続いてしまいます。これでは、Salesforceを導入していても、データに基づいた営業管理や経営判断を行うことが難しくなります。
要件定義では、単にダッシュボードの見た目を整えるだけでは不十分です。どのデータをもとに、どの条件で、どのタイミングの数字を集計するのかを整理する必要があります。数字が信頼されない原因は、画面の問題ではなく、データの定義や入力ルールの問題であることが多いため、根本から見直すことが重要です。
2.1 集計条件が統一されていない
レポートやダッシュボードの数字が信頼されない原因として多いのが、集計条件の不統一です。たとえば、「商談中」の定義が担当者によって違う、受注見込み金額を入力する基準が統一されていない、失注理由の選択肢が曖昧で担当者ごとに解釈が違う、活動件数に電話やメールを含めるかどうかが部署によって異なるといった状態では、同じSalesforce上の数字でも実態を正しく表しているとはいえません。
このような状態では、管理者がレポートを見ても正しい判断ができなくなります。数字が増えているように見えても、入力基準が変わっただけかもしれません。売上見込みが高く表示されていても、案件段階の定義が緩ければ、実際の成約可能性とはずれている可能性があります。Salesforce要件定義では、指標ごとの定義を明確にし、誰が入力しても同じ意味になるように設計する必要があります。
また、集計条件は経営層、管理者、現場担当者の間で共有されている必要があります。経営層が見ている売上見込みと、営業現場が考えている見込み案件の範囲が違っていれば、会議での認識もずれます。要件定義では、単にレポートを作るのではなく、そのレポートが何を表しているのか、どの判断に使うのかを明確にすることが重要です。
2.2 経営層と現場で見たい情報が違う
Salesforceのダッシュボードが使われない理由の一つに、経営層と現場で見たい情報が違うにもかかわらず、同じ画面で対応しようとしていることがあります。経営層は売上見込み、顧客層別の傾向、受注率、解約リスク、営業組織全体の生産性などを見たい一方で、現場担当者は今日対応すべき顧客、次回商談予定、未完了タスク、直近の顧客履歴などを確認したい場合が多くあります。
目的の違う情報を一つのダッシュボードに詰め込むと、どちらにとっても使いにくい画面になります。経営層には詳細すぎ、現場には抽象的すぎる画面になってしまうと、結局誰も日常的に見なくなります。Salesforce要件定義では、利用者ごとの目的に合わせて、必要な指標、表示形式、確認頻度を整理することが大切です。
経営層向けには全体傾向や意思決定に必要な指標を中心にし、営業管理者向けにはチーム別の進捗や案件リスクを見えるようにし、現場担当者向けには日々の行動につながる情報を表示するなど、役割ごとに画面を分けることで、Salesforceの活用度は高まりやすくなります。要件定義では、誰が何を見るのかを分けて考えることが、使われるダッシュボード設計の前提になります。
3. 部門ごとにSalesforceの使い方が違っている
部門ごと、拠点ごと、担当者ごとにSalesforceの使い方が大きく違っている場合も、要件定義に取り組むべきサインです。同じ顧客情報や案件情報を扱っているにもかかわらず、入力方法、更新タイミング、項目の解釈、活動履歴の残し方が違うと、組織全体で情報を共有しにくくなります。
この状態では、Salesforceが全社共通の顧客情報基盤ではなく、部門ごとの個別管理ツールのようになってしまいます。ある部門では案件段階を細かく管理している一方で、別の部門ではほとんど更新していない場合、全社の営業状況を同じ基準で見ることはできません。また、営業から顧客支援へ引き継ぐ際や、販売促進部門が営業に見込み顧客を渡す際にも、必要な情報が不足したり、解釈がずれたりする可能性があります。
Salesforce要件定義では、全社で共通化すべき部分と、部門ごとに柔軟に運用してよい部分を分けることが重要です。すべてを完全に統一しようとすると現場に合わなくなることがありますが、統一すべき情報まで部門任せにしてしまうと、データ活用が難しくなります。共通ルールと部門固有ルールの境界を設計することが、Salesforceを組織全体で活用するための重要なポイントです。
3.1 共通ルールがないまま運用されている
部門ごとに使い方が違う背景には、導入時に共通ルールを十分に決めないまま運用を始めているケースがあります。最初は小さな違いでも、運用期間が長くなるほど部門ごとの独自ルールが増え、入力項目の使い方やデータの解釈がばらばらになります。その結果、同じSalesforceを使っていても、実際には部門ごとに異なる前提で情報が蓄積される状態になります。
たとえば、ある部門では「提案中」を見積提出後の段階として使い、別の部門では初回提案前の状態として使っている場合、案件段階別の集計は正しい意味を持ちません。また、失注理由の選択肢を担当者が自由に解釈している場合、失注分析をしても改善につながる示唆を得にくくなります。Salesforce要件定義では、顧客名、案件段階、活動履歴、失注理由、顧客分類、問い合わせ種別など、集計や連携に関わる項目の定義を整える必要があります。
一方で、すべての業務を細かく標準化しすぎると、部門ごとの実務に合わなくなることもあります。要件定義では、共通化するべき項目と、部門ごとに柔軟に使える項目を分けることが大切です。共通ルールはデータ活用と部門間連携のために必要ですが、現場の業務を無理に一つの型へ押し込むことが目的ではありません。
3.2 引き継ぎに必要な情報が整理されていない
Salesforceの使い方が部門ごとに違うと、部門間の引き継ぎにも影響します。営業が受注後に顧客支援へ情報を渡す場合、顧客の導入目的、契約条件、注意点、過去のやり取り、顧客が期待している成果などが正しく伝わっていないと、顧客対応の品質が下がります。販売促進部門から営業へ見込み顧客を渡す場合も、関心内容や接点履歴が整理されていなければ、営業担当者は適切な提案を行いにくくなります。
引き継ぎに必要な情報が自由記述の中に埋もれている場合も注意が必要です。自由記述は柔軟に情報を残せる一方で、確認する側が毎回文章を読み解かなければならず、重要な情報を見落とす可能性があります。Salesforce要件定義では、引き継ぎに必須の情報を項目として整理し、補足情報は自由記述に残すなど、使いやすい形に分けることが大切です。
また、引き継ぎは単に情報を登録するだけではなく、どの状態になったら次の部門へ渡すのか、誰が確認するのか、確認後にどのような対応を行うのかまで設計する必要があります。Salesforceを部門間連携の基盤として使うには、データ項目だけでなく、業務フロー全体を要件定義に含めることが重要です。
4. 改修や追加設定を重ねて構造が複雑になっている
Salesforceを長く使っている企業では、過去の要望に応じて項目、画面、入力規則、自動処理、権限、通知、外部システム連携を少しずつ追加してきた結果、全体構造が複雑になっていることがあります。最初は小さな改善だったとしても、十分な設計整理を行わずに改修を重ねると、どの設定が何のために存在しているのか、変更するとどこに影響するのかがわかりにくくなります。
このような状態では、新しい要望に対応するたびに確認作業が増えます。項目を一つ変更するだけでも、レポート、ダッシュボード、自動処理、権限、外部システム連携に影響する可能性があるため、改修のスピードが落ちます。また、過去の設定を十分に理解している担当者が退職や異動をした場合、運用そのものが属人化してしまうリスクもあります。
Salesforce要件定義は、新規導入時だけでなく、既存環境を整理するためにも必要です。特に、改修を重ねて環境が複雑になっている場合は、新しい機能を追加する前に、現行環境の棚卸しを行い、残すべきもの、統合すべきもの、削除や停止を検討すべきものを整理することが重要です。
4.1 使われていない項目や処理が残っている
過去に作られた項目や自動処理が、現在の業務では使われていないにもかかわらず残っていることがあります。たとえば、過去の営業施策で使っていた顧客分類、現在は使われていない承認項目、廃止された商品に関する選択肢、古い運用に合わせた通知などが残っていると、画面が複雑になり、利用者が必要な情報を見つけにくくなります。
使われていない項目が多いと、現場担当者はどこに何を入力すべきか迷いやすくなります。また、管理者にとっても、どの項目が現在の分析やレポートに必要なのか判断しにくくなります。Salesforce要件定義では、新しい項目を追加する前に、既存項目の利用状況を確認し、不要な項目や重複している項目を整理することが重要です。
自動処理についても同様です。過去に設定された通知、入力規則、自動更新、承認処理が現在の業務に合っていない場合、利用者に不要な通知が届いたり、意図しないデータ更新が起きたりすることがあります。要件定義では、設定の存在理由と現在の必要性を確認し、Salesforce全体をシンプルで管理しやすい状態に戻す視点が必要です。
4.2 変更時の影響範囲が見えなくなっている
Salesforce環境が複雑化している場合、変更時の影響範囲が見えにくくなります。一つの項目を変更しただけでも、その項目を使っているレポート、ダッシュボード、自動処理、外部システム連携、入力規則、権限設定に影響する可能性があります。影響範囲を把握しないまま改修を行うと、現場で突然数字が変わったり、必要な通知が届かなくなったり、連携先のシステムでエラーが発生したりすることがあります。
この状態を避けるには、既存設定の構造を整理し、どのデータがどこで使われているのかを把握する必要があります。Salesforce要件定義では、単に新しい要望を整理するだけでなく、現在の構成、利用中の項目、連携先、権限、分析画面、自動処理を確認し、変更時の影響を見える化することが重要です。
また、影響範囲が見えない環境では、改修の判断が慎重になりすぎ、必要な改善が進まないこともあります。現場から改善要望が出ても、「どこに影響するかわからないから変更できない」という状態になれば、Salesforceは変化する業務に対応しにくくなります。要件定義を通じて構造を整理することは、将来の改善スピードを高めるためにも重要です。
5. 現場に定着せず、別管理が増えている
Salesforceを導入しているにもかかわらず、現場で表計算ファイル、個人メモ、別の管理表、チャットでの報告、部門独自の進捗表が増えている場合は、要件定義を見直すべき重要なサインです。これは、Salesforceが現場の業務に十分合っていない、または現場にとって使いにくい状態になっていることを示しています。
別管理が増えると、Salesforce上の情報は最新ではなくなります。営業担当者は自分の管理表を更新しているが、Salesforceは後回しになっている、管理者はSalesforceではなく別ファイルを見て会議を行っている、顧客支援部門は問い合わせ履歴を別の場所で管理しているといった状態では、顧客情報が分散し、組織として正しい判断がしにくくなります。
Salesforce要件定義では、なぜ現場が別管理を使っているのかを丁寧に確認する必要があります。単に「Salesforceに入力してください」と指示するだけでは、根本的な解決にはなりません。現場が別管理を使う理由には、画面が見にくい、必要な情報を一覧できない、入力が面倒、既存の会議資料に使いにくい、検索しにくい、部門特有の管理項目がないなど、設計上の課題が隠れていることが多いです。
5.1 現場の作業負担が増えている
Salesforceが定着しない理由の一つは、現場にとって作業負担が増えていることです。営業担当者は、顧客対応、商談準備、提案資料作成、社内調整、報告業務など、多くの業務を抱えています。その中でSalesforceへの入力が追加作業として感じられると、利用は進みにくくなります。特に、入力した情報が自分の業務にどう役立つのかわからない場合、Salesforceは便利な道具ではなく、管理のための負担として受け止められやすくなります。
要件定義では、Salesforceを現場の報告作業を増やす仕組みではなく、日々の業務を進めやすくする仕組みとして設計することが重要です。入力した情報が次回対応予定に反映される、顧客の過去履歴をすぐ確認できる、会議資料が自動的に作りやすくなる、管理者への報告が簡単になるといった形で、現場にとっての利点が明確であれば、利用は定着しやすくなります。
また、入力画面や一覧画面の使いやすさも定着に大きく影響します。必要な情報にたどり着くまでの操作が多い、画面に不要な項目が多い、更新したい情報が見つけにくいといった状態では、現場はより簡単な別管理に流れやすくなります。Salesforce要件定義では、管理者が見たい情報だけでなく、現場が毎日使う操作の負担を減らす視点が欠かせません。
5.2 現場の声が設計に反映されていない
Salesforceの設計が管理者視点に偏っていると、現場にとって使いにくい仕組みになりやすくなります。管理者が見たい数値を集めるための項目ばかりが増え、営業担当者が顧客対応で使いたい情報、顧客支援担当者が確認したい履歴、販売促進担当者が施策に使いたい顧客分類が整理されていない場合、現場はSalesforceを日常業務の中心として使いにくくなります。
要件定義では、現場担当者へのヒアリングが欠かせません。実際にどの画面を使っているのか、どの項目で迷うのか、どの情報が見つけにくいのか、どの作業に時間がかかっているのか、どの情報があれば顧客対応しやすくなるのかを確認することで、利用者にとって意味のある設計に近づけられます。現場の声を聞かずに設計すると、機能は整っていても使われない状態になりやすくなります。
ただし、現場の要望をすべてそのまま反映すればよいわけではありません。個別要望をすべて追加すると、項目や画面が増えすぎて、かえって使いにくくなる可能性があります。Salesforce要件定義では、現場の声を集めたうえで、共通化すべき要望、部門固有で対応すべき要望、運用ルールで解決できる要望を整理することが重要です。
おわりに
Salesforce要件定義に取り組むべきサインは、入力されない項目が増えている、レポートやダッシュボードの数字が信頼されていない、部門ごとに使い方が違っている、改修や追加設定を重ねて構造が複雑になっている、現場に定着せず別管理が増えているという5つに整理できます。これらのサインは、Salesforceそのものが悪いというよりも、自社の業務、データ、運用ルールに合わせた設計が十分に整理されていないことを示している場合が多くあります。
これらの課題が出ている状態で、単に項目を追加したり、画面を少し変更したり、ダッシュボードを増やしたりしても、根本的な解決にならないことがあります。重要なのは、自社の営業活動、顧客情報管理、案件管理、部門間連携、経営判断において、Salesforceをどのような役割で使うのかを改めて整理することです。そのうえで、必要な項目、入力タイミング、データ定義、権限、レポート、画面、運用ルールを一貫して設計する必要があります。
Salesforceは、正しく要件定義を行えば、営業管理や顧客管理を支える強力な業務基盤になります。一方で、要件が曖昧なまま運用を続けると、情報が散らばり、現場負担が増え、意思決定に使いにくい状態になってしまいます。現在の運用に違和感がある場合は、早い段階でSalesforce要件定義に取り組み、業務とデータの両方を整理することが重要です。
