フィールドセールス支援システム開発の発注/外注/依頼/委託方法について

フィールドセールス支援システムの発注・外注は、SFAを選んで終わりではなく、訪問前後の業務を整理し、現場が使い続けられる範囲を決めてから委託先と契約することが成功の近道です。

本記事では、フィールドセールス支援システムを開発・導入するときの発注形態、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積書の比較方法を順番に解説します。営業担当者が訪問先で入力できること、既存の顧客・見積・基幹データとつながること、導入後にExcelへ戻らないことを重視して説明します。

▼全体ガイドの記事
・フィールドセールス支援システム開発の完全ガイド

フィールドセールス支援システムを発注する前の全体像

発注前に決めるべきことは、製品名よりも「何を標準機能で済ませ、何を設定・連携・個別開発するか」です。フィールドセールス支援システムは、顧客・担当者・訪問・商談・見積・受注をつなぐため、最初の線引きが曖昧だと、予算も納期も膨らみやすくなります。

営業日報をデジタル化したいのか、訪問予定と実績を一元管理したいのか、商談の停滞を減らしたいのか、見積承認まで短縮したいのかで、必要なシステムは変わります。たとえば「売上を上げたい」という目的だけでは要件になりません。「訪問後24時間以内の活動記録率を高める」「次回アクション未設定の商談を減らす」「見積承認の滞留時間を短くする」のように、業務とKPIへ落とし込む必要があります。

対象範囲も、営業部だけに限定するのか、営業事務、マーケティング、受注、在庫、経理まで含めるのかを決めます。範囲を広げるほど連携と権限設計は複雑になりますが、営業だけで閉じると二重入力が残る場合があります。最初から全社を作り込むのではなく、代表的な営業所や5〜20人程度のチームで検証する段階設計が現実的です。

フィールドセールスでは、移動中や訪問先で片手操作できるスマートフォン画面、少ないタップで活動を記録できる入力設計、写真や資料を添付できる機能が重要です。地下や山間部など通信が不安定な場所を訪問する場合は、オフライン入力、再接続時の同期、重複登録や競合更新への対応も確認します。

地図やGPSを使う場合は、便利だからという理由だけで常時取得しないことが大切です。訪問開始・終了の任意記録で足りるのか、位置情報を誰が見られるのか、何日保存するのか、本人へどのように通知するのかを要件に含めます。位置情報、顧客担当者の連絡先、商談履歴を扱うため、機能要件と同じ段階で権限、監査ログ、端末紛失時の対応も決める必要があります。

フィールドセールス支援システムの発注形態はどう選びますか？

発注形態は、標準機能中心のSaaS導入、SaaSの設定・連携支援、kintoneなどのローコード開発、パッケージのカスタマイズ、フルスクラッチ開発に大別できます。自社独自の営業プロセスが競争力の中心でない限り、標準機能やローコードで始め、差が出る部分だけを拡張する方が、費用と保守負担を抑えやすくなります。

顧客管理、案件管理、営業日報、パイプライン、ダッシュボードなど、すでに一般化した業務を短期間で整えるならSaaSが候補になります。初期費用を抑えやすく、アップデートやインフラ運用をサービス提供会社に任せられる一方、料金改定、データ保管場所、API制限、オフライン機能、細かな入力画面の変更可否を確認する必要があります。

パッケージのカスタマイズは、標準の営業プロセスを活かしながら、自社の承認、見積、商品、拠点、権限に合わせる方法です。導入会社の知見を利用できますが、過度な改修はバージョンアップの妨げになります。見積書では、標準設定、追加開発、将来のアップデート対応を分けて記載してもらうことが大切です。

kintoneなどのローコード基盤は、顧客、訪問、商談、活動履歴の画面を業務に合わせて組み立てやすく、社内担当者が改善に参加しやすい選択肢です。2026年8月時点のkintone公式料金は、ライトが月額1,000円、スタンダードが1,800円、ワイドが3,000円の1ユーザー料金で、いずれも税抜です。スタンダードとワイドは外部サービス連携やプラグインに対応しますが、画面設計、帳票、地図、データ移行、保守の費用は別途確認が必要です。（出典: サイボウズ株式会社「kintone 料金」、2026年）

ローコードで失敗しやすいのは、部門ごとに似たアプリを増やし、顧客や商談の正本が分からなくなることです。発注時には、マスタを誰が管理するか、アプリ間の連携ルール、プラグインの契約主体、担当者が退職した場合の引き継ぎ方法を確認します。小さく始める場合でも、将来のデータ統合を見据えた命名規則と権限設計が必要です。

独自の訪問ルート、特殊な商談審査、商品構成と在庫を組み合わせた提案、複雑な代理店管理など、標準製品では業務上の強みを表現できない場合は、スクラッチ開発を検討します。ただし、自由度が高い分、要件定義、設計、テスト、運用保守、セキュリティ更新を長期に担う必要があります。

フルスクラッチを選ぶ場合でも、最初からすべての機能を作る必要はありません。訪問記録、案件の次回アクション、顧客マスタなど、効果測定しやすい範囲を第一段階にし、実利用で得た課題を第二段階へ回します。開発会社へは、ソースコード、設計書、API仕様、テスト結果、運用手順、第三者ライブラリの一覧を納品物として明示します。

RFPと要件整理はどこまで準備して発注しますか？

RFPは、開発会社へ提案を依頼するための文書です。完璧な仕様書を作ってから相談する必要はありませんが、解決したい課題、対象ユーザー、現行業務、必要な連携、希望時期、予算の考え方、提案に求める回答形式は書いておく必要があります。要件定義を発注者の仕事として捉え、現場部門と情報システム部門が一緒に整理することが、見積精度と導入後の定着を左右します。

業務面では、訪問前の予定確認、訪問中の顧客情報参照、訪問後の活動入力、案件更新、見積申請、受注引き継ぎの流れを書きます。データ面では、顧客、担当者、拠点、商談、商品、価格表、訪問履歴、添付資料の項目、件数、重複の状態、移行対象期間を整理します。非機能面では、スマートフォンの対応OS、画面応答、通信断時の動作、稼働時間、バックアップ、権限、監査ログ、障害時の連絡体制を記載します。

提案条件には、プロジェクト体制、想定スケジュール、見積の内訳、前提条件、追加費用の扱い、導入支援と教育の範囲、納品物、保守窓口を指定します。同じ質問に各社が答えられる形にしておくと、価格だけでなく、どこまで責任を持つ提案かを比較しやすくなります。IPAは要件定義について、ビジネス要求とシステム化要求を整理し、関係者と合意して要件にする流れを示しています。（出典: IPA「要件定義とは？」、掲載情報を2026年確認）

機能一覧だけでは、現場で使えるか判断できません。「訪問前に顧客の前回商談と未回収の見積を確認する」「訪問先で写真を添付して次回提案日を入力する」「通信が切れた状態で下書きし、復旧後に同期する」「上司が滞留案件だけを確認する」といったシナリオを作り、画面や操作を確認します。

入力時間は、目標を先に決めて実測します。たとえば訪問終了後に3分以内で最低限の記録を完了できるか、必須項目が多すぎないか、音声入力や選択式で負担を減らせるかを、実際の営業担当者に試してもらいます。PoCでは便利なデモよりも、通信状態、既存データの検索、入力ミスの訂正、上司からのフィードバックまで含めて検証することが重要です。

Excelや既存SFAから移行する場合は、顧客名の表記揺れ、担当者の重複、失注案件の扱い、過去履歴の保存期間を決めます。移行前にデータを複製してクレンジングし、件数照合、必須項目、文字コード、添付ファイル、権限別の見え方をテストします。古いデータをすべて載せるより、現場が参照する期間と法務・監査上必要な期間を分ける方が、検索性と安全性を保ちやすくなります。

個人情報保護委員会のガイドラインでは、委託先の安全管理措置を確認し、契約に個人データの取扱いと把握方法を盛り込み、必要に応じて監査する考え方が示されています。再委託の相手、業務内容、データの取扱方法も確認対象です。（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2024年改訂版を2026年確認）RFPでは、MFA、最小権限、暗号化、操作ログ、CSV出力ログ、バックアップ、退職者アカウントの無効化、事故時の報告時間を質問項目に入れます。

契約形態は請負・準委任・SaaS利用をどう使い分けますか？

契約形態は、成果物と責任範囲をどこまで確定できるかで選びます。要件が固まった開発部分は請負、要件整理や伴走支援のように作業内容を変えながら進める部分は準委任、製品を継続利用する部分はSaaS利用契約というように、工程ごとに組み合わせる方法が実務的です。

請負契約では、完成させるシステムや成果物を定義し、納品、検収、契約不適合への対応、瑕疵修補の範囲、支払条件を確認します。「SFAを開発する」ではなく、画面一覧、機能一覧、外部連携、権限、性能、対応端末、テスト項目、納品物の形式まで落とし込む必要があります。

開発途中の追加要望は、変更管理票で扱います。追加機能の費用、納期、既存機能への影響、承認者を記録し、口頭依頼をそのまま無償対応にしないことが重要です。逆に、発注者側の判断が遅れた場合にベンダーの作業が止まる条件も、契約やプロジェクト計画に書いておきます。

準委任契約は、要件定義、現状分析、プロトタイプ、導入伴走、運用改善のように、状況を見ながら専門家の作業を依頼するときに向いています。完成システムの結果を保証する契約ではないため、月ごとの作業範囲、稼働時間、担当者、会議体、報告書、課題管理、成果の確認方法を明記します。

RFP作成支援を準委任で依頼し、その後の開発を請負へ切り替える方法もあります。発注者に要件整理の経験が不足している場合は有効ですが、要件定義を支援した会社が開発も受注する場合には、比較の公平性と追加提案の妥当性を確認します。要件整理だけを第三者に依頼する選択肢も含め、役割と利益相反を説明してもらうことが大切です。

SaaS利用では、ユーザー数、プラン、最低利用期間、料金改定、サポート時間、障害時の対応、データのバックアップ、解約後のエクスポート期限を確認します。開発会社との保守契約では、月額費用に含まれる監視、障害対応、軽微な改修、OSやブラウザ更新、セキュリティパッチ、問い合わせ回数を分けて記載します。

納品後に自社で運用できるよう、管理者権限、設定一覧、データモデル、連携先、ソースコードの権利、第三者サービスの契約名義を確認します。再委託先を使う場合は、再委託の承認、アクセス可能なデータ、事故時の責任分担も契約に含めます。契約書の確認は法務や専門家にも相談し、個別事情に応じて判断する必要があります。

フィールドセールス支援システムの費用相場はいくらですか？

費用は、ライセンス、初期設定、要件定義、画面・機能開発、外部連携、データ移行、教育、保守を合算して考えます。フィールドセールス専用の公的な相場統計は確認できないため、以下はリサーチノートに整理したCRM・SFA業務システムのレンジを、機能範囲に合わせて示した目安です。画面数、ユーザー数、連携数、オフライン対応、セキュリティ水準で大きく変わるため、予算取りの出発点として扱います。

SaaSを標準機能中心で導入する場合は、初期設定・データ整理・操作説明を含めて10万〜100万円程度、月額ライセンスは1ユーザーあたり数千円から数万円程度が目安です。SaaSの設定、既存データ移行、MA・基幹システム連携、権限設計、定着支援まで委託する場合は、総額100万〜500万円程度のレンジが候補になります。

ローコード開発は、初期50万〜300万円程度に月額ライセンスやプラグイン費用が加わる想定です。パッケージやSFAの大規模カスタマイズは300万〜1,500万円程度、スクラッチ開発は1,000万〜5,000万円以上になる場合があります。一般的なCRM・SFAの整理では、パッケージのカスタマイズを100万〜1,000万円、フルスクラッチを500万〜数億円とする幅もありますが、これは要件の違いが大きい推定レンジです。特定の金額を相場として断定せず、必ず前提条件と一緒に比較します。

製品の公式価格を使うと、ライセンスと開発会社の作業費を分離できます。Salesforceの公式価格ページでは、2026年8月時点でStarter Suiteが月額3,000円、Pro Suiteが12,000円、Enterpriseが21,000円、Unlimitedが42,000円、Agentforce 1 Salesが66,000円の1ユーザー料金として掲載されています。10人で利用するとライセンスだけで月額3万円〜66万円、年額では36万円〜792万円の幅になるため、初期設定、連携、教育、保守を別に積算する必要があります。（出典: セールスフォース・ジャパン「Salesforce販売価格」、2026年）

kintoneのスタンダードを10人で使う場合は、公式の月額1,800円を基にすると月額1万8,000円、年額21万6,000円のライセンスです。ただし、これは製品利用料の計算であり、営業画面の設計、名刺や地図との連携、帳票、データ移行、教育、保守は含まれません。ライセンスが安いことだけで判断せず、3年間の利用料と委託費、社内管理工数を合算した総保有コストで見積もります。

10人規模では、SaaS標準導入や小規模ローコードで始め、初期10万〜300万円程度の範囲から要件を絞る考え方があります。30人規模になると、拠点・権限・承認・データ移行・管理者教育が増え、SaaS支援やローコード開発で100万〜500万円程度、カスタマイズを含めるとそれ以上の提案が出やすくなります。100人規模では、ライセンスだけでなく、複数拠点の展開、連携、負荷・権限テスト、研修、運用体制を含めた中規模以上の予算が必要になります。

この人数別の金額は市場統計ではなく、方式別の目安レンジをユーザー規模に当てはめた予算設計例です。要件定義、設計、開発、テスト、移行の費用配分を分け、初期開発費の10〜20%程度を年間の保守・改修枠として仮置きすると、翌年度の費用を見落としにくくなります。最終的には、同じRFPに対する複数社の見積とPoC結果で調整します。

委託先選定と見積比較では何を確認しますか？

委託先は、知名度や単価だけで決めません。フィールドセールスの業務理解、スマートフォンと通信断への対応、顧客・案件データの移行、既存システムとの連携、現場教育、運用保守、セキュリティ、同規模の実績を一つずつ確認します。候補を2〜4社程度に絞り、同じRFP、同じデモシナリオ、同じ質問票で提案を受けると比較しやすくなります。

提案会社には、訪問営業のスマートフォン画面を実データに近いサンプルで見せてもらいます。検索、記録、写真添付、次回アクション、上司の確認までを一連の流れで操作し、標準機能、設定、追加開発の境界を確認します。デモがきれいでも、現場で入力しない理由を解消できなければ定着しません。営業担当者や営業事務が参加する評価会を設け、入力時間と使いにくい点を記録します。

導入後については、操作研修だけでなく、管理者の育成、利用率の計測、入力項目の見直し、問い合わせ対応、月次改善会の有無を確認します。システムの納品をゴールにする会社と、KPIを見ながら業務を変える会社では、同じ製品でも成果が変わります。営業部門だけでなく、情報システム、受注、経理が参加する運用体制を提案できるかも評価します。

見積書では、要件定義、基本設計、画面・機能、外部連携、データ移行、テスト、教育、プロジェクト管理、保守を分けてもらいます。「一式」と書かれた項目は、対象画面数、連携先、データ件数、テスト回数、訪問回数、納品物を質問します。作業時間や人月だけでなく、誰が何を完成させる費用なのかを確認することが大切です。

比較時は、最安値をそのまま採用しないようにします。安い見積にデータ移行、現場研修、セキュリティ診断、リリース後の問い合わせが含まれていない場合、後から追加費用が発生します。提案の前提、発注者側の作業、除外項目、変更単価、納期の余裕、保守開始日を横並びにし、同じ条件に補正してから判断します。

「何でもできます」「短期間で導入できます」という説明だけで、できないことや前提を説明しない会社には注意が必要です。オフライン対応が一部画面だけ、API連携に別契約が必要、既存データの品質が悪く移行工数が増える、プラグインの提供終了時に代替策がないなど、後から問題になる条件を質問します。

また、担当者一人に設定やデータ構造が集中していないかを確認します。設計書、設定一覧、管理者マニュアル、障害対応手順、ソースコード、アカウント一覧が納品され、社内の複数人が運用を引き継げる状態かを見ます。IPAは2026年3月に中小企業の情報セキュリティ対策ガイドライン第4.0版を公開し、2026年7月にも更新履歴を掲載しています。バックアップやサプライチェーン対策も含むため、RFPと委託先評価の基準に活用できます。（出典: IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」、2026年）

発注からリリースまでの進め方と失敗を防ぐポイント

発注先を決めた後は、要件を確定して終わりではありません。現場が試し、データを移し、業務ルールを変え、利用状況を確認する工程までをプロジェクトに含めます。段階導入にすることで、全社展開前に入力負荷、権限、連携、教育の問題を修正できます。

最初に、代表的な営業所やチームを対象に、訪問登録、案件更新、写真添付、承認、ダッシュボードの一連のPoCを行います。目安として6〜12週間程度の検証期間を置き、実際の営業日で使います。検証では、入力完了率、訪問後24時間以内の記録率、検索時間、次回アクション設定率、管理者の確認時間を測り、導入前の値と比較します。

データ移行は、本番一回だけで済ませません。テスト環境へ少量のデータを移し、件数と項目を照合し、次に全量に近いデータで処理時間とエラーを確認します。切り替え当日は、旧システムをいつ停止するか、差分データをどう反映するか、問題が起きた場合に戻せるかを決めます。移行責任者、承認者、問い合わせ窓口を明確にしておくことが重要です。

営業担当者が入力しない原因は、意識の問題とは限りません。同じ内容を日報、Excel、メール、基幹システムへ何度も入力する設計、訪問中に画面が開かない設計、入力しても上司が見ない運用なら、システムは定着しにくくなります。入力項目を減らし、既存の報告を置き換え、入力した情報が案件会議や見積に役立つ状態を作ります。

KPIは、ログイン数だけでは不十分です。訪問後24時間以内の活動記録率、次回アクション設定率、滞留案件数、見積承認の所要時間、案件化率、予測と実績の差、報告にかかる時間を組み合わせます。月次で利用率と成果を見直し、使われない項目を削り、営業現場の声を次の改善へ反映します。

よくある質問（FAQ）

発注前によくある疑問を、方式、費用、委託先選びの観点から回答します。自社の規模や既存システムによって最適解は変わるため、回答をそのまま当てはめず、RFPの前提条件に置き換えて検討します。

標準的な顧客・案件・活動管理を早く始めたい場合はSaaSやパッケージが向いています。独自の訪問・承認・見積プロセスが競争力の中心で、標準機能では業務を変えられない場合に限り、ローコードの拡張やスクラッチ開発を検討します。最初から全面的に作り込まず、PoCで現場の利用価値を確かめる方法が安全です。

標準SaaSの初期設定なら10万〜100万円程度、連携・移行・定着支援まで含めると100万〜500万円程度、ローコードは50万〜300万円程度、パッケージの大規模カスタマイズは300万〜1,500万円程度、スクラッチは1,000万〜5,000万円以上が一つの目安です。フィールドセールス専用の公的統計ではない推定レンジなので、ユーザー数、画面数、連携、オフライン対応、保守を含むかをそろえて見積比較します。

RFPと評価基準を準備したうえで、2〜4社程度に同じ条件で依頼すると比較しやすくなります。候補数を増やしすぎると、提案を評価する時間が不足します。費用、実績、現場デモ、データ移行、保守、セキュリティ、担当者との相性を確認し、最終候補にはPoCや要件定義支援を依頼してから本開発を決める方法もあります。

取得目的、取得する場面、閲覧者、保存期間、削除方法を決め、必要な範囲だけを扱います。委託先の安全管理措置、再委託先、アクセス権限、暗号化、監査ログ、バックアップ、事故時の報告、契約終了時の返却・消去を確認します。位置情報を常時取得するのではなく、訪問開始・終了など業務上必要な場面に限定できないかを検討することも大切です。

まとめ

フィールドセールス支援システムを発注するときは、製品や開発会社を先に決めず、営業の訪問前・訪問中・訪問後の業務と目標KPIを整理します。そのうえで、SaaS、パッケージ、ローコード、スクラッチのどこまでが自社に合うかを判断します。

RFPには、業務フロー、データ、スマートフォン操作、通信断、既存システム連携、権限、監査ログ、移行、教育、保守を記載します。見積は総額だけでなく、要件定義、開発、連携、移行、テスト、定着支援、保守の内訳と前提条件を比較します。2026年時点の公式ライセンス価格も参考にしながら、初期費用と月額費用を分け、数年単位の総保有コストで判断することが重要です。

最終的に大切なのは、導入後も営業現場が使い続け、活動情報が次の訪問や案件会議に役立つことです。PoC、データ移行リハーサル、現場研修、月次改善までを発注範囲に含め、委託先と責任分担を明確にすることで、Excelへ戻るリスクを抑えられます。

▼全体ガイドの記事
・フィールドセールス支援システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。