フィールドサービス管理システム開発の発注/外注/依頼/委託方法について

フィールドサービス管理システムの発注は、業務整理、要件設定、提案比較、段階導入の順に進めると、現場業務の改善につながります。

全体像は完全ガイドにまとめています。契約と費用、委託先の比べ方、AI・IoTの確認事項も、この流れに沿って順に見ていきます。

▼全体ガイドの記事
・フィールドサービス管理システム開発の完全ガイド

フィールドサービス管理システムの発注・外注の全体像

フィールドサービス管理システムを中心に、顧客や作業情報、請求がつながるハブ図
受付から請求までの情報を同じ基盤で扱う構成です。

このシステムは、顧客、設備資産、保守契約をつなぐ業務基盤です。作業指示や部品、作業実績、請求も、この基盤でつなぎます。事務所と現場の情報差を小さくするのが役割で、作業員の現在地は、その中の一部にすぎません。

発注時は、機能の多さで製品を選ぶより先に、受付から請求までのどの詰まりを、誰が、何か月で改善するかを決めます。

発注前に整理するべき業務範囲

業務ごとに必要な項目が違うため、まず代表的な3業務を選び、現状の流れを図にします。

  • 受付から訪問調整:問い合わせ、案件化、優先度判定、日時調整、技術者の割り当ての流れ。
  • 現地作業:チェック、写真・署名、部品使用、例外処理の流れ。
  • 報告から請求:作業報告、見積、請求までの担当者と承認者。

対象業務は、設備工事、定期点検、故障修理、設置工事から選びます。

選んだ業務は、現状の担当者と承認者を記録し、入力媒体と例外処理も残しておきます。

システム化する範囲と、当面は既存業務を残す範囲を分けておくと、過剰な開発を防げます。

発注形態の選び方(SaaS・パッケージ・スクラッチ)

発注形態は、標準機能にどこまで合うかと、独自の要件をどれだけ必要とするかで選びます。運用の負担も含めて、各方式を比べます。

  • SaaS:短期間で標準機能を使いたい場合に有力です。
  • パッケージ:初期設定や連携開発を加え、標準化と自社要件を調整します。
  • スクラッチ:独自の料金計算、設備台帳、協力会社の承認などが競争力に直結する場合に検討します。IoT連携がある場合も、競争力への直結を基準にします。

SaaSは、アップデートやバックアップ、セキュリティ運用を受けやすく、少人数でも始めやすい方式です。ただし、業務を標準フローに合わせる判断が必要になります。

スクラッチでは、OS更新や脆弱性対応、保守人材までを長期費用に含めて考えます。

ポイント

まず、受付から請求までのどの詰まりを、誰が、何か月で改善するかを決めます。そのうえで、標準機能で足りるか、独自要件が競争力に直結するかを基準に、発注形態を選びます。

フィールドサービス管理システムの発注・外注の進め方

現状把握から要件整理、提案比較、導入、検収へ進む発注手順の図
小規模な検証を挟みながら、判断材料を順にそろえます。

発注は、現状の把握から効果の評価まで、5つの段階を順に踏みます。この順で進めると、判断材料をそろえられます。

  1. 現状の把握と、目的・KPIの設定。
  2. 要件の整理と、候補先へのRFP提示。
  3. 提案・デモ・見積の比較と、契約。
  4. PoCまたは段階導入、移行と教育の実施。
  5. 検収と、KPIによる効果の評価。

最初から全拠点を置き換えると、例外やデータ品質の問題が見えにくくなります。

そこで、検証は技術者5〜10名、1拠点、数週間の実データで始めます。そのうえで、報告入力時間や請求までの日数を測っておくと、導入の判断が感覚に偏りにくくなります。

要件定義・企画フェーズの決定事項

要件表は、規模から現場の条件、機能の優先度、必要な証跡まで、順に書き込みます。

  • 利用規模:技術者、管理者、案件、拠点、協力会社の数、1日当たりの訪問件数。
  • 現場環境:通信圏外の有無、端末、既存システム。
  • 優先機能:MUST、効果の大きいWANT、将来検討に分類。

MUSTには、作業指示や変更通知、写真・署名・チェックリスト登録を含めます。

オフライン保存と再同期、設備履歴、請求データの引き渡しも、対象に入ります。

要件は、画面一覧だけでなく、業務シナリオで表します。たとえば、午後の訪問中に通信が切れ、部品を追加で使い、顧客の署名を取り、帰社せずに請求の準備まで進めるシナリオです。

このシナリオを、ベンダーのデモで再現してもらいます。そうすると、オフライン同期と権限、例外処理を確かめられます。

帳票連携も、同じ場面で見ておきます。

RFPと提案依頼書に盛り込む項目

RFPは、背景や対象業務、システムをそろえて示します。非機能要件やスケジュール、提出形式も、同じRFPに含めます。

  • 業務と体制:経営課題、拠点、利用者区分、対象業務。
  • データと連携:移行対象、既存システム、API、連携方向、更新頻度。
  • 提案条件:希望日程、予算の考え方、提案書の形式。

正とするデータは、顧客や設備、契約について明記します。

作業履歴や部品、請求についても、続けて書き出します。

販売管理や会計との連携では、障害時の再送方法とマスタの所有者を確認します。

CRMや地図、IoTとの連携でも、再送方法とマスタの所有者を確かめます。

提案には、要求ごとの対応と、標準機能と追加開発の区別を求めます。

前提条件と体制を示してもらい、納品物と検収条件も明記してもらいます。

運用支援とデータ持ち出し方法も示してもらいます。

同じ粒度で比べると、要件理解や変更のしやすさを判断できます。

PoC・段階導入・本番移行の進め方

PoCでは、代表業務を選び、導入前後で比べる指標を定めます。効果は、自社の実データで測ることが大切です。

  • 現場効率:配車時間、報告入力時間、移動距離。
  • 作業品質:再訪問率、初回解決率。
  • 事務処理:請求確定までの日数、協力会社の報告回収率。

ベンダーが示す効果の数値は、モデルケースや自社調査によるものがあります。

効果の数値は、自社の実績から計算し直します。

本番移行では、顧客名や住所の表記ゆれと、設備番号の重複を整えます。履歴の欠損や契約期間の形式も、あわせて直します。

リハーサルでは、件数に加えて、代表顧客の設備履歴が端末で正しく表示されるかを確認します。

教育は、利用者の立場ごとに分けて行います。管理者やディスパッチャー、技術者、協力会社が対象です。

紙の手順書だけでなく、実際の訪問シナリオで練習します。

ポイント

要件はシナリオで表し、PoCで小さく検証してから広げるかを、報告入力時間と請求までの日数の実測で判断します。全拠点への一括展開は、例外やデータ品質の問題が見えにくくなるため避けます。

発注時に選ぶ契約形態と委託範囲

要件がまだ固まっていない企画段階と、仕様に沿って構築する段階とでは、適した契約が異なります。

契約名だけで選ばないことが大切です。

成果物と責任分界、変更手続き、検収は、文書にして残します。瑕疵対応や知的財産、データ返却も、あわせて書き残します。

SaaS導入支援では、設定と業務コンサルティングを分けて確認します。

準委任契約が向く場面

準委任は、作業時間や専門的な役務の提供を前提にする契約です。要件定義や業務整理、設計、アジャイル開発、導入の伴走が、主な使いどころになります。

現場への聞き取りで要件が変わる場合は、作業範囲と担当者、期間を定めます。あわせて、報告方法や上限工数、意思決定の責任も決めておきます。

完成機能の品質責任があいまいにならないよう、各スプリントの受け入れ条件と未完了事項を記録します。

請負契約が向く場面

請負は、合意した仕様に基づいて、システムや画面、帳票、連携機能を完成させる契約です。納期や検収条件を明確にしやすい点が特徴です。

協力会社向けポータルやIoT連携を途中で追加する場合は、変更契約や追加見積が必要になります。

仕様書にない要望を口頭で進めると、完成の定義や追加費用をめぐって紛争になるおそれがあります。そのため、変更要求票に、影響範囲と納期、金額、承認者を残します。

契約書で確認するデータ・運用・セキュリティ

位置情報は、個人に関する情報が連続して蓄積され、特定の個人を識別できる場合には、個人情報に該当し得ます。この扱いは、個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン(通則編)」に示されています。同ガイドラインは、2026年6月に一部改正されました。

契約では、取得から終了までの条件を整理します。

  • 対象データ:顧客情報と住所、設備番号、位置情報、写真・署名、作業履歴について、所有権と利用目的を決める。
  • 取得と閲覧:業務時間や案件中だけの取得、閲覧者の限定、保存期間の設定、本人への説明の設計。
  • 運用と安全管理:障害連絡と復旧目標、バックアップと監査ログ、脆弱性、再委託、保存地域。
  • 契約終了:データの出力形式、仕様書とソースコードの引き渡し条件。

取得条件や本人への説明は、RFPと契約に反映します。

2026年3月には、経済産業省などが、サイバーインフラ事業者に求める役割のガイドラインを策定しました(出典:経済産業省・内閣官房国家サイバー統括室、2026年3月)。

委託先に任せきりにせず、発注者と受託者の責務を、契約の前にすり合わせます。

ポイント

要件がまだ固まっていない段階では準委任、仕様が固まって完成物を求める段階では請負が、判断の目安になります。委託範囲は、データの扱いと契約終了時の返却条件まで含めて決めます。

フィールドサービス管理システムの費用相場とコストの内訳

小規模クラウドからスクラッチまで、規模別の初期導入費用レンジを並べた横棒図
複数拠点や独自開発を含むほど、初期費用の幅が広がります。

費用は、ライセンスや初期設定、要件定義といった項目に分けて考えます。画面・帳票やAPI連携、地図・GPSの費用も、同じ考え方で見ておきます。さらに、端末、データのクレンジングと移行、テスト、教育、保守も、別に見ておきます。

公開料金の月額と、個別見積の導入・開発費は、分けて比べます。

金額を一つにまとめると、安く見える提案と高く見える提案を公平に比べにくくなります。

ここで示す金額は、リサーチノートと2026年時点の公式価格、一般的な開発見積を合わせた推定レンジです。これは個別案件の確定価格ではありません。利用規模や要件に応じて、見積を確認してください。

公式ライセンス価格から見る月額の目安

Salesforce Japanの公式価格は、役割ごとに異なります(1ユーザー当たり月額、年間契約、2026年8月確認)。

  • Dispatcher・Technician:各21,000円。
  • Field Service Plus:27,600円。
  • Contractor・Contractor Plus:6,600円・9,600円。
  • Microsoft Dynamics 365 Field Service:15,742円、契約社員向け7,496円(1ユーザー当たり月額相当、年払い・税別)。
  • FieldOS:月額9,800円、19,800円、59,800円。

Microsoftの価格は、2026年8月に出典ページで確認しました(出典:Microsoft Japan公式価格ページ、2026年8月確認)。

設備工事向けのFieldOSは、公式サイトで月額プランを掲載しています(2026年8月確認)。

料金の単位は役割ごとに違うため、管理者や技術者、協力会社の登録人数によって実額が変わります。

標準機能だけで使う小規模事業者なら月1万〜10万円程度、技術者・管理者が10〜20名のチームなら月10万〜50万円程度が目安です。

複数拠点やAI、最適化、外部連携、監査ログを加えると、月50万円を超える場合があります。

見積は、利用者区分と追加機能を分けて求めます。

初期導入・追加開発の費用レンジ

初期費用と導入期間は、小規模クラウドの導入からスクラッチ開発まで、範囲ごとに比べます。

  • 小規模クラウド:標準機能、少人数、CSV移行、帳票設定を中心に、初期費用0〜200万円、期間2週間〜2か月程度。
  • 標準クラウド:初期設定、モバイル設定、権限、会計・CRM連携、教育を加え、初期200万〜800万円、3〜6か月程度。
  • 複数拠点:協力会社、在庫、IoT、オフライン同期、配車最適化を含み、初期800万〜2,000万円、6〜12か月程度。
  • スクラッチ:独自の契約・料金計算、設備台帳、現場帳票、承認、外部データ連携を一体で作り、1,500万〜4,000万円以上、9〜18か月程度。

この金額には、製品ライセンス費よりも、導入設計や設定、移行、検証の費用が含まれることがあります。

これらは、公開統計で確定したFSM専用の相場ではありません。業務システムの規模や工数、移行の難度から置いた推定です。

独自要件の範囲によって、スクラッチの開発規模は変わります。

要件の追加やデータの汚れ、テスト環境、並行稼働が増えると、費用は上振れします。

見落としやすいランニングコスト

月額ライセンス以外にも、継続してかかる費用を確認します。利用人数の変動に合う課金方法や、解約後の移行費も判断材料になります。

  • 通信・連携:API従量課金、地図・ルート検索、SMS・メール、IoT通信。
  • 運用:端末・MDM、保守、サポート、教育、バックアップ、監査。
  • 契約終了:データ出力や再移行にかかる作業費。

協力会社の利用者が増減する場合は、固定ユーザー課金とログイン課金、外部作業員向けの低価格ライセンスを比べます。

ポイント

公開料金の月額と、個別見積の導入費は、別々の数字として扱います。金額は利用規模と要件で大きく変わるため、一つの金額で判断せず、利用者区分と追加機能を分けた見積で見ます。

見積を取り、委託先を比較するポイント

総額だけでなく、見積に含まれる作業と前提の外にある項目を確認します。候補先には、同じRFPと業務シナリオを渡します。

見積は、標準機能や設定、追加開発、連携を、行を分けて示してもらいます。さらに、移行やテスト、教育、保守、オプションも、分けて示してもらいます。

製品価格と導入・開発パートナーの作業費を分けて示すと、将来のライセンス改定や保守費も見通しやすくなります。

提案と見積の比較条件

現場業務を再現するデモで、機能の適合性を確かめます。比較では、連携や運用の責任者も確認します。

  • 業務適合:訪問業務、配車、設備・部品管理、オフライン対応。
  • 導入体制:基幹連携、データ移行、セキュリティ、保守、費用透明性。
  • デモ内容:受付、割り当て、訪問報告、写真・署名、部品、請求連携。

通信圏外での入力や再同期も、試しておきます。入力の停止や履歴検索の失敗、データの重複があると、効果を得にくくなります。

製品ベンダーには、標準基盤の拡張性を確認します。たとえば、Salesforce、Microsoft、ServiceNowなどが該当します。

SI・開発会社には、近い業務の実績を確認します。設備、製造、建設、通信業の実績に加え、現場アプリやIoT、基幹連携の経験も対象になります。

会社の規模や知名度だけで決めず、要件定義から移行、教育、稼働後のKPI改善まで、どこを誰が受け持つかを確かめます。

委託先に聞くべき質問

委託先の実績や機能、変更手続きは、質問への答えで確かめます。

  • 実績:同規模の技術者数と訪問件数で標準提供した機能は何ですか。
  • 同期:通信圏外で入力した作業報告は、いつ、どう同期しますか。
  • 移行:顧客・設備・契約・履歴データの移行は誰が担当しますか。
  • 追加要望:単価と承認方法はどうなっていますか。
  • 位置情報:目的、取得範囲、時間帯、閲覧権限、保存期間をどう設計しますか。

障害窓口と復旧目標、脆弱性報告、再委託、担当者交代、契約終了後の返却も確認します。ソースコードと設計書の扱いも、対象に含めます。

GPSの導入だけで、生産性が自動的に上がるわけではありません。配車判断や訪問実績、事故時の確認など、目的を明確にします。

そのうえで、取得範囲と閲覧権限、保存期間、従業員への説明を整えます。現場の信頼を損なわない運用設計まで提案できる会社を選びます。

発注で起きやすい失敗と対策

失敗を避けるには、現場の代表者を要件定義に加えておきます。移行データや協力会社の利用も、早めに扱うことが大切です。

  • 目的の後回し:機能一覧より先に、業務の目的を決める。
  • 現場不在:技術者や配車、請求、情報システム、管理者を加える。
  • 運用準備不足:移行品質や協力会社、AI・IoTの運用ルールを検討する。

現場代表者と業務シナリオ、KPIは、共同で決めます。AIやIoTを先行させず、まず運用ルールを整えます。

初期見積だけでなく、3年間の総保有コストを比べます。増員や拠点追加のシナリオも、あわせて作っておきます。

総保有コストには、ライセンスの増員費や端末更新、API・地図の従量料金を含めます。さらに、保守や追加開発、教育、移行、解約時の出力費も加えます。

価格差が小さい場合は、現場定着や障害対応、データの持ち出し、契約変更のしやすさも判断材料にします。

ポイント

同じRFPと業務シナリオで比べられる見積かどうかが、委託先を選ぶときの目安になります。総額だけで比べると、前提外の項目を見落としやすくなります。

2026年の発注で確認したいAI・IoT・セキュリティ動向

2026年時点では、AI配車や報告要約、予防保全、現場への手順提示が、提案に含まれやすくなっています。たとえば、ServiceNow Japanの公式FSMページは、AIによる作業割り当て、資産・履歴を使う保守計画、モバイル支援を説明しています。出典は、ServiceNow Japan「フィールドサービス管理」、2026年8月確認です。

AIの訪問順や部品候補は、そのまま採用しないことを前提に、判断者や根拠データ、誤りの修正、ログ保存を要件に含めます。

AIを発注範囲に含める前の確認

AI機能の見積では、データと保存場所、外部送信を確認します。誤出力時の責任や利用上限、追加料金も、あわせて確かめます。

報告要約は人が承認してから顧客へ送り、予防保全の警告は設備担当が確かめます。このように、最終の判断は人に残します。

効果は、AIを導入したかどうかではなく、報告作成時間や再訪問率、見落とし件数の変化で測ります。

IoT・モバイル・位置情報の安全管理

現場端末の情報保護や、IoT接続、稼働後の安全管理に必要な条件を整理します。

  • 端末保護:顧客住所や設備情報、写真、署名の保存を想定。紛失時の遠隔ロックやOS支援、暗号化の有無。
  • アクセス管理:SSOや多要素認証、権限分離、監査ログ、バックアップ、脆弱性報告窓口。
  • IoT接続:機器認証、通信暗号化、ファームウェア更新、異常データ、ネットワーク分離をRFPに記載する。
  • 稼働後:アカウント削除、復旧訓練、事故連絡の責任者と期限を決める。

稼働後は、誰がアカウントを無効化するか、協力会社の退職者のアカウントをいつ削除するかを決めておきます。加えて、復旧訓練の頻度と、事故時の連絡時間を決めておきます。

製品は、機能の多さではなく、運用できる安全性を基準に比べます。

よくある質問

発注では費用だけでなく、決める時期や現場利用者の参加も大切です。よくある疑問に、順に答えます。

フィールドサービス管理システムの開発費はいくらですか?

標準SaaSは初期費用が0〜200万円、連携や教育を加える標準クラウドは200万〜800万円が目安です。

複数拠点・協力会社・IoT連携は初期800万〜2,000万円、独自業務を含むスクラッチは初期1,500万〜4,000万円以上になる可能性があります。

いずれも、要件や移行、利用者数、保守の範囲によって変わる推定のレンジです。そのため、見積はライセンスや導入支援、開発、運用を分けて取ります。

RFPがなくても開発会社に相談できますか?

相談はできます。現状の業務や困りごと、対象拠点、利用者数、既存システム、希望時期を伝えると、提案の精度が上がります。

完成した仕様書は必須ではありません。業務ヒアリングや要件定義を準委任で依頼し、その成果をもとに請負の範囲を決める方法もあります。

複数社に同じ情報を渡すため、簡易版のRFPを用意することをおすすめします。

協力会社や個人の位置情報も管理できますか?

製品によって、協力会社向けの契約社員ライセンスやポータル、指示共有、報告承認、位置情報の範囲は異なります。

協力会社が自分の案件だけを見られるか、報告の修正履歴が残るか、契約終了後にアクセスが止まるかを、デモで確認します。

位置情報は、目的や取得時間、保存期間、閲覧者を決めて扱います。そのうえで、必要最小限の運用にします。

導入効果はどのKPIで測ればよいですか?

基本となるのは、配車時間や報告入力時間(1件当たり)、再訪問率、初回解決率です。さらに、移動距離や請求までの日数、請求漏れ、報告回収率も測ります。

導入前の4週間程度の実績を保存しておき、同じ業務と拠点で、導入後と比べます。

ログイン人数だけでなく、二重入力の減少や請求リードタイムの短縮を、経営指標につなげて見ます。

まとめ

発注前に受付から請求までの流れを一覧にし、MUST・WANT、対象拠点、利用者、連携先、KPIを決めます。次に、方式を選び、RFPへ業務シナリオと非機能要件を記載します。

発注前の確認事項

公式ライセンス価格と導入・開発費は分けて、初期費用だけでなく、3年間の総保有コストで比べます。

要件整理や伴走は準委任、仕様の完成は請負を検討します。データや位置情報、セキュリティの扱いは、文書にします。移行や保守、解約時の返却条件も、文書化しておきます。

導入後の改善の続け方

PoCや段階導入で自社のKPIを検証し、現場が使い続けられる委託先を選びます。

稼働後も、配車や報告入力、再訪問、初回解決、請求リードタイムを定期的に見直します。業務とシステムを一緒に改善します。

▼全体ガイドの記事
・フィールドサービス管理システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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