Salesforceの入力負荷を下げる5つの実践手順｜現場が「面倒」と感じる原因とUI改善策

「Salesforceが使われない」——入力負荷は導入失敗の最大原因

SFA・CRMの導入企業が増える一方で、「入れたけれど現場に定着しない」という声は後を絶ちません。IDC Japanの調査によると、CRM導入企業のうち現場の入力率が目標水準を満たしているのは全体の3割程度に留まるという報告もあります。Salesforceも例外ではなく、ライセンスコストをかけて導入したにもかかわらず、営業担当者がExcelや個人メモに戻ってしまうケースは少なくありません。

定着しない理由として「使い方の教育不足」や「現場の意識の問題」が語られることがありますが、実態はそれだけではありません。最も根本的な原因は、入力そのものの負荷が高すぎることにあります。画面を開くたびに大量の項目が並んでいる、商談を1件登録するのに複数の画面を行き来しなければならない、業務の流れとUIの設計がかみ合っていない——こうした構造的な問題が積み重なり、現場は「面倒」と感じて離脱します。

入力率が下がれば、データの精度が落ちます。データが使えなければ、マネージャーは判断できず、経営層は投資対効果を測れません。入力負荷の問題は、現場だけの不満ではなく、組織全体のデータ活用基盤を揺るがす課題です。

本記事では、Salesforceの入力負荷を改善するための実践的な手順を5つに整理して解説します。設定レベルの見直しから標準機能の活用、カスタム開発、そして運用設計まで、意思決定者が全体像を把握して優先度を判断できる粒度でまとめています。

入力が「面倒」になる本当の理由——4つの構造的原因

現場から「Salesforceへの入力が面倒」という声が上がるとき、その原因は単純な操作の手間だけではありません。業務設計・画面設計・運用設計の三層にわたる構造的な問題が絡み合っているケースがほとんどです。改善策を検討する前に、まず原因を正確に分類しておくことが重要です。

原因1：標準レイアウトが業務に合っておらず、不要な項目が多い

Salesforceは導入時、標準のページレイアウトに多数の項目が並んだ状態で提供されます。カスタマイズを行わないまま運用を始めると、自社の業務に不要な項目が画面上に残り続けます。営業担当者が1件の商談を登録するだけで、スクロールを繰り返しながら十数項目に入力しなければならない、というのは珍しい状況ではありません。表示項目の多さそのものが認知負荷を高め、入力を億劫にさせます。

原因2：業務の流れとSalesforceの画面遷移がかみ合っていない

商談・取引先・活動履歴など、Salesforceのオブジェクトは独立したレコードとして設計されています。しかし現場の業務では、「訪問直後に商談ステータスを更新しながら、次のアクションも記録したい」というように、複数のオブジェクトにまたがる操作が1つの業務行為に紐づいていることがあります。画面遷移が業務フローと一致していないと、1つの作業に何度もタブを切り替えたり、関連レコードを手動で検索したりする手間が発生します。

原因3：スマートフォン・タブレットでの利用を前提にしていない

外出先や移動中にSalesforceへ入力したいという需要は、フィールドセールスを持つ企業では特に高まっています。しかし、PC画面向けに最適化されたページレイアウトをそのままモバイルで利用すると、タップ操作のしにくさや画面の見づらさが顕著になります。Salesforceにはモバイル専用のレイアウト設定がありますが、PC側のカスタマイズのみに対応して放置されているケースも少なくありません。

原因4：「なぜ入力するのか」が現場に腹落ちしていない

入力負荷の問題は、UI設計だけでは解決しきれない場合があります。そもそも「この項目を入力すると、誰がどう活用するのか」が現場に伝わっていないと、入力行為が単なる義務作業として認識されます。目的が見えない作業は心理的な抵抗を生みやすく、結果として入力率の低下につながります。これは操作の問題ではなく、運用設計・組織コミュニケーションの問題です。

以上の4つは、それぞれ異なるレイヤーに属する原因です。設定で対応できるもの、開発が必要なもの、運用改善で対応すべきものが混在しているため、原因を切り分けずに施策を打つと効果が限定的になります。

改善前に確認すること——現状の入力負荷を「見える化」する

施策を先に決めてしまうことが、Salesforce改善でもっともよくある失敗パターンです。「とりあえず項目を減らす」「入力ガイドを作る」といった対策が現場に刺さらないのは、どの画面・どのオブジェクト・どのフィールドに問題があるかを確認しないまま動いているためです。改善の前に、まず現状を数値と言葉で把握することが先決です。

レポート・ダッシュボードで入力率を数値化する

Salesforceの標準レポート機能を使えば、オブジェクトごとのフィールド入力状況をある程度把握できます。具体的には、必須・任意を問わず「空白のまま保存されているレコードの割合」をオブジェクト単位で集計します。商談オブジェクトであれば、「金額」「フェーズ」「次のステップ」などの重要フィールドごとに入力率を出し、ダッシュボードで一覧化します。入力率が低いフィールドほど、現場が入力を省略しやすい=負荷が高いか・意味を見出せていない項目と判断できます。

現場ヒアリングで「どこで手が止まるか」を特定する

数値だけでは「なぜ入力されないか」の理由は分かりません。実際に営業担当者やSFAの日常利用者に対して、15〜30分程度の個別ヒアリングを設計することをお勧めします。聞くべき質問の例は次のとおりです。

• 入力を後回しにしがちな画面・タイミングはどこか
• 「何を入れればいいか分からない」と感じるフィールドはあるか
• モバイルとPC、どちらで入力することが多いか
• 入力しても「使われている実感がない」と感じる項目はあるか

複数人のヒアリング結果を照合すると、特定の画面や項目に不満が集中していることが多く、優先して手を入れるべき箇所が絞り込めます。

ページレイアウト棚卸し——不要フィールドの洗い出しチェックリスト

ヒアリングと並行して、ページレイアウトの棚卸しを行います。以下のチェックリストを目安に、各フィールドの要否を確認してください。

• このフィールドは誰が・いつ・何のために参照しているか説明できるか
• 過去6か月間で入力されたレコードは全体の何割か（目安：30%未満は要検討）
• レポートや自動化のトリガーとして実際に使われているか
• 導入当初の要件定義から業務が変わり、実態と乖離していないか
• 似た意味のフィールドが複数存在していないか

このプロセスを経ずに「UIを改善する」「自動入力を実装する」といった施策に進むと、本来は不要なフィールドに工数をかけたり、問題の少ない画面を優先して改修したりするリスクが生じます。現状の見える化は、改善の優先順位を正しく決めるための前提工程です。

実践手順1——ページレイアウトとレコードタイプを整理する

Salesforceの入力負荷を下げるうえで、最初に手をつけるべきはページレイアウトの見直しです。追加開発を必要とせず、管理者権限があれば設定画面から即日変更できる領域であるにもかかわらず、導入時の設定がそのまま放置されているケースは少なくありません。

必須項目は「最小限」に絞る——入力完了率が変わる設計原則

ページレイアウトに表示されるフィールド数が多いほど、現場の入力意欲は低下します。特に「必須」に設定された項目が多い画面は、情報が揃っていない段階での登録を妨げ、結果として「後で入れよう」という先送りを生みます。

見直しの基本的な考え方は次のとおりです。

• 必須項目は「商談を前に進めるために今すぐ必要な情報」だけに絞る（例：商談名・取引先・クローズ予定日）
• 「あると便利」な項目は任意フィールドとして残しつつ、セクションを分けて下部に配置する
• 管理用途のフィールド（レポート集計用など）は、現場の入力画面には表示しない設計にする

フィールドをセクションで論理的にグループ化すると、視線の流れが整理され、入力漏れも減少します。「基本情報」「提案内容」「管理情報」のように役割で分けるだけでも、現場の体感は大きく変わります。

レコードタイプで営業フェーズごとに表示項目を切り替える

すべてのフェーズで同一のページレイアウトを使っている場合、初期の引き合い段階から最終クロージング時まで、同じ入力画面が表示されます。これが「まだ決まっていない項目を埋めなければならない」という摩擦を生む原因です。

レコードタイプを活用すると、フェーズや部門ごとに表示するフィールドを切り替えられます。設定の流れは以下のとおりです。

1. オブジェクトマネージャーでレコードタイプを作成し、フェーズ名（例：「初期接触」「提案中」「契約交渉」）を定義する
2. フェーズごとに必要なフィールドのみを含むページレイアウトを作成・割り当てる
3. プロファイルまたは権限セットと組み合わせることで、営業担当・マネージャー・インサイドセールスごとに表示を分けることもできる

このアプローチにより、「今のフェーズでは不要な項目」が画面から消え、入力すべき情報が明確になります。結果として入力完了率の向上と、データ品質の改善が同時に期待できます。

実践手順2——入力の手間を自動化する標準機能を活用する

ページレイアウトを整理して「見せる項目」を絞り込んだ後は、残った入力項目そのものの手間を減らすステップに進みます。Salesforceには、設定だけで入力作業を自動化できる標準機能が複数備わっています。開発工数をかけずに着手できるため、SFA入力率を上げる施策の中でも優先度が高い取り組みです。

デフォルト値・数式フィールドで「入力しなくてよい項目」を増やす

まず確認したいのが、デフォルト値の設定です。「担当者の所属部門」「商談フェーズの初期値」「通貨単位」など、大多数のケースで値が決まっている項目は、デフォルト値を設定するだけで入力ゼロにできます。取引先レコードから商談を新規作成する場合は、取引先名や住所といった関連情報を自動補完できるため、転記ミスの防止にもつながります。

次に活用したいのが数式フィールドです。「粗利率＝売上－原価÷売上」のように計算で求められる値は、数式フィールドに定義することで現場の手入力を不要にできます。計算ミスのリスクも排除できるため、データ品質の向上にも直結します。

以下に、各機能の設定難易度と効果の目安を整理します。

• デフォルト値設定：設定難易度は低い。管理画面の項目設定から値を指定するだけで完結します。効果は「定型項目の入力時間をほぼゼロにする」点で即効性があります。
• 取引先からの自動補完：設定難易度は低〜中程度。参照関係フィールドを正しく構成する必要がありますが、既存の標準リレーションがあれば比較的容易です。
• 数式フィールド：設定難易度は中程度。関数の記述が必要ですが、四則演算レベルであれば管理者が習得しやすい範囲です。計算項目の手入力を根絶できる効果があります。

フロービルダーで入力をトリガーにした後続処理を自動化する

入力そのものを減らすだけでなく、「入力後に発生する作業」も自動化の対象です。Salesforceのフロービルダーを使うと、レコードの保存をトリガーにして後続処理を自動実行できます。たとえば、商談フェーズが「受注」に変わった瞬間に契約レコードを自動生成する、活動レポートを関係者に自動送信するといった処理が、コードなしで設定可能です。

現場担当者が「入力したら次にあれもしなければ」と感じる二次作業を自動化することで、Salesforce操作を簡単にするだけでなく、入力そのものへの心理的抵抗を下げる効果も期待できます。

• フロービルダー（レコードトリガー型）：設定難易度は中程度。画面フローと比べてUIが直感的で、プログラミング知識がなくても構築できるケースが多いです。入力負荷の改善効果は高く、特に「入力→転記→通知」の繰り返し作業を抱えている組織で効果が出やすい機能です。

これらの標準機能は、いずれも追加ライセンスや外部ツールなしに利用できます。まずデフォルト値と数式フィールドで「入力しなくてよい項目」を増やし、次にフロービルダーで「入力後の手作業」を削減する、という順序で進めると効果を実感しやすくなります。

実践手順3——LWCカスタムコンポーネントでUI自体を作り変える

ページレイアウトの整理や標準機能の活用だけでは解消できない入力負荷があります。複数オブジェクトにまたがる入力、段階的な情報収集が必要なフロー、外部システムとのリアルタイム連携といった要件がそれにあたります。こうした場面では、LWC（Lightning Web Components）によるカスタムUI開発が有力な選択肢になります。

標準機能の限界——どこからカスタム開発が必要になるか

Salesforceの標準UIはオブジェクト単位で画面が分かれており、複数のオブジェクトにまたがる入力をひとつの画面で完結させることが難しい構造になっています。たとえば、商談と取引先と活動履歴をまとめて登録したい場合、標準機能では画面を3回遷移する必要があります。

以下のような状況が重なっているときは、カスタム開発の検討段階と判断できます。

• 入力に必要な画面遷移が3ステップ以上ある
• 入力途中で別オブジェクトの参照や登録が必要になる
• 入力項目の表示・非表示を動的に切り替えたい条件が複雑
• 外部システムのデータとリアルタイムで照合する必要がある

ワンページ入力フォームとウィザード形式UIの効果

LWCを使えば、複数オブジェクトへの登録を1画面で完結させるワンページフォームを実装できます。営業担当者が商談情報を入力すると、紐づく取引先情報と活動履歴が同時に保存される、といった設計が可能になります。画面遷移のたびに入力内容を見失うストレスがなくなり、入力完了率の改善につながるケースが少なくありません。

また、入力ステップを段階的に案内するウィザード形式のUIも、LWCの活用場面のひとつです。入力項目が多い場合でも、ステップごとに表示する項目を絞り込むことで、担当者が「何を入力すべきか」を迷わずに進められます。CLANEが手がけた製造業の案件では、20項目以上ある受注登録フォームをウィザード形式に再設計し、入力ミスの発生頻度が大きく下がった事例があります。

外部システムと連携したリアルタイム補完・重複チェック

LWCはSalesforce JavaScript（LWC内のJavaScript層）を通じて外部APIと通信できるため、入力中にリアルタイムで外部データを参照する仕組みを組み込めます。たとえば、会社名を入力した時点で法人番号データベースと照合し、住所や代表者名を自動補完するといった実装が可能です。

重複チェックも同様です。Salesforceの標準重複管理は保存時に検知する仕様ですが、LWCを使えば入力フィールドからフォーカスが外れた瞬間に既存レコードを照合し、担当者に警告を表示できます。入力後ではなく入力中に問題を伝えることで、手戻りの発生を防ぎやすくなります。

LWC開発はSalesforceの標準設定と比べると工数と専門知識が必要になりますが、「標準機能の調整では現場の入力フローを変えられない」と判断した段階で、開発投資の優先度を検討する実践手順に位置づけられます。

実践手順4——Apexで「業務ロジックを入力の手前に移す」

標準機能やLWCで対応できる範囲を超えた場合、Salesforce専用のサーバーサイド言語であるApexを活用することで、入力負荷をさらに構造的に削減できます。

Apexとは——Salesforce専用のサーバーサイド言語を一言で説明する

Apexは、Salesforceのサーバー上で動作するプログラミング言語です。JavaやC#に近い構文を持ち、「Salesforce開発言語」として知られています。フロー（標準機能）では表現しきれない複雑な業務ロジックを、Salesforceのデータと直接連携しながら実装できる点が特徴です。意思決定者の視点では、「現場が手動でやっている計算・転記・チェック作業をサーバー側に移す手段」と理解しておくと実態に近いです。

Apexトリガーで「入力後の手作業」を自動処理に置き換える

Apexトリガーは、レコードの保存・更新などのタイミングで自動的に処理を実行する仕組みです。たとえば、商談が「受注」に更新された瞬間に関連する請求レコードを自動生成したり、取引先の業種コードから営業担当者を自動アサインしたりといった処理が実装できます。これにより、入力完了後に担当者が別システムを操作したり、上長が手動で割り当て作業をしたりするステップをなくすことができます。

外部API連携で住所・企業情報を自動取得する実装パターン

Apexはsalesforce.comの外部APIとも通信できるため、入力項目そのものを減らすアプローチも取れます。代表的なパターンは次のとおりです。

• 郵便番号から住所を自動補完：郵便番号APIと連携し、7桁入力だけで都道府県・市区町村・番地を自動入力する
• 法人番号から企業情報を取得：国税庁の法人番号APIと連携し、会社名・所在地を自動セットする
• 名刺データとの同期：名刺管理ツールのAPIを通じて、取引先・取引先責任者レコードを自動生成・更新する

いずれも「入力させる前にデータを用意する」という発想の実装です。Salesforceの入力負荷改善において、Apexによるバックエンド処理は、UIの改善と並ぶ有効な手段になります。

実践手順5——運用設計と現場への「インプット導線」を整える

画面設計や自動化の整備を進めても、現場の行動習慣が変わらなければ入力率は上がりません。ツールの改善と並行して、「入力したくなる・入力せざるを得ない」運用の仕組みを整えることが、定着への最後のステップです。

「入力するとどう役立つか」を現場が実感できる仕組みを作る

SFA入力率が上がらない背景には、「入力しても自分には何も返ってこない」という実感の欠如があります。入力データをダッシュボードで可視化し、自分の担当案件の進捗や受注予測を確認できる状態にすることで、入力の動機づけが生まれます。

具体的には、以下のような表示を営業担当者ごとのホーム画面に配置します。

• 今月の商談進捗と受注見込み額
• 次アクション未登録の商談件数（入力漏れの気づきを促す）
• チーム内での入力完了率の比較

「入力すると自分の仕事が整理される」という体験を設計することが、Salesforce操作を簡単にする以上に定着を左右します。

商談プロセスにSalesforce入力を組み込むルール設計の考え方

入力を「任意の記録作業」として扱っている限り、後回しになり続けます。商談の各フェーズ移行条件として、特定項目の入力完了を必須にするルール設計が有効です。

たとえば「提案中」フェーズへの移行時に決裁者情報と次回アポ日を必須入力とする、「クロージング」移行時に見積金額と競合情報の記入を条件にするといった設計です。これによりSalesforceへの入力が商談を前進させる行為と一致し、「面倒な事務作業」という認識が薄れていきます。

Salesforceモバイルアプリで「その場で入力できる」環境を整える

訪問直後や移動中に入力できる環境がなければ、記憶が薄れた夜や翌朝に入力をまとめて行うことになり、精度と継続性が下がります。Salesforceモバイルアプリを活用し、商談後すぐに入力できるフローを整備することが重要です。

モバイルでの入力負荷を下げるには、表示するフィールドをPC画面より絞り込んだモバイル専用レイアウトの設定と、音声入力や定型文選択の活用が効果的です。「その場で30秒で登録できる」状態を目指すことが、SFA入力率を上げる運用設計の基本方針になります。

5つの手順を「どの順で・どこまでやるか」——優先度の判断軸

5つの手順をすべて同時に実施する必要はありません。現状の課題レベルと組織のリソースに応じて、着手すべき手順は異なります。段階を踏まずにカスタム開発から入ると、コストをかけても効果が出ないケースが少なくありません。

段階別・対応優先度マトリクス（標準設定／運用改善／カスタム開発）

下記の3段階を目安に、自社がどの段階に該当するかを確認してください。

• 第1段階：標準設定の見直し（手順1・2）——ページレイアウトの整理、レコードタイプの分離、入力規則・自動入力の活用。追加コストなしで着手できるため、まず最初に取り組むべき領域です。現場から「項目が多すぎる」「同じことを何度も入力する」という声が出ている場合は、ここで改善できる余地が大きいです。
• 第2段階：運用設計の見直し（手順5）——入力タイミングの設計、モバイル活用、インプット導線の整備。標準設定を整えても入力率が上がらない場合は、運用・習慣の問題が残っていることが多く、現場への浸透策とセットで対処します。
• 第3段階：カスタム開発（手順3・4）——LWCによるUI再構築、Apexによる業務ロジックの自動処理。標準機能と運用改善を実施してもなお入力負荷が解消されない場合に検討します。開発コストと保守コストが発生するため、効果の試算を先に行うことが重要です。

カスタム開発に踏み切るべきタイミングの見極め方

カスタム開発の判断基準は「標準機能では業務フローに合わせられないか」という点に集約されます。具体的には、入力項目数を減らしてもワークフローの都合上どうしても省けない、他システムとのデータ連携が手動になっている、モバイルでの操作性が業務上の支障になっているといった状況が重なる場合が、開発検討の目安になります。

まとめ——入力負荷の改善は「設定・開発・運用」の三層で取り組む

Salesforceの入力負荷を下げるためには、単発のUI変更や項目の削減だけでは不十分です。本記事で解説してきた5つの実践手順を振り返ると、改善の取り組みは大きく三つの層に整理できます。

• 設定層：ページレイアウト・レコードタイプの整理、標準の自動化機能の活用
• 開発層：LWC（Lightning Web Components）によるカスタムUIの構築、Apexによる業務ロジックの前倒し処理
• 運用層：入力導線の設計、現場への定着支援、継続的なフィードバックの仕組み化

この三層は独立しているわけではなく、相互に補完し合う関係にあります。設定だけで解決できる課題もあれば、業務の複雑さによってはカスタム開発が不可欠なケースも少なくありません。また、どれだけ優れたUIを構築しても、運用設計が伴わなければ現場には定着しません。

優先度の判断軸としては、まず設定層で対応できる範囲を最大化し、それでも残る摩擦に対してLWCやApexによる開発投資を検討するという順序が現実的です。

CLANEは、SalesforceのApexおよびLWCを活用したカスタム開発を強みとしており、設定・開発・運用の三層にわたって伴走しながら、現場定着まで一貫して支援しています。