行程管理システムの発注・外注は、見積、手配、顧客情報、当日の運行を一つの業務データでつなげられるかを基準に、業務の整理から導入後の評価まで順に進めます。
パッケージか個別開発か、RFPに何を書くか、見積金額の妥当性をどう判断するかで迷う担当者は少なくありません。
▼全体ガイドの記事
・行程管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
行程管理システムの発注・外注で最初に決める事項
行程管理システムは、旅行会社の案件管理、宿泊や交通の手配、貸切バスの運行、安全記録などを扱う業務システムです。
発注前には、何を作るかだけでなく、どの業務を標準化し、どの例外を残すかまで決めておきます。そうすると、提案内容と見積を比べやすくなります。
対象業務と利用者の切り分け
業種によって、行程管理で中心になる業務は変わります。旅行会社、バス会社、DMCの主な業務を並べると、切り分ける範囲が見えてきます。
- 旅行会社：営業、手配、添乗
- バス会社：配車、乗務員管理
- DMCやランドオペレーター：仕入れ、多言語対応
同じ「行程管理」でも、旅行会社は見積から手配、顧客への案内までを重視します。一方、バス会社は運賃計算や休憩、交替運転に加えて、運行指示書や点呼、日報も重視します。
利用者は、営業担当、手配担当、管理者、添乗員、乗務員、取引先などに分かれます。切り分けをしないまま「全部入り」のシステムを発注すると、使わない機能に費用がかかり、現場も入力を嫌がるおそれがあります。
まずは部署ごとに、使っている帳票や入力項目、確認する相手を並べ、手戻りが起きる場面も書き出します。そのうえで、今回の対象と将来の候補を分けてください。
導入目的を測定できるKPI
導入目的は、「DX化したい」「情報をまとめたい」のままでは委託先に伝わりにくく、測定できる形に変える必要があります。たとえば、行程表の初稿作成時間や見積作成時間、手配漏れの件数を測定対象にします。行程変更が関係者へ伝わるまでの時間や、当日の問い合わせ件数も含めます。
導入前の1か月間だけでも現状値を記録しておくと、提案段階で必要な機能を絞り込めます。ナビタイムジャパンの「行程表クラウド」は、公式ページで行程表作成時間を従来の10分の1にできると訴求し、140社以上の導入実績を示しています。
ただし、これは同社サービスの紹介情報で、自社でも同じ削減率になると断定できる数字ではありません。見積の比較では、実データを使ったデモで自社の平均的な案件を一件再現し、導入前後のKPIを計測できる設計かを確認します。
行程管理システムの発注形態の選び方
業務が標準化されていて早く使い始めたいなら、クラウドSaaSか業界パッケージが候補です。既存システムを活かしつつ不足部分を埋めたいなら部分カスタムを、独自の販売・収益・運行ルールが競争力に直結するならスクラッチ開発を検討します。
選ぶときは、まず業務の差別化要因と変更の頻度を見ます。技術方式は、その結果を受けて決めます。
クラウドSaaS・業界パッケージと標準機能の合わせ方
クラウドSaaSや旅行業向けパッケージは、サーバーの構築やアップデートを自社で抱えずに始められる形態です。行程表、見積、手配、地図、顧客管理といった旅行業務の共通機能があらかじめ用意されていれば、要件定義と導入教育を短くできます。
複数拠点で同じ情報を共有したい会社や、専任のIT担当者が少ない会社に合いやすいです。一方で、独自帳票や特殊な料金計算、例外的な承認経路を大量に追加すると、パッケージの利点が薄れます。
標準機能で業務を変えられる部分、設定で対応する部分、追加開発が必要な部分を分け、追加開発の保守費用と将来のバージョンアップの影響も聞いてください。また、月額料金だけでなく、初期設定やデータ移行、解約時のデータ返却の費用も確認が必要です。アカウント追加、API利用、サポートの扱いも、契約前に聞いておきます。
部分カスタムとスクラッチ開発の対象の絞り方
部分カスタムは、既存の予約、会計、CRM、GPS、デジタコを残し、行程データを連携の中心にする方法です。最初のリリースは「行程登録・見積・手配状況・帳票出力」に絞り、会計連携や顧客向け通知は第二段階に回すと、投資と現場負担を抑えられます。発注時の仕様には、API連携の方式とデータの主システム、連携失敗時の再送方法、重複登録を防ぐルールを含めます。
スクラッチ開発は、既製品では表現しにくい要件がある場合に選びます。たとえば、複数法人の採算管理や独自の旅行商品、複雑な配車、安全監視、リアルタイム共有などが該当します。
費用と期間は大きくなりますが、要件定義書や画面・帳票仕様、テスト仕様書を納品物に含めると、将来の委託先変更に備えられます。さらに、ソースコードやデータベース定義、API仕様、運用手順書も、納品物として求めます。
RFPと要件整理で伝える内容
RFPは、開発会社に希望を伝える資料であると同時に、自社の業務を整理するための道具です。
細かな画面デザインを最初から固定するより、現状の流れや解決したい問題を共有したほうが、委託先から実現方法の違う提案を受け取れます。必要なデータや業務上の制約、成功指標も伝えます。
現状業務と課題の書き方
現状説明には、案件の受付から請求・精算までの業務フローを入れます。行程作成、見積、予約・手配は、一つの工程として並べます。
行程作成、見積、予約・手配のあとに続く工程は、3つあります。
- 変更：行程の変更を、誰がどのファイルに反映するか
- 顧客案内：変更後の行程を顧客へどう伝えるか
- 当日運行：添乗員や乗務員が当日に見る情報
各工程では、誰が、どのファイルや帳票に、何を入力し、誰が確認するかを示します。そのうえで、転記回数や締切、差し戻し、手配漏れ、情報が古くなるタイミングも記録してください。
たとえば、「行程変更に弱い」という課題は、次のように書けます。「ホテル変更を営業がメールで連絡し、手配担当が別のExcelを修正し、添乗員には前日の電話で伝えている。最新情報の確認に平均30分かかり、月に数回は古い帳票が残る」具体的な業務の場面があれば、開発会社は通知や履歴、承認、帳票が必要かどうかを判断しやすくなります。
機能要件の優先順位と利用シーン
機能要件は、必須、できれば必要、将来検討の3段階に分けて書きます。必須機能には、次の内容を含めます。
- 行程作成：日付・時刻・滞在時間・移動手段・休憩を含む行程、地図と経路
- 見積・手配：手配先・予約番号・回答期限、変更履歴
- 顧客情報：参加者情報、PDFやWebでの行程表出力
バス事業者であれば、配車や乗務員の割当、運行指示書、点呼、日報、位置情報の連携も候補になります。
機能名を並べるだけでなく、利用シーンも書き添えてください。
たとえば、「行程を編集できる」と書くより、「顧客から宿泊先変更を受けた担当者が、変更前後を確認し、見積と手配状況を更新し、権限を持つ添乗員へ最新の行程表を通知する」と書くほうが具体的です。
利用シーンがあれば、履歴や権限、通知、承認、再出力が必要かどうかを提案の段階で判断できます。
非機能要件と移行条件の確認
行程と参加者名簿をクラウドに置くなら、利用時間、障害時の復旧目標、バックアップ、アクセス権限、操作ログを、RFPに入れておきます。通信と保存データの暗号化、スマートフォン対応、データ出力、サポート窓口も対象です。
個人情報保護委員会の通則ガイドラインは、取得から削除・廃棄までの段階ごとに、取扱方法と責任者を定めることを示しています。アクセス制御などの技術的安全管理措置も挙げられています。そのため、行程管理システムでも、機能要件だけでなく運用ルールと委託先管理まで設計が必要です。
移行条件には、移す範囲を顧客、施設、交通ごとに記します。ほかに、次の対象も移す範囲を示します。
- 料金：移行する料金データの範囲
- 過去案件：移行する過去案件の範囲
- テンプレート：移行するテンプレートの範囲
- ユーザー権限：移行する権限設定の範囲
移行元のExcelが複数あり表記が揺れている場合は、名寄せを発注者側と委託先のどちらで行うかで費用が変わります。移行件数やデータ形式、欠損時の扱い、検証方法、リハーサルの回数を見積条件に含めると、後からの追加請求を抑えられます。
行程管理システムの契約形態の選び方
契約形態は、開発対象と責任範囲が明確か、要件が変わりやすいか、できあがったものをどう検収するかで選びます。
判断は契約書の名称だけでなく、工程ごとに行います。要件定義、設計、開発、テスト、移行、保守を、どの契約で委託するかを分けて確認してください。
法的な適否は個別事情で変わるため、重要な案件では弁護士や契約実務に詳しい専門家への確認も必要です。
準委任と請負の違いと責任範囲
要件が固まり、完成させるシステムと検収条件を明確にできる工程なら、完成を目的とする請負契約が候補になります。一方、要件定義や調査、アジャイル開発のように、専門家の作業や協議を積み上げる工程では、準委任契約が使われることがあります。
押さえておきたいのは、準委任なら納品物が不要になり、請負なら変更が無料になるわけではない点です。要件定義を準委任で行い、その結果をもとに開発を請負で発注する、または小さな機能単位で準委任の反復開発を行うなど、工程ごとに組み合わせる方法もあります。
契約書には、作業内容や納品物、検収方法、期限を明記してください。報告や再委託、障害対応、途中終了、データ返却も書いておきます。知的財産権、秘密保持、個人情報の取扱いも含めます。
追加変更とベンダーロックインへの契約上の備え
行程管理では、現場から「この帳票も欲しい」「この例外も自動化したい」といった要望が増えやすいものです。変更要求を受けたら、影響範囲や追加工数、費用、納期を双方で記録します。テスト範囲と既存機能への影響も書き添え、承認を得てから着手する手順を作ります。
発注時の見積に含まれる範囲と、別途請求になる範囲は、機能一覧に紐付けて示します。また、データをCSVや標準形式で出力できるか、データベースの構造やAPI仕様を開示できるかを確認します。ソースコードや設定情報の権利をどう扱うかも、契約で確かめます。
クラウドサービスなら、解約時のデータ返却形式や返却期限、削除証明、移行支援の料金を契約前に聞いておきます。初期費用の安さだけでなく、5年間の利用・保守・移行の総費用で比べることが大切です。
行程管理システムの費用相場と見積内訳
行程管理システムの専用製品は、利用人数や拠点数、機能によって価格が変わります。連携やデータ移行、サポートの内容でも差が出て、公開定価がないサービスも多いです。
ここで示すのは、NotebookLMのリサーチノート、2026年公開の業務システム相場、行程管理製品の機能範囲をもとにした目安です。
専用製品の一律料金ではないため、実際の予算はRFPを渡して個別見積を取得してください。
導入形態ごとの初期費用のレンジ
既存のクラウドSaaSの契約と初期設定は、機能が標準化されていれば、初期費用0〜50万円程度が一つの目安です。小規模な個別開発や部分カスタムは150〜500万円程度、中規模の業務システム開発は500〜1,500万円程度が目安になります。
行程や見積、顧客、手配、権限、帳票をまとめて作る場合は小規模側に、請求・会計連携や複数部署、データ移行まで含める場合は中規模側に近づきます。複数拠点の基幹連携や複雑な権限・監査を含む場合は、2,000〜5,000万円以上になる可能性があります。連携先に次のものを含む場合も、同じ範囲に入る可能性があります。
- 予約：既存システムとの連携
- 会計：既存システムとの連携
- CRM：既存システムとの連携
- GPS：既存システムとの連携
- 運行管理の統合：既存システムとの統合
全社基幹刷新のレベルでは、5,000万円から数億円まで幅があります。これらは機能と期間を前提にした推定レンジで、会社規模や技術者単価から特定の金額を断定するものではありません。出典は、NotebookLMのリサーチノートと、2026年公開の類似業務システムの費用情報です。
見積の工程別内訳と保守費用
見積書では、要件定義から開発、結合・総合テストまでを工程ごとに分けてください。データ移行や教育、リリース後の支援も分けて書いてもらいます。SaaSの場合は、月額利用料やユーザー追加、ストレージ、API従量課金、個別サポートを5年間の総額に含めてください。
ノートの整理では、工程配分の目安として、要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%、開発30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%程度が目安です。比率は案件によって変わりますが、要件定義やテストがほとんど計上されていない見積は、後で追加費用が発生しないか確認が必要です。
スクラッチ開発の保守は、初期開発費の年10〜20%程度を検討の目安にできます。たとえば初期開発費が3,000万円なら、年間300〜600万円程度になります。ただし、一般的な保守比率を当てはめた試算で、障害対応や機能改善、クラウド費、ライセンス、サポート時間を含むかどうかで変わります。
委託先の選び方と見積比較のポイント
委託先は、価格の安さや知名度だけでなく、旅行・観光業務への理解、行程変更や例外処理への対応、現場定着の支援力、連携とセキュリティの実装力で比較します。
提案書の見栄えよりも、自社の実際の案件を題材にして、どこまで標準機能で対応し、どこから追加開発になるかを説明できる会社を選びます。
業界知識と近い実績の確認
実績を聞くときは、「旅行会社向けの導入がありますか」と尋ねるだけに留めず、もう一歩踏み込みます。団体旅行や国内日帰り、宿泊、インバウンド、貸切バスなど、自社に近い業務の導入事例を尋ねます。そのうえで、行程表や見積、手配、原価、請求、運行管理のどこまで使われたかを確認します。
可能であれば、匿名化された画面や運用フロー、導入前後の作業時間、現場教育の期間も見せてもらいます。比較候補には、旅行業務やバス運行管理に接点のある実在企業があり、ナビタイムジャパン、ブロードリーフ、クレスコ・ジェイキューブのほか、次の企業が挙げられます。
- アゼスタ：比較候補の一社
- アジェンダ：比較候補の一社
- ティービーケー・システムズ：比較候補の一社
たとえばブロードリーフの公開導入事例には、行程表・見積作成が1件2時間から20分程度になった事例があります。これは個別企業の事例で、自社の効果を保証するものではありません。そのため、同じ条件で試算してもらうことが大切です。
同じ前提での見積比較
相見積もりは、同じRFPを渡し、利用人数や拠点数、移行件数、連携範囲をそろえて行います。見積比較表には、初期費用や月額費用、要件定義、追加開発、テスト、移行を分けて記載します。教育、保守、クラウド・ライセンスも、同じ表に並べます。ほかに、次の項目も比較表に含めます。
- 交通・地図API：利用料の扱いを分けて記載
- 消費税：税額の扱いを明示
安い会社には機能が欠けているのか、高い会社には過剰な要件があるのかを、分解して確認できます。特に注意したいのは、「別途相談」「実費」「要件確定後に提示」という項目です。曖昧な項目があれば、想定単価や上限、見積を出すタイミング、発注者が準備するデータ、追加になる条件を質問してください。
評価は、価格だけでなく、要件理解や提案の具体性、担当者の経験、体制、納期の現実性で点数化します。保守やデータ返却の扱いも点数に含めると、社内説明がしやすくなります。
セキュリティと委託先管理の質問項目
参加者名簿、連絡先、緊急連絡先、食事や配慮事項などを扱う場合、権限を役職・拠点・案件単位で設定できるかを確認します。誰がいつ何を変更したかが分かる操作ログや、退職者のアカウント停止、CSV出力の制御を確認します。バックアップの世代数や障害時の連絡経路、復旧目標、脆弱性対応をどこまで誰が受け持つかも、質問項目に入れてください。
貸切バスを扱う場合は、運送引受書、点呼記録、業務記録、運行指示書など、社内で保存・確認が必要な記録の出力方法と承認者を確かめます。国土交通省は、貸切バスの安全確保に関する制度やデジタル式運行記録計の資料を公開しています。
法令対応は行程システムだけで完結しないため、現場の運行管理者と所管官庁の最新情報を確認しながら要件に落とし込みます。
発注後の開発・導入を成功させる進め方
発注先を決めたあとも、開発会社に任せきりにせず、発注者側の業務責任者と現場代表をプロジェクトに参加させます。
行程管理は例外が多いため、実際の案件を使った確認と現場での試行を早く繰り返すほど、リリース後の手戻りを減らせます。
小さなパイロットでの実データ検証
パイロットは、一つの支店や担当チーム、商品種別などに絞って行います。最初から全社の全案件を移すより、小さく試すほうが確かめやすいです。
国内日帰りや宿泊、団体、貸切バスといった通常の案件に加え、行程変更、キャンセル、悪天候による代替案のような例外も、シナリオに含めてください。画面が動くかだけでなく、旧帳票と新しい行程表の差分や、見積と手配に反映されるかを確認します。権限の違う人に、どう見えるかも確かめておきます。
パイロット期間には、行程作成時間や見積作成時間、手配漏れ、変更の伝達時間、問い合わせ数、利用者が迷った箇所を記録します。改善しない場合、入力項目が多すぎる、マスタが古い、業務ルールが決まっていない、教育が不足しているといった原因も考えられます。結果をもとに、機能追加より運用整理を優先する判断も必要です。
リリース前の教育と運用ルールの整備
操作研修は、機能の説明会より、役割別の実習を重視します。営業が案件を登録し、手配担当が予約を更新し、管理者が承認し、添乗員が当日の最新情報を見る流れを練習します。
入力しないと次の工程に進めない項目、変更理由の書き方、キャンセル時の処理、緊急時の連絡方法を、運用マニュアルにまとめてください。リリース後は、問い合わせ窓口や障害と要望の分類、マスタ更新の担当、月次のKPI確認、権限の見直し、バックアップ確認を定例化します。
旅行業法については、観光庁が旅行業の登録制度や旅程管理主任者制度、関係法令・省令を公開しています。業務システムの設計では、制度改正を追う担当者を決め、法令の個別判断は所管官庁や専門家に確認します。
行程管理システムの発注・外注でよくある質問
発注前に寄せられることの多い疑問に、ここで答えておきます。費用や契約条件は個別案件で変わるため、目安をそのまま予算や法的判断に使わず、自社の業務範囲とRFPに照らして確認します。
行程管理システムの発注費用はいくらですか？
標準SaaSの初期設定なら0〜50万円程度、小規模な部分開発なら150〜500万円程度、中規模の業務システムなら500〜1,500万円程度が、機能範囲付きの目安です。複数拠点や会計・予約・GPS・運行管理を統合する場合は、2,000〜5,000万円以上になる可能性があります。
専用製品の公開定価を示すものではないため、利用者数や移行件数、連携数、保守範囲をそろえて、個別見積を取得してください。
RFPを作れない状態でも開発会社へ相談できますか？
相談はできます。現状の帳票や業務フロー、困っている場面、利用者、案件数、導入希望時期を準備しておけば、要件定義から支援する会社とも話を進められます。
複数社の提案と見積を公平に比べたい場合は、必須機能、対象範囲、成功KPI、移行データ、非機能要件だけでも先に整理しておきます。
SaaSと個別開発はどちらが行程管理に向いていますか？
標準的な行程表や見積、手配、顧客管理を早く始めたいなら、SaaSや業界パッケージが向いています。独自の料金計算や複雑な採算管理、複数法人の権限、既存基幹との固有連携が競争力に直結するなら、部分カスタムやスクラッチ開発が候補です。
まず標準製品で業務を試し、差別化に必要な部分だけを追加する段階導入も有効です。
委託先には何社へ見積を依頼すればよいですか？
比較可能な提案を得るには、業界パッケージに強い会社、個別開発に強い会社、連携やクラウド運用に強い会社など、得意領域の違う候補を3〜5社程度に絞る方法が現実的です。
候補の数を増やしすぎると、質問対応と評価に時間がかかります。そのため、RFPを渡す前に実績や対象業務、予算感、支援範囲を確かめ、自社に合う候補だけに依頼します。
まとめ：行程管理システムの発注に向けた業務と契約の整理
行程管理システムの発注では、まず旅行会社やバス会社、DMCなどの対象業務と利用者を切り分けます。そのうえで、行程表作成時間や手配漏れ、変更の伝達時間、見積作成時間などを、KPIとして決めます。
次に、SaaS・パッケージ・部分カスタム・スクラッチ開発の違いを比べ、標準機能で済ませる部分と自社固有の開発部分を分けます。
発注前のRFPと見積比較表の準備
RFPには、現状業務と課題、必須機能と将来機能を含めます。利用者やデータ移行、連携、セキュリティ、導入時期、成功指標も、必要な項目として書き入れます。
見積は初期費用だけでなく、要件定義やテスト、教育、保守まで含めて比べてください。クラウドやAPI、データ返却も、同じ前提でそろえます。
費用のレンジは、機能範囲付きの目安として扱い、特定の金額を先に決めつけないことが安全です。
現場を巻き込んだ段階的な導入
委託先を決めたあとは、実データに近い案件でパイロットを行い、現場の入力負担とKPIの変化を確認します。
運用ルールには、次の項目を落とし込みます。
- 個人情報：アクセス権限と変更履歴
- バックアップ：障害時の連絡
- 貸切バス：記録の保存
運用ルールが決まったら、教育とマスタ整備も含めてリリース計画を作ります。
機能数を増やすよりも、最新の行程情報が必要な人に確実に届く状態を先に作るほうが、外注を成功させる近道です。
行程管理システムは、行程表を作るためのツールにとどまらず、営業や手配、運行、顧客対応、請求をつなぐ業務基盤です。
自社の業務を言語化し、契約と費用の前提をそろえたうえで、実績と伴走体制のある委託先へ相談してください。
▼全体ガイドの記事
・行程管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。